idnits 2.17.1 draft-mohali-diversion-history-info-00.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 26. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 734. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 745. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 752. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 758. 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 88 instances of too long lines in the document, the longest one being 40 characters in excess of 72. ** The abstract seems to contain references ([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 347 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 (July 11, 2008) is 5739 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3969' is defined on line 653, but no explicit reference was found in the text == Unused Reference: 'RFC4234' is defined on line 658, 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 (~~), 5 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: January 12, 2009 British Telecom 6 J. Van Gee 7 Belgacom 8 M. Dolly 9 ATT 10 F. Silva 11 Portugal Telecom 12 G. Sciortino 13 C. Amenta 14 Italtel 15 July 11, 2008 17 Mapping and interworking of Diversion information Between Diversion and 18 History-Info Headers in the Session Initiation Protocol (SIP) 19 draft-mohali-diversion-history-info-00 21 Status of this Memo 23 By submitting this Internet-Draft, each author represents that any 24 applicable patent or other IPR claims of which he or she is aware 25 have been or will be disclosed, and any of which he or she becomes 26 aware will be disclosed, in accordance with Section 6 of 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 January 12, 2009. 46 Abstract 48 Both History-Info and Diversion headers are able to transport 49 diverting information in Session Initiation Protocol (SIP) signaling. 50 This document proposes a way to map call forwarding information 51 contained in a Diversion header into a History-Info header and vice 52 versa. In addition, an interworking policy is proposed to manage the 53 headers coexistence. 54 Prior to existence of [RFC4244] describing the History-Info header, 55 there was a draft introducing a header named Diversion for the 56 transport of diversion information. 57 Since the Diversion header is used in many existing networks 58 implementations and it is not standardized for transport of diversion 59 information, a mapping with the standardized History-Info header is 60 needed. 62 Requirements Language 64 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 65 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 66 document are to be interpreted as described in [RFC2119]. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 1.2. Background . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 74 2.1. Interworking need . . . . . . . . . . . . . . . . . . . . 5 75 2.2. Interworking recommendations . . . . . . . . . . . . . . . 5 76 3. Headers syntaxes reminder . . . . . . . . . . . . . . . . . . 7 77 3.1. History-Info header syntax . . . . . . . . . . . . . . . . 7 78 3.2. Diversion header syntax . . . . . . . . . . . . . . . . . 8 79 4. Headers in SIP METHOD . . . . . . . . . . . . . . . . . . . . 9 80 5. Diversion header to History-Info header . . . . . . . . . . . 9 81 6. History-Info header to Diversion header . . . . . . . . . . . 12 82 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 7.1. Example with Diversion header changed into 84 History-Info header . . . . . . . . . . . . . . . . . . . 14 85 7.2. Example with History-Info header changed into 86 Diversion header . . . . . . . . . . . . . . . . . . . . . 14 87 7.3. Example with two SIP networks using History-Info 88 header interworking with a SIP network using Diversion 89 header . . . . . . . . . . . . . . . . . . . . . . . . . . 14 90 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 91 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 92 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 93 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 94 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 96 Intellectual Property and Copyright Statements . . . . . . . . . . 19 98 1. Introduction 100 1.1. Overview 102 For enhanced network services (eg. Voicemail, IVR or automatic call 103 distribution), it is necessary for the called SIP user agent to 104 identify from whom and why the session was diverted. In order to be 105 used by various service providers or applications, redirection 106 information needs to pass through the network. 107 This is possible with two different SIP headers: History-Info 108 [RFC4244] and Diversion [draft-levy-sip-diversion-08] which both able 109 to transport diversion information in SIP signaling. Because of this 110 double possibility, it is necessary to map one into the other. 111 This document provides a standard mechanism of translation between 112 the History-Info header and the Diversion header. 114 1.2. Background 116 To transport diversion information, the History-Info header [RFC4244] 117 and an URI extension [RFC4458] are advocated in the standardized 118 Communication Diversion (CDIV) service Protocol Specifications 119 [TS_183004] and [TS_24.604]. 120 Because of the implementation of the Diversion header in some SIP 121 networks/terminals and the History-Info header in others, it is 122 necessary to map one to the other. 124 At first, the Diversion header was described in 125 [draft-levy-sip-diversion-08], which is today discarded. This header 126 contains the list of the diverting user(s) with associated 127 information. The top-most diversion entry (first in the list) 128 corresponds to the last diverting user and the bottom-most entry to 129 the first diverting user (see syntax below). 131 At the same time, the History-Info header was proposed for the 132 transport of "request history" information which allows the receiving 133 application to determine hints about how and why the session arrived 134 at the application/user. As history information is larger than 135 diversion information, diversion information MUST be located and 136 extracted from the History-Info header. This is not the case with 137 the Diversion header. In addition, for diverting information the 138 History-Info header MUST be completed by [RFC4458] for the transport 139 of the diversion reason. 141 Those headers have different syntaxes described below. Note that the 142 main difference is that the History-Info header is a chronological 143 writing header whereas the Diversion header is the opposite (i.e. the 144 first diversion entry read correspond to the last diverting user). 146 2. Problem Statement 148 2.1. Interworking need 150 The Diversion header is used for recording communication diversion 151 information which could be useful to network entities downstream. 152 Today, this SIP header is implemented by several manufacturers and 153 deployed in several networks. 155 In addition, the History-Info header is standardized, among other 156 needs, for the transportation of diversion information. 158 As both are answering to call forwarding needs, according to the one 159 created or completed in one side and the one interpreted in the other 160 side, diverting information could be mixed-up if they are both 161 present in the INVITE request. So, Diversion and History-Info 162 headers MUST NOT independently coexist for the session signalling. 164 For the transportation of consistent diversion information 165 downstream, it is necessary to make the two headers interwork. 166 Mapping between the Diversion header and the History-Info header is 167 presented in sections 5 and 6. 169 2.2. Interworking recommendations 171 To avoid the two headers coexisting it would be better to replace one 172 by the other during the interworking, but this may not be possible 173 due to the information that History-Info header may carry. 174 Indeed, the History-Info header is larger than Diversion header and 175 is used for other services than call diversion: in addition to trace 176 call forwarding information, it is acting as a session history and 177 could store all successive R-URI values. So, sometimes, it will not 178 be possible to suppress the History-Info header after the Diversion 179 header has been created. 181 SIP network/terminal using Diversion to SIP network/terminal using 182 History-Info header: 184 When the Diversion header is mapped into a History-Info header, the 185 Diversion header MUST be suppressed in the outgoing INVITE. It is 186 considered that all information present in the Diversion header is 187 transferred in the History-Info header. 189 If a History-Info header is present in the incoming INVITE (in 190 addition to Diversion header), the Diversion header and History-Info 191 header present MUST be mixed and only the diversion information not 192 yet present in the History-Info header MUST be inserted as a last 193 entry (more recent) in the existing History-Info header as 194 recommended in [RFC4244]. 195 As an example, this could be the case of an INVITE coming from a 196 network_2 using Diversion header but before passed through a 197 network_1 using History-Info header (or the network_2 uses History- 198 Info header to transport successive URI information) and going to a 199 network_3 using History-Info header. In that case, the incoming 200 INVITE contains a Diversion header and a History-info header. So 201 that, it is necessary to create, for network_3, a single History-Info 202 header gathering existing information in the History-Info header 203 received and those present in the Diversion header. Then network_3 204 could use call forwarding information that are present in a single 205 header and add its own diversion information if necessary. 207 Note that the chronological order could not be certified. If 208 previous policy recommendations are applied, the chronological order 209 is respected as Diversion entries are inserted at the end of the 210 History-Info header taking into account the Diversion internal 211 chronology. 213 SIP network/terminal using History-Info header to SIP network/ 214 terminal using Diversion header: 216 When the History-Info header is mapped into a Diversion header, some 217 precautions MUST be taken. 218 If the History-Info header contains only communication diversion 219 information, then it MUST be suppressed after the mapping. 220 If the History-Info header contains other information, then only the 221 information of concern to the diverting user MUST be used to create 222 entries in the Diversion header and the History-Info header MUST be 223 kept as received in the INVITE forwarded downstream. 225 Note: The History-Info header could be used for other reasons than 226 CDIV services, for example by a service which need to know if a 227 specific AS had yet been invoked in the signalling path. If the call 228 is after forwarded to a network using History-Info header, it would 229 be better to not loose history information due to passing though the 230 network which only support Diversion header. A recommended solution 231 MUST NOT disrupt the standard behaviour and networks which not 232 implement History-Info header MUST be transparent to an incoming 233 History-Info header. 235 If a Diversion header is already presents in the incoming INVITE (in 236 addition to History-Info header), only diversion information present 237 in the History-Info header but not in the Diversion header MUST be 238 inserted from the last entry (more recent) into the existing 239 Diversion header as recommended in the Diversion draft 240 [draft-levy-sip-diversion-08]. Note that the chronological order 241 could not be certified. If previous policy recommendations are 242 respected, this case SHOULD NOT happen. 244 Forking case: 245 The History-Info header enables the recording of sequential forking 246 for the same served-user. During a mapping from the History-Info 247 header to Diversion header, the History-Info entries contaning a 248 forking situation (with an incremented "index" parameter) could be 249 either mapped for each entry with a call forwarding "cause" 250 parameter, the interworking entity could choose to create only one 251 Diversion entry or to not apply the mapping. The choice could be 252 done according a local policy. 254 3. Headers syntaxes reminder 256 3.1. History-Info header syntax 258 History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry) 259 hi-entry = hi-targeted-to-uri *( SEMI hi-param ) 260 hi-targeted-to-uri= name-addr 261 hi-param = hi-index / hi-extension 262 hi-index = "index" EQUAL 1*DIGIT *(DOT 1*DIGIT) 263 hi-extension = generic-param 265 The History-Info header is specified in [RFC4244]. Amongst the 266 information contained in the header list is the diversion information 267 with a specific cause code mentioning the diversion reason. These 268 optional cause codes are defined in [RFC4458]. It is also possible 269 to introduce the Privacy header defined in [RFC3323] for diversion 270 information. The top-most History-Info entry (first in the list) 271 corresponds to the oldest history information. 272 A diverting user information is identifiable by the History-Info 273 entry containing a cause-param with cause value as listed in 274 [RFC4458] and by the entry just before. The last diversion target is 275 identifiable by the last History-Info entries containing a cause- 276 param with cause value as listed in RFC 4458. 277 The cause-param is inserted in the hi-targeted-to-uri of the address 278 were the communication is diverted to. The index parameter is a 279 string of digits, separated by dots to indicate the number of forward 280 hops and retargets. 282 Example: 284 History-Info: 285 ;index=1, 286 index=1.1, 288 ; index=1.1.1, 290 Policy concerning "histinfo" option tag in Supported header: 291 According to [RFC4244], a proxy that receives a Request with the 292 "histinfo" option tag in the Supported header should return captured 293 History-Info in subsequent, provisional and final responses to the 294 Request. The behaviour depend whether the local policy support the 295 capture of History-Info or not. 297 3.2. Diversion header syntax 299 It seems that there is some few mistakes in the Diversion syntax, so 300 it would be better to use the following syntax: 302 Diversion = "Diversion" HCOLON diversion-params *(COMMA diversion- 303 params) 304 diversion-params = name-addr *(SEMI (diversion-reason / diversion- 305 counter / diversion-limit / diversion-privacy / diversion-screen / 306 diversion-extension)) 307 diversion-reason = "reason" EQUAL ("unknown" / "user-busy" / "no- 308 answer" / "unavailable" / "unconditional" / "time-of-day" / "do-not- 309 disturb" / "deflection" / "follow-me" / "out-of-service" / "away" / 310 token / quoted-string) 311 diversion-counter = "counter" EQUAL 1*2DIGIT 312 diversion-limit = "limit" EQUAL 1*2DIGIT 313 diversion-privacy = "privacy" EQUAL ("full" / "name" / "uri" / "off" 314 / token / quoted-string) 315 diversion-screen = "screen" EQUAL ("yes" / "no" / token / quoted- 316 string) 317 diversion-extension = token [EQUAL (token / quoted-string)] 319 Note: The Diversion header could be used in the comma-separated 320 format as described below and in a header-separated format. Both 321 formats could be combined a received INVITE as RECOMMENDED in 322 [RFC3261]. 324 Example: 326 Diversion: 327 diverting_user2_addr; reason="user-busy"; counter=1; privacy=full, 328 diverting_user1_addr; reason="unconditional"; counter=1; privacy=off 330 4. Headers in SIP METHOD 332 You can find here a reminder of History-Info header field and 333 Diversion header field in relation to methods. As those headers does 334 not have the same capabilities, it is necessary to clarify the 335 interworking. 336 Use of History-Info header field: 338 Header field where proxy ACK BYE CAN INV OPT REG MSG 339 ------------ ----- ----- --- --- --- --- --- --- --- 340 History-Info amdr - - - o o o o 341 SUB NOT REF INF UPD PRA PUB 342 --- --- --- --- --- --- --- 343 History-Info amdr o o o - - - o 345 Use of Diversion header field: 347 Header field where enc. e-e ACK BYE CAN INV OPT REG 348 ------------ ----- ----- --- --- --- --- --- --- --- 349 Diversion R h - - - o - - 350 Diversion 3xx h - - - o - - 352 The recommended interworking presented in this document SHOULD apply 353 only for INVITE requests. 355 In 3xx responses, both headers could be present. 356 When a proxy wants to interwork with a network supporting the other 357 header field, it SHOULD apply the mapping between Diversion header 358 and History-Info header in the 3xx response. 359 When a recursing proxy redirects an initial INVITE after receving a 360 3xx response, it SHOULD add as a last entry either a Diversion header 361 or History-Info header (according its capabilities) in the forwarded 362 INVITE. Local policies could apply to send the received header in 363 the next INVITE or not. 365 Other messages where History-Info could be present are not used for 366 the Call Forwarding service and SHOULD NOT be changed into Diversion 367 header. The destination network MUST be transparent the received 368 History-Info header. 370 5. Diversion header to History-Info header 372 For N Diversion entries N+1 History-Info entries MUST be created. To 373 create the History-Info entries in the same order than during a 374 session establishment, the Diversion entries MUST be mapped from the 375 bottom-most until the top-most. 377 The first entry created in the History-Info header contains: 379 - a hi-target-to-uri with the name-addr parameter of the bottom- 380 most Diversion header 382 - the privacy entry mapping the privacy parameter of the bottom- 383 most Diversion header, 385 - an index set to 1. 387 For the each Diversion header, the next History-info entries are 388 mapped as following: 390 Source Destination 391 Diversion header component: History-Info header component: 392 ============================================================================= 393 Name-addr of the previous Hi-target-to-uri 394 (on top) Diversion header. 395 If there is no previous(top-most), 396 it is the Request-URI address. 398 ============================================================================= 399 Reason Cause 400 "unknown"--------------------------------------404 401 "unconditional"--------------------------------302 402 "user-busy"------------------------------------486 403 "No-answer"------------------------------------408 404 "deflection "----------------------------------480 405 "Unavailable"----------------------------------503 406 "time-of-day"----------------------------------404 (default) or 302 407 "do-not-disturb"-------------------------------404 (default) or 302 408 "follow-me"------------------------------------404 (default) or 302 409 "out-of-service"-------------------------------404 (default) 410 "away"-----------------------------------------404 (default) or 302 412 ============================================================================= 413 Counter Hi-index 414 "1" or parameter ------------------------------The previous created index 415 no present is incremented with ".1" 416 Superior to "1" -------------------------------1+[(N-1)*".1"] 417 (i.e. N) 419 ============================================================================= 420 Privacy of the previous Privacy escaped in the 421 (on top) Diversion header. hi-targeted-to-uri 422 If there is no previous(top-most), 423 no privacy parameter is created. 424 "full"-----------------------------------------"history" 425 "Off"------------------------------------------Privacy header field 426 absent or "none" 427 "name"-----------------------------------------"history" 428 "uri"------------------------------------------"history" 429 ============================================================================= 431 Note: For other optional Diversion parameters, there is no 432 recommendation. 433 Note: For values of the "reason" parameter which are mapped with a 434 recommended default value, it could also be possible to choose an 435 other value or to omit the parameter. 437 Concerning local policies recommendations about headers coexistence 438 in the INVITE request, see section 2.2. 440 6. History-Info header to Diversion header 442 As each previous diverting user MUST be present in the received 443 History-Info header, one Diversion header entry per diverting user 444 MUST be created in order to not to loose any diverting information. 446 For each History-Info header containing a cause-param with cause 447 value as listed in the [RFC4458]; a Diversion header entry MUST be 448 created. The first History-Info header entry selected will be mapped 449 into the last Diversion header entry and so on. 451 In this case, the History-Info header MUST be mapped into the 452 Diversion header as following: 454 Source Destination 455 History-Info header component: Diversion header component: 456 ============================================================================ 457 Hi-target-to-uri of the Name-addr 458 History-Info which precedes the one 459 containing a diverting cause-param 461 ============================================================================ 462 Cause Reason 463 404--------------------------------------------"unknown" 464 302--------------------------------------------"unconditional" 465 486--------------------------------------------"user-busy" 466 408--------------------------------------------"No-answer" 467 480 or 487-------------------------------------"deflection " 468 503--------------------------------------------"Unavailable" 470 ============================================================================ 471 Hi-index Counter 472 Mandatory parameter for-------------------------The counter is set to "1". 473 History-Info reflecting 474 the chronological order 475 of the information. 476 ============================================================================ 477 Privacy escaped in the Privacy 478 hi-targeted-to-uri of the 479 History-Info which precedes the one 480 containing a diverting cause-param. 481 Optional parameter for History-Info, 482 this Privacy indicates that this 483 specific History-Info header SHOULD 484 not be forwarded. 485 "history"---------------------------------------"full" 486 Privacy header field ---------------------------"Off" 487 Absent or "none" 489 ============================================================================ 490 Privacy header [RFC3323] Privacy 491 The Privacy indicates that all 492 History-Info headers SHOULD NOT 493 be forwarded. 494 "history"---------------------------------------"full" 495 ============================================================================ 497 Concerning local policies recommendations about headers coexistence 498 in the INVITE request, see section 2.2. 500 Editor's note: Iinterworking with Voicemail URI, defined in 502 [RFC4458], will be added in the next release of the document. 504 7. Examples 506 7.1. Example with Diversion header changed into History-Info header 508 INVITE last_diverting_target 509 Diversion: 510 diverting_user3_address;reason="unconditional";counter=1;privacy=off, 511 diverting_user2_address;reason="user-busy";counter=1;privacy=full, 512 diverting_user1_address;reason="no-answer";counter=1;privacy=off 514 Mapped into: 516 History-Info: 517 ; index=1, 518 index=1.1, 520 index=1.1.1, 522 index=1.1.1.1, 524 7.2. Example with History-Info header changed into Diversion header 526 History-Info: 527 ; index=1, 528 index=1.1, 530 index=1.1.1 532 Mapped into: 534 Diversion: 535 diverting_user2_address; reason="user-busy"; counter=1; privacy=off, 536 diverting_user1_address; reason="unconditional"; counter=1; 537 privacy=full 539 7.3. Example with two SIP networks using History-Info header 540 interworking with a SIP network using Diversion header 542 A -> P1 -> B -> C -> P2 -> D-> E 543 A, B, C, D and E are users. 544 B, C and D have Call Forwarding service invoked. 545 P1 and P2 are proxies. 546 Only relevant information is shown on the following call flow. 548 IWF* IWF* 549 SIP network using | SIP network using |SIP network 550 History-Info | Diversion |using 551 | |History-Info 552 | | 553 UA A P1 AS B | P2 AS C UE C AS D | UE E 554 | | | | | | | | | | 555 |INVITE | | | | | | | | | 556 |------>| | | | | | | | | 557 | | | | | | | | | | 558 | |INVITE | | | | | | | | 559 | |------>| | | | | | | | 560 | |Supported: histinfo | | | | | | 561 | | History-Info: | | | | | | 562 | | ; index=1, | | | | | 563 | | ; index=1.1 | | | | | 564 | | | | | | | | | | 565 | | |INVITE | | | | | | | 566 | | |------>| | | | | | | 567 | | |History-Info: | | | | | | 568 | | |; index=1,| | | | | 569 | | |; index=1.1 | | | | | 570 | | |; cause=302; index=1.1.1 | | | 571 | | | | | | | | | | 572 | | | |INVITE | | | | | | 573 | | | |------>| | | | | | 574 | | | |Diversion: | | | | | 575 | | | |B reason= unconditional counter=1 | | 576 | | | |History-Info: | | | | | 577 | | | |; index=1,| | | | 578 | | | |; index=1.1 | | | | 579 | | | |; cause=302; index=1.1.1 | | 580 | | | | | | | | | | 581 | | | | |INVITE | | | | | 582 | | | | |------>| | | | | 583 | | | | |No modification of Diversion due to P2 | 584 | | | | | | | | | | 585 | | | | | |INVITE | | | | 586 | | | | | |------>| | | | 587 | | | | | | | | | | 588 | | | | | |<--180-| | | | 589 | | | | | | | | | | 590 | | | | | No response timer expire | | 591 | | | | | |---INVITE----->| | | 592 | | | Diversion: | | | 593 | | | userC; reason=no-answer; counter=1; privacy=full, 594 | | | userB; reason=unconditional; counter=1; privacy=off, 595 | | | History-Info: | | | 596 | | | ; index=1, | | | 597 | | | ; index=1.1 | | | 598 | | | ; cause=302; index=1.1.1 | | 599 | | | | | | | | | | 600 | | | | | | | |INVITE | | 601 | | | | | | | |------>| | 602 | | | Diversion: | | 603 | | | userD; reason=time-of-day; counter=1; privacy=off | 604 | | | userC; reason=no-answer; counter=1; privacy=full, | 605 | | | userB; reason=unconditional; counter=1; privacy=off, 606 | | | History-Info: | | 607 | | | ; index=1, | | 608 | | | ; index=1.1 | | 609 | | | ; cause=302; index=1.1.1 | | 610 | | | | | | | | | | 611 | | | | | | | | | INVITE | 612 | | | | | | | | |-------->| 613 | | | History-Info: | 614 | | | ; index=1, | 615 | | | ; index=1.1; privacy=none, | 616 | | | ; cause=302; index=1.1.1, | 617 | | | ; privacy=history; index=1.1.1.1, | 618 | | | ; cause=408; privacy=none; index=1.1.1.1.1, 619 | | | ; cause=404; index=1.1.1.1.1.1 | 620 | | | | | | | | | | 621 | | | | | | | | | | 623 * Note: The IWF is an interworking function which could be a stand-alone equipment not defined in this draft. 625 8. IANA Considerations 627 This document makes no request of IANA. 629 9. Security Considerations 631 The use of Diversion header or History-Info header require to apply 632 the requested privacy and integrity asked by each diverting user or 633 entity. Without integrity, the requested privacy functions could be 634 downgraded or eliminated, potentially exposing identity information. 635 Without confidentiality, eavesdroppers on the network (or any 636 intermediaries between the user and the privacy service) could see 637 the very personal information that the user has asked the privacy 638 service to obscure. Unauthorised insertion, deletion of modification 639 of those headers can provide misleading information to users and 640 applications. A SIP entity that can provide a redirection reason in 641 a History-Info header or Diversion header SHOULD be able to suppress 642 this in accordance with privacy requirements of the user concerned. 644 10. References 646 10.1. Normative References 648 [RFC2119] "Key words for use in RFCs to Indicate Requirement 649 Levels", RFC 2119, March 1997. 651 [RFC3261] "SIP: Session Initiation Protocol", RFC 3261, June 2002. 653 [RFC3969] "The Internet Assigned Number Authority (IANA) Uniform 654 Resource Identifier (URI) Parameter Registry for the 655 Session Initiation Protocol (SIP), BCP 99", RFC 3969, 656 December 2004. 658 [RFC4234] "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, 659 October 2005. 661 10.2. Informative References 663 [RFC3323] "A Privacy Mechanism for the Session Initiation Protocol 664 (SIP)", RFC 3323, November 2002. 666 [RFC4244] "An Extension to the Session Initiation Protocol (SIP) for 667 Request History Information", RFC 4244, November 2005. 669 [RFC4458] "Session Initiation Protocol (SIP) URIs for Applications 670 such as Voicemail and Interactive Voice Response (IVR)", 671 RFC 4458, April 2006. 673 [TS_183004] 674 Telecommunications and Internet converged Services and 675 Protocols for Advanced Networking (TISPAN), "PSTN/ISDN 676 simulation services: Communication Diversion (CDIV); 677 Protocol specification, Release 2, ETSI TS 183004", 678 November 2007. 680 [TS_24.604] 681 3rd Generation Partnership Project, "Technical 682 Specification Group Core Network and Terminals ; 683 Communication Diversion (CDIV) using IP Multimedia 684 (IM)Core Network (CN) subsystem ; Protocol specification 685 (Release 8), 3GPP TS 24.604", April 2008. 687 [draft-levy-sip-diversion-08] 688 "Diversion Indication in SIP, 689 draft-levy-sip-diversion-08", August 2004. 691 Authors' Addresses 693 Marianne Mohali 694 France Telecom 695 38-40 rue du General Leclerc 696 Issy-Les-Moulineaux Cedex 9 92794 697 France 699 Phone: +33 1 45 29 45 14 700 Email: marianne.mohali@orange-ftgroup.com 702 Steve Norreys 703 British Telecom 705 Jan Van Gee 706 Belgacom 708 Martin Dolly 709 ATT 711 Francisco Silva 712 Portugal Telecom 714 Guiseppe Sciortino 715 Italtel 717 Cinzia Amenta 718 Italtel 720 Full Copyright Statement 722 Copyright (C) The IETF Trust (2008). 724 This document is subject to the rights, licenses and restrictions 725 contained in BCP 78, and except as set forth therein, the authors 726 retain all their rights. 728 This document and the information contained herein are provided on an 729 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 730 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 731 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 732 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 733 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 734 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 736 Intellectual Property 738 The IETF takes no position regarding the validity or scope of any 739 Intellectual Property Rights or other rights that might be claimed to 740 pertain to the implementation or use of the technology described in 741 this document or the extent to which any license under such rights 742 might or might not be available; nor does it represent that it has 743 made any independent effort to identify any such rights. Information 744 on the procedures with respect to rights in RFC documents can be 745 found in BCP 78 and BCP 79. 747 Copies of IPR disclosures made to the IETF Secretariat and any 748 assurances of licenses to be made available, or the result of an 749 attempt made to obtain a general license or permission for the use of 750 such proprietary rights by implementers or users of this 751 specification can be obtained from the IETF on-line IPR repository at 752 http://www.ietf.org/ipr. 754 The IETF invites any interested party to bring to its attention any 755 copyrights, patents or patent applications, or other proprietary 756 rights that may cover technology that may be required to implement 757 this standard. Please address the information to the IETF at 758 ietf-ipr@ietf.org.