idnits 2.17.1 draft-jennings-sip-voicemail-uri-06.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 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 852. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 829. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 836. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 842. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 190: '...rtion of the URI SHOULD be used as the...' RFC 2119 keyword, line 191: '..., while the target SHOULD be mapped to...' RFC 2119 keyword, line 194: '...rection counters SHOULD be set to one ...' RFC 2119 keyword, line 199: '... The UM system MAY use the fact that...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 12, 2006) is 6678 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFCAAAA' on line 627 ** Obsolete normative reference: RFC 4234 (ref. '4') (Obsoleted by RFC 5234) -- Obsolete informational reference (is this intentional?): RFC 4244 (ref. '6') (Obsoleted by RFC 7044) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Jennings 3 Internet-Draft Cisco Systems 4 Expires: July 16, 2006 F. Audet 5 Nortel Networks 6 J. Elwell 7 Siemens Communications 8 January 12, 2006 10 Session Initiation Protocol (SIP) URIs for Applications such as 11 Voicemail and Interactive Voice Response (IVR) 12 draft-jennings-sip-voicemail-uri-06 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on July 16, 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2006). 43 Abstract 45 The Session Initiation Protocol (SIP) is often used to initiate 46 connections to applications such as voicemail or interactive voice 47 recognition systems. This specification describes a convention for 48 forming SIP service URIs that request particular services based on 49 redirecting targets from such applications. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Mechanism (UAS and Proxy) . . . . . . . . . . . . . . . . . . 4 55 2.1. Target . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.2. Cause . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.3. Retrieving Messages . . . . . . . . . . . . . . . . . . . 5 58 3. Interaction with Request History Information . . . . . . . . . 5 59 4. Limitations of Voicemail URI . . . . . . . . . . . . . . . . . 6 60 5. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 6.1. Proxy Forwards Busy to Voicemail . . . . . . . . . . . . . 7 63 6.2. Endpoint forwards busy to Voicemail . . . . . . . . . . . 9 64 6.3. Endpoint forwards busy to TDM via a gateway . . . . . . . 11 65 6.4. Endpoint forwards busy to Voicemail with History Info . . 12 66 6.5. Zero Configuration UM System . . . . . . . . . . . . . . . 14 67 6.6. Call Coverage . . . . . . . . . . . . . . . . . . . . . . 15 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 70 8.1. Integrity Protection of Forwarding in SIP . . . . . . . . 16 71 8.2. Privacy Related Issues on the Second Call Leg . . . . . . 17 72 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 73 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 74 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 75 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 77 Intellectual Property and Copyright Statements . . . . . . . . . . 21 79 1. Introduction 81 Many applications such as Unified Messaging (UM systems and 82 Interactive Voice Recognition (IVR) systems have been developed out 83 of traditional telephony. They can be used for storing and 84 interacting with voice, video, faxes, email, and instant messaging 85 services. Users often use SIP to initiate communications with these 86 applications. When a SIP call is routed to an application, it is 87 necessary that the application be able to obtain several bits of 88 information from the session initiation message so that it can 89 deliver the desired services. 91 For the purpose of this document, we will use UM as the main example, 92 but other applications may use the mechanism defined in this 93 document. The UM needs to know what mailbox should be used and 94 possible reasons for the type of service desired from the UM. Many 95 voice mail systems provide different greetings depending whether the 96 call went to voicemail because the user was busy or because the user 97 did not answer. All of this information can be delivered in existing 98 SIP signaling from the call control that retargets the call to the 99 UM, but there are no conventions for describing how the desired 100 mailbox and the service requested are expressed. It would be 101 possible for every vendor to make this configurable so that any site 102 could get it to work; however, this approach is unrealistic for 103 achieving interoperability among call control, gateways, and unified 104 messaging systems from different vendors. This specification 105 describes a convention for describing this mailbox and service 106 information in the SIP URI so that vendors and operators can build 107 interoperable systems. 109 If there were no need to interoperate with TDM based voicemail 110 systems or to allow TDM systems to use VoIP unified messaging 111 systems, this problem would be a little easier. The problem that is 112 introduced in the VoIP to TDM case is as follows. The SIP system 113 needs to tell a PSTN GW both the subscriber's mailbox identifier 114 (which typically looks like a phone number) and the address of the 115 voicemail system in the TDM network (again a phone number). 117 The question has been asked why the To header cannot be used to 118 specify which mailbox to use. One problem is that the call control 119 proxies cannot modify the To header, and the UACs often set it 120 incorrectly because they do not have information about the 121 subscribers in the domain they are trying to call. This happens 122 because the routing of the call often translates the URI multiple 123 times before it results in an identifier for the desired user that is 124 valid in the namespace that the UM system understands. 126 2. Mechanism (UAS and Proxy) 128 The mechanism works by encoding the information for the desired 129 service in the SIP Request-URI that is sent to the UM system. Two 130 chunks of information are encoded, the first being the target mailbox 131 to use and the second being the SIP status code that caused this 132 retargeting and indicates the desired service. The userinfo and 133 hostport parts of the Request-URI will identify the voicemail 134 service, the target mailbox can be put in the target parameter and 135 the reason can be put in the cause parameter. For example, if the 136 proxy wished to use Bob's mailbox because his phone was busy, the URI 137 sent to the UM system could be something like: 139 sip:voicemail@example.com;target=bob%40example.com;cause=486 141 2.1. Target 143 Target is a URI parameter that indicates the address of the 144 retargeting entity: in the context of UM, this can be the mailbox 145 number. For example, in the case of a voice mail system on the PSTN, 146 the user portion will contain the phone number of the voice mail 147 system, while the target will contain the phone number of the 148 subscriber's mailbox. 150 2.2. Cause 152 Cause is a URI parameter that is used to indicate the service that 153 the UAS receiving the message should perform. The following values 154 for this URI parameter are defined: 156 +---------------------------------+-------+ 157 | Redirecting Reason | Value | 158 +---------------------------------+-------+ 159 | Unknown/Not available | 404 | 160 | User Busy | 486 | 161 | No Reply | 408 | 162 | Unconditional | 302 | 163 | Deflection during alerting | 487 | 164 | Deflection immediate response | 480 | 165 | Mobile subscriber not reachable | 503 | 166 +---------------------------------+-------+ 168 The mapping to PSTN protocols is important both for gateways that 169 connect the IP network to existing TDM customer's equipment, such as 170 PBXs and voicemail systems, and for gateways that connect the IP 171 network to the PSTN network. ISUP has signaling encodings for this 172 information that can be treated as roughly equivalent for the 173 purposes here. For this reason, this specification uses the names of 174 Redirecting Reason values defined in ITU-T Q.732.2-5 [8]. In this 175 specification, the Redirecting Reason Values are referred to as 176 "Causes". It should be understood that the term "Cause" has nothing 177 to do with PSTN "Cause values" (as per ITU-T Q.850 [9] and RFC 3398 178 [5]) but are instead mapped to ITU-T Q.732.2-5 Redirecting Reasons. 179 Since ISUP interoperates with other PSTN networks such as Q.931 [10] 180 and QSIG [11] using well-known rules, it makes sense to use the ISUP 181 names as the most appropriate superset. If no appropriate mapping to 182 a cause value defined in this specification exists in a network, it 183 would be mapped to 302 "Unconditional". Similarly, if the mapping 184 occurs from one of the causes defined in this specification to a PSTN 185 system that does not have an equivalent reason value, it would be 186 mapped to that network's equivalent of "Unconditional". If a new 187 cause parameter needs to be defined, this specification will have to 188 be updated. 190 The user portion of the URI SHOULD be used as the address of the 191 voicemail system on the PSTN, while the target SHOULD be mapped to 192 the original redirecting number on the PSTN side. 194 The redirection counters SHOULD be set to one unless additional 195 information is available. 197 2.3. Retrieving Messages 199 The UM system MAY use the fact that the From header is the same as 200 the URI target as a hint that the user wishes to retrieve messages. 202 3. Interaction with Request History Information 204 The Request History mechanism [6] provides more information relating 205 to multiple retargetings. It is reasonable to have systems in which 206 both the information in this specification and the History 207 information are included and one or both are used. 209 History-Info specifies a means of providing the UAS and UAC with 210 information about the retargeting of a request. This information 211 includes the initial Request-URI and any retarget-to URIs. This 212 information is placed in the History-Info header field, which, except 213 where prevented by privacy considerations, is built up as the request 214 progresses and, upon reaching the UAS, is returned in certain 215 responses. 217 History-Info, when deployed at relevant SIP entities, is intended to 218 provide a comprehensive trace of retargeting for a SIP request, along 219 with the SIP response codes that led to retargeting. 221 History-Info can complement this specification. In particular, when 222 a proxy inserts a URI containing the parameters defined in this 223 specification into the Request-URI of a forwarded request, the proxy 224 can also insert a History-Info header field entry into the forwarded 225 request and the URI in that entry will incorporate these parameters. 226 Therefore even if the Request-URI is replaced as a result of 227 rerouting by a downstream proxy, the History-Info header field will 228 still contain these parameters, which may be of use to the UAS. 229 Consequently, UAS that make use of this information may find the 230 information in the History-Info header, and/or in the Request-URI, 231 depending on the capability of the proxy to support generation of 232 History-Info, or the behavior of downstream proxies, and therefore 233 applications need to take this into account. 235 4. Limitations of Voicemail URI 237 This specification requires the proxy that is requesting the service 238 to understand whether the UM system it is targeting supports the 239 syntax defined in this specification. Today, this information is 240 provided to the proxy by configuration. For practical purposes this 241 means that the approach is unlikely to work in cases in which the 242 proxy is not configured with information about the UM system or the 243 UM is not in the same administrative domain. 245 This approach only works when the service the call control wants 246 applied is fairly simple. For example it does not allow the proxy to 247 express information like "Do not offer to connect to the target's 248 colleague because that address has already been tried". 250 The limitations discussed in this section are addressed by History- 251 Info [6]. 253 5. Syntax 255 The ABNF[4] grammar for these parameters is shown below. The 256 definitions of pvalue and Status-Code are defined in the ABNF in RFC 257 3261[1]. 259 target-param = "target" EQUAL pvalue 261 cause-param = "cause" EQUAL Status-Code 263 It is worth noting that the ABNF requires some characters to be 264 escaped if they occur in the value of the target parameters. For 265 example, the "@" character needs to be escaped. 267 6. Examples 269 This section provides some example use cases for the solution 270 proposed in this document. For the purpose of this document, UM is 271 used as the main example, but other applications may use this 272 mechanism. The examples are intended to highlight the potential 273 applicability of this solution and are not intended to limit its 274 applicability. 276 Also the examples show just service retargeting on busy, but can 277 easily be adapted to show other forms of retargeting. 279 In several of the examples, the URI are broken across more than one 280 line. This was only done for formatting and is not a valid SIP 281 message. Some of the characters in the URIs are not correctly 282 escaped to improve readability. The examples are all shown using 283 sip: with UDP transport, for readability. It should be understood 284 that using sips: with TLS transport is preferable. 286 6.1. Proxy Forwards Busy to Voicemail 288 In this example, Alice calls Bob. Bob's proxy determines that Bob is 289 busy, and the proxy forwards the call to Bob's voicemail. Alice's 290 phone is at 192.0.2.1 while Bob's phone is at 192.0.2.2. The 291 important thing to note is the URI in message F7. 293 Alice Proxy Bob voicemail 294 | | | | 295 | INVITE F1 | | | 296 |--------------->| INVITE F2 | | 297 | |------------->| | 298 |(100 Trying) F3 | | | 299 |<---------------| 486 Busy F4 | | 300 | |<-------------| | 301 | | ACK F5 | | 302 | |------------->| | 303 |(181 Call is Being Forwarded) F6 | 304 |<---------------| | INVITE F7 | 305 | |--------------------------------->| 306 * Rest of flow not shown * 308 F1: INVITE 192.0.2.1 -> proxy.example.com 310 INVITE sip:+15555551002@example.com;user=phone SIP/2.0 311 Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9 312 From: Alice ;tag=9fxced76sl 313 To: sip:+15555551002@example.com;user=phone 314 Call-ID: c3x842276298220188511 315 CSeq: 1 INVITE 316 Max-Forwards: 70 317 Contact: 318 Content-Type: application/sdp 319 Content-Length: *Body length goes here* 321 * SDP goes here* 323 F2: INVITE proxy.example.com -> 192.0.2.2 325 INVITE sip:+15555551002@192.0.2.2 SIP/2.0 326 Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1 327 Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9 328 From: Alice ;tag=9fxced76sl 329 To: sip:+15555551002@example.com;user=phone 330 Call-ID: c3x842276298220188511 331 CSeq: 1 INVITE 332 Max-Forwards: 70 333 Contact: 334 Content-Type: application/sdp 335 Content-Length: *Body length goes here* 337 * SDP goes here* 339 F4: 486 192.0.2.2 -> proxy.example.com 341 SIP/2.0 486 Busy Here 342 Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1 343 Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9 344 From: Alice ;tag=9fxced76sl 345 To: sip:+15555551002@example.com;user=phone;tag=09xde23d80 346 Call-ID: c3x842276298220188511 347 CSeq: 1 INVITE 348 Content-Length: 0 349 F7: INVITE proxy.example.com -> um.example.com 351 INVITE sip:voicemail@example.com;\ 352 target=sip:+15555551002%40example.com;user=phone;\ 353 cause=486 SIP/2.0 354 Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-2 355 Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9 356 From: Alice ;tag=9fxced76sl 357 To: sip:+15555551002@example.com;user=phone 358 Call-ID: c3x842276298220188511 359 CSeq: 1 INVITE 360 Max-Forwards: 70 361 Contact: 362 Content-Type: application/sdp 363 Content-Length: *Body length goes here* 365 * SDP goes here* 367 6.2. Endpoint forwards busy to Voicemail 369 In this example, Alice calls Bob. Bob is busy, but forwards the 370 session directly to his voicemail. Alice's phone is at 192.0.2.1 371 while Bob's phone is at 192.0.2.2. The important thing to note is 372 the URI in the Contact in message F3. 374 Alice Proxy Bob voicemail 375 | | | | 376 | INVITE F1 | | | 377 |--------------->| INVITE F2 | | 378 | |------------->| | 379 | | 302 Moved F3 | | 380 | 302 Moved F4 |<-------------| | 381 |<---------------| | | 382 | ACK F5 | | | 383 |--------------->| ACK F6 | | 384 | |------------->| | 385 | INVITE F7 | 386 |-------------------------------------------------->| 387 * Rest of flow not shown * 389 F1: INVITE 192.0.2.1 -> proxy.example.com 391 INVITE sip:+15555551002@example.com;user=phone SIP/2.0 392 Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9 393 From: Alice ;tag=9fxced76sl 394 To: sip:+15555551002@example.com;user=phone 395 Call-ID: c3x842276298220188511 396 CSeq: 1 INVITE 397 Max-Forwards: 70 398 Contact: 399 Content-Type: application/sdp 400 Content-Length: *Body length goes here* 402 * SDP goes here* 404 F2: INVITE proxy.example.com -> 192.0.2.2 406 INVITE sip:line1@192.0.2.2 SIP/2.0 407 Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1 408 Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9 409 From: Alice ;tag=9fxced76sl 410 To: sip:+15555551002@example.com;user=phone 411 Call-ID: c3x842276298220188511 412 CSeq: 1 INVITE 413 Max-Forwards: 70 414 Contact: 415 Content-Type: application/sdp 416 Content-Length: *Body length goes here* 418 * SDP goes here* 420 F3: 302 192.0.2.2 -> proxy.example.com 422 SIP/2.0 302 Moved Temporarily 423 Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1 424 Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9 425 From: Alice ;tag=9fxced76sl 426 To: sip:+15555551002@example.com;user=phone;tag=09xde23d80 427 Call-ID: c3x842276298220188511 428 CSeq: 1 INVITE 429 Contact: 432 Content-Length: 0 433 F7: INVITE proxy.example.com -> um.example.com 435 INVITE sip: voicemail@example.com;\ 436 target=sip:+15555551002%40example.com;user=phone;\ 437 cause=486 SIP/2.0 438 Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-2 439 Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9 440 From: Alice ;tag=9fxced76sl 441 To: sip:+15555551002@example.com;user=phone 442 Call-ID: c3x842276298220188511 443 CSeq: 1 INVITE 444 Max-Forwards: 70 445 Contact: 446 Content-Type: application/sdp 447 Content-Length: *Body length goes here* 449 * SDP goes here* 451 6.3. Endpoint forwards busy to TDM via a gateway 453 In this example, the voicemail is reached via a gateway to a TDM 454 network. Bob's number is +1 555 555-1002, while voicemail's number 455 on the TDM network is +1-555-555-2000. 457 The call flow is the same as in Section 6.2 except for the Contact 458 URI in F4 and the Request URI in F7. 460 Alice Proxy Bob voicemail 461 | | | | 462 | INVITE F1 | | | 463 |--------------->| INVITE F2 | | 464 | |------------->| | 465 |(100 Trying) F3 | | | 466 |<---------------| 302 Moved F4 | | 467 | |<-------------| | 468 | | ACK F5 | | 469 | |------------->| | 470 |(181 Call is Being Forwarded) F6 | 471 |<---------------| | INVITE F7 | 472 | |--------------------------------->| 473 * Rest of flow not shown * 475 F4: 486 192.0.2.2 -> proxy.example.com 477 SIP/2.0 302 Moved temporarily 478 Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1 479 Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9 480 From: Alice ;tag=9fxced76sl 481 To: sip:+15555551002@example.com;user=phone;tag=09xde23d80 482 Call-ID: c3x842276298220188511 483 CSeq: 1 INVITE 484 Contact: 486 Content-Length: 0 488 F7: INVITE proxy.example.com -> gw.example.com 490 INVITE sip:+15555552000@example.com;user=phone;\ 491 target=tel:+15555551002;cause=486\ 492 SIP/2.0 493 Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-2 494 Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9 495 From: Alice ;tag=9fxced76sl 496 To: sip:+15555551002@example.com;user=phone 497 Call-ID: c3x842276298220188511 498 CSeq: 1 INVITE 499 Max-Forwards: 70 500 Contact: 501 Content-Type: application/sdp 502 Content-Length: *Body length goes here* 504 * SDP goes here* 506 6.4. Endpoint forwards busy to Voicemail with History Info 508 This example illustrates how History Info works in conjunction with 509 service retargeting. The scenario is the same as Section 6.1. 511 F1: INVITE 192.0.2.1 -> proxy.example.com 513 INVITE sip:+15555551002@example.com;user=phone SIP/2.0 514 Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9 515 From: Alice ;tag=9fxced76sl 516 To: sip:+15555551002@example.com;user=phone 517 Call-ID: c3x842276298220188511 518 CSeq: 1 INVITE 519 Max-Forwards: 70 520 Contact: 521 History-Info: ;index=1 522 Content-Type: application/sdp 523 Content-Length: *Body length goes here* 525 * SDP goes here* 527 F2: INVITE proxy.example.com -> 192.0.2.2 529 INVITE sip:line1@192.0.2.2 SIP/2.0 530 Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1 531 Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9 532 From: Alice ;tag=9fxced76sl 533 To: sip:+15555551002@example.com;user=phone 534 Call-ID: c3x842276298220188511 535 CSeq: 1 INVITE 536 Max-Forwards: 70 537 Contact: 538 History-Info: ;index=1, 539 ;index=1.1 541 Content-Type: application/sdp 542 Content-Length: *Body length goes here* 544 * SDP goes here* 545 F7: INVITE proxy.example.com -> um.example.com 547 INVITE sip: voicemail@example.com;\ 548 target=sip:+15555551002%40example.com;user=phone;\ 549 cause=486 SIP/2.0 550 Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-2 551 Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9 552 From: Alice ;tag=9fxced76sl 553 To: sip:+15555551002@example.com;user=phone 554 Call-ID: c3x842276298220188511 555 CSeq: 1 INVITE 556 Max-Forwards: 70 557 Contact: 558 History-Info: ;index=1, 559 ;index=1.1 561 ;index=2 564 Contact: 565 Content-Type: application/sdp 566 Content-Length: *Body length goes here* 568 * SDP goes here* 570 6.5. Zero Configuration UM System 572 In this example, the UM system has no configuration information 573 specific to any user. The proxy is configured to pass a URI that 574 provides the prompt to play and an email address in the user portion 575 of the URI to which the recorded message is to be sent. 577 The call flow is the same as in Section 6.1, except that the URI in 578 F7 changes to specify the user part as Bob's email address, and the 579 Netann [7] URI play parameter specifies where the greeting to play 580 can be fetched from. 582 F7: INVITE proxy.example.com -> voicemail.example.com 584 INVITE sip:voicemail@example.com;target=mailto:bob%40example.com;\ 585 cause=486;play=http://www.example.com/bob/busy.wav SIP/2.0 586 Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-2 587 Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9 588 From: Alice ;tag=9fxced76sl 589 To: sip:+15555551002@example.com;user=phone 590 Call-ID: c3x842276298220188511 591 CSeq: 1 INVITE 592 Max-Forwards: 70 593 Contact: 594 Content-Type: application/sdp 595 Content-Length: *Body length goes here* 597 * SDP goes here* 599 In addition, if the proxy wished to indicate a VXML script that the 600 UM should execute, it could add a parameter to the URI in the above 601 message that looked like: 603 voicexml=http://www.example.com/bob/busy.vxml 605 6.6. Call Coverage 607 In a Call Coverage example, a user on the PSTN calls a 800 number. 608 The GW sends this to the proxy which recognizes that the helpdesk is 609 the target. Alice and Bob are staffing the help desk and are tried 610 sequentially but neither answers, so the call is forwarded to the 611 helpdesk's voice mail. 613 The details of this flow are trivial and not shown: the key item in 614 this example is that the INVITE to Alice and Bob looks as follows: 616 INVITE sip:voicemail@example.com;target=helpdesk%40example.com;\ 617 cause=302 SIP/2.0 619 7. IANA Considerations 621 This specification adds two new values to the IANA registration in 622 the "SIP/SIPS URI Parameters" registry as defined in [3]. 624 Parameter Name Predefined Values Reference 625 ____________________________________________ 626 target No [RFCAAAA] 627 cause Yes [RFCAAAA] 629 [Note to IANA: Please replace AAAA with the RFC number of this 630 specification. 632 8. Security Considerations 634 This draft discusses transactions involving at least three parties, 635 which increases the complexity of the privacy issues. 637 The new URI parameters defined in this draft are generally sent from 638 a Proxy or call control system to a Unified Messaging (UM) system or 639 to a gateway to the PSTN and then to a voicemail system. These new 640 parameters tell the UM what service the proxy wishes to have 641 performed. Just as any message sent from the proxy to the UM needs 642 to be integrity protected, these messages need to be integrity 643 protected to stop attackers from, for example, causing a voicemail 644 meant for a company's CEO to go to an attacker's mailbox. RFC 3261 645 provides a TLS mechanism suitable for performing this integrity 646 protection. 648 The signaling from the Proxy to the UM or gateway will reveal who is 649 calling whom and possibly some information about a user's presence 650 based on whether the call was answered or sent to voicemail. This 651 information can be protected by encrypting the SIP traffic between 652 the Proxy and UM or gateway. Again, RFC 3261 contains mechanisms for 653 accomplishing this using TLS. 655 Implementations should implement and use TLS. 657 8.1. Integrity Protection of Forwarding in SIP 659 The forwarding of a call in SIP brings up a very strange trust issue. 660 Consider the normal case when A calls B and the call gets forwarded 661 to C by a network element in B's domain, and then C answers the call. 662 A has called B but ended up talking to C. This scenario may be hard 663 to separate from a man-in-the-middle attack. 665 There are two possible solutions. One is that B sends back 666 information to A saying don't call me, call C and signs it as B. The 667 problem is that this solution involves revealing that B has forwarded 668 to C, which B often may not want to do. For example, B may be a work 669 phone that has been forwarded to a mobile or home phone. The user 670 does not want to reveal their mobile or home phone number but, even 671 more importantly, does not want to reveal that they are not in the 672 office. 674 The other possible solution is that A needs to trust B only to 675 forward to a trusted identity. This requires a hop-by-hop transitive 676 trust such that each hop will only send to a trusted next hop and 677 each hop will only do things that the user at that hop desired. This 678 solution is enforced in SIP using the SIPS URI and TLS based hop-by- 679 hop security. It protects from an off axis attack, but if one of the 680 hops is not trustworthy, the call may be diverted to an attacker. 682 Any redirection of a call to an attacker's mailbox is serious. It is 683 trivial for an attacker to make its mailbox seem very much like the 684 real mailbox and forward the messages to the real mailbox so that the 685 fact that the messages have been intercepted or even tampered with 686 escapes detection. Approaches such as the SIPS URL and the History- 687 Info[6] can help protect against these attacks. 689 8.2. Privacy Related Issues on the Second Call Leg 691 In the case where A calls B and gets redirected to C, occasionally 692 people suggest there is a a requirement for the call leg from B to C 693 to be anonymous. The SIP case is not the PSTN and there is no call 694 leg from B to C; instead there is a VoIP session between A and C. If 695 A has put a To header field value containing B in the initial invite 696 message, unless something special is done about it, C would see that 697 To header field value. If the person who answers phone C says "I 698 think you dialed the wrong number, who were you trying to reach?" A 699 will probably specify B. 701 If A does not want C to see that the call was to B, A needs a special 702 relationship with the forwarding Proxy to induce it not to reveal 703 that information. The call should go through an anonymization 704 service that provides session or user level privacy (as described in 705 RFC 3323 [2]) service before going to C. It is not hard to figure out 706 how to meet this requirement, but it is unclear why anyone would want 707 this service. 709 The scenario in which B wants to make sure that C does not see that 710 the call was to B is easier to deal with but a bit weird. The usual 711 argument is Bill wants to forward his phone to Monica but does not 712 want Monica to find out his phone number. It is hard to imagine that 713 Monica would want to accept all Bill's calls without knowing how to 714 call Bill to complain. The only person Monica will be able to 715 complain to is Hilary, when she tries to call Bill. Several popular 716 web portals will send SMS alert message about things like stock 717 prices and weather to mobile phone users today. Some of these 718 contain no information about the account on the web portal that 719 initiated them, making it nearly impossible for the mobile phone 720 owner to stop them. This anonymous message forwarding has turned out 721 to be a really bad idea even where no malice is present. Clearly 722 some people are fairly dubious about the need for this, but never 723 mind: let's look at how it is solved. 725 In the general case, the proxy needs to route the call through an 726 anonymization service and everything will be cleaned up. Any 727 anonymization service that performs the "Privacy: Header" Service in 728 RFC 3323 [2] must remove the cause and target URI parameters from the 729 URI. Privacy of the parameters when they from part of a URI within 730 the History-Info header is covered in History-Info [6]. 732 This specification does not discuss the security considerations of 733 mapping to a PSTN Gateway. Security implications of mapping to ISUP 734 for example, are discussed in RFC 3398 [5]. 736 9. Acknowledgments 738 Many thanks to Mary Barnes, Steve Levy, Dean Willis, Allison Mankin, 739 Martin Dolly, Paul Kyzivat, Erick Sasaki, Lyndsay Campbell, Keith 740 Drage, Miguel Garcia, Sebastien Garcin, Roland Jesske, Takumi Ohba 741 and Rohan Mahy. 743 10. References 745 10.1. Normative References 747 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 748 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 749 Session Initiation Protocol", RFC 3261, June 2002. 751 [2] Peterson, J., "A Privacy Mechanism for the Session Initiation 752 Protocol (SIP)", RFC 3323, November 2002. 754 [3] Camarillo, G., "The Internet Assigned Number Authority (IANA) 755 Uniform Resource Identifier (URI) Parameter Registry for the 756 Session Initiation Protocol (SIP)", BCP 99, RFC 3969, 757 December 2004. 759 [4] Crocker, D. and P. Overell, "Augmented BNF for Syntax 760 Specifications: ABNF", RFC 4234, October 2005. 762 10.2. Informative References 764 [5] Camarillo, G., Roach, A., Peterson, J., and L. Ong, "Integrated 765 Services Digital Network (ISDN) User Part (ISUP) to Session 766 Initiation Protocol (SIP) Mapping", RFC 3398, December 2002. 768 [6] Barnes, M., "An Extension to the Session Initiation Protocol 769 (SIP) for Request History Information", RFC 4244, 770 November 2005. 772 [7] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network Media 773 Services with SIP", RFC 4240, December 2005. 775 [8] "Stage 3 description for call offering supplementary services 776 using signalling system No. 7: Call diversion services", ITU- 777 T Recommendation Q.732.2-5, December 1999. 779 [9] "Usage of cause and location in the Digital Subscriber 780 Signalling System No. 1 and the Signalling System No. 7 ISDN 781 User Part", ITU-T Recommendation Q.850, May 1998. 783 [10] "ISDN user-network interface layer 3 specification for basic 784 call control", ITU-T Recommendation Q.931, May 1998. 786 [11] "Information technology - Telecommunications and information 787 exchange between systems - Private Integrated Services Network 788 - Circuit mode bearer services - Inter-exchange signalling 789 procedures and protocol", ISO/IEC 11572, March 2000. 791 Authors' Addresses 793 Cullen Jennings 794 Cisco Systems 795 170 West Tasman Drive 796 Mailstop SJC-21/2 797 San Jose, CA 95134 798 USA 800 Phone: +1 408 421-9990 801 Email: fluffy@cisco.com 803 Francois Audet 804 Nortel Networks 805 4655 Great America Parkway 806 Santa Clara, CA 95054 807 US 809 Phone: +1 408 495 3756 810 Email: audet@nortel.com 812 John Elwell 813 Siemens Communications 814 Technology Drive 815 Beeston, Nottingham NG9 1LA 816 UK 818 Email: john.elwell@siemens.com 820 Intellectual Property Statement 822 The IETF takes no position regarding the validity or scope of any 823 Intellectual Property Rights or other rights that might be claimed to 824 pertain to the implementation or use of the technology described in 825 this document or the extent to which any license under such rights 826 might or might not be available; nor does it represent that it has 827 made any independent effort to identify any such rights. Information 828 on the procedures with respect to rights in RFC documents can be 829 found in BCP 78 and BCP 79. 831 Copies of IPR disclosures made to the IETF Secretariat and any 832 assurances of licenses to be made available, or the result of an 833 attempt made to obtain a general license or permission for the use of 834 such proprietary rights by implementers or users of this 835 specification can be obtained from the IETF on-line IPR repository at 836 http://www.ietf.org/ipr. 838 The IETF invites any interested party to bring to its attention any 839 copyrights, patents or patent applications, or other proprietary 840 rights that may cover technology that may be required to implement 841 this standard. Please address the information to the IETF at 842 ietf-ipr@ietf.org. 844 Disclaimer of Validity 846 This document and the information contained herein are provided on an 847 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 848 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 849 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 850 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 851 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 852 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 854 Copyright Statement 856 Copyright (C) The Internet Society (2006). This document is subject 857 to the rights, licenses and restrictions contained in BCP 78, and 858 except as set forth therein, the authors retain all their rights. 860 Acknowledgment 862 Funding for the RFC Editor function is currently provided by the 863 Internet Society.