idnits 2.17.1 draft-mohali-diversion-history-info-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 28. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 919. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 930. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 937. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 943. 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 Copyright Line does not match the current year == Line 409 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 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 (November 1, 2008) is 5654 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3969' is defined on line 835, 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: 4 errors (**), 0 flaws (~~), 4 warnings (==), 8 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: May 5, 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 November 1, 2008 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-01 23 Status of this Memo 25 By submitting this Internet-Draft, each author represents that any 26 applicable patent or other IPR claims of which he or she is aware 27 have been or will be disclosed, and any of which he or she becomes 28 aware will be disclosed, in accordance with Section 6 of BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 This Internet-Draft will expire on May 5, 2009. 48 Abstract 50 Diversion header is not standardized but widely used to convey 51 diverting information in Session Initiation Protocol (SIP) signaling. 52 This informational document proposes a way to make interwork call 53 diversion information contained in a Diversion header with a History- 54 Info header or with the Voicemail-URI which are standardized 55 solutions. In addition, an interworking policy is proposed to manage 56 the headers coexistence. 57 The History-Info header is described in [RFC4244] and the Voicemail 58 URI in [RFC4458]. 59 Since the Diversion header is used in many existing networks 60 implementations for transport of diversion informationand its 61 interworking with standardized solutions is not obvious, an 62 interworking recommendation is needed. 64 Requirements Language 66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 67 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 68 document are to be interpreted as described in [RFC2119]. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 1.2. Background . . . . . . . . . . . . . . . . . . . . . . . . 4 75 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 76 2.1. Interworking need . . . . . . . . . . . . . . . . . . . . 5 77 2.2. Interworking recommendations . . . . . . . . . . . . . . . 5 78 3. Headers syntaxes reminder . . . . . . . . . . . . . . . . . . 8 79 3.1. History-Info header syntax . . . . . . . . . . . . . . . . 8 80 3.2. Diversion header syntax . . . . . . . . . . . . . . . . . 9 81 4. Headers in SIP Method . . . . . . . . . . . . . . . . . . . . 10 82 5. Diversion header to History-Info header . . . . . . . . . . . 11 83 6. History-Info header to Diversion header . . . . . . . . . . . 14 84 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 85 7.1. Example with Diversion header changed into 86 History-Info header . . . . . . . . . . . . . . . . . . . 16 87 7.2. Example with History-Info header changed into 88 Diversion header . . . . . . . . . . . . . . . . . . . . . 16 89 7.3. Example with two SIP networks using History-Info 90 header interworking with a SIP network using Diversion 91 header . . . . . . . . . . . . . . . . . . . . . . . . . . 16 92 7.4. Interworking between Diversion header and Voicemail URI . 18 93 7.5. Additional interworking Cases . . . . . . . . . . . . . . 19 94 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 95 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 96 10. Acknowlegements . . . . . . . . . . . . . . . . . . . . . . . 20 97 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 98 11.1. Normative References . . . . . . . . . . . . . . . . . . . 21 99 11.2. Informative References . . . . . . . . . . . . . . . . . . 21 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 101 Intellectual Property and Copyright Statements . . . . . . . . . . 23 103 1. Introduction 105 1.1. Overview 107 For some network services (eg. Voicemail, IVR or automatic call 108 distribution), it is necessary for the called SIP user agent to 109 identify from whom and why the session was diverted. In order to be 110 used by various service providers or applications, redirection 111 information needs to pass through the network. 112 This is possible with two different SIP headers: History-Info 113 header[RFC4244] and Diversion header which are both able to transport 114 diversion information in SIP signaling. Because of the current 115 wildely use of Diversion header even if it is not a standard, it is 116 necessary to have a guideline to make this header interwork with 117 History-Info header. 118 This document provides a mechanism of translation between the 119 Diversion header and the History-Info header and between the 120 Diversion header and the Voicemail URI. 122 1.2. Background 124 The History-Info header [RFC4244] and a the URI extension (including 125 Voicemail URI)[RFC4458] are recommended by IETF to convey redirection 126 information. They are also recommended in the "Communication 127 Diversion (CDIV) service" TISPAN specification [TS_183004] and 3GPP 128 specification[TS_24.604]. 130 At first, the Diversion header was described in 131 [draft-levy-sip-diversion-08], which is today discarded. This header 132 contains the list of the diverting user(s) with associated 133 information and the expired draft could explain why many 134 implementations are based on this header. It has been chosen to 135 standardized the History-Info header because it could transport 136 "request history" information which allows the receiving application 137 to determine hints about how and why the session arrived at the 138 application/user. As History-Info header information is larger than 139 call diversion information, it is realy important to be sure of not 140 loosing information and be able to extract the good data with help of 141 the retargeting cause described in [RFC4458] for the transport of the 142 diversion reason. 144 Those headers have different syntaxes described below. Note that the 145 main difference is that the History-Info header is a chronological 146 writing header whereas the Diversion header is the opposite (i.e. the 147 first diversion entry read correspond to the last diverting user). 149 2. Problem Statement 151 2.1. Interworking need 153 The Diversion header is used for recording communication diversion 154 information which could be useful to downstream network entities. 155 Today, this SIP header is implemented by several manufacturers and 156 deployed in several networks. 158 The History-Info header is standardized, among other needs, for the 159 transportation of diversion information. 161 As both are answering to call forwarding needs, according to the one 162 created or completed in one side and the one interpreted in the other 163 side, diverting information could be mixed-up if they are both 164 present in the INVITE request. So, Diversion and History-Info 165 headers MUST NOT independently coexist for the session signalling. 167 For the transportation of consistent diversion information 168 downstream, it is necessary to make the two headers interwork. 169 Interworking between the Diversion header and the History-Info header 170 is presented in sections 5 and 6. As the interworking is not obvious 171 and the coexistence not easy according the use cases, is it proposed 172 a policy to manage the headers interaction. 174 In addition, Voicemail URI proposes an other way to convey diversion 175 information in the R-URI. So, it is also necessary to describe the 176 interworking between Diversion header and a Voicemail URI. This 177 interworking is presented in section 7.4. 179 2.2. Interworking recommendations 181 History-Info header is a standardized solution, so a network using 182 the Diversion header MUST be able to provide information at the good 183 format to a network using the History-Info header. In this case, to 184 avoid both headers coexistence it is recommended as often as possible 185 to replace the Diversion header per the History-Info header in the 186 INVITE request during the interworking. 187 For some specific interworking situations (see section 7.5), it could 188 be needed to create a Diversion header from a received History-Info 189 header. Since, the History-Info header has a boarder scope than the 190 Diversion header and could be used for other services than call 191 diversion ; in addition to trace call diversion information, it is 192 acting as a session history and could store all successive R-URI 193 values. So, even if it should be better to remove the History-Info 194 header after the Diversion header has been created to avoid 195 confusion; if the History-Info header contains supplementary 196 information it MUST be remained and passed transparently in this 197 network. 198 These are the more simple interworking situations where a header is 199 created from the other one. More interworking cases, like situation 200 where persistence of both headers is needed, are described in section 201 7.5. 202 If some information could be lost and use downstream or according the 203 header used per network elements, it is necessary to have a local 204 policy to find the best way to keep information up to the terminating 205 user agent. 207 SIP network/terminal using Diversion to SIP network/terminal using 208 History-Info header: 210 When the Diversion header is used to create a History-Info header, 211 the Diversion header MUST be removed in the outgoing INVITE. It is 212 considered that all information present in the Diversion header is 213 transferred in the History-Info header. 215 If a History-Info header is present in the incoming INVITE (in 216 addition to Diversion header), the Diversion header and History-Info 217 header present MUST be mixed and only the diversion information not 218 yet present in the History-Info header MUST be inserted as a last 219 entry (more recent) in the existing History-Info header as 220 recommended in [RFC4244]. 221 As an example, this could be the case of an INVITE coming from a 222 network_2 using Diversion header but before passed through a 223 network_1 using History-Info header (or the network_2 uses History- 224 Info header to transport successive URI information) and going to a 225 network_3 using History-Info header. 227 IWF* IWF* 228 network1 | network_2 |network_3 229 History-Info | Diversion |using 230 | |Hist-Info 231 | | 232 UA A P1 AS B | P2 AS C UA C AS D | UA E 233 | | | | | | | | | | 234 |INVITE | | | | | | | | | 235 |------>| | | | | | | | | 236 | | | | | | | | | | 237 | |INVITE | | | | | | | | 238 | |------>| | | | | | | | 239 | |Supported: histinfo | | | | | | 240 | | History-Info: | | | | | | 241 | | ; index=1, | | | | | 242 | | ; index=1.1 | | | | | 243 | | | | | | | | | | 244 | | |INVITE | | | | | | | 245 | | |------>| | | | | | | 246 | | |History-Info: | | | | | | 247 | | |; index=1,| | | | | 248 | | |; index=1.1 | | | | | 249 | | |; cause=302; index=1.1.1 | | | 250 In this case, the incoming INVITE contains a Diversion header and a 251 History-Info header. So that, it is necessary to create, for 252 network_3, a single History-Info header gathering existing 253 information in the History-Info header received and those present in 254 the Diversion header. Then network_3 could use call forwarding 255 information that are present in a single header and add its own 256 diversion information if necessary. 258 Note: if a network is not able either to use only one header each 259 time, or to maintain both headers up to date, the chronological order 260 could not be certified. 261 Note: it is not possible to have only Diversion header when the 262 History-Info header contains more than call diversion information. 263 If previous policy recommendations are applied, the chronological 264 order is respected as Diversion entries are inserted at the end of 265 the History-Info header taking into account the Diversion internal 266 chronology. 268 SIP network/terminal using History-Info header to SIP network/ 269 terminal using Diversion header: 271 When the History-Info header is interpreted to create a Diversion 272 header, some precautions MUST be taken. 273 If the History-Info header contains only communication diversion 274 information, then it MUST be suppressed after the interworking. 276 If the History-Info header contains other information, then only the 277 information of concern to the diverting user MUST be used to create 278 entries in the Diversion header and the History-Info header MUST be 279 kept as received in the INVITE forwarded downstream. 281 Note: The History-Info header could be used for other reasons than 282 CDIV services, for example by a service which need to know if a 283 specific AS had yet been invoked in the signalling path. If the call 284 is after forwarded to a network using History-Info header, it would 285 be better to not loose history information due to passing though the 286 network which only support Diversion header. A recommended solution 287 MUST NOT disrupt the standard behaviour and networks which not 288 implement History-Info header MUST be transparent to an incoming 289 History-Info header. 291 If a Diversion header is already present in the incoming INVITE (in 292 addition to History-Info header), only diversion information present 293 in the History-Info header but not in the Diversion header MUST be 294 inserted from the last entry (more recent) into the existing 295 Diversion header as recommended in the Diversion draft 296 [draft-levy-sip-diversion-08]. Note that the chronological order 297 could not be certified. If previous policy recommendations are 298 respected, this case SHOULD NOT happen. 300 Forking case: 301 The History-Info header enables the recording of sequential forking 302 for the same served-user. During a interworking from the History- 303 Info header to Diversion header, the History-Info entries containing 304 a forking situation (with an incremented "index" parameter) could be 305 either mapped for each entry with a call forwarding "cause" 306 parameter, the interworking entity could choose to create only one 307 Diversion entry or to not apply the interworking. The choice could 308 be done according a local policy. 310 The same logic is applied for an interworking with Voicemail URI (see 311 section 7.4). 313 3. Headers syntaxes reminder 315 3.1. History-Info header syntax 317 History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry) 318 hi-entry = hi-targeted-to-uri *( SEMI hi-param ) 319 hi-targeted-to-uri= name-addr 320 hi-param = hi-index / hi-extension 321 hi-index = "index" EQUAL 1*DIGIT *(DOT 1*DIGIT) 322 hi-extension = generic-param 324 The History-Info header is specified in [RFC4244]. Amongst the 325 information contained in the header list is the diversion information 326 with a specific cause code mentioning the diversion reason. These 327 optional cause codes are defined in [RFC4458]. The RFC4244 contains 328 a Privacy section introducing the use of Privacy header defined in 329 [RFC3323] for diversion information. The top-most History-Info entry 330 (first in the list) corresponds to the oldest history information. 331 A diverting user information is identifiable by the History-Info 332 entry containing a cause-param with cause value as listed in 333 [RFC4458] and by the entry just before. The last diversion target is 334 identifiable by the last History-Info entries containing a cause- 335 param with cause value as listed in RFC 4458. 336 The cause-param is inserted in the hi-targeted-to-uri of the address 337 were the communication is diverted to. The index parameter is a 338 string of digits, separated by dots to indicate the number of forward 339 hops and retargets. 341 Example: 343 History-Info: 344 ;index=1, 345 ;index=1.1, 347 ; index=1.1.1, 349 Policy concerning "histinfo" option tag in Supported header: 350 According to [RFC4244], a proxy that receives a Request with the 351 "histinfo" option tag in the Supported header should return captured 352 History-Info in subsequent, provisional and final responses to the 353 Request. The behaviour depend whether the local policy support the 354 capture of History-Info or not. 356 3.2. Diversion header syntax 358 The current document is not written to define again the Diversion 359 header and its use but to be shure that the syntax is interpreted in 360 the same way by everyone. So that, the Diversion syntax is here a 361 little changed to correspond to the current ABNF[RFC4234]: 363 Diversion = "Diversion" HCOLON diversion-params *(COMMA diversion- 364 params) 365 diversion-params = name-addr *(SEMI (diversion-reason / diversion- 366 counter / diversion-limit / diversion-privacy / diversion-screen / 367 diversion-extension)) 368 diversion-reason = "reason" EQUAL ("unknown" / "user-busy" / "no- 369 answer" / "unavailable" / "unconditional" / "time-of-day" / "do-not- 370 disturb" / "deflection" / "follow-me" / "out-of-service" / "away" / 371 token / quoted-string) 372 diversion-counter = "counter" EQUAL 1*2DIGIT 373 diversion-limit = "limit" EQUAL 1*2DIGIT 374 diversion-privacy = "privacy" EQUAL ("full" / "name" / "uri" / "off" 375 / token / quoted-string) 376 diversion-screen = "screen" EQUAL ("yes" / "no" / token / quoted- 377 string) 378 diversion-extension = token [EQUAL (token / quoted-string)] 380 Note: The Diversion header could be used in the comma-separated 381 format as described below and in a header-separated format. Both 382 formats could be combined a received INVITE as RECOMMENDED in 383 [RFC3261]. 385 Example: 387 Diversion: 388 diverting_user2_addr; reason="user-busy"; counter=1; privacy=full, 389 diverting_user1_addr; reason="unconditional"; counter=1; privacy=off 391 4. Headers in SIP Method 393 You can find here a reminder of History-Info header field and 394 Diversion header field in relation to methods. As those headers do 395 not have the same capabilities, it is necessary to clarify the 396 interworking. 398 Use of History-Info header field: 400 Header field where proxy ACK BYE CAN INV OPT REG MSG 401 ------------ ----- ----- --- --- --- --- --- --- --- 402 History-Info amdr - - - o o o o 403 SUB NOT REF INF UPD PRA PUB 404 --- --- --- --- --- --- --- 405 History-Info amdr o o o - - - o 407 Use of Diversion header field: 409 Header field where enc. e-e ACK BYE CAN INV OPT REG 410 ------------ ----- ----- --- --- --- --- --- --- --- 411 Diversion R h - - - o - - 412 Diversion 3xx h - - - o - - 414 The recommended interworking presented in this document SHOULD apply 415 only for INVITE requests. 417 In 3xx responses, both headers could be present. 418 When a proxy wants to interwork with a network supporting the other 419 header field, it SHOULD apply the interworking between Diversion 420 header and History-Info header in the 3xx response. 421 When a recursing proxy redirects an initial INVITE after receiving a 422 3xx response, it SHOULD add as a last entry either a Diversion header 423 or History-Info header (according to its capabilities) in the 424 forwarded INVITE. Local policies could apply to send the received 425 header in the next INVITE or not. 427 Other messages where History-Info could be present are not used for 428 the Call Forwarding service and SHOULD NOT be changed into Diversion 429 header. The destination network MUST be transparent the received 430 History-Info header. 432 5. Diversion header to History-Info header 434 For N Diversion entries N+1 History-Info entries MUST be created. To 435 create the History-Info entries in the same order than during a 436 session establishment, the Diversion entries MUST be mapped from the 437 bottom-most until the top-most. 439 The first entry created in the History-Info header contains: 441 - a hi-target-to-uri with the name-addr parameter of the bottom- 442 most Diversion header 443 - the privacy entry interworking the privacy parameter of the 444 bottom-most Diversion header, 446 - an index set to 1. 448 For each Diversion header, the next History-info entries are mapped 449 as following: 451 Source Destination 452 Diversion header component: History-Info header component: 453 ======================================================================= 454 Name-addr of the previous Hi-target-to-uri 455 (on top) Diversion header. 456 If there is no previous(top-most), 457 it is the Request-URI address. 459 ======================================================================= 460 Reason Cause 461 "unknown"---------------------------------404 462 "unconditional"---------------------------302 463 "user-busy"-------------------------------486 464 "no-answer"-------------------------------408 465 "deflection "-----------------------------480 466 "unavailable"-----------------------------503 467 "time-of-day"-----------------------------404 (default) or 302 468 "do-not-disturb"--------------------------404 (default) or 302 469 "follow-me"-------------------------------404 (default) or 302 470 "out-of-service"--------------------------404 (default) 471 "away"------------------------------------404 (default) or 302 473 ======================================================================= 474 Counter Hi-index 475 "1" or parameter -------------------------The previous created index 476 no present is incremented with ".1" 477 Superior to "1" --------------------------Create N-1 placeholder History 478 (i.e. N) entry with the previous index 479 incremented with ".1" 480 Then the History-Info header 481 created with the Diversion 482 entry with the previous index 483 incremented with ".1" 484 ======================================================================= 485 Privacy of the previous Privacy escaped in the 486 (on top) Diversion header. hi-targeted-to-uri 487 If there is no previous(top-most), 488 no privacy parameter is created. 489 "full"------------------------------------"history" 490 "Off"-------------------------------------Privacy header field 491 absent or "none" 492 "name"------------------------------------"history" 493 "uri"-------------------------------------"history" 494 ======================================================================= 496 Note: For other optional Diversion parameters, there is no 497 recommendation. 499 Note: For values of the "reason" parameter which are mapped with a 500 recommended default value, it could also be possible to choose an 501 other value or to omit the parameter. 503 Note : The Diversion header could contain a Tel:URI in the name-addr 504 parameter but it seems to not be possible to have a Tel:URI in the 505 History-Info header. RFC3261 gives an indication as to the mapping 506 between sip: and tel: URIs but in this particular case it is 507 difficult to assign a valid hostport as the diversion has occurred in 508 a previous network and a valid hostport is difficult to determine. 509 So, it is suggested that in case of Tel:URI in the Diversion header, 510 the History-Info header should be created with a SIP URI with 511 user=phone. 513 Note: The Diversion header allows the carrying of a counter which had 514 retained the information about the number of redirections which have 515 occurred. History-Info does not have an equivalent because to trace 516 and count diversion occurred it is necessary to count cause parameter 517 containing a value associated to a call diversion. To read the index 518 value is not enough. With the use of the "placeholder" entry the 519 History-info header entries could reflect the real number of 520 diversion occurred. Example of placeholder entry in the History-Info 521 header: ;index=1.1 522 For a placeholder History entry the value "404" shall be taken. 524 Concerning local policies recommendations about headers coexistence 525 in the INVITE request, see sections 2.2 and 7.5. 527 6. History-Info header to Diversion header 529 As each previous diverting user MUST be present in the received 530 History-Info header, one Diversion header entry per diverting user 531 MUST be created in order not to loose any diverting information. 533 For each History-Info header containing a cause-param with cause 534 value as listed in the [RFC4458]; a Diversion header entry MUST be 535 created. The first History-Info header entry selected will be mapped 536 into the last Diversion header entry and so on. 538 In this case, the History-Info header MUST be mapped into the 539 Diversion header as following: 541 Source Destination 542 History-Info header component: Diversion header component: 543 ===================================================================== 544 Hi-target-to-uri of the Name-addr 545 History-Info which precedes the one 546 containing a diverting cause-param 548 ===================================================================== 549 Cause Reason 550 404---------------------------------------"unknown" 551 302---------------------------------------"unconditional" 552 486---------------------------------------"user-busy" 553 408---------------------------------------"no-answer" 554 480 or 487--------------------------------"deflection " 555 503---------------------------------------"unavailable" 557 ===================================================================== 558 Hi-index Counter 559 Mandatory parameter for--------------------The counter is set to "1". 560 History-Info reflecting 561 the chronological order 562 of the information. 563 ===================================================================== 564 Privacy escaped in the Privacy 565 hi-targeted-to-uri of the 566 History-Info which precedes the one 567 containing a diverting cause-param. 568 Optional parameter for History-Info, 569 this Privacy indicates that this 570 specific History-Info header SHOULD 571 not be forwarded. 572 "history"----------------------------------"full" 573 Privacy header field ----------------------"Off" 574 Absent or "none" 576 ===================================================================== 577 Privacy header [RFC3323] Privacy 578 The Privacy indicates that all 579 History-Info headers SHOULD NOT 580 be forwarded. 581 "history"----------------------------------"full" 582 ===================================================================== 584 Concerning local policies recommendations about headers coexistence 585 in the INVITE request, see section 2.2. 587 Editor's note: interworking with Voicemail URI, defined in [RFC4458], 588 will be added in the next release of the document. 590 7. Examples 592 7.1. Example with Diversion header changed into History-Info header 594 INVITE last_diverting_target 595 Diversion: 596 diverting_user3_address;reason=unconditional;counter=1;privacy=off, 597 diverting_user2_address;reason=user-busy;counter=1;privacy=full, 598 diverting_user1_address;reason=no-answer;counter=1;privacy=off 600 Mapped into: 602 History-Info: 603 ; index=1, 604 index=1.1, 606 index=1.1.1, 608 index=1.1.1.1, 610 7.2. Example with History-Info header changed into Diversion header 612 History-Info: 613 ; index=1, 614 index=1.1, 616 index=1.1.1 618 Mapped into: 620 Diversion: 621 diverting_user2_address; reason=user-busy; counter=1; privacy=off, 622 diverting_user1_address; reason=unconditional; counter=1; 623 privacy=full 625 7.3. Example with two SIP networks using History-Info header 626 interworking with a SIP network using Diversion header 628 A -> P1 -> B -> C -> P2 -> D-> E 629 A, B, C, D and E are users. 630 B, C and D have Call Forwarding service invoked. 631 P1 and P2 are proxies. 632 Only relevant information is shown on the following call flow. 634 IWF* IWF* 635 SIP network using | SIP network using |SIP net. 636 History-Info | Diversion |using 637 | |Hist-Info 638 | | 639 UA A P1 AS B | P2 AS C UA C AS D | UA E 640 | | | | | | | | | | 641 |INVITE | | | | | | | | | 642 |------>| | | | | | | | | 643 | | | | | | | | | | 644 | |INVITE | | | | | | | | 645 | |------>| | | | | | | | 646 | |Supported: histinfo | | | | | | 647 | | History-Info: | | | | | | 648 | | ; index=1, | | | | | 649 | | ; index=1.1 | | | | | 650 | | | | | | | | | | 651 | | |INVITE | | | | | | | 652 | | |------>| | | | | | | 653 | | |History-Info: | | | | | | 654 | | |; index=1,| | | | | 655 | | |; index=1.1 | | | | | 656 | | |; cause=302; index=1.1.1 | | | 657 | | | | | | | | | | 658 | | | |INVITE | | | | | | 659 | | | |------>| | | | | | 660 | | | |Diversion: | | | | | 661 | | | |B reason= unconditional counter=1 | | 662 | | | |History-Info: | | | | | 663 | | | |; index=1,| | | | 664 | | | |; index=1.1 | | | | 665 | | | |; cause=302; index=1.1.1| | 666 | | | | | | | | | | 667 | | | | |INVITE | | | | | 668 | | | | |------>| | | | | 669 | | | | |No modification of Diversion due to P2| 670 | | | | | | | | | | 671 | | | | | |INVITE | | | | 672 | | | | | |------>| | | | 673 | | | | | | | | | | 674 | | | | | |<--180-| | | | 675 | | | | | | | | | | 676 | | | | | No response timer expire | | 677 | | | | | |---INVITE--->| | | 678 | | | Diversion: | | | 679 | | | userC; reason=no-answer; counter=1; privacy=full, 680 | | | userB; reason=unconditional; counter=1; privacy=off, 681 | | | History-Info: | | | 682 | | | ; index=1, | | | 683 | | | ; index=1.1 | | | 684 | | | ; cause=302; index=1.1.1 | | 685 | | | | | | | | | | 686 | | | | | | | |INVITE | | 687 | | | | | | | |------>| | 688 | | | Diversion: | | 689 | | | userD; reason=time-of-day; counter=1; privacy=off| 690 | | | userC; reason=no-answer; counter=1; privacy=full,| 691 | | | userB; reason=unconditional; counter=1; privacy=off, 692 | | | History-Info: | | 693 | | | ; index=1, | | 694 | | | ; index=1.1 | | 695 | | | ; cause=302; index=1.1.1 | | 696 | | | | | | | | | | 697 | | | | | | | | | INVITE | 698 | | | | | | | | |------->| 699 | | | History-Info: | 700 | | | ; index=1, | 701 | | | ; index=1.1; privacy=none, | 702 | | | ; cause=302; index=1.1.1, | 703 | | | ; privacy=history; index=1.1.1.1, | 704 | | | ; cause=408; privacy=none; index=1.1.1.1.1, 705 | | | ; cause=404; index=1.1.1.1.1.1 | 706 | | | | | | | | | | 707 | | | | | | | | | | 709 * Note: The IWF is an interworking function which could be a stand-alone 710 equipment not defined in this draft (it could be a proxy). 712 7.4. Interworking between Diversion header and Voicemail URI 714 Voicemail URI is a mechanism described in RFC4458 to provide a simple 715 way to transport only one redirecting user address and the reason why 716 the diversion occurred in the R-URI of the INVITE request. This 717 mechanism is mainly used for call diversion to a voicemail. 719 Diversion header to Voicemail URI: 721 Received: 722 Diversion: userA-address;reason=user-busy;counter=1;privacy=full 724 Sent (Voicemail URI created in the R-URI line of the INVITE): 725 sip: voicemail@example.com;target=userA-address;cause=486 SIP/2.0 727 Mapping of the Redirection Reason is the same as for History-Info 728 header with a default value set to 404. 730 If the Diversion header contains more than one Diversion entry, the 731 choice of the redirecting user information inserted in the URI is in 732 charge of the network local policy. For example, the choice 733 criterion of the redirecting information inserted in the URI could be 734 the destination of forwarded INVITE request (if the voicemail serves 735 this user or not). 737 Note: This interworking could be done in addition to the interworking 738 of the Diversion header into the History-Info header. 740 Voicemail URI to Diversion header: 741 In case of real Voicemail, this way of interworking should not 742 happen. However, if for any reason it occurs, it is recommended to 743 do it as following: 745 Received: 746 INVITE sip: voicemail@example.com;\ 747 target=sip:+33145454500%40example.com;user=phone;\ 748 cause=302 SIP/2.0 750 Sent in the forwarded INVITE: 751 Diversion: sip:+ 752 33145454500%40example.com;user=phone;reason=unconditional;counter=1 754 7.5. Additional interworking Cases 756 Even if for particular cases in which both headers could coexist it 757 should be the network local policy responsibility to make it work 758 together, here are described some situations and some recommendations 759 on the behaviour to follow. 761 In the case where there is one network which includes different 762 nodes, some of which support Diversion header and some which support 763 History-info header, the problem is when any node handling a message 764 does not know which node will next handle the message. This case can 765 occur when the network has new and old nodes, the older ones using 766 Diversion header and the more recent History-Info header. 767 While a network replacement may be occurring there will be a time 768 when both nodes exist in the network. If the different nodes are 769 being used to support different subscriber types due to different 770 node capabilities then the problem is more important. In this case 771 there is a need to pass both History-Info header and Diversion header 772 within the network core. 773 These headers need to be equivalent to ensure that whatever node 774 receives the message the correct diversion information is received. 775 This requires that whichever header is received there is a 776 requirement to be able to compare the headers and to convert the 777 headers. Depending upon node capability then it may be possible to 778 make assumptions as to how this is handled. 779 If it is known that the older Diversion header supporting nodes do 780 not pass on any received History-Info header then the interworking 781 becomes easier. If a message is received with only Diversion headers 782 then it has originated from an 'old' node. The equivalent History- 783 Info entries can be created and these can then be passed as well as 784 the Diversion header. 785 If the node creates a new History-Info header for a call diversion, 786 then an additional Diversion header must be created. 787 If the next node is an 'old' node then the Diversion header will be 788 used by that node and the History-Info entries will be removed from 789 the message when it is passed on. 790 If the next node is a new node then the presence of both Diversion 791 header and History-Info header means that interworking has already 792 occurred and the Diversion and History-Info entries must be 793 considered equivalent. 794 If both nodes pass on both History-Info header and Diversion header 795 but only actively use one, then both types of node need to perform 796 the interworking and must maintain equivalence between the headers. 797 This will eventually result in the use of Diversion header being 798 deprecated when all nodes in the network support History-Info header. 800 8. IANA Considerations 802 This document makes no request of IANA. 804 9. Security Considerations 806 The use of Diversion header or History-Info header require to apply 807 the requested privacy and integrity asked by each diverting user or 808 entity. Without integrity, the requested privacy functions could be 809 downgraded or eliminated, potentially exposing identity information. 810 Without confidentiality, eavesdroppers on the network (or any 811 intermediaries between the user and the privacy service) could see 812 the very personal information that the user has asked the privacy 813 service to obscure. Unauthorised insertion, deletion of modification 814 of those headers can provide misleading information to users and 815 applications. A SIP entity that can provide a redirection reason in 816 a History-Info header or Diversion header SHOULD be able to suppress 817 this in accordance with privacy requirements of the user concerned. 819 10. Acknowlegements 821 The editors would like to acknowledge the constructive feedback 822 provided by Ian Elz, Jean-Francois Mule, Lionel Morand, Xavier 823 Marjou, Philippe Fouquart, Mary Barnes, Francois Audet, Erick Sasaki 824 and Shida Schubert. 826 11. References 828 11.1. Normative References 830 [RFC2119] "Key words for use in RFCs to Indicate Requirement 831 Levels", RFC 2119, March 1997. 833 [RFC3261] "SIP: Session Initiation Protocol", RFC 3261, June 2002. 835 [RFC3969] "The Internet Assigned Number Authority (IANA) Uniform 836 Resource Identifier (URI) Parameter Registry for the 837 Session Initiation Protocol (SIP), BCP 99", RFC 3969, 838 December 2004. 840 [RFC4234] "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, 841 October 2005. 843 11.2. Informative References 845 [RFC3323] "A Privacy Mechanism for the Session Initiation Protocol 846 (SIP)", RFC 3323, November 2002. 848 [RFC4244] "An Extension to the Session Initiation Protocol (SIP) for 849 Request History Information", RFC 4244, November 2005. 851 [RFC4458] "Session Initiation Protocol (SIP) URIs for Applications 852 such as Voicemail and Interactive Voice Response (IVR)", 853 RFC 4458, April 2006. 855 [TS_183004] 856 Telecommunications and Internet converged Services and 857 Protocols for Advanced Networking (TISPAN), "PSTN/ISDN 858 simulation services: Communication Diversion (CDIV); 859 Protocol specification, Release 2, ETSI TS 183004", 860 November 2007. 862 [TS_24.604] 863 3rd Generation Partnership Project, "Technical 864 Specification Group Core Network and Terminals ; 865 Communication Diversion (CDIV) using IP Multimedia 866 (IM)Core Network (CN) subsystem ; Protocol specification 867 (Release 8), 3GPP TS 24.604", April 2008. 869 [draft-levy-sip-diversion-08] 870 "Diversion Indication in SIP, 871 draft-levy-sip-diversion-08", August 2004. 873 Authors' Addresses 875 Marianne Mohali 876 France Telecom 877 38-40 rue du General Leclerc 878 Issy-Les-Moulineaux Cedex 9 92794 879 France 881 Phone: +33 1 45 29 45 14 882 Email: marianne.mohali@orange-ftgroup.com 884 Steve Norreys 885 British Telecom 887 Jan Van Geel 888 Belgacom 890 Martin Dolly 891 ATT 893 Francisco Silva 894 Portugal Telecom 896 Guiseppe Sciortino 897 Italtel 899 Cinzia Amenta 900 Italtel 902 Christer Holmberg 903 Ericsson 905 Full Copyright Statement 907 Copyright (C) The IETF Trust (2008). 909 This document is subject to the rights, licenses and restrictions 910 contained in BCP 78, and except as set forth therein, the authors 911 retain all their rights. 913 This document and the information contained herein are provided on an 914 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 915 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 916 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 917 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 918 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 919 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 921 Intellectual Property 923 The IETF takes no position regarding the validity or scope of any 924 Intellectual Property Rights or other rights that might be claimed to 925 pertain to the implementation or use of the technology described in 926 this document or the extent to which any license under such rights 927 might or might not be available; nor does it represent that it has 928 made any independent effort to identify any such rights. Information 929 on the procedures with respect to rights in RFC documents can be 930 found in BCP 78 and BCP 79. 932 Copies of IPR disclosures made to the IETF Secretariat and any 933 assurances of licenses to be made available, or the result of an 934 attempt made to obtain a general license or permission for the use of 935 such proprietary rights by implementers or users of this 936 specification can be obtained from the IETF on-line IPR repository at 937 http://www.ietf.org/ipr. 939 The IETF invites any interested party to bring to its attention any 940 copyrights, patents or patent applications, or other proprietary 941 rights that may cover technology that may be required to implement 942 this standard. Please address the information to the IETF at 943 ietf-ipr@ietf.org.