idnits 2.17.1 draft-mohali-diversion-history-info-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 72 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([RFC4458], [RFC4244]), 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 == Line 421 has weird spacing: '...d where enc. ...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: ===================================================================== Hi-index Counter Mandatory parameter for--------------------The counter is set to "1". History-Info reflecting the chronological order of the information. ===================================================================== Privacy header [RFC3323]escaped in the Privacy hi-targeted-to-uri of the History-Info which precedes the one containing a diverting cause-param. Optional parameter for History-Info, this Privacy indicates that this specific History-Info header SHOULD not be forwarded. "history"----------------------------------"full" Privacy header field ----------------------"Off" Absent or "none" -- 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 (February 12, 2009) is 5524 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3969' is defined on line 858, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) -- Obsolete informational reference (is this intentional?): RFC 4244 (Obsoleted by RFC 7044) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 3 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 4 Intended status: Informational S. Norreys 5 Expires: August 16, 2009 British Telecom 6 J. Van Geel 7 Belgacom 8 M. Dolly 9 ATT 10 F. Silva 11 Portugal Telecom 12 G. Sciortino 13 C. Amenta 14 Italtel 15 C. Holmberg 16 Ericsson 17 February 12, 2009 19 Mapping and interworking of Diversion information Between Diversion and 20 History-Info Headers in the Session Initiation Protocol (SIP) 21 draft-mohali-diversion-history-info-02 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on August 16, 2009. 46 Copyright Notice 48 Copyright (c) 2009 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 Abstract 60 Diversion header is not standardized but widely used to convey 61 diverting information in Session Initiation Protocol (SIP) signaling. 62 This informational document proposes a way to make interwork call 63 diversion information contained in a Diversion header with a History- 64 Info header or with the Voicemail-URI which are standardized 65 solutions. In addition, an interworking policy is proposed to manage 66 the headers coexistence. 67 The History-Info header is described in [RFC4244] and the Voicemail 68 URI in [RFC4458]. 69 Since the Diversion header is used in many existing networks 70 implementations for transport of diversion informationand its 71 interworking with standardized solutions is not obvious, an 72 interworking recommendation is needed. 74 Requirements Language 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in [RFC2119]. 80 Table of Contents 82 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 83 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 84 1.2. Background . . . . . . . . . . . . . . . . . . . . . . . . 4 85 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 86 2.1. Interworking need . . . . . . . . . . . . . . . . . . . . 5 87 2.2. Interworking recommendations . . . . . . . . . . . . . . . 5 88 3. Headers syntaxes reminder . . . . . . . . . . . . . . . . . . 8 89 3.1. History-Info header syntax . . . . . . . . . . . . . . . . 8 90 3.2. Diversion header syntax . . . . . . . . . . . . . . . . . 9 91 4. Headers in SIP Method . . . . . . . . . . . . . . . . . . . . 10 92 5. Diversion header to History-Info header . . . . . . . . . . . 11 93 6. History-Info header to Diversion header . . . . . . . . . . . 14 94 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 95 7.1. Example with Diversion header changed into 96 History-Info header . . . . . . . . . . . . . . . . . . . 16 97 7.2. Example with History-Info header changed into 98 Diversion header . . . . . . . . . . . . . . . . . . . . . 16 99 7.3. Example with two SIP networks using History-Info 100 header interworking with a SIP network using Diversion 101 header . . . . . . . . . . . . . . . . . . . . . . . . . . 16 102 7.4. Interworking between Diversion header and Voicemail URI . 18 103 7.5. Additional interworking Cases . . . . . . . . . . . . . . 19 104 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 105 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 106 10. Acknowlegements . . . . . . . . . . . . . . . . . . . . . . . 20 107 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 108 11.1. Normative References . . . . . . . . . . . . . . . . . . . 21 109 11.2. Informative References . . . . . . . . . . . . . . . . . . 21 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 111 Intellectual Property and Copyright Statements . . . . . . . . . . 23 113 1. Introduction 115 1.1. Overview 117 For some network services (eg. Voicemail, IVR or automatic call 118 distribution), it is necessary for the called SIP user agent to 119 identify from whom and why the session was diverted. In order to be 120 used by various service providers or applications, redirection 121 information needs to pass through the network. 122 This is possible with two different SIP headers: History-Info 123 header[RFC4244] and Diversion header which are both able to transport 124 diversion information in SIP signaling. Because of the current 125 wildely use of Diversion header even if it is not a standard, it is 126 necessary to have a guideline to make this header interwork with 127 History-Info header. 128 This document provides a mechanism of translation between the 129 Diversion header and the History-Info header and between the 130 Diversion header and the Voicemail URI. 132 1.2. Background 134 The History-Info header [RFC4244] and a the URI extension (including 135 Voicemail URI)[RFC4458] are recommended by IETF to convey redirection 136 information. They are also recommended in the "Communication 137 Diversion (CDIV) service" 3GPP specification[TS_24.604]. 139 At first, the Diversion header was described in 140 [draft-levy-sip-diversion-08], which is today discarded. This header 141 contains the list of the diverting user(s) with associated 142 information and the expired draft could explain why many 143 implementations are based on this header. It has been chosen to 144 standardized the History-Info header because it could transport 145 "request history" information which allows the receiving application 146 to determine hints about how and why the session arrived at the 147 application/user. As History-Info header information is larger than 148 call diversion information, it is realy important to be sure of not 149 loosing information and be able to extract the good data with help of 150 the retargeting cause described in [RFC4458] for the transport of the 151 diversion reason. 153 Those headers have different syntaxes described below. Note that the 154 main difference is that the History-Info header is a chronological 155 writing header whereas the Diversion header is the opposite (i.e. the 156 first diversion entry read correspond to the last diverting user). 158 2. Problem Statement 160 2.1. Interworking need 162 The Diversion header is used for recording communication diversion 163 information which could be useful to downstream network entities. 164 Today, this SIP header is implemented by several manufacturers and 165 deployed in several networks. 167 The History-Info header is standardized, among other needs, for the 168 transportation of diversion information. 170 As both are answering to call forwarding needs, according to the one 171 created or completed in one side and the one interpreted in the other 172 side, diverting information could be mixed-up if they are both 173 present in the INVITE request. So, Diversion and History-Info 174 headers MUST NOT independently coexist for the session signalling. 176 For the transportation of consistent diversion information 177 downstream, it is necessary to make the two headers interwork. 178 Interworking between the Diversion header and the History-Info header 179 is presented in sections 5 and 6. As the interworking is not obvious 180 and the coexistence not easy according the use cases, is it proposed 181 a policy to manage the headers interaction. 183 In addition, Voicemail URI proposes an other way to convey diversion 184 information in the R-URI. So, it is also necessary to describe the 185 interworking between Diversion header and a Voicemail URI. This 186 interworking is presented in section 7.4. 188 2.2. Interworking recommendations 190 History-Info header is a standardized solution, so a network using 191 the Diversion header MUST be able to provide information at the good 192 format to a network using the History-Info header. In this case, to 193 avoid both headers coexistence it is recommended as often as possible 194 to replace the Diversion header per the History-Info header in the 195 INVITE request during the interworking. 196 For some specific interworking situations (see section 7.5), it could 197 be needed to create a Diversion header from a received History-Info 198 header. Since, the History-Info header has a boarder scope than the 199 Diversion header and could be used for other services than call 200 diversion ; in addition to trace call diversion information, it is 201 acting as a session history and could store all successive R-URI 202 values. So, even if it should be better to remove the History-Info 203 header after the Diversion header has been created to avoid 204 confusion; if the History-Info header contains supplementary 205 information it MUST be remained and passed transparently in this 206 network. 207 These are the more simple interworking situations where a header is 208 created from the other one. More interworking cases, like situation 209 where persistence of both headers is needed, are described in section 210 7.5. 211 If some information could be lost and use downstream or according the 212 header used per network elements, it is necessary to have a local 213 policy to find the best way to keep information up to the terminating 214 user agent. 216 SIP network/terminal using Diversion to SIP network/terminal using 217 History-Info header: 219 When the Diversion header is used to create a History-Info header, 220 the Diversion header MUST be removed in the outgoing INVITE. It is 221 considered that all information present in the Diversion header is 222 transferred in the History-Info header. 224 If a History-Info header is present in the incoming INVITE (in 225 addition to Diversion header), the Diversion header and History-Info 226 header present MUST be mixed and only the diversion information not 227 yet present in the History-Info header MUST be inserted as a last 228 entry (more recent) in the existing History-Info header as 229 recommended in [RFC4244]. 230 As an example, this could be the case of an INVITE coming from a 231 network_2 using Diversion header but before passed through a 232 network_1 using History-Info header (or the network_2 uses History- 233 Info header to transport successive URI information) and going to a 234 network_3 using History-Info header. 236 IWF* IWF* 237 network1 | network_2 |network_3 238 History-Info | Diversion |using 239 | |Hist-Info 240 | | 241 UA A P1 AS B | P2 AS C UA C AS D | UA E 242 | | | | | | | | | | 243 |INVITE | | | | | | | | | 244 |------>| | | | | | | | | 245 | | | | | | | | | | 246 | |INVITE | | | | | | | | 247 | |------>| | | | | | | | 248 | |Supported: histinfo | | | | | | 249 | | History-Info: | | | | | | 250 | | ; index=1, | | | | | 251 | | ; index=1.1 | | | | | 252 | | | | | | | | | | 253 | | |INVITE | | | | | | | 254 | | |------>| | | | | | | 255 | | |History-Info: | | | | | | 256 | | |; index=1,| | | | | 257 | | |; index=1.1 | | | | | 258 | | |; cause=302; index=1.1.1 | | | 259 In this case, the incoming INVITE contains a Diversion header and a 260 History-Info header. So that, it is necessary to create, for 261 network_3, a single History-Info header gathering existing 262 information in the History-Info header received and those present in 263 the Diversion header. Then network_3 could use call forwarding 264 information that are present in a single header and add its own 265 diversion information if necessary. 267 Note: if a network is not able either to use only one header each 268 time, or to maintain both headers up to date, the chronological order 269 could not be certified. 270 Note: it is not possible to have only Diversion header when the 271 History-Info header contains more than call diversion information. 272 If previous policy recommendations are applied, the chronological 273 order is respected as Diversion entries are inserted at the end of 274 the History-Info header taking into account the Diversion internal 275 chronology. 277 SIP network/terminal using History-Info header to SIP network/ 278 terminal using Diversion header: 280 When the History-Info header is interpreted to create a Diversion 281 header, some precautions MUST be taken. 282 If the History-Info header contains only communication diversion 283 information, then it MUST be suppressed after the interworking. 285 If the History-Info header contains other information, then only the 286 information of concern to the diverting user MUST be used to create 287 entries in the Diversion header and the History-Info header MUST be 288 kept as received in the INVITE forwarded downstream. 290 Note: The History-Info header could be used for other reasons than 291 CDIV services, for example by a service which need to know if a 292 specific AS had yet been invoked in the signalling path. If the call 293 is after forwarded to a network using History-Info header, it would 294 be better to not loose history information due to passing though the 295 network which only support Diversion header. A recommended solution 296 MUST NOT disrupt the standard behaviour and networks which not 297 implement History-Info header MUST be transparent to an incoming 298 History-Info header. 300 If a Diversion header is already present in the incoming INVITE (in 301 addition to History-Info header), only diversion information present 302 in the History-Info header but not in the Diversion header MUST be 303 inserted from the last entry (more recent) into the existing 304 Diversion header as recommended in the Diversion draft 305 [draft-levy-sip-diversion-08]. Note that the chronological order 306 could not be certified. If previous policy recommendations are 307 respected, this case SHOULD NOT happen. 309 Forking case: 310 The History-Info header enables the recording of sequential forking 311 for the same served-user. During a interworking from the History- 312 Info header to Diversion header, the History-Info entries containing 313 a forking situation (with an incremented "index" parameter) could be 314 either mapped for each entry with a call forwarding "cause" 315 parameter, the interworking entity could choose to create only one 316 Diversion entry or to not apply the interworking. The choice could 317 be done according a local policy. 319 The same logic is applied for an interworking with Voicemail URI (see 320 section 7.4). 322 3. Headers syntaxes reminder 324 3.1. History-Info header syntax 326 History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry) 327 hi-entry = hi-targeted-to-uri *( SEMI hi-param ) 328 hi-targeted-to-uri= name-addr 329 hi-param = hi-index / hi-extension 330 hi-index = "index" EQUAL 1*DIGIT *(DOT 1*DIGIT) 331 hi-extension = generic-param 333 The History-Info header is specified in [RFC4244]. Amongst the 334 information contained in the header list is the diversion information 335 with a specific cause code mentioning the diversion reason. These 336 optional cause codes are defined in [RFC4458]. The RFC4244 contains 337 a Privacy section introducing the use of Privacy header defined in 338 [RFC3323] for diversion information. The top-most History-Info entry 339 (first in the list) corresponds to the oldest history information. 340 A diverting user information is identifiable by the History-Info 341 entry containing a cause-param with cause value as listed in 342 [RFC4458] and by the entry just before. The last diversion target is 343 identifiable by the last History-Info entries containing a cause- 344 param with cause value as listed in RFC 4458. 345 The cause-param is inserted in the hi-targeted-to-uri of the address 346 were the communication is diverted to. The index parameter is a 347 string of digits, separated by dots to indicate the number of forward 348 hops and retargets. 349 Note: A history entry could contain the "gr" parameter. Regardless 350 the rules concerning "gr" parameter define in which must be applied, 351 this parameter has no impact on the mapping and must only be copied 352 with the served user address. [TS_24.604] 354 Example: 356 History-Info: 357 ;index=1, 358 ;index=1.1, 359 ; index=1.1.1, 361 Policy concerning "histinfo" option tag in Supported header: 362 According to [RFC4244], a proxy that receives a Request with the 363 "histinfo" option tag in the Supported header should return captured 364 History-Info in subsequent, provisional and final responses to the 365 Request. The behaviour depend whether the local policy support the 366 capture of History-Info or not. 368 3.2. Diversion header syntax 370 The current document is not written to define again the Diversion 371 header and its use but to be shure that the syntax is interpreted in 372 the same way by everyone. So that, the Diversion syntax is here a 373 little changed to correspond to the current ABNF[RFC4234]: 375 Diversion = "Diversion" HCOLON diversion-params *(COMMA diversion- 376 params) 377 diversion-params = name-addr *(SEMI (diversion-reason / diversion- 378 counter / diversion-limit / diversion-privacy / diversion-screen / 379 diversion-extension)) 380 diversion-reason = "reason" EQUAL ("unknown" / "user-busy" / "no- 381 answer" / "unavailable" / "unconditional" / "time-of-day" / "do-not- 382 disturb" / "deflection" / "follow-me" / "out-of-service" / "away" / 383 token / quoted-string) 384 diversion-counter = "counter" EQUAL 1*2DIGIT 385 diversion-limit = "limit" EQUAL 1*2DIGIT 386 diversion-privacy = "privacy" EQUAL ("full" / "name" / "uri" / "off" 387 / token / quoted-string) 388 diversion-screen = "screen" EQUAL ("yes" / "no" / token / quoted- 389 string) 390 diversion-extension = token [EQUAL (token / quoted-string)] 392 Note: The Diversion header could be used in the comma-separated 393 format as described below and in a header-separated format. Both 394 formats could be combined a received INVITE as RECOMMENDED in 395 [RFC3261]. 397 Example: 399 Diversion: 400 diverting_user2_addr; reason="user-busy"; counter=1; privacy=full, 401 diverting_user1_addr; reason="unconditional"; counter=1; privacy=off 403 4. Headers in SIP Method 405 You can find here a reminder of History-Info header field and 406 Diversion header field in relation to methods. As those headers do 407 not have the same capabilities, it is necessary to clarify the 408 interworking. 410 Use of History-Info header field: 412 Header field where proxy ACK BYE CAN INV OPT REG MSG 413 ------------ ----- ----- --- --- --- --- --- --- --- 414 History-Info amdr - - - o o o o 415 SUB NOT REF INF UPD PRA PUB 416 --- --- --- --- --- --- --- 417 History-Info amdr o o o - - - o 419 Use of Diversion header field: 421 Header field where enc. e-e ACK BYE CAN INV OPT REG 422 ------------ ----- ----- --- --- --- --- --- --- --- 423 Diversion R h - - - o - - 424 Diversion 3xx h - - - o - - 426 The recommended interworking presented in this document SHOULD apply 427 only for INVITE requests. 429 In 3xx responses, both headers could be present. 430 When a proxy wants to interwork with a network supporting the other 431 header field, it SHOULD apply the interworking between Diversion 432 header and History-Info header in the 3xx response. 433 When a recursing proxy redirects an initial INVITE after receiving a 434 3xx response, it SHOULD add as a last entry either a Diversion header 435 or History-Info header (according to its capabilities) in the 436 forwarded INVITE. Local policies could apply to send the received 437 header in the next INVITE or not. 439 Other messages where History-Info could be present are not used for 440 the Call Forwarding service and SHOULD NOT be changed into Diversion 441 header. The destination network MUST be transparent the received 442 History-Info header. 443 Note : the following mapping is inspired from the ISUP to SIP 444 interworking described in. [TS_29.163] 446 5. Diversion header to History-Info header 448 The following text is valid only if no History-Info is present in the 449 INVITE request. If at least one History-Info header is present, the 450 interworking function shall adapt its behaviour to respect the 451 chronological order. See section 2.2. 452 For N Diversion entries N+1 History-Info entries MUST be created. To 453 create the History-Info entries in the same order than during a 454 session establishment, the Diversion entries MUST be mapped from the 455 bottom-most until the top-most. Each Diversion entry shall be mapped 456 into a History-Info entry. An additional (the last one) History-Info 457 entry must be created wiht the diverted-to party address presents in 458 the R-URI of the received INVITE, The mapping is described below. 460 The first entry created in the History-Info header contains: 462 - a hi-target-to-uri with the name-addr parameter of the bottom- 463 most Diversion header 465 - if a privacy parameter is present in the bottom-most Diversion 466 entry, then a Privacy header could be escaped in the History-Info 467 header as described bellow, 469 - an index set to 1. 471 For each following Diversion entry (from bottom to top), the History- 472 info entries are created as following (from top to bottom): 474 Source Destination 475 Diversion header component: History-Info header component: 476 ======================================================================= 477 Name-addr Hi-target-to-uri 479 ======================================================================= 480 Reason of the previous cause-param 481 Diversion entry 482 "unknown"---------------------------------404 483 "unconditional"---------------------------302 484 "user-busy"-------------------------------486 485 "no-answer"-------------------------------408 486 "deflection "-----------------------------480 or 487 487 "unavailable"-----------------------------404 488 "time-of-day"-----------------------------404 (default) or 302 489 "do-not-disturb"--------------------------404 (default) or 302 490 "follow-me"-------------------------------404 (default) or 302 491 "out-of-service"--------------------------404 (default) 492 "away"------------------------------------404 (default) or 302 494 ======================================================================= 495 Counter Hi-index 496 "1" or parameter -------------------------The previous created index 497 no present is incremented with ".1" 498 Superior to "1" --------------------------Create N-1 placeholder History 499 (i.e. N) entry with the previous index 500 incremented with ".1" 501 Then the History-Info header 502 created with the Diversion 503 entry with the previous index 504 incremented with ".1" 505 ======================================================================= 506 Privacy Privacy header escaped in the 507 hi-targeted-to-uri 508 "full"------------------------------------"history" 509 "Off"-------------------------------------Privacy header field 510 absent or "none" 511 "name"------------------------------------"history" 512 "uri"-------------------------------------"history" 513 ======================================================================= 515 A last History-Info entry is created and contains: 517 - a hi-target-to-uri with the Request-URI of the INVITE request. 519 - a cause-param from the top-most Diversion entry, mapped from the 520 diversion-reason as described above. 522 - if a privacy parameter is present in the top-most Diversion 523 entry, then a Privacy header could be escaped in the History-Info 524 header as described above, 526 - an index set to the previous created index and incremented with 527 ".1" 529 Note: For other optional Diversion parameters, there is no 530 recommendation. 532 Note: For values of the "reason" parameter which are mapped with a 533 recommended default value, it could also be possible to choose an 534 other value or to omit the parameter. 536 Note : The Diversion header could contain a Tel:URI in the name-addr 537 parameter but it seems to not be possible to have a Tel:URI in the 538 History-Info header. RFC3261 gives an indication as to the mapping 539 between sip: and tel: URIs but in this particular case it is 540 difficult to assign a valid hostport as the diversion has occurred in 541 a previous network and a valid hostport is difficult to determine. 542 So, it is suggested that in case of Tel:URI in the Diversion header, 543 the History-Info header should be created with a SIP URI with 544 user=phone. 546 Note: The Diversion header allows the carrying of a counter which had 547 retained the information about the number of redirections which have 548 occurred. History-Info does not have an equivalent because to trace 549 and count diversion occurred it is necessary to count cause parameter 550 containing a value associated to a call diversion. To read the index 551 value is not enough. With the use of the "placeholder" entry the 552 History-info header entries could reflect the real number of 553 diversion occurred. Example of placeholder entry in the History-Info 554 header: ;index=1.1 For a 555 placeholder History entry the value "404" shall be taken. 557 Concerning local policies recommendations about headers coexistence 558 in the INVITE request, see sections 2.2 and 7.5. 560 6. History-Info header to Diversion header 562 To create the Diversion entries in the same order than during a 563 session establishment, the History-Info entries MUST be mapped from 564 the top-most until the bottom-most. The first History-Info header 565 entry selected will be mapped into the last Diversion header entry 566 and so on. One Diversion header entry MUST be created for each 567 History-Info entry with a cause-param reflecting a diverting reason 568 as listed in the [RFC4458]. 570 In this case, the History-Info header MUST be mapped into the 571 Diversion header as following: 573 Source Destination 574 History-Info header component: Diversion header component: 575 ===================================================================== 576 Hi-target-to-uri of the Name-addr 577 History-Info which precedes the one 578 containing a diverting cause-param 580 ===================================================================== 581 Cause-param Reason 582 404---------------------------------------"unknown" 583 302---------------------------------------"unconditional" 584 486---------------------------------------"user-busy" 585 408---------------------------------------"no-answer" 586 480 or 487--------------------------------"deflection " 587 503---------------------------------------"unavailable" 589 ===================================================================== 590 Hi-index Counter 591 Mandatory parameter for--------------------The counter is set to "1". 592 History-Info reflecting 593 the chronological order 594 of the information. 595 ===================================================================== 596 Privacy header [RFC3323]escaped in the Privacy 597 hi-targeted-to-uri of the 598 History-Info which precedes the one 599 containing a diverting cause-param. 600 Optional parameter for History-Info, 601 this Privacy indicates that this 602 specific History-Info header SHOULD 603 not be forwarded. 604 "history"----------------------------------"full" 605 Privacy header field ----------------------"Off" 606 Absent or "none" 608 ===================================================================== 610 Concerning local policies recommendations about headers coexistence 611 in the INVITE request, see section 2.2. 613 7. Examples 615 7.1. Example with Diversion header changed into History-Info header 617 INVITE last_diverting_target 618 Diversion: 619 diverting_user3_address;reason=unconditional;counter=1;privacy=off, 620 diverting_user2_address;reason=user-busy;counter=1;privacy=full, 621 diverting_user1_address;reason=no-answer;counter=1;privacy=off 623 Mapped into: 625 History-Info: 626 ; index=1, 627 ;index=1.1, 628 ;index=1.1.1, 629 ;index=1.1.1.1, 631 7.2. Example with History-Info header changed into Diversion header 633 History-Info: 634 ; index=1, 635 ;index=1.1, 636 ;index=1.1.1 638 Mapped into: 640 Diversion: 641 diverting_user2_address; reason=user-busy; counter=1; privacy=off, 642 diverting_user1_address; reason=unconditional; counter=1; 643 privacy=full 645 7.3. Example with two SIP networks using History-Info header 646 interworking with a SIP network using Diversion header 648 A -> P1 -> B -> C -> P2 -> D-> E 649 A, B, C, D and E are users. 650 B, C and D have Call Forwarding service invoked. 651 P1 and P2 are proxies. 652 Only relevant information is shown on the following call flow. 654 IWF* IWF* 655 SIP network using | SIP network using |SIP net. 656 History-Info | Diversion |using 657 | |Hist-Info 658 | | 660 UA A P1 AS B | P2 AS C UA C AS D | UA E 661 | | | | | | | | | | 662 |INVITE | | | | | | | | | 663 |------>| | | | | | | | | 664 | | | | | | | | | | 665 | |INVITE | | | | | | | | 666 | |------>| | | | | | | | 667 | |Supported: histinfo | | | | | | 668 | | History-Info: | | | | | | 669 | | ; index=1, | | | | | 670 | | ; index=1.1 | | | | | 671 | | | | | | | | | | 672 | | |INVITE | | | | | | | 673 | | |------>| | | | | | | 674 | | |History-Info: | | | | | | 675 | | |; index=1,| | | | | 676 | | |; index=1.1 | | | | | 677 | | |; index=1.1.1 | | | 678 | | | | | | | | | | 679 | | | |INVITE | | | | | | 680 | | | |------>| | | | | | 681 | | | |Diversion: | | | | | 682 | | | |B reason= unconditional counter=1 | | 683 | | | |History-Info: | | | | | 684 | | | |; index=1,| | | | 685 | | | |; index=1.1 | | | | 686 | | | |; cause=302; index=1.1.1| | 687 | | | | | | | | | | 688 | | | | |INVITE | | | | | 689 | | | | |------>| | | | | 690 | | | | |No modification of Diversion due to P2| 691 | | | | | | | | | | 692 | | | | | |INVITE | | | | 693 | | | | | |------>| | | | 694 | | | | | | | | | | 695 | | | | | |<--180-| | | | 696 | | | | | | | | | | 697 | | | | | No response timer expire | | 698 | | | | | |---INVITE--->| | | 699 | | | Diversion: | | | 700 | | | userC; reason=no-answer; counter=1; privacy=full, 701 | | | userB; reason=unconditional; counter=1; privacy=off, 702 | | | History-Info: | | | 703 | | | ; index=1, | | | 704 | | | ; index=1.1 | | | 705 | | | ; index=1.1.1 | | 706 | | | | | | | | | | 707 | | | | | | | |INVITE | | 708 | | | | | | | |------>| | 709 | | | Diversion: | | 710 | | | userD; reason=time-of-day; counter=1; privacy=off| 711 | | | userC; reason=no-answer; counter=1; privacy=full,| 712 | | | userB; reason=unconditional; counter=1; privacy=off, 713 | | | History-Info: | | 714 | | | ; index=1, | | 715 | | | ; index=1.1 | | 716 | | | ; index=1.1.1 | | 717 | | | | | | | | | | 718 | | | | | | | | | INVITE | 719 | | | | | | | | |------->| 720 | | | History-Info: | 721 | | | ; index=1, | 722 | | | ; index=1.1? privacy=none, | 723 | | | ; index=1.1.1, | 724 | | | ; index=1.1.1.1, | 725 | | | ; index=1.1.1.1.1, 726 | | | ; index=1.1.1.1.1.1 | 727 | | | | | | | | | | 728 | | | | | | | | | | 730 * Note: The IWF is an interworking function which could be a stand-alone 731 equipment not defined in this draft (it could be a proxy). 733 7.4. Interworking between Diversion header and Voicemail URI 735 Voicemail URI is a mechanism described in RFC4458 to provide a simple 736 way to transport only one redirecting user address and the reason why 737 the diversion occurred in the R-URI of the INVITE request. This 738 mechanism is mainly used for call diversion to a voicemail. 740 Diversion header to Voicemail URI: 742 Received: 743 Diversion: userA-address;reason=user-busy;counter=1;privacy=full 745 Sent (Voicemail URI created in the R-URI line of the INVITE): 746 sip: voicemail@example.com;target=userA-address;cause=486 SIP/2.0 748 Mapping of the Redirection Reason is the same as for History-Info 749 header with a default value set to 404. 750 If the Diversion header contains more than one Diversion entry, the 751 choice of the redirecting user information inserted in the URI is in 752 charge of the network local policy. For example, the choice 753 criterion of the redirecting information inserted in the URI could be 754 the destination of forwarded INVITE request (if the voicemail serves 755 this user or not). 757 Note: This interworking could be done in addition to the interworking 758 of the Diversion header into the History-Info header. 760 Voicemail URI to Diversion header: 761 In case of real Voicemail, this way of interworking should not 762 happen. However, if for any reason it occurs, it is recommended to 763 do it as following: 765 Received: 766 INVITE sip: voicemail@example.com;\ 767 target=sip:+33145454500%40example.com;user=phone;\ 768 cause=302 SIP/2.0 770 Sent in the forwarded INVITE: 771 Diversion: sip:+ 772 33145454500%40example.com;user=phone;reason=unconditional;counter=1 774 7.5. Additional interworking Cases 776 Even if for particular cases in which both headers could coexist it 777 should be the network local policy responsibility to make it work 778 together, here are described some situations and some recommendations 779 on the behaviour to follow. 781 In the case where there is one network which includes different 782 nodes, some of which support Diversion header and some which support 783 History-info header, the problem is when any node handling a message 784 does not know which node will next handle the message. This case can 785 occur when the network has new and old nodes, the older ones using 786 Diversion header and the more recent History-Info header. 787 While a network replacement may be occurring there will be a time 788 when both nodes exist in the network. If the different nodes are 789 being used to support different subscriber types due to different 790 node capabilities then the problem is more important. In this case 791 there is a need to pass both History-Info header and Diversion header 792 within the network core. 793 These headers need to be equivalent to ensure that whatever node 794 receives the message the correct diversion information is received. 795 This requires that whichever header is received there is a 796 requirement to be able to compare the headers and to convert the 797 headers. Depending upon node capability then it may be possible to 798 make assumptions as to how this is handled. 799 If it is known that the older Diversion header supporting nodes do 800 not pass on any received History-Info header then the interworking 801 becomes easier. If a message is received with only Diversion headers 802 then it has originated from an 'old' node. The equivalent History- 803 Info entries can be created and these can then be passed as well as 804 the Diversion header. 805 If the node creates a new History-Info header for a call diversion, 806 then an additional Diversion header must be created. 807 If the next node is an 'old' node then the Diversion header will be 808 used by that node and the History-Info entries will be removed from 809 the message when it is passed on. 810 If the next node is a new node then the presence of both Diversion 811 header and History-Info header means that interworking has already 812 occurred and the Diversion and History-Info entries must be 813 considered equivalent. 814 If both nodes pass on both History-Info header and Diversion header 815 but only actively use one, then both types of node need to perform 816 the interworking and must maintain equivalence between the headers. 817 This will eventually result in the use of Diversion header being 818 deprecated when all nodes in the network support History-Info header. 820 8. IANA Considerations 822 This document makes no request of IANA. 824 9. Security Considerations 826 The use of Diversion header or History-Info header require to apply 827 the requested privacy and integrity asked by each diverting user or 828 entity. Without integrity, the requested privacy functions could be 829 downgraded or eliminated, potentially exposing identity information. 830 Without confidentiality, eavesdroppers on the network (or any 831 intermediaries between the user and the privacy service) could see 832 the very personal information that the user has asked the privacy 833 service to obscure. Unauthorised insertion, deletion of modification 834 of those headers can provide misleading information to users and 835 applications. A SIP entity that can provide a redirection reason in 836 a History-Info header or Diversion header SHOULD be able to suppress 837 this in accordance with privacy requirements of the user concerned. 839 10. Acknowlegements 841 The editors would like to acknowledge the constructive feedback 842 provided by Ian Elz, Jean-Francois Mule, Lionel Morand, Xavier 843 Marjou, Philippe Fouquart, Mary Barnes, Francois Audet, Erick Sasaki 844 and Shida Schubert. 846 11. References 848 11.1. Normative References 850 [RFC2119] "Key words for use in RFCs to Indicate Requirement 851 Levels", RFC 2119, March 1997. 853 [RFC3261] "SIP: Session Initiation Protocol", RFC 3261, June 2002. 855 [RFC3323] "A Privacy Mechanism for the Session Initiation Protocol 856 (SIP)", RFC 3323, November 2002. 858 [RFC3969] "The Internet Assigned Number Authority (IANA) Uniform 859 Resource Identifier (URI) Parameter Registry for the 860 Session Initiation Protocol (SIP), BCP 99", RFC 3969, 861 December 2004. 863 [RFC4234] "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, 864 October 2005. 866 11.2. Informative References 868 [RFC4244] "An Extension to the Session Initiation Protocol (SIP) for 869 Request History Information", RFC 4244, November 2005. 871 [RFC4458] "Session Initiation Protocol (SIP) URIs for Applications 872 such as Voicemail and Interactive Voice Response (IVR)", 873 RFC 4458, April 2006. 875 [TS_24.604] 876 3rd Generation Partnership Project, "Technical 877 Specification Group Core Network and Terminals ; 878 Communication Diversion (CDIV) using IP Multimedia 879 (IM)Core Network (CN) subsystem ; Protocol specification 880 (Release 8), 3GPP TS 24.604", December 2008. 882 [TS_29.163] 883 3rd Generation Partnership Project, "Technical 884 Specification Group Core Network and Terminals ; 885 Interworking between the IP Multimedia (IM) Core Network 886 (CN) Subsystem and Circuit Switched (CS) networks (Release 887 8)", December 2008. 889 [draft-levy-sip-diversion-08] 890 "Diversion Indication in SIP, 891 draft-levy-sip-diversion-08", August 2004. 893 Authors' Addresses 895 Marianne Mohali 896 France Telecom 897 38-40 rue du General Leclerc 898 Issy-Les-Moulineaux Cedex 9 92794 899 France 901 Phone: +33 1 45 29 45 14 902 Email: marianne.mohali@orange-ftgroup.com 904 Steve Norreys 905 British Telecom 907 Jan Van Geel 908 Belgacom 910 Martin Dolly 911 ATT 913 Francisco Silva 914 Portugal Telecom 916 Guiseppe Sciortino 917 Italtel 919 Cinzia Amenta 920 Italtel 922 Christer Holmberg 923 Ericsson