idnits 2.17.1 draft-mohali-diversion-history-info-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 ([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 507 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 (June 24, 2009) is 5414 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3326' is defined on line 916, but no explicit reference was found in the text == Unused Reference: 'RFC3969' is defined on line 919, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) ** Obsolete normative reference: RFC 4244 (Obsoleted by RFC 7044) Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Mohali 3 Internet-Draft France Telecom 4 Intended status: Informational June 24, 2009 5 Expires: December 26, 2009 7 Mapping and interworking of Diversion information Between Diversion and 8 History-Info Headers in the Session Initiation Protocol (SIP) 9 draft-mohali-diversion-history-info-04 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on December 26, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 The Diversion header is not standardized but widely used to convey 48 diverting information in Session Initiation Protocol (SIP) signaling. 49 This informational document proposes a way to interwork call 50 diversion information contained in Diversion header with a History- 51 Info header. In addition, an interworking policy is proposed to 52 manage the headers coexistence. 53 The History-Info header is described in [RFC4244] and the Diversion 54 header is described in [draft-levy-sip-diversion-09]. 55 Note to the RFC-Editor: The reference to this draft should be 56 replaced by the Historic RFC reference (work in progress). 57 Since the Diversion header is used in many existing networks 58 implementations for transport of diversion information and its 59 interworking with standardized solutions is not obvious, an 60 interworking recommendation is 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 requirements and scope . . . . . . . . . . . 5 75 2.2. Interworking recommendations . . . . . . . . . . . . . . . 6 76 2.2.1. SIP network/terminal using Diversion to SIP 77 network/terminal using History-Info header . . . . . . 7 78 2.2.2. SIP network/terminal using History-Info header to 79 SIP network/terminal using Diversion header . . . . . 8 80 3. Headers syntaxes reminder . . . . . . . . . . . . . . . . . . 9 81 3.1. History-Info header syntax . . . . . . . . . . . . . . . . 9 82 3.2. Diversion header syntax . . . . . . . . . . . . . . . . . 11 83 4. Headers in SIP Method . . . . . . . . . . . . . . . . . . . . 12 84 5. Diversion header to History-Info header . . . . . . . . . . . 13 85 6. History-Info header to Diversion header . . . . . . . . . . . 16 86 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 87 7.1. Example with Diversion header changed into 88 History-Info header . . . . . . . . . . . . . . . . . . . 17 89 7.2. Example with History-Info header changed into 90 Diversion header . . . . . . . . . . . . . . . . . . . . . 17 91 7.3. Example with two SIP networks using History-Info 92 header interworking with a SIP network using Diversion 93 header . . . . . . . . . . . . . . . . . . . . . . . . . . 17 94 7.4. Additional interworking Cases . . . . . . . . . . . . . . 19 95 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 96 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 97 10. Acknowlegements . . . . . . . . . . . . . . . . . . . . . . . 21 98 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 99 11.1. Normative References . . . . . . . . . . . . . . . . . . . 21 100 11.2. Informative References . . . . . . . . . . . . . . . . . . 22 101 Appendix A. Interworking between Diversion header and 102 Voicemail URI . . . . . . . . . . . . . . . . . . . . 22 103 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 105 1. Introduction 107 1.1. Overview 109 For some network services (eg. Voicemail, IVR or automatic call 110 distribution), it is helpful for the called SIP user agent to 111 identify from whom and why the session was diverted. For this 112 information to be used in various service providers or by various 113 applications, this redirection information needs to pass through the 114 network. 115 This is possible with two different SIP headers: History-Info 116 header [RFC4244] and Diversion header which are both able to 117 transport diversion information in SIP signaling. Although the 118 Diversion header is not standardized, it is widely used. Therefore, 119 it is useful to have guidelines to make this header interwork with 120 the standard History-Info header. 121 This document provides a mechanism of translation between the 122 Diversion header and the History-Info header. 124 1.2. Background 126 The History-Info header [RFC4244] and the URI extension (including 127 Voicemail URI) [RFC4458] are recommended by IETF to convey 128 redirection information. They are also recommended in the 129 "Communication Diversion (CDIV) service" 3GPP specification 130 [TS_24.604]. 132 At first, the Diversion header was described in 133 [draft-levy-sip-diversion-09], which is today discarded. 134 Note to the RFC-Editor: The reference to this draft should be 135 replaced by the Historic RFC reference (work in progress). 136 This header contains a list of the diverting URIs with associated 137 information providing specific information as to why a call was 138 diverted. Most of implementations have implemented the Diversion 139 header when the History-Info header was not a standard. The IETF has 140 chosen to standardize the History-Info header in part because it can 141 transport general "request history" information which allows the 142 receiving application to determine how and why the session arrived at 143 the application/user. As History-Info header information is larger 144 than call diversion information, it is really important to be sure of 145 not losing information and be able to extract the relevant data using 146 the retargeting cause URI parameter described in [RFC4458] for the 147 transport of the diversion reason. 149 Those headers have different syntaxes described below. Note that the 150 main difference is that the History-Info header is a chronological 151 writing header whereas the Diversion header is the opposite (i.e. the 152 first diversion entry read correspond to the last diverting user). 154 The Appendix provides an interworking guideline between the Diversion 155 header and the Voicemail URI which is another way to convey diversion 156 information described in [RFC4458]. 158 2. Problem Statement 160 2.1. Interworking requirements and scope 162 This section provides the baseline terminology used in the rest of 163 the document and defines the scope of interworking between these two 164 headers that need to be addressed. 165 They are many ways in which SIP signaling can be used to modify a 166 session destination before it is established and many reasons for 167 doing so. The behavior of the SIP entities that will have to further 168 process the session downstream will sometimes vary depending on the 169 reasons that lead to changing the destination, for example whether it 170 is for simple proxy to route the session or for an application server 171 to provide a supplementary service. 172 The approach and scope in which the Diversion header and the History- 173 Info header address this problem are different. For clarity, the 174 following vocabulary is used in this document: 176 Retargeting/redirecting: 177 Retargeting/redirecting refer to the process of a Proxy Server/User 178 Agent Client (UAC) changing a Uniform Resource Identifier (URI) in a 179 request and thus changing the target of the request. These terms are 180 defined in [RFC4244]. The History-Info header is used to store 181 retargeting information. 183 Call forwarding/call diversion/communication diversion: 184 These terms are equivalent and refer to the Communications Diversion 185 (CDIV) supplementary services, based on the ISDN Communication 186 diversion supplementary services and defined in 3GPP [TS_24.604]. 187 They are applicable to entities which are intended to modify the 188 original destination of an IP multimedia session prior to or during 189 the session establishment. 191 This document does not describe when or how History-Info or Diversion 192 headers are used. The following is offered to clarify the context in 193 which this interworking is used. 195 The History-Info header is used in practice to convey call diversion 196 related information by using a cause URI parameter [RFC4458] in the 197 relevant entry. 199 The Diversion header has exactly the same scope as the call diversion 200 service and each header entry reflects a call diversion invocation. 202 The Diversion header is used for recording communication diversion 203 information which could be useful to network entities downstream. 204 Today, this SIP header is implemented by several manufacturers and 205 deployed in several networks. 207 The History-Info header is used to store all retargeting information 208 including call diversion information. 209 Note, however, that the use of cause URI parameter [RFC4458] in a 210 History-Info entry for a call diversion is specific to the 3GPP 211 specifications. RFC4458 focuses on retargeting toward voicemail 212 server and does not specify whether the cause URI parameter should be 213 added or not in a URI for other cases. As a consequence, 214 implementations that do not use the cause URI parameter for call 215 forwarding information, are not considered for the mapping described 216 in this document. Nevertheless, some recommendations are given in 217 the next sections on how not to lose non-mapped information at the 218 boundary between a network region using History-Info header and one 219 using the Diversion header. 221 Since both headers addresses call forwarding needs, diverting 222 information could be mixed-up or be inconsistent if both headers are 223 present in an uncoordinated fashion in the INVITE request. So, 224 Diversion and History-Info headers MUST NOT independently coexist for 225 the session signaling. This specific address how to convert 226 information between the two, and when and how to preserve both 227 headers to cover additional cases. 229 For the transportation of consistent diversion information 230 downstream, it is necessary to make the two headers interwork. 231 Interworking between the Diversion header and the History-Info header 232 is introduced in sections 5 and 6. Since coexistence scenario may 233 vary from one use case to another, guidelines regarding headers 234 interaction are proposed. 236 2.2. Interworking recommendations 238 Interworking function: 239 In a normal case, the network topology assumption is that the 240 interworking described in this document should be performed by a 241 specific SIP border device which by configuration is aware that it is 242 at the border between two regions, one using History-Info header and 243 one using Diversion header. 245 History-Info header is a standardized solution, so a network using 246 the Diversion header MUST be able to provide information to a network 247 using the History-Info header. In this case, to avoid both headers 248 coexistence it is recommended as often as possible to replace the 249 Diversion header with the History-Info header in the INVITE request 250 during the interworking. 252 Since, the History-Info header has a boarder scope than the Diversion 253 header and may be used for services other than call diversion. In 254 addition to tracing call diversion information, History-Info header 255 also acts as a session history and could store all successive R-URI 256 values. Consequently, even if it should be better to remove the 257 History-Info header after the Diversion header has been created to 258 avoid any confusion; if the History-Info header contains 259 supplementary (non-diversion) information it MUST be retained as is 260 and passed transparently in this network. It is possible to have 261 History-Info headers that do not have values that can be mapped into 262 the Diversion header. In this case, no interworking with Diversion 263 header should be performed and implementations will have to decide 264 what to do. This point is out of this document scope. 265 As a conclusion, it is recommended to have local policies minimizing 266 the loss of information and find the best way to keep it up to the 267 terminating user agent. 268 This section describes the basic and commonly used use case. More 269 unusual interworking cases, are described in section 7.5. 271 2.2.1. SIP network/terminal using Diversion to SIP network/terminal 272 using History-Info header 274 When the Diversion header is used to create a History-Info header, 275 the Diversion header MUST be removed in the outgoing INVITE. It is 276 considered that all information present in the Diversion header is 277 transferred in the History-Info header. 279 If a History-Info header is present in the incoming INVITE (in 280 addition to Diversion header), the Diversion header and History-Info 281 header present MUST be mixed and only the diversion information not 282 yet present in the History-Info header MUST be inserted as a last 283 entry (more recent) in the existing History-Info header as 284 recommended in [RFC4244]. 285 As an example, this could be the case of an INVITE coming from 286 network_2 using Diversion header but has previously passed through 287 network_1 using History-Info header (or the network_2 uses History- 288 Info header to transport successive URI information) and going to 289 network_3 using History-Info header. 291 IWF* IWF* 292 network1 | network_2 |network_3 293 History-Info | Diversion |using 294 | |Hist-Info 295 | | 296 UA A P1 AS B | P2 AS C UA C AS D | UA E 297 | | | | | | | | | | 298 |INVITE | | | | | | | | | 299 |------>| | | | | | | | | 300 | | | | | | | | | | 301 | |INVITE | | | | | | | | 302 | |------>| | | | | | | | 303 | |Supported: histinfo | | | | | | 304 | | History-Info: | | | | | | 305 | | ; index=1, | | | | | 306 | | ; index=1.1 | | | | | 307 | | | | | | | | | | 308 | | |INVITE | | | | | | | 309 | | |------>| | | | | | | 310 | | |History-Info: | | | | | | 311 | | |; index=1,| | | | | 312 | | |; index=1.1 | | | | | 313 | | |; cause=302; index=1.1.1 | | | 314 In this case, the incoming INVITE contains a Diversion header and a 315 History-Info header. So that, it is necessary to create, for 316 network_3, a single History-Info header gathering existing 317 information from both the History-Info and the Diversion headers 318 received. Then network_3 could use call forwarding information that 319 is present in a single header and add its own diversion information 320 if necessary. 322 Note: if a network is not able either to use only one header each 323 time, or to maintain both headers up to date, the chronological order 324 could not be certified. 326 Note: it is not possible to have only Diversion header when the 327 History-Info header contains more than call diversion information. 328 If previous policy recommendations are applied, the chronological 329 order is respected as Diversion entries are inserted at the end of 330 the History-Info header taking into account the Diversion internal 331 chronology. 333 2.2.2. SIP network/terminal using History-Info header to SIP network/ 334 terminal using Diversion header 336 When the History-Info header is interpreted to create a Diversion 337 header, some precautions MUST be taken. 338 If the History-Info header contains only communication diversion 339 information, then it MUST be suppressed after the interworking. 340 If the History-Info header contains other information, then only the 341 information of concern to the diverting user MUST be used to create 342 entries in the Diversion header and the History-Info header MUST be 343 kept as received in the INVITE and forwarded downstream. 345 Note: The History-Info header could be used for other reasons than 346 CDIV services, for example by a service which need to know if a 347 specific AS had yet been invoked in the signaling path. If the call 348 is later forwarded to a network using History-Info header, it would 349 be better to not lose history information due to passing though the 350 network which only support Diversion header. A recommended solution 351 MUST NOT disrupt the standard behavior and networks which do not 352 implement the History-Info header MUST be transparent to a received 353 History-Info header. 355 If a Diversion header is present in the incoming INVITE (in addition 356 to History-Info header), only diversion information present in the 357 History-Info header but not in the Diversion header MUST be inserted 358 from the last entry (more recent) into the existing Diversion header 359 as recommended in the Diversion draft [draft-levy-sip-diversion-09]. 360 Note to the RFC-Editor: The reference to this draft should be 361 replaced by the Historic RFC reference (work in progress). 362 Note that the chronological order could not be certified. If 363 previous policy recommendations are respected, this case SHOULD NOT 364 happen. 366 Forking case: 367 The History-Info header enables the recording of sequential forking 368 for the same served-user. During a interworking from the History- 369 Info header to Diversion header, the History-Info entries containing 370 a forking situation (with an incremented "index" parameter) could be 371 either mapped for each entry with a call forwarding "cause" 372 parameter, the interworking entity could choose to create only one 373 Diversion entry or to not apply the interworking. The choice could 374 be done according a local policy. 376 The same logic is applied for an interworking with Voicemail URI (see 377 the Appendix). 379 3. Headers syntaxes reminder 381 3.1. History-Info header syntax 383 History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry) 384 hi-entry = hi-targeted-to-uri *( SEMI hi-param ) 385 hi-targeted-to-uri= name-addr 386 hi-param = hi-index / hi-extension 387 hi-index = "index" EQUAL 1*DIGIT *(DOT 1*DIGIT) 388 hi-extension = generic-param 390 The History-Info header is specified in [RFC4244]. The top-most 391 History-Info entry (first in the list) corresponds to the oldest 392 history information. A hi-entry may contain a cause URI parameter 393 expressing the diversion reason. This optional cause URI parameter 394 is defined in [RFC4458] with the following syntax: cause-param = 395 "cause" EQUAL Status-Code. This parameter is also named cause-param 396 and should be inserted in the History-Info entry (URI) of the 397 diverted-to user in case of call diversion as recommended in the 3GPP 398 CDIV specification [TS_24.604]. The cause values used in the cause- 399 param for the diverting reason are listed in the RFC and because it 400 is a parameter dedicated to call forwarding service, its presence is 401 used to determine that a hi-entry is a diverting user. More exactly, 402 each diverting user is located in the hi-entry before the one 403 containing a cause-param with cause value as listed in RFC 4458. 405 Moreover, the Reason header defined in [RFC3326]SHOULD be escaped in 406 the hi-entry of the diverting user when the call diversion is due to 407 a SIP response received. The Reason header contains a cause 408 parameter set to the true SIP response code received (Status-Code). 409 Therefore, in case of call diversion due to a SIP response, both 410 cause parameters should be used. The complexity is that these 411 parameters could be used at the same time in the History-Info header 412 but not in the same hi-entry and not with the same meaning. Only the 413 cause-param is dedicated to call diversion service. The 'cause' 414 Reason header parameter is not taken into account in the mapping with 415 a Diversion header. 417 [RFC4458] also defines the 'target' URI parameter which could be 418 inserted in a R-URI and consequently in the hi-targeted-to-uri. This 419 parameter is used to keep the diverting user address in the 420 downstream INVITE request in Voicemail URI implementation. As this 421 information is yet present in the hi-entries, the 'target' URI 422 parameter is not taken into account regarding the interworking with 423 the Diversion header. From the Diversion header, it could be 424 possible to create the 'target' URI parameter in the hi-entries 425 and/or in the R-URI but this possibility is on local policies 426 responsabilty and not described in this document. 428 A Privacy header as defined in [RFC3323] could also be included in 429 hi-entries with the 'history' value defined in the RFC4244. 431 The index parameter is a string of digits, separated by dots to 432 indicate the number of forward hops and retargets. first one is 434 Note: A history entry could contain the "gr" parameter. Regardless 435 the rules concerning "gr" parameter defined in [TS_24.604] which must 436 be applied, this parameter has no impact on the mapping and must only 437 be copied with the served user address. 439 Example: 441 History-Info: 442 ;index=1, 444 ;index=1.1, 445 ; index=1.1.1, 447 Policy concerning "histinfo" option tag in Supported header: 448 According to [RFC4244], a proxy that receives a Request with the 449 "histinfo" option tag in the Supported header should return captured 450 History-Info in subsequent, provisional and final responses to the 451 Request. The behavior depends upon whether the local policy supports 452 the capture of History-Info or not. 454 3.2. Diversion header syntax 456 The current document is not written to define again the Diversion 457 header and its use but to be sure that the syntax is interpreted in 458 the same way by everyone. So that, the Diversion syntax is here a 459 little changed to correspond to the current ABNF [RFC4234]: 461 Diversion = "Diversion" HCOLON diversion-params *(COMMA diversion- 462 params) 463 diversion-params = name-addr *(SEMI (diversion-reason / diversion- 464 counter / diversion-limit / diversion-privacy / diversion-screen / 465 diversion-extension)) 466 diversion-reason = "reason" EQUAL ("unknown" / "user-busy" / "no- 467 answer" / "unavailable" / "unconditional" / "time-of-day" / "do-not- 468 disturb" / "deflection" / "follow-me" / "out-of-service" / "away" / 469 token / quoted-string) 470 diversion-counter = "counter" EQUAL 1*2DIGIT 471 diversion-limit = "limit" EQUAL 1*2DIGIT 472 diversion-privacy = "privacy" EQUAL ("full" / "name" / "uri" / "off" 473 / token / quoted-string) 474 diversion-screen = "screen" EQUAL ("yes" / "no" / token / quoted- 475 string) 476 diversion-extension = token [EQUAL (token / quoted-string)] 478 Note: The Diversion header could be used in the comma-separated 479 format as described below and in a header-separated format. Both 480 formats could be combined a received INVITE as RECOMMENDED in 481 [RFC3261]. 483 Example: 485 Diversion: 486 diverting_user2_addr; reason="user-busy"; counter=1; privacy=full, 487 diverting_user1_addr; reason="unconditional"; counter=1; privacy=off 489 4. Headers in SIP Method 491 You can find here a reminder of History-Info header field and 492 Diversion header field in relation to methods. As those headers do 493 not have the same capabilities, it is necessary to clarify the 494 interworking. 496 Use of History-Info header field: 498 Header field where proxy ACK BYE CAN INV OPT REG MSG 499 ------------ ----- ----- --- --- --- --- --- --- --- 500 History-Info amdr - - - o o o o 501 SUB NOT REF INF UPD PRA PUB 502 --- --- --- --- --- --- --- 503 History-Info amdr o o o - - - o 505 Use of Diversion header field: 507 Header field where enc. e-e ACK BYE CAN INV OPT REG 508 ------------ ----- ----- --- --- --- --- --- --- --- 509 Diversion R h - - - o - - 510 Diversion 3xx h - - - o - - 512 The recommended interworking presented in this document SHOULD apply 513 only for INVITE requests. 515 In 3xx responses, both headers could be present. 516 When a proxy wants to interwork with a network supporting the other 517 header field, it SHOULD apply the interworking between Diversion 518 header and History-Info header in the 3xx response. 519 When a recursing proxy redirects an initial INVITE after receiving a 520 3xx response, it SHOULD add as a last entry either a Diversion header 521 or History-Info header (according to its capabilities) in the 522 forwarded INVITE. Local policies could apply to send the received 523 header in the next INVITE or not. 525 Other messages where History-Info could be present are not used for 526 the Call Forwarding service and SHOULD NOT be changed into Diversion 527 header. The destination network MUST be transparent the received 528 History-Info header. 529 Note : the following mapping is inspired from the ISUP to SIP 530 interworking described in [TS_29.163]. 532 5. Diversion header to History-Info header 534 The following text is valid only if no History-Info is present in the 535 INVITE request. If at least one History-Info header is present, the 536 interworking function shall adapt its behavior to respect the 537 chronological order. See section 2.2. 538 For N Diversion entries N+1 History-Info entries MUST be created. To 539 create the History-Info entries in the same order than during a 540 session establishment, the Diversion entries MUST be mapped from the 541 bottom-most until the top-most. Each Diversion entry shall be mapped 542 into a History-Info entry. An additional (the last one) History-Info 543 entry must be created with the diverted-to party address present in 544 the R-URI of the received INVITE, The mapping is described below. 546 The first entry created in the History-Info header contains: 548 - a hi-target-to-uri with the name-addr parameter of the bottom- 549 most Diversion header 551 - if a privacy parameter is present in the bottom-most Diversion 552 entry, then a Privacy header could be escaped in the History-Info 553 header as described below, 555 - an index set to 1. 557 For each following Diversion entry (from bottom to top), the History- 558 info entries are created as following (from top to bottom): 560 Source Destination 561 Diversion header component: History-Info header component: 562 ======================================================================= 563 Name-addr Hi-target-to-uri 565 ======================================================================= 566 Reason of the previous cause-param (not present in 567 Diversion entry the first created hi-entry) 568 "unknown"---------------------------------404 (default 'cause' value) 569 "unconditional"---------------------------302 570 "user-busy"-------------------------------486 571 "no-answer"-------------------------------408 572 "deflection "-----------------------------480 or 487 573 "unavailable"-----------------------------404 574 "time-of-day"-----------------------------404 (default) 575 "do-not-disturb"--------------------------404 (default) 576 "follow-me"-------------------------------404 (default) 577 "out-of-service"--------------------------404 (default) 578 "away"------------------------------------404 (default) 580 ======================================================================= 581 Counter Hi-index 582 "1" or parameter -------------------------The previous created index 583 no present is incremented with ".1" 584 Superior to "1" --------------------------Create N-1 placeholder History 585 (i.e. N) entry with the previous index 586 incremented with ".1" 587 Then the History-Info header 588 created with the Diversion 589 entry with the previous index 590 incremented with ".1" 591 ======================================================================= 592 Privacy Privacy header escaped in the 593 hi-targeted-to-uri 594 "full"------------------------------------"history" 595 "Off"-------------------------------------Privacy header field 596 absent or "none" 597 "name"------------------------------------"history" 598 "uri"-------------------------------------"history" 599 ======================================================================= 601 A last History-Info entry is created and contains: 603 - a hi-target-to-uri with the Request-URI of the INVITE request. 605 - a cause-param from the top-most Diversion entry, mapped from the 606 diversion-reason as described above. 608 - if a privacy parameter is present in the top-most Diversion 609 entry, then a Privacy header could be escaped in the History-Info 610 header as described above, 612 - an index set to the previous created index and incremented with 613 ".1" 615 Note: For other optional Diversion parameters, there is no 616 recommendation as History-Info header does not provide equivalent 617 parameters. 619 Note: For values of the diversion-reason values which are mapped with 620 a recommended default value, it could also be possible to choose 621 another value. The cause-param URI parameter offers less possible 622 values than the diversion-reason parameter. However, it has been 623 considered that cause-param values list was sufficient to implement 624 CDIV service as defined in 3GPP as it cover a large portion of cases. 626 Note : The Diversion header could contain a Tel:URI in the name-addr 627 parameter but it seems to not be possible to have a Tel:URI in the 628 History-Info header. RFC3261 gives an indication as to the mapping 629 between sip: and tel: URIs but in this particular case it is 630 difficult to assign a valid hostport as the diversion has occurred in 631 a previous network and a valid hostport is difficult to determine. 632 So, it is suggested that in case of Tel:URI in the Diversion header, 633 the History-Info header should be created with a SIP URI with 634 user=phone. 636 Note: 637 The Diversion header allows the carrying of a counter which had 638 retained the information about the number of redirections which have 639 occurred. History-Info does not have an equivalent because to trace 640 and count diversion occurred it is necessary to count cause parameter 641 containing a value associated to a call diversion. To read the index 642 value is not enough. With the use of the "placeholder" entry the 643 History-info header entries could reflect the real number of 644 diversion occurred. 645 Example of placeholder entry in the History-Info header: 646 ;index=1.1 647 ;index=1.1.1 648 cause=xxx reflects the diverting reason of a previous diverting user. 649 For a placeholder hi-entry the value "404" shall be taken for the 650 cause-param and so, located in the next hi-entry. 652 Concerning local policies recommendations about headers coexistence 653 in the INVITE request, see sections 2.2 and 7.5. 655 6. History-Info header to Diversion header 657 To create the Diversion entries in the same order than during a 658 session establishment, the History-Info entries MUST be mapped from 659 the top-most until the bottom-most. The first History-Info header 660 entry selected will be mapped into the last Diversion header entry 661 and so on. One Diversion header entry MUST be created for each 662 History-Info entry with a cause-param reflecting a diverting reason 663 as listed in the [RFC4458]. 665 In this case, the History-Info header MUST be mapped into the 666 Diversion header as following: 668 Source Destination 669 History-Info header component: Diversion header component: 670 ===================================================================== 671 Hi-target-to-uri of the Name-addr 672 History-Info which precedes the one 673 containing a diverting cause-param 675 ===================================================================== 676 Cause-param Reason 677 404---------------------------------------"unknown" (default value) 678 302---------------------------------------"unconditional" 679 486---------------------------------------"user-busy" 680 408---------------------------------------"no-answer" 681 480 or 487--------------------------------"deflection " 682 503---------------------------------------"unavailable" 684 ===================================================================== 685 Hi-index Counter 686 Mandatory parameter for--------------------The counter is set to "1". 687 History-Info reflecting 688 the chronological order 689 of the information. 690 ===================================================================== 691 Privacy header [RFC3323]escaped in the Privacy 692 hi-targeted-to-uri of the 693 History-Info which precedes the one 694 containing a diverting cause-param. 695 Optional parameter for History-Info, 696 this Privacy indicates that this 697 specific History-Info header SHOULD 698 not be forwarded. 699 "history"----------------------------------"full" 700 Privacy header field ----------------------"Off" 701 Absent or "none" 702 ===================================================================== 704 Note: For other optional History-Info parameters, there is no 705 recommendation as Diversion header does not provide equivalent 706 parameters. 708 Concerning local policies recommendations about headers coexistence 709 in the INVITE request, see section 2.2. 711 7. Examples 713 7.1. Example with Diversion header changed into History-Info header 715 INVITE last_diverting_target 716 Diversion: 717 diverting_user3_address;reason=unconditional;counter=1;privacy=off, 718 diverting_user2_address;reason=user-busy;counter=1;privacy=full, 719 diverting_user1_address;reason=no-answer;counter=1;privacy=off 721 Mapped into: 723 History-Info: 724 ; index=1, 725 ;index=1.1, 726 ;index=1.1.1, 727 ;index=1.1.1.1, 729 7.2. Example with History-Info header changed into Diversion header 731 History-Info: 732 ; index=1, 733 ;index=1.1, 734 ;index=1.1.1 736 Mapped into: 738 Diversion: 739 diverting_user2_address; reason=user-busy; counter=1; privacy=off, 740 diverting_user1_address; reason=unconditional; counter=1; 741 privacy=full 743 7.3. Example with two SIP networks using History-Info header 744 interworking with a SIP network using Diversion header 746 A -> P1 -> B -> C -> P2 -> D-> E 747 A, B, C, D and E are users. 748 B, C and D have Call Forwarding service invoked. 749 P1 and P2 are proxies. 750 Only relevant information is shown on the following call flow. 752 IWF* IWF* 753 SIP network using | SIP network using |SIP net. 754 History-Info | Diversion |using 755 | |Hist-Info 756 | | 757 UA A P1 AS B | P2 AS C UA C AS D | UA E 758 | | | | | | | | | | 759 |INV B | | | | | | | | | 760 |------>| | | | | | | | | 761 | | | | | | | | | | 762 | |INV B | | | | | | | | 763 | |------>| | | | | | | | 764 | |Supported: histinfo | | | | | | 765 | | History-Info: | | | | | | 766 | | ; index=1, | | | | | 767 | | ; index=1.1 | | | | | 768 | | | | | | | | | | 769 | | |INV C | | | | | | | 770 | | |------>| | | | | | | 771 | | |History-Info: | | | | | | 772 | | |; index=1,| | | | | 773 | | |; index=1.1 | | | | | 774 | | |; index=1.1.1 | | | 775 | | | | | | | | | | 776 | | | |INV C | | | | | | 777 | | | |------>| | | | | | 778 | | | |Diversion: | | | | | 779 | | | |B reason= unconditional counter=1 | | 780 | | | |History-Info: | | | | | 781 | | | |; index=1,| | | | 782 | | | |; index=1.1 | | | | 783 | | | |; index=1.1.1| | 784 | | | | | | | | | | 785 | | | | |INV C | | | | | 786 | | | | |------>| | | | | 787 | | | | |No modification of Diversion due to P2| 788 | | | | | | | | | | 789 | | | | | |INV C | | | | 790 | | | | | |------>| | | | 791 | | | | | | | | | | 792 | | | | | |<--180-| | | | 793 | | | | | | | | | | 794 | | | | | No response timer expire | | 795 | | | | | |---INV D --->| | | 796 | | | Diversion: | | | 797 | | | userC; reason=no-answer; counter=1; privacy=full, 798 | | | userB; reason=unconditional; counter=1; privacy=off, 799 | | | History-Info: | | | 800 | | | ; index=1, | | | 801 | | | ; index=1.1 | | | 802 | | | ; index=1.1.1 | | 803 | | | | | | | | | | 804 | | | | | | | |INV E | | 805 | | | | | | | |------>| | 806 | | | Diversion: | | 807 | | | userD; reason=time-of-day; counter=1; privacy=off| 808 | | | userC; reason=no-answer; counter=1; privacy=full,| 809 | | | userB; reason=unconditional; counter=1; privacy=off, 810 | | | History-Info: | | 811 | | | ; index=1, | | 812 | | | ; index=1.1 | | 813 | | | ; index=1.1.1 | | 814 | | | | | | | | | | 815 | | | | | | | | | INV E | 816 | | | | | | | | |------->| 817 | | | History-Info: | 818 | | | ; index=1, | 819 | | | ; index=1.1, | 820 | | | ; index=1.1.1, | 821 | | | ; index=1.1.1.1, | 822 | | | ; index=1.1.1.1.1, 823 | | | ; index=1.1.1.1.1.1 | 824 | | | | | | | | | | 825 | | | | | | | | | | 827 * Note: The IWF is an interworking function which could be a stand-alone 828 equipment not defined in this draft (it could be a proxy). 830 7.4. Additional interworking Cases 832 Even if for particular cases in which both headers could coexist it 833 should be the network local policy responsibility to make it work 834 together, here are described some situations and some recommendations 835 on the behavior to follow. 837 In the case where there is one network which includes different 838 nodes, some of which support Diversion header and some which support 839 History-info header, the problem is when any node handling a message 840 does not know which node will next handle the message. This case can 841 occur when the network has new and old nodes, the older ones using 842 Diversion header and the more recent History-Info header. 843 While a network replacement may be occurring there will be a time 844 when both nodes exist in the network. If the different nodes are 845 being used to support different subscriber types due to different 846 node capabilities then the problem is more important. In this case 847 there is a need to pass both History-Info header and Diversion header 848 within the network core. 849 These headers need to be equivalent to ensure that whatever node 850 receives the message the correct diversion information is received. 851 This requires that whichever header is received there is a 852 requirement to be able to compare the headers and to convert the 853 headers. Depending upon node capability then it may be possible to 854 make assumptions as to how this is handled. 855 If it is known that the older Diversion header supporting nodes do 856 not pass on any received History-Info header then the interworking 857 becomes easier. If a message is received with only Diversion headers 858 then it has originated from an 'old' node. The equivalent History- 859 Info entries can be created and these can then be passed as well as 860 the Diversion header. 861 If the node creates a new History-Info header for a call diversion, 862 then an additional Diversion header must be created. 863 If the next node is an 'old' node then the Diversion header will be 864 used by that node and the History-Info entries will be removed from 865 the message when it is passed on. 866 If the next node is a new node then the presence of both Diversion 867 header and History-Info header means that interworking has already 868 occurred and the Diversion and History-Info entries must be 869 considered equivalent. 870 If both nodes pass on both History-Info header and Diversion header 871 but only actively use one, then both types of node need to perform 872 the interworking and must maintain equivalence between the headers. 873 This will eventually result in the use of Diversion header being 874 deprecated when all nodes in the network support History-Info header. 876 8. IANA Considerations 878 This document makes no request of IANA. 880 9. Security Considerations 882 The use of Diversion header or History-Info header require to apply 883 the requested privacy and integrity asked by each diverting user or 884 entity. Without integrity, the requested privacy functions could be 885 downgraded or eliminated, potentially exposing identity information. 886 Without confidentiality, eavesdroppers on the network (or any 887 intermediaries between the user and the privacy service) could see 888 the very personal information that the user has asked the privacy 889 service to obscure. Unauthorised insertion, deletion of modification 890 of those headers can provide misleading information to users and 891 applications. A SIP entity that can provide a redirection reason in 892 a History-Info header or Diversion header SHOULD be able to suppress 893 this in accordance with privacy requirements of the user concerned. 895 10. Acknowlegements 897 The editor would like to acknowledge the constructive feedback and 898 support provided by Steve Norreys, Jan Van Geel, Martin Dolly, 899 Francisco Silva, Guiseppe. Sciortino, Cinza Amenta, Christer 900 Holmberg, Ian Elz, Jean-Francois Mule, Lionel Morand, Xavier Marjou, 901 Philippe Fouquart, Mary Barnes, Francois Audet, Erick Sasaki, Shida 902 Schubert and Joel M. Halpern. 904 11. References 906 11.1. Normative References 908 [RFC2119] "Key words for use in RFCs to Indicate Requirement 909 Levels", RFC 2119, March 1997. 911 [RFC3261] "SIP: Session Initiation Protocol", RFC 3261, June 2002. 913 [RFC3323] "A Privacy Mechanism for the Session Initiation Protocol 914 (SIP)", RFC 3323, November 2002. 916 [RFC3326] "The Reason Header Field for the Session Initiation 917 Protocol (SIP)", RFC 3326, December 2002. 919 [RFC3969] "The Internet Assigned Number Authority (IANA) Uniform 920 Resource Identifier (URI) Parameter Registry for the 921 Session Initiation Protocol (SIP), BCP 99", RFC 3969, 922 December 2004. 924 [RFC4234] "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, 925 October 2005. 927 [RFC4244] "An Extension to the Session Initiation Protocol (SIP) for 928 Request History Information", RFC 4244, November 2005. 930 11.2. Informative References 932 [RFC4458] "Session Initiation Protocol (SIP) URIs for Applications 933 such as Voicemail and Interactive Voice Response (IVR)", 934 RFC 4458, April 2006. 936 [TS_24.604] 937 3rd Generation Partnership Project, "Technical 938 Specification Group Core Network and Terminals ; 939 Communication Diversion (CDIV) using IP Multimedia 940 (IM)Core Network (CN) subsystem ; Protocol specification 941 (Release 8), 3GPP TS 24.604", December 2008. 943 [TS_29.163] 944 3rd Generation Partnership Project, "Technical 945 Specification Group Core Network and Terminals ; 946 Interworking between the IP Multimedia (IM) Core Network 947 (CN) Subsystem and Circuit Switched (CS) networks (Release 948 8)", December 2008. 950 [draft-levy-sip-diversion-09] 951 "Diversion Indication in SIP, 952 draft-levy-sip-diversion-09", May 2009. 954 Appendix A. Interworking between Diversion header and Voicemail URI 956 Voicemail URI is a mechanism described in RFC4458 to provide a simple 957 way to transport only one redirecting user address and the reason why 958 the diversion occurred in the R-URI of the INVITE request. This 959 mechanism is mainly used for call diversion to a voicemail. 961 Diversion header to Voicemail URI: 963 Received: 964 Diversion: userA-address;reason=user-busy;counter=1;privacy=full 966 Sent (Voicemail URI created in the R-URI line of the INVITE): 967 sip: voicemail@example.com;target=userA-address;cause=486 SIP/2.0 969 Mapping of the Redirection Reason is the same as for History-Info 970 header with a default value set to 404. 971 If the Diversion header contains more than one Diversion entry, the 972 choice of the redirecting user information inserted in the URI is in 973 charge of the network local policy. For example, the choice 974 criterion of the redirecting information inserted in the URI could be 975 the destination of forwarded INVITE request (if the voicemail serves 976 this user or not). 978 Note: This interworking could be done in addition to the interworking 979 of the Diversion header into the History-Info header. 981 Voicemail URI to Diversion header: 982 In case of real Voicemail, this way of interworking should not 983 happen. However, if for any reason it occurs, it is recommended to 984 do it as following: 986 Received: 987 INVITE sip: voicemail@example.com;\ 988 target=sip:+33145454500%40example.com;user=phone;\ 989 cause=302 SIP/2.0 991 Sent in the forwarded INVITE: 992 Diversion: sip:+ 993 33145454500%40example.com;user=phone;reason=unconditional;counter=1 995 Author's Address 997 Marianne Mohali 998 France Telecom 999 38-40 rue du General Leclerc 1000 Issy-Les-Moulineaux Cedex 9 92794 1001 France 1003 Phone: +33 1 45 29 45 14 1004 Email: marianne.mohali@orange-ftgroup.com