idnits 2.17.1 draft-ietf-sipping-3pcc-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 : ---------------------------------------------------------------------------- ** There are 66 instances of too long lines in the document, the longest one being 8 characters in excess of 72. 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (December 24, 2003) is 7429 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) == Unused Reference: '8' is defined on line 1261, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 1274, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3330 (ref. '11') (Obsoleted by RFC 5735) == Outdated reference: A later version (-12) exists of draft-ietf-mmusic-sdescriptions-02 == Outdated reference: A later version (-09) exists of draft-ietf-iptel-cpl-08 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING J. Rosenberg 3 Internet-Draft dynamicsoft 4 Expires: June 23, 2004 J. Peterson 5 Neustar 6 H. Schulzrinne 7 Columbia University 8 G. Camarillo 9 Ericsson Advanced Signalling 10 Research Lab 11 December 24, 2003 13 Best Current Practices for Third Party Call Control in the Session 14 Initiation Protocol 15 draft-ietf-sipping-3pcc-06 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that other 24 groups may also distribute working documents as Internet-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 http:// 32 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 June 23, 2004. 39 Copyright Notice 41 Copyright (C) The Internet Society (2003). All Rights Reserved. 43 Abstract 45 Third party call control refers to the ability of one entity to 46 create a call in which communication is actually between other 47 parties. Third party call control is possible using the mechanisms 48 specified within the Session Initiation Protocol (SIP). However, 49 there are several possible approaches, each with different benefits 50 and drawbacks. This document discusses best current practices for the 51 usage of SIP for third party call control. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. 3pcc Call Establishment . . . . . . . . . . . . . . . . . . 4 59 4.1 Flow I . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 4.2 Flow II . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 4.3 Flow III . . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 4.4 Flow IV . . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 5. Recommendations . . . . . . . . . . . . . . . . . . . . . . 10 64 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 10 65 7. Continued Processing . . . . . . . . . . . . . . . . . . . . 11 66 8. 3pcc and Early Media . . . . . . . . . . . . . . . . . . . . 14 67 9. Third Party Call Control and SDP Preconditions . . . . . . . 16 68 9.1 Controller Initiates . . . . . . . . . . . . . . . . . . . . 16 69 9.2 Party A Initiates . . . . . . . . . . . . . . . . . . . . . 18 70 10. Example Call Flows . . . . . . . . . . . . . . . . . . . . . 21 71 10.1 Click to Dial . . . . . . . . . . . . . . . . . . . . . . . 21 72 10.2 Mid-Call Announcement Capability . . . . . . . . . . . . . . 23 73 11. Implementation Recommendations . . . . . . . . . . . . . . . 25 74 12. Security Considerations . . . . . . . . . . . . . . . . . . 26 75 12.1 Authorization and Authentication . . . . . . . . . . . . . . 26 76 12.2 End-to-End Encryption and Integrity . . . . . . . . . . . . 27 77 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 27 78 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 79 Normative References . . . . . . . . . . . . . . . . . . . . 28 80 Informative References . . . . . . . . . . . . . . . . . . . 28 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 29 82 Intellectual Property and Copyright Statements . . . . . . . 31 84 1. Introduction 86 In the traditional telephony context, third party call control allows 87 one entity (which we call the controller) to set up and manage a 88 communications relationship between two or more other parties. Third 89 party call control (referred to as 3pcc) is often used for operator 90 services (where an operator creates a call that connects two 91 participants together) and conferencing. 93 Similarly, many SIP services are possible through third party call 94 control. These include the traditional ones on the PSTN, but also new 95 ones such as click-to-dial. Click-to-dial allows a user to click on a 96 web page when they wish to speak to a customer service 97 representative. The web server then creates a call between the user 98 and a customer service representative. The call can be between two 99 phones, a phone and an IP host, or two IP hosts. 101 Third party call control is possible using only the mechanisms 102 specified within RFC 3261 [1]. Indeed, many different call flows are 103 possible, each of which will work with SIP compliant user agents. 104 However, there are benefits and drawbacks to each of these flows. The 105 usage of third party call control also becomes more complex when 106 aspects of the call utilize SIP extensions or optional features of 107 SIP. In particular, the usage of RFC 3312 [2] (used for coupling of 108 signaling to resource reservation) with third party call control is 109 non-trivial, and is discussed in Section 9. Similarly, the usage of 110 early media (where session data is exchanged before the call is 111 accepted) with third party call control is not trivial; both of them 112 specify the way in which user agents generate and respond to SDP, and 113 it is not clear how to do both at the same time. This is discussed 114 further in Section 8. 116 This document serves as a best current practice for implementing 117 third party call control without usage of any extensions specifically 118 designed for that purpose. Section 4 presents the known call flows 119 that can be used to achieve third party call control, and provides 120 guidelines on their usage. Section 9 discusses the interactions of 121 RFC 3312 [2] with third party call control. Section 8 discusses the 122 interactions of early media with third party call control. Section 10 123 provides example applications that make usage of the flows 124 recommended here. 126 2. Terminology 128 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 129 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 130 and "OPTIONAL" are to be interpreted as described in RFC 2119 [3] and 131 indicate requirement levels for compliant implementations. 133 3. Definitions 135 The following terms are used throughout this document: 137 3pcc: Third Party Call Control, which refers to the general ability 138 to manipulate calls between other parties. 140 Controller: A controller is a SIP User Agent that wishes to create a 141 session between two other user agents. 143 4. 3pcc Call Establishment 145 The primary primitive operation of third party call control is the 146 establishment of a session between participants A and B. 147 Establishment of this session is orchestrated by a third party, 148 referred to as the controller. 150 This section documents three call flows that the controller can 151 utilize in order to provide this primitive operation. 153 4.1 Flow I 155 A Controller B 156 |(1) INVITE no SDP | | 157 |<------------------| | 158 |(2) 200 offer1 | | 159 |------------------>| | 160 | |(3) INVITE offer1 | 161 | |------------------>| 162 | |(4) 200 OK answer1 | 163 | |<------------------| 164 | |(5) ACK | 165 | |------------------>| 166 |(6) ACK answer1 | | 167 |<------------------| | 168 |(7) RTP | | 169 |.......................................| 171 Figure 1 173 The call flow for Flow I is shown in Figure 1. The controller first 174 sends an INVITE A (1). This INVITE has no session description. A's 175 phone rings, and A answers. This results in a 200 OK (2) that 176 contains an offer [4]. The controller needs to send its answer in the 177 ACK, as mandated by [1]. To obtain the answer, it sends the offer it 178 got from A (offer1) in an INVITE to B (3). B's phone rings. When B 179 answers, the 200 OK (4) contains the answer to this offer, answer1. 180 The controller sends an ACK to B (5), and then passes answer1 to A in 181 an ACK sent to it (6). Because the offer was generated by A, and the 182 answer generated by B, the actual media session is between A and B. 183 Therefore, media flows between them (7). 185 This flow is simple, requires no manipulation of the SDP by the 186 controller, and works for any media types supported by both 187 endpoints. However, it has a serious timeout problem. User B may not 188 answer the call immediately. The result is that the controller cannot 189 send the ACK to A right away. This causes A to retransmit the 200 OK 190 response periodically. As specified in RFC 3261 Section 13.3.1.4, the 191 200 OK will be retransmitted for 64*T1 seconds. If an ACK does not 192 arrive by then, the call is considered to have failed. This limits 193 the applicability of this flow to scenarios where the controller 194 knows that B will answer the INVITE immediately. 196 4.2 Flow II 198 A Controller B 199 |(1) INVITE bh sdp1 | | 200 |<------------------| | 201 |(2) 200 sdp2 | | 202 |------------------>| | 203 | |(3) INVITE sdp2 | 204 | |------------------>| 205 |(4) ACK | | 206 |<------------------| | 207 | |(5) 200 OK sdp3 | 208 | |<------------------| 209 | |(6) ACK | 210 | |------------------>| 211 |(7) INVITE sdp3 | | 212 |<------------------| | 213 |(8) 200 OK sdp2 | | 214 |------------------>| | 215 |(9) ACK | | 216 |<------------------| | 217 |(10) RTP | | 218 |.......................................| 220 Figure 2 222 An alternative flow, Flow II, is shown in Figure 2. The controller 223 first sends an INVITE to user A (1). This is a standard INVITE, 224 containing an offer (sdp1) with a single audio media line, one codec, 225 a random port number (but not zero), and a connection address of 226 0.0.0.0. This creates an initial media stream that is ``black 227 holed'', since no media (or RTCP packets [9] will flow from A. The 228 INVITE causes A's phone to ring. 230 Note that the usage of 0.0.0.0, though recommended by RFC 3264, 231 has numerous drawbacks. It is anticipated that a future 232 specification will recommend usage of a domain within the .invalid 233 DNS top level domain instead of the 0.0.0.0 IP address. As a 234 result, implementors are encouraged to track such developments 235 once they arise. 237 When A answers (2), the 200 OK contains an answer, sdp2, with a valid 238 address in the connection line. The controller sends an ACK (4). It 239 then generates a second INVITE (3). This INVITE is addressed to user 240 B, and it contains sdp2 as the offer to B. Note that the role of sdp2 241 has changed. In the 200 OK (message 2), it was an answer, but in the 242 INVITE, it is an offer. Fortunatly, all valid answers are valid 243 initial offers. This INVITE causes B's phone to ring. When it 244 answers, it generates a 200 OK (5) with an answer, sdp3. The 245 controller then generates an ACK (6). Next, it sends a re-INVITE to A 246 (7) containing sdp3 as the offer. Once again, there has been a 247 reversal of roles. sdp3 was an answer, and now it is an offer. 248 Fortunately, an answer to an answer recast as an offer is, in turn, a 249 valid offer. This re-INVITE generates a 200 OK (8) with sdp2, 250 assuming that A doesn't decide to change any aspects of the session 251 as a result of this re-INVITE. This 200 OK is ACKed (9), and then 252 media can flow from A to B. Media from B to A could already start 253 flowing once message 5 was sent. 255 This flow has the advantage that all final responses are immediately 256 ACKed. It therefore does not suffer from the timeout and message 257 inefficiency problems of flow 1. However, it too has troubles. First 258 off, it requires that the controller know the media types to be used 259 for the call (since it must generate a "blackhole" SDP, which 260 requires media lines). Secondly, the first INVITE to A (1) contains 261 media with a 0.0.0.0 connection address. The controller expects that 262 the response contains a valid, non-zero connection address for A. 263 However, experience has shown that many UAs respond to an offer of a 264 0.0.0.0 connection address with an answer containing a 0.0.0.0 265 connection address. The offer-answer specification [4] explicitly 266 tells implementors not to do this, but at the time of publication of 267 this document, many implementations still did. If A should respond 268 with a 0.0.0.0 connection address in sdp2, the flow will not work. 270 However, the most serious flaw in this flow is the assumption that 271 the 200 OK to the re-INVITE (message 8) contains the same SDP as in 272 message 2. This may not be the case. If it is not, the controller 273 needs to re-INVITE B with that SDP (say, sdp4), which may result in 274 getting a different SDP, sdp5 , in the 200 OK from B. Then, the 275 controller needs to re-INVITE A again, and so on. The result is an 276 infinite loop of re-INVITEs. It is possible to break this cycle by 277 having very smart UAs which can return the same SDP whenever 278 possible, or really smart controllers that can analyze the SDP to 279 determine if a re-INVITE is really needed. However, we wish to keep 280 this mechanism simple, and avoid SDP awareness in the controller. As 281 a result, this flow is not really workable. It is therefore NOT 282 RECOMMENDED. 284 4.3 Flow III 286 A Controller B 287 |(1) INVITE no SDP | | 288 |<---------------------| | 289 |(2) 200 offer1 | | 290 |--------------------->| | 291 |(3) ACK answer1 (bh) | | 292 |<---------------------| | 293 | |(4) INVITE no SDP | 294 | |--------------------->| 295 | |(5) 200 OK offer2 | 296 | |<---------------------| 297 |(6) INVITE offer2' | | 298 |<---------------------| | 299 |(7) 200 answer2' | | 300 |--------------------->| | 301 | |(8) ACK answer2 | 302 | |--------------------->| 303 |(9) ACK | | 304 |<---------------------| | 305 |(10) RTP | | 306 |.............................................| 308 Figure 3 310 A third flow, Flow III, is shown in Figure 3 312 First, the controller sends an INVITE (1) to user A without any SDP 313 (which is good, since it means that the controller doesn't need to 314 assume anything about the media composition of the session). A's 315 phone rings. When A answers, a 200 OK is generated (2) containing its 316 offer, offer1. The controller generates an immediate ACK containing 317 an answer (3). This answer is a "black hole" SDP, with its connection 318 address equal to 0.0.0.0. 320 The controller then sends an INVITE to B without SDP (4). This causes 321 B's phone to ring. When they answer, a 200 OK is sent, containing 322 their offer, offer2 (5). This SDP is used to create a re-INVITE back 323 to A (6). That re-INVITE is based on offer2, but may need to be 324 reorganized to match up media lines, or to trim media lines. For 325 example, if offer1 contained an audio and a video line, in that 326 order, but offer2 contained just an audio line, the controller would 327 need to add a video line to the offer (setting its port to zero) to 328 create offer2'. Since this is a re-INVITE, it should complete quickly 329 in the general case. Thats good, since user B is retransmitting their 330 200 OK, waiting for an ACK. The SDP in the 200 OK (7) from A, 331 answer2', may also need to be reorganized or trimmed before sending 332 it an the ACK to B (8) as answer2. Finally, an ACK is sent to A (9), 333 and then media can flow. 335 This flow has many benefits. First, it will usually operate without 336 any spurious retransmissions or timeouts (although this may still 337 happen if a re-INVITE is not responded to quickly). Secondly, it does 338 not require the controller to guess the media that will be used by 339 the participants. 341 There are some drawbacks. The controller does need to perform SDP 342 manipulations. Specifically, it must take some SDP, and generate 343 another SDP which has the same media composition, but has connection 344 addresses equal to 0.0.0.0. This is needed for message 3. Secondly, 345 it may need to reorder and trim on SDP X, so that its media lines 346 match up with those in some other SDP, Y. Thirdly, the offer from B 347 (offer2) may have no codecs or media streams in common with the offer 348 from A (offer 1). The controller will need to detect this condition, 349 and terminate the call. Finally, the flow is far more complicated 350 than the simple and elegant Flow I (Figure 1). 352 4.4 Flow IV 354 A Controller B 355 |(1) INVITE offer1 | | 356 |no media | | 357 |<---------------------| | 358 |(2) 200 answer1 | | 359 |no media | | 360 |--------------------->| | 361 |(3) ACK | | 362 |<---------------------| | 363 | |(4) INVITE no SDP | 364 | |--------------------->| 365 | |(5) 200 OK offer2 | 366 | |<---------------------| 367 |(6) INVITE offer2' | | 368 |<---------------------| | 369 |(7) 200 answer2' | | 370 |--------------------->| | 371 | |(8) ACK answer2 | 372 | |--------------------->| 373 |(9) ACK | | 374 |<---------------------| | 375 |(10) RTP | | 376 |.............................................| 378 Figure 4 380 Flow IV shows a variation on Flow III that reduces its complexity. 381 The actual message flow is identical, but the SDP placement and 382 construction differs. The initial INVITE (1) contains SDP with no 383 media at all, meaning that there are no m lines. This is valid, and 384 implies that the media makeup of the session will be established 385 later through a re-INVITE [4]. Once the INVITE is received, user A is 386 alerted. When they answer the call, the 200 OK (2) has an answer with 387 no media either. This is acknowledged by the controller (3). The flow 388 from this point onwards is identical to Flow III. However, the 389 manipulations required to convert offer2 to offer2', and answer2' to 390 answer2, are much simpler. Indeed, no media manipulations are needed 391 at all. The only change that is needed is to modify the origin lines, 392 so that the origin line in offer2' is valid based on the value in 393 offer1 (validify requires that the version increments by one, and 394 that the other parameters remain unchanged). 396 There are some limitations associated with this flow. First, user A 397 will be alerted without any media having been established yet. This 398 means that user A will not be able to reject or accept the call based 399 on its media composition. Secondly, both A and B will end up 400 answering the call (i.e., generating a 200 OK) before it is known 401 whether there is compatible media. If there is no media in common, 402 the call can be terminated later with a BYE. However, the users will 403 have already been alerted, resulting in user annoyance and possibly 404 resulting in billing events. 406 5. Recommendations 408 Flow I (Figure 1) represents the simplest and the most efficient 409 flow. This flow SHOULD be used by a controller if it knows with 410 certainty that user B is actually an automata that will answer the 411 call immediately. This is the case for devices such as media servers, 412 conferencing servers, and messaging servers, for example. Since we 413 expect a great deal of third party call control to be to automata, 414 special caseing this scenario is reasonable. 416 For calls to unknown entities, or to entities known to represent 417 people, it is RECOMMENDED that Flow IV (Figure 4) be used for third 418 party call control. Flow III MAY be used instead, but it provides no 419 additional benefits over Flow IV. However, Flow II SHOULD NOT be 420 used, because of the potential for infinite ping-ponging of 421 re-INVITEs. 423 Several of these flows use a ``black hole'' connection address of 424 0.0.0.0. This is an IPV4 address with the property that packets sent 425 to it will never leave the host which sent them; they are just 426 discarded. Those flows are therefore specific to IPv4. For other 427 network or address types, an address with an equivalent property 428 SHOULD be used. 430 In most cases, including the recommended flow, user A will hear 431 silence while the call to B completes. This may not always be ideal. 432 It can be remedied by connecting the caller to a music-on-hold source 433 while the call to B occurs. 435 6. Error Handling 437 There are numerous error cases which merit discussion. 439 With all of the call flows in Section 4, one call is established to 440 A, and then the controller attempts to establish a call to B. 441 However, this call attempt may fail, for any number of reasons. User 442 B might be busy (resulting in a 486 response to the INVITE), there 443 may not be any media in common, the request may time out, and so on. 444 If the call attempt to B should fail, it is RECOMMENDED that the 445 controller send a BYE to A. This BYE SHOULD include a Reason header 446 [5] which carries the status code from the error response. This will 447 inform A of the precise reason for the failure. The information is 448 important from a user interface perspective. For example, if A was 449 calling from a black phone, and B generated a 486, the BYE will 450 contain a Reason code of 486, and this could be used to generate a 451 local busy signal so that A knows that B is busy. 453 A Controller B 454 |(1) INVITE offer1 | | 455 |no media | | 456 |<---------------------| | 457 |(2) 200 answer1 | | 458 |no media | | 459 |--------------------->| | 460 |(3) ACK | | 461 |<---------------------| | 462 | |(4) INVITE no SDP | 463 | |--------------------->| 464 | |(5) 180 | 465 | |<---------------------| 466 |(6) INVITE offer2 | | 467 |--------------------->| | 468 |(7) 491 | | 469 |<---------------------| | 470 |(8) ACK | | 471 |--------------------->| | 473 Figure 5 475 Another error condition worth discussion is shown in Figure 5. After 476 the controller establishes the dialog with A (messages 1-3) it 477 attempts to contact B (message 4). Contacting B may take some time. 478 During that interval, A could possibly attempt a re-INVITE, providing 479 an updated offer. However, the controller cannot pass this offer on 480 to B, since it has an INVITE transaction pending with it. As a 481 result, the controller needs to reject the request. It is RECOMMENDED 482 that a 491 response be used. The situation here is similar to the 483 glare condition described in [1], and thus the same error handling is 484 sensible. However, A is likely to retry its request (as a result of 485 the 491), and this may occur before the exchange with B is completed. 486 In that case, the controller would respond with another 491. 488 7. Continued Processing 490 Once the calls are established, both participants believe they are in 491 a single point-to-point call. However, they are exchanging media 492 directly with each other, rather than with the controller. The 493 controller is involved in two dialogs, yet sees no media. 495 Since the controller is still a central point for signaling, it now 496 has complete control over the call. If it receives a BYE from one of 497 the participants, it can create a new BYE and hang up with the other 498 participant. This is shown in Figure 6. 500 A Controller B 501 |(1) BYE | | 502 |------------------>| | 503 |(2) 200 OK | | 504 |<------------------| | 505 | |(3) BYE | 506 | |------------------>| 507 | |(4) 200 OK | 508 | |<------------------| 510 Figure 6 512 Similarly, if it receives a re-INVITE from one of the participants, 513 it can forward it to the other participant. Depending on which flow 514 was used, this may require some manipulation on the SDP before 515 passing it on. 517 However, the controller need not "proxy" the SIP messages received 518 from one of the parties. Since it is a Back to Back User Agent 519 (B2BUA), it can invoke any signaling mechanism on each dialog, as it 520 sees fit. For example, if the controller receives a BYE from A, it 521 can generate a new INVITE to a third party, C, and connect B to that 522 participant instead. A call flow for this is shown in Figure 7, 523 assuming the case where C represents an end user, not an automata. 524 Note that it is just Flow IV. 526 A Controller B C 527 |(1) BYE | | | 528 |--------------->| | | 529 |(2) 200 OK | | | 530 |<---------------| | | 531 | |(3) INV no media| | 532 | |-------------------------------->| 533 | |(4) 200 no media| | 534 | |<--------------------------------| 535 | |(5) ACK | | 536 | |-------------------------------->| 537 | |(6) INV no SDP | | 538 | |--------------->| | 539 | |(7) 200 offer3 | | 540 | |<---------------| | 541 | |(8) INV offer3' | | 542 | |-------------------------------->| 543 | |(9) 200 answer3'| | 544 | |<--------------------------------| 545 | |(10) ACK | | 546 | |-------------------------------->| 547 | |(11) ACK answer3| | 548 | |--------------->| | 549 | | |(12) RTP | 550 | | |................| 552 Figure 7 554 From here, new parties can be added, removed, transferred, and so on, 555 as the controller sees fit. In many cases, the controller will be 556 required to modify the SDP exchanged between the participants in 557 order to affect these changes. In particular, the version number in 558 the SDP will need to be changed by the controller in certain cases. 559 If the controller should issue an SDP offer on its own (for example, 560 to place a call on hold), it will need to increment the version 561 number in the SDP offer. The other participant in the call will not 562 know that the controller has done this, and any subsequent offer it 563 generates will have the wrong version number as far as its peer is 564 concerned. As a result, the controller will be required to modify the 565 version number in SDP messages to match what the recipient is 566 expecting. 568 It is important to point out that the call need not have been 569 established by the controller in order for the processing of this 570 section to be used. Rather, the controller could have acted as a 571 B2BUA during a call established by A towards B (or vice a versa). 573 8. 3pcc and Early Media 575 Early media represents the condition where the session is established 576 (as a result of the completion of an offer/answer exchange), yet the 577 call itself has not been accepted. This is usually used to convey 578 tones or announcements regarding progress of the call. Handling of 579 early media in a third party call is straightforward. 581 A Controller B 582 | | | 583 |(1) INVITE offer1 | | 584 |no media | | 585 |<---------------------| | 586 | | | 587 | | | 588 | | | 589 | | | 590 | | | 591 |(2) 200 answer1 | | 592 |no media | | 593 |--------------------->| | 594 |(3) ACK | | 595 |<---------------------| | 596 | |(4) INVITE no SDP | 597 | |--------------------->| 598 | | | 599 | |(5) 183 offer2 | 600 | |<---------------------| 601 |(6) INVITE offer2' | | 602 |<---------------------| | 603 |(7) 200 answer2' | | 604 |--------------------->| | 605 |(8) ACK | | 606 |<---------------------| | 607 | |(9) PRACK answer2 | 608 | |--------------------->| 609 | |(10) 200 PRACK | 610 | |<---------------------| 611 |(11) RTP | | 612 |.............................................| 613 | | | 614 | |(12) 200 OK | 615 | |<---------------------| 616 | |(13) ACK | 617 | |--------------------->| 618 Figure 8 620 Figure 8 shows the case where user B generates early media before 621 answering the call. The flow is almost identical to Flow IV from 622 Figure 4. The only difference is that user B generates a reliable 623 provisional response (5) [6] instead of a final response, and answer2 624 is carried in a PRACK (8) instead of an ACK. When party B finally 625 does accept the call (11), there is no change in the session state, 626 and therefore, no signaling needs to be done with user A. The 627 controller simply ACKs the 200 OK (12) to confirm the dialog. 629 A Controller B 630 | | | 631 |(1) INVITE offer1 | | 632 |no media | | 633 |<---------------------| | 634 | | | 635 |ring | | 636 | | | 637 |(2) 183 answer1 | | 638 |no media | | 639 |--------------------->| | 640 |(3) PRACK | | 641 |<---------------------| | 642 |(4) 200 PRACK | | 643 |--------------------->| | 644 | |(5) INVITE no SDP | 645 | |--------------------->| 646 | | |ring 647 | | | 648 | | |answer 649 | | | 650 | |(6) 200 OK offer2 | 651 | |<---------------------| 652 |(7) UPDATE offer2' | | 653 |<---------------------| | 654 |answer | | 655 | | | 656 |(8) 200 answer2' | | 657 |--------------------->| | 658 | |(9) ACK answer2 | 659 | |--------------------->| 660 |(10) RTP | | 661 |.............................................| 662 |(11) 200 OK | | 663 |--------------------->| | 664 |(12) ACK | | 665 |<---------------------| | 667 Figure 9 669 The case where user A generates early media is more complicated, and 670 is shown in Figure 9. The flow is based on Flow IV. The controller 671 sends an INVITE to user A (1), with an offer containing no media 672 streams. User A generates a reliable provisional response (2) 673 containing an answer with no media streams. The controller PRACKs 674 this provisional response (3). Now, the controller sends an INVITE 675 without SDP to user B (5). User B's phone rings, and they answer, 676 resulting in a 200 OK (6) with an offer, offer2. The controller now 677 needs to update the session parameters with user A. However, since 678 the call has not been answered, it cannot use a re-INVITE. Rather, it 679 uses a SIP UPDATE request (7) [7], passing the offer (after modifying 680 it to get the origin field correct). User A generates its answer in 681 the 200 OK to the UPDATE (8). This answer is passed to user B in the 682 ACK (9). When user A finally answers (11), there is no change in 683 session state, so the controller simply ACKs the 200 OK (12). 685 Note that it is likely that there will be clipping of media in this 686 call flow. User A is likely a PSTN gateway, and has generated a 687 provisional response because of early media from the PSTN side. The 688 PSTN will deliver this media even though the gateway does not have 689 anywhere to send it, since the initial offer from the controller had 690 no media streams. When user B answers, media can begin to flow. 691 However, any media sent to the gateway from the PSTN up to that point 692 will be lost. 694 9. Third Party Call Control and SDP Preconditions 696 A SIP extension has been specified that allows for the coupling of 697 signaling and resource reservation [2]. This specification relies on 698 exchanges of session descriptions before completion of the call 699 setup. These flows are initiated when certain SDP parameters are 700 passed in the initial INVITE. As a result, the interaction of this 701 mechanism with third party call control is not obvious, and worth 702 detailing. 704 9.1 Controller Initiates 706 In one usage scenario, the controller wishes to make use of 707 preconditions in order to avoid the call failure scenarios documented 708 in Section 4.4. Specifically, the controller can use preconditions in 709 order to guarantee that neither party is alerted unless there is a 710 common set of media and codecs. It can also provide both parties with 711 information on the media composition of the call before they decide 712 to accept it. 714 User Controller Customer Service 715 | | | 716 |(1) INVITE no SDP | | 717 |require precon | | 718 |<------------------| | 719 |(2) 183 offer1 | | 720 |optional precon | | 721 |------------------>| | 722 | | | 723 | |(3) INVITE offer1 | 724 | |------------------>| 725 | | | 726 | | | 727 | | | 728 | |(4) 200 OK answer1 | 729 | |no precon | 730 | |<------------------| 731 | |(5) ACK | 732 | |------------------>| 733 |(6) PRACK answer1 | | 734 |<------------------| | 735 | | | 736 | | | 737 |(7) 200 PRACK | | 738 |------------------>| | 739 | | | 740 | | | 741 |(8) 200 INVITE | | 742 |------------------>| | 743 |(9) ACK | | 744 |<------------------| | 746 Figure 10 748 The flow for this scenario is shown in Figure 10. In this example, we 749 assume that user B is an automata or agent of some sort which will 750 answer the call immediately. Therefore, the flow is based on Flow I. 751 The controller sends an INVITE to user A containing no SDP, but with 752 a Require header indicating that preconditions are required. This 753 specific scenario (an INVITE without an offer, but with a Require 754 header indicating preconditions) is not described in [2]. It is 755 RECOMMENDED that the UAS respond with an offer in a 1xx including the 756 media streams it wishes to use for the call, and for each, list all 757 preconditions it supports as optional. Of course, the user is not 758 alerted at this time. The controller takes this offer and passes it 759 to user B (3). User B does not support preconditions, or does, but is 760 not interested in them. Therefore, when it answers the call, the 200 761 OK contains an answer without any preconditions listed (4). This 762 answer is passed to user A in the PRACK (6). At this point, user A 763 knows that there are no preconditions actually in use for the call, 764 and therefore, it can alert the user. When the call is answered, user 765 A sends a 200 OK to the controller (8) and the call is complete. 767 In the event that the offer generated by user A was not acceptable to 768 user B (because of non-overlapping codecs or media, for example), 769 user B would immediately reject the INVITE (message 3). The 770 controller would then CANCEL the request to user A. In this 771 situation, neither user A nor user B would have been alerted, 772 achieving the desired effect. It is interesting to note that this 773 property is achieved using preconditions even though it doesn't 774 matter what specific types of preconditions are supported by user A. 776 It is also entirely possible that user B does actually desire 777 preconditions. In that case, it might generate a 1xx of its own with 778 an answer containing preconditions. That answer would still be passed 779 to user A, and both parties would proceed with whatever measures are 780 necessary to meet the preconditions. Neither user would be alerted 781 until the preconditions were met. 783 9.2 Party A Initiates 785 In Section 9.1, the controller requested the use of preconditions to 786 achieve a specific goal. It is also possible that the controller 787 doesn't care (or perhaps doesn't even know) about preconditions, but 788 one of the participants in the call does care. A call flow for this 789 case is shown in Figure 11. 791 A Controller B 792 |(1) INVITE offer1 | | 793 |no media | | 794 |<---------------------| | 795 |(2) 183 answer1 | | 796 |no media | | 797 |--------------------->| | 798 |(3) PRACK | | 799 |<---------------------| | 800 |(4) 200 OK | | 801 |--------------------->| | 802 | |(5) INVITE no SDP | 803 | |--------------------->| 804 | |(6) 183 offer2 | 805 | |des=sendrecv | 806 | |conf=recv | 807 | |cur=none | 808 | |<---------------------| 809 |(7) UPDATE offer2' | | 810 |des=sendrecv | | 811 |conf=recv | | 812 |cur=none | | 813 |<---------------------| | 814 |(8) 200 UPDATE | | 815 |answer2' | | 816 |des=sendrecv | | 817 |conf=recv | | 818 |cur=none | | 819 |--------------------->| | 820 | |(9) PRACK answer2 | 821 | |des=sendrecv | 822 | |conf=recv | 823 | |cur=none | 824 | |--------------------->| 825 | |(10) 200 PRACK | 826 | |<---------------------| 827 |(11) reservation | | 828 |-------------------------------------------->| 829 |(12) reservation | | 830 |<--------------------------------------------| 831 |(13) UPDATE offer3 | | 832 |des=sendrecv | | 833 |conf=recv | | 834 |cur=recv | | 835 |--------------------->| | 836 | |(14) UPDATE offer3' | 837 | |des=sendrecv | 838 | |conf=recv | 839 | |cur=recv | 840 | |--------------------->| 841 | |(15) 200 UPDATE | 842 | |answer3' | 843 | |des=sendrecv | 844 | |conf=recv | 845 | |cur=send | 846 | |<---------------------| 847 |(16) 200 UPDATE | | 848 |answer3 | | 849 |des=sendrecv | | 850 |conf=recv | | 851 |cur=send | | 852 |<---------------------| | 853 | | | 854 | |(17) UPDATE offer4 | 855 | |des=sendrecv | 856 | |conf=recv | 857 | |cur=sendrecv | 858 | |<---------------------| 859 |(18) UPDATE offer4' | | 860 |des=sendrecv | | 861 |conf=recv | | 862 |cur=sendrecv | | 863 |<---------------------| | 864 | | | 865 |(19) 200 UPDATE | | 866 |answer4' | | 867 |des=sendrecv | | 868 |conf=recv | | 869 |cur=sendrecv | | 870 |--------------------->| | 871 | |(20) 200 UPDATE | 872 | |answer4 | 873 | |des=sendrecv | 874 | |conf=recv | 875 | |cur=sendrecv | 876 | |--------------------->| 877 |(21) 180 INVITE | | 878 |--------------------->| | 879 | |(22) 180 INVITE | 880 | |<---------------------| 881 | | | 882 |(23) 200 INVITE | | 883 |--------------------->| | 884 |(24) ACK | | 885 |<---------------------| | 886 | | | 887 | |(25) 200 INVITE | 888 | |<---------------------| 889 | |(26) ACK | 890 | |--------------------->| 892 Figure 11 894 The controller follows Flow IV; it has no specific requirements for 895 support of the preconditions specification [2]. Therefore, it sends 896 an INVITE (1) with SDP that contains no media lines. User A is 897 interested in supporting preconditions, and does not want to ring its 898 phone until resources are reserved. Since there are no media streams 899 in the INVITE, it can't reserve resources for media streams, and 900 therefore it can't ring the phone until they are conveyed in a 901 subsequent offer and then reserved. Therefore, it generates a 183 902 with the answer, and doesn't alert the user (2). The controller 903 PRACKs this (3) and A responds to the PRACK (4). 905 At this point, the controller attempts to bring B into the call. It 906 sends B an INVITE without SDP (5). B is interested in having 907 preconditions for this call. Therefore, it generates its offer in a 908 183 that contains the appropriate SDP attributes (6). The controller 909 passes this offer to A in an UPDATE request (7). The controller uses 910 UPDATE because the call has not been answered yet, and therefore, it 911 cannot use a re-INVITE. User A sees that its peer is capable of 912 supporting preconditions. Since it desires preconditions for the 913 call, it generates an answer in the 200 OK (8) to the UPDATE. This 914 answer, in turn, is passed to B in the PRACK for the provisional 915 response (9). Now, both sides perform resource reservation. User A 916 succeeds first, and passes an updated session description in an 917 UPDATE request (13). The controller simply passes this to A (after 918 the manipulation of the origin field, as required in Flow IV) in an 919 UPDATE (14), and the answer (15) is passed back to A (16). The same 920 flow happens, but from B to A, when B's reservation succeeds (17-20). 921 Since the preconditions have been met, both sides ring (21 and 22), 922 and then both answer (23 and 25), completing the call. 924 What is important about this flow is that the controller doesn't know 925 anything about preconditions. It merely passes the SDP back and forth 926 as needed. The trick is the usage of UPDATE and PRACK to pass the SDP 927 when needed. That determination is made entirely based on the offer/ 928 answer rules described in [6] and [7], and is independent of 929 preconditions. 931 10. Example Call Flows 933 10.1 Click to Dial 935 The first application of this capability we discuss is click to dial. 936 In this service, a user is browsing the web page of an e-commerce 937 site, and would like to speak to a customer service representative. 938 They click on a link, and a call is placed to a customer service 939 representative. When the representative picks up, the phone on the 940 user's desk rings. When they pick up, the customer service 941 representative is there, ready to talk to the user. 943 Customer Service Controller Users Phone Users Browser 944 | |(1) HTTP POST | | 945 | |<--------------------------------------| 946 | |(2) HTTP 200 OK | | 947 | |-------------------------------------->| 948 |(3) INVITE offer1 | | | 949 |no media | | | 950 |<------------------| | | 951 |(4) 200 answer1 | | | 952 |no media | | | 953 |------------------>| | | 954 |(5) ACK | | | 955 |<------------------| | | 956 | |(6) INVITE no SDP | | 957 | |------------------>| | 958 | |(7) 200 OK offer2 | | 959 | |<------------------| | 960 |(8) INVITE offer2' | | | 961 |<------------------| | | 962 |(9) 200 answer2' | | | 963 |------------------>| | | 964 | |(10) ACK answer2 | | 965 | |------------------>| | 966 |(11) ACK | | | 967 |<------------------| | | 968 |(12) RTP | | | 969 |.......................................| | 971 Figure 12 973 The call flow for this service is given in Figure 12. It is identical 974 to that of Figure 4, with the exception that the service is triggered 975 through an http POST request when the user clicks on the link. 976 Normally, this POST request would contain neither the number of the 977 user or of the customer service representative. The user's number 978 would typically be obtained by web application from back-end 979 databases, since the user would have presumably logged into the site, 980 giving the server the needed context. The customer service number 981 would typically be obtained through provisioning. Thus, the HTTP POST 982 is actually providing the server nothing more than an indication that 983 a call is desired. 985 We note that this service can be provided through other mechanisms, 986 namely PINT [10]. However, there are numerous differences between the 987 way in which the service is provided by pint, and the way in which it 988 is provided here: 990 o The pint solution enables calls only between two PSTN endpoints. 992 The solution described here allows calls between PSTN phones 993 (through SIP enabled gateways) and native IP phones. 995 o When used for calls between two PSTN phones, the solution here may 996 result in a portion of the call being routed over the Internet. In 997 pint, the call is always routed only over the PSTN. This may 998 result in better quality calls with the pint solution, depending 999 on the codec in use and QoS capabilities of the network routing 1000 the Internet portion of the call. 1002 o The PINT solution requires extensions to SIP (PINT is an extension 1003 to SIP), whereas the solution described here is done with baseline 1004 SIP. 1006 o The PINT solution allows the controller (acting as a PINT client) 1007 to "step out" once the call is established. The solution described 1008 here requires the controller to maintain call state for the entire 1009 duration of the call. 1011 10.2 Mid-Call Announcement Capability 1013 The third party call control mechanism described here can also be 1014 used to enable mid-call announcements. Consider a service for 1015 pre-paid calling cards. Once the pre-paid call is established, the 1016 system needs to set a timer to fire when they run out of minutes. 1017 When this timer fires, we would like the user to hear an announcement 1018 which tells them to enter a credit card to continue. Once they enter 1019 the credit card info, more money is added to the pre-paid card, and 1020 the user is reconnected to the destination party. 1022 We consider here the usage of third party call control just for 1023 playing the mid-call dialog to collect the credit card information. 1025 Pre-Paid User Controller Called Party Media Server 1026 | |(1) INV SDP c=bh | | 1027 | |------------------>| | 1028 | |(2) 200 answer1 | | 1029 | |<------------------| | 1030 | |(3) ACK | | 1031 | |------------------>| | 1032 |(4) INV no SDP | | | 1033 |<------------------| | | 1034 |(5) 200 offer2 | | | 1035 |------------------>| | | 1036 | |(6) INV offer2 | | 1037 | |-------------------------------------->| 1038 | |(7) 200 answer2 | | 1039 | |<--------------------------------------| 1040 |(8) ACK answer2 | | | 1041 |<------------------| | | 1042 | |(9) ACK | | 1043 | |-------------------------------------->| 1044 |(10) RTP | | | 1045 |...........................................................| 1046 | |(11) BYE | | 1047 | |-------------------------------------->| 1048 | |(12) 200 OK | | 1049 | |<--------------------------------------| 1050 | |(13) INV no SDP | | 1051 | |------------------>| | 1052 | |(14) 200 offer3 | | 1053 | |<------------------| | 1054 |(15) INV offer3' | | | 1055 |<------------------| | | 1056 |(16) 200 answer3' | | | 1057 |------------------>| | | 1058 | |(17) ACK answer3' | | 1059 | |------------------>| | 1060 |(18) ACK | | | 1061 |<------------------| | | 1062 |(19) RTP | | | 1063 |.......................................| | 1065 Figure 13 1067 We assume the call is set up so that the controller is in the call as 1068 a B2BUA. When the timer fires, we wish to connect the caller to a 1069 media server. The flow for this is shown in Figure 13. When the timer 1070 expires, the controller places the called party with a connection 1071 address of 0.0.0.0 (1). This effectively ``disconnects'' the called 1072 party. The controller then sends an INVITE without SDP to the the 1073 pre-paid caller (4). The offer returned from the caller (5) is used 1074 in an INVITE to the media server which will be collecting digits (6). 1075 This is an instantiation of Flow I. This flow can only be used here 1076 because the media server is an automata, and will answer the INVITE 1077 immediately. If the controller was connecting the pre-paid user with 1078 another end user, Flow III would need to be used. The media server 1079 returns an immediate 200 OK (7) with an answer, which is passed to 1080 the caller in an ACK (8). The result is that the media server and the 1081 pre-paid caller have their media streams connected. 1083 The media server plays an announcement, and prompts the user to enter 1084 a credit card number. After collecting the number, the card number is 1085 validated. The media server then passes the card number to the 1086 controller (using some means outside the scope of this 1087 specification), and then hangs up the call (11). 1089 After hanging up with the media server, the controller reconnects the 1090 user to the original called party. To do this, the controller sends 1091 an INVITE without SDP to the called party (13). The 200 OK (14) 1092 contains an offer, offer3. The controller modifies the SDP (as is 1093 done in Flow III), and passes the offer in an INVITE to the pre-paid 1094 user (15). The pre-paid user generates an answer in a 200 OK (16) 1095 which the controller passes to user B in the ACK (17). At this point, 1096 the caller and called party are reconnected. 1098 11. Implementation Recommendations 1100 Most of the work involved in supporting third party call control is 1101 within the controller. A standard SIP UA should be controllable using 1102 the mechanisms described here. However, third party call control 1103 relies on a few features that might not be implemented. As such, we 1104 RECOMMEND that implementors of user agent servers to support the 1105 following: 1107 o Offers and answers that contain a connection line with an address 1108 of 0.0.0.0. 1110 o Re-invites that change the port to which media should be sent 1112 o Re-invites that change the connection address 1114 o Re-invites that add a media stream 1116 o Re-invites that remove a media stream (setting its port to zero) 1118 o Re-invites that add a codec amongst the set in a media stream 1120 o SDP Connection address of zero 1122 o Initial invites with a connection address of zero 1124 o Initial invites with no SDP 1126 o Initial invites with SDP but no media lines 1128 o Re-invites with no SDP 1130 o The UPDATE method [7] 1132 o Reliability of provisional responses [6] 1133 o Integration of resource management and SIP [2]. 1135 12. Security Considerations 1137 12.1 Authorization and Authentication 1139 In most uses of SIP INVITE, whether or not a call is accepted is 1140 based on a decision made by a human when presented information about 1141 the call, such as the identity of the caller. In other cases, 1142 automata answer the calls, and whether or not they do so may depend 1143 on the particular application to which SIP is applied. For example, 1144 if a caller makes a SIP call to a voice portal service, the call may 1145 be rejected unless the caller has previously signed up (perhaps via a 1146 web site). In other cases, call handling policies are made based on 1147 automated scripts, such as those desribed by the Call Processing 1148 Language [13]. Frequently, those decisions are also made based on the 1149 identity of the caller. 1151 These authorization mechanisms would be applied to normal first party 1152 calls and third party calls, as these two are indistinguishable. As a 1153 result, it is important for these authorization policies to continue 1154 to operate correctly for third party calls. Of course, third party 1155 calls introduce a new party - the one initiating the third party 1156 call. Do the authorization policies apply based on the identity of 1157 that third party, or do they apply based on the participants in the 1158 call? Ideally, the participants would be able to know the identities 1159 of both other parties, and have authorization policies be based on 1160 those, as appropriate. However, this is not possible using existing 1161 mechanisms. As a result, the next best thing is for the INVITE 1162 requests to contain the identity of the third party. Ultimately, this 1163 is the user who is requesting communication, and it makes sense for 1164 call authorization policies to be based on that identity. 1166 This requires, in turn, that the controller authenticate itself as 1167 that third party. This can be challenging, and the appropriate 1168 mechanism depends on the specific application scenario. 1170 In one common scenario, the controller is acting on behalf of one of 1171 the participants in the call. A typical example is click-to-dial, 1172 where the controller and the customer service representative are run 1173 by the same administrative domain. Indeed, for the purposes of 1174 identification, the controller can legitimately claim to be the 1175 customer service representative. In this scenario, it would be 1176 appropriate for the INVITE to the end user to contain a From field 1177 identifying the customer service rep, and authenticate the request 1178 using S/MIME (see RFC 3261 [1], Section 23) signed by the key of the 1179 customer service rep (which is held by the controller) 1180 This requires the controller to actually have credentials with which 1181 it can authenticate itself as the customer support representative. In 1182 many other cases, the controller is representing one of the 1183 participants, but does not possess their credentials. Unfortunately, 1184 there are currently no standardized mechanisms that allow a user to 1185 delegate credentials to the controller in a way that limits their 1186 usage to specific third party call control operations. In the absence 1187 of such a mechanisms, the best that can be done is to use the display 1188 name in the From field to indicate the identity of the user on who's 1189 behalf the call is being made. It is RECOMMENDED that the display 1190 name be set to ``[controller] on behalf of [user]'', where user and 1191 controller are textual identities of the user and controller, 1192 respectively. In this case, the URI in the From field would identify 1193 the controller. 1195 In other situations, there is no real relationship between the 1196 controller and the participants in the call. In these situations, 1197 ideally the controller would have a means to assert that the call is 1198 from a particular identity (which could be one of the participants, 1199 or even a third party, depending on the application), and to validate 1200 that assertion with a signature using the key of the controller. 1202 12.2 End-to-End Encryption and Integrity 1204 With third party call control, the controller is actually one of the 1205 participants as far as the SIP dialog is concerened. Therefore, 1206 encryption and integrity of the SIP messages, as provided by S/MIME, 1207 will occur between participants and the controller, rather than 1208 directly between participants. 1210 However, integrity, authenticity and confidentiality of the media 1211 sessions can be provided through a controller. End-to-end media 1212 security is based on the exchange of keying material within SDP [12]. 1213 The proper operation of these mechanisms with third party call 1214 control depends on the controller behaving properly. So long as it is 1215 not attempting to explicitly disable these mechanisms, the protocols 1216 will properly operate between the participants, resulting in a secure 1217 media session that even the controller cannot eavesdrop or modify. 1218 Since third party call control is based on a model of trust between 1219 the users and the controller, it is reasonable to assume it is 1220 operating in a well-behaved manner. However, there is no 1221 cryptographic means that can prevent the controller from interfering 1222 with the initial exchanges of keying materials. As a result, it is 1223 trivially possibly for the controller to insert itself as an 1224 intermediary on the media exchange, if it should so desire. 1226 13. IANA Considerations 1227 There are no IANA considerations associated with this specification. 1229 14. Acknowledgements 1231 The authors would like to thank Paul Kyzivat, Rohan Mahy, Eric 1232 Rescorla, Allison Mankin and Sriram Parameswar for their comments. 1234 Normative References 1236 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1237 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 1238 Session Initiation Protocol", RFC 3261, June 2002. 1240 [2] Camarillo, G., Marshall, W. and J. Rosenberg, "Integration of 1241 Resource Management and Session Initiation Protocol (SIP)", RFC 1242 3312, October 2002. 1244 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1245 Levels", BCP 14, RFC 2119, March 1997. 1247 [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 1248 Session Description Protocol (SDP)", RFC 3264, June 2002. 1250 [5] Schulzrinne, H., Oran, D. and G. Camarillo, "The Reason Header 1251 Field for the Session Initiation Protocol (SIP)", RFC 3326, 1252 December 2002. 1254 [6] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional 1255 Responses in Session Initiation Protocol (SIP)", RFC 3262, June 1256 2002. 1258 [7] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE 1259 Method", RFC 3311, October 2002. 1261 [8] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 1262 32, RFC 2606, June 1999. 1264 Informative References 1266 [9] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, 1267 "RTP: A Transport Protocol for Real-Time Applications", RFC 1268 3550, July 2003. 1270 [10] Petrack, S. and L. Conroy, "The PINT Service Protocol: 1271 Extensions to SIP and SDP for IP Access to Telephone Call 1272 Services", RFC 2848, June 2000. 1274 [11] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002. 1276 [12] Andreasen, F., Baugher, M. and D. Wing, "SDP Security 1277 Descriptions for Media Streams", 1278 draft-ietf-mmusic-sdescriptions-02 (work in progress), October 1279 2003. 1281 [13] Lennox, J., Wu, X. and H. Schulzrinne, "CPL: A Language for 1282 User Control of Internet Telephony Services", 1283 draft-ietf-iptel-cpl-08 (work in progress), August 2003. 1285 Authors' Addresses 1287 Jonathan Rosenberg 1288 dynamicsoft 1289 600 Lanidex Plaza 1290 Parsippany, NJ 07054 1291 US 1293 Phone: +1 973 952-5000 1294 EMail: jdrosen@dynamicsoft.com 1295 URI: http://www.jdrosen.net 1297 Jon Peterson 1298 Neustar 1299 1800 Sutter Street 1300 Suite 570 1301 Concord, CA 94520 1302 US 1304 Phone: +1 925 363-8720 1305 EMail: jon.peterson@neustar.biz 1306 URI: http://www.neustar.biz 1308 Henning Schulzrinne 1309 Columbia University 1310 M/S 0401 1311 1214 Amsterdam Ave. 1312 New York, NY 10027 1313 US 1315 EMail: schulzrinne@cs.columbia.edu 1316 URI: http://www.cs.columbia.edu/~hgs 1317 Gonzalo Camarillo 1318 Ericsson Advanced Signalling Research Lab 1319 FIN-02420 Jorvas 1320 Finland 1322 EMail: Gonzalo.Camarillo@ericsson.com 1324 Intellectual Property Statement 1326 The IETF takes no position regarding the validity or scope of any 1327 intellectual property or other rights that might be claimed to 1328 pertain to the implementation or use of the technology described in 1329 this document or the extent to which any license under such rights 1330 might or might not be available; neither does it represent that it 1331 has made any effort to identify any such rights. Information on the 1332 IETF's procedures with respect to rights in standards-track and 1333 standards-related documentation can be found in BCP-11. Copies of 1334 claims of rights made available for publication and any assurances of 1335 licenses to be made available, or the result of an attempt made to 1336 obtain a general license or permission for the use of such 1337 proprietary rights by implementors or users of this specification can 1338 be obtained from the IETF Secretariat. 1340 The IETF invites any interested party to bring to its attention any 1341 copyrights, patents or patent applications, or other proprietary 1342 rights which may cover technology that may be required to practice 1343 this standard. Please address the information to the IETF Executive 1344 Director. 1346 Full Copyright Statement 1348 Copyright (C) The Internet Society (2003). All Rights Reserved. 1350 This document and translations of it may be copied and furnished to 1351 others, and derivative works that comment on or otherwise explain it 1352 or assist in its implementation may be prepared, copied, published 1353 and distributed, in whole or in part, without restriction of any 1354 kind, provided that the above copyright notice and this paragraph are 1355 included on all such copies and derivative works. However, this 1356 document itself may not be modified in any way, such as by removing 1357 the copyright notice or references to the Internet Society or other 1358 Internet organizations, except as needed for the purpose of 1359 developing Internet standards in which case the procedures for 1360 copyrights defined in the Internet Standards process must be 1361 followed, or as required to translate it into languages other than 1362 English. 1364 The limited permissions granted above are perpetual and will not be 1365 revoked by the Internet Society or its successors or assignees. 1367 This document and the information contained herein is provided on an 1368 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1369 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1370 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1371 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1372 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1374 Acknowledgement 1376 Funding for the RFC Editor function is currently provided by the 1377 Internet Society.