idnits 2.17.1 draft-rosenberg-sip-3pcc-03.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 16) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 3 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** 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 738: '...cks, user agents SHOULD authenticate t...' RFC 2119 keyword, line 739: '... controller MUST sign the request as...' RFC 2119 keyword, line 742: '...ser. User agents SHOULD be configured ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 4 has weird spacing: '...-03.txt dyna...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 21, 2001) is 8192 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) -- Missing reference section? '1' on line 916 looks like a reference -- Missing reference section? '2' on line 920 looks like a reference -- Missing reference section? '3' on line 924 looks like a reference -- Missing reference section? '4' on line 928 looks like a reference -- Missing reference section? '5' on line 932 looks like a reference -- Missing reference section? '6' on line 936 looks like a reference -- Missing reference section? '7' on line 940 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force SIP WG 3 Internet Draft Rosenberg/Peterson/Schulzrinne/Camarillo 4 draft-rosenberg-sip-3pcc-03.txt dynamicsoft,Neustar,Columbia U.,Ericsson 5 November 21, 2001 6 Expires: May 2002 8 Third Party Call Control in SIP 10 STATUS OF THIS MEMO 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress". 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 To view the list Internet-Draft Shadow Directories, see 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document discusses the usage of the Session Initiation Protocol 34 (SIP) for third party call control. Third party call control refers 35 to the ability of one entity to create a call in which communications 36 is actually between other parties. We present a SIP mechanism for 37 accomplishing third party call control that does not require any 38 extensions or changes to SIP. 40 1 Introduction 42 In the traditional telephony context, third party call control allows 43 one entity (which we call the controller) to set up and manage a 44 communications relationship between two or more other parties. Third 45 party call control is often used for operator services (where an 46 operator creates a call that connects two participants together), and 47 conferencing. 49 On the Internet, a wider range of services are enabled through a 50 third party session control mechanism. This is because other IP 51 applications, such as web, email, presence, instant messaging, and 52 chat can now be brought into the picture. An excellent example is 53 click-to-dial. This service allows a user to click on a web page when 54 they wish to speak to a customer service representative. The web 55 server then creates a call between the user and a customer service 56 representative. The call can be between two phones, a phone and an IP 57 host, or two IP hosts. 59 In order to support third party call control applications, a 60 mechanism is needed that allows a controller to create, modify, and 61 terminate calls with other entities. In this document, we present a 62 mechanism using the Session Initiation Protocol (SIP) [1] which 63 allows a controller to execute third party services. The mechanism is 64 not an extension to SIP. It is merely an application of the tools 65 enabled through RFC 2543. A controller can create calls between any 66 entity that contains a normal SIP user agent. After desribing the 67 mechanism, we present three third party services which take 68 advtantage of this mechanism. One is click-to-dial, the second is a 69 feature that enables a mid-call announcement for credit card 70 authorization , and the third is a timed conference bridge 71 initiation. 73 2 Third Party Control 75 The basic idea behind the third party mechanism is simple. A 76 controller first calls one of the participants, A, and presents the 77 INVITE without any media. When this call is complete, the controller 78 has the SDP needed to communicate with A. The controller then uses 79 SDP A to initiate a call to participant B. When this call is 80 completed, the controller has the SDP needed to communicate with B. 81 This information is then passed to A. The result is that there is a 82 call leg between the controller and A, a call leg between the 83 controller and B, but media between A and B. 85 To demonstrate the recommended call flow for achieving this result, 86 we step through an evolution of the call flows and explain the 87 benefits and drawbacks of each, eventually arriving at the 88 recommended flow. 90 2.1 First Attempt 92 The controller first sends an INVITE to the first user, A, whose 93 phone is to ring. This is a standard INVITE, but it contains no SDP. 94 When A answers, the controller does not yet send an ACK. It generates 95 a second INVITE. This INVITE is addressed to the second user, B, to 96 be connected in the call. This INVITE contains the SDP as received 97 from the 200 OK from A. When the 200 OK to this second INVITE 98 arrives, the controller ACK s it, takes the SDP, and includes that in 99 the ACK for the first call. A flow diagram for this mechanism is 100 given in 1. 102 This flow is simple, requires no manipulation of the SDP by the 103 controller, and works for any media types supported by both 104 endpoints. However, it has a serious timeout problem. User B may not 105 answer the call immediately. The result is that the controller cannot 106 send the ACK to A. This causes A to retransmit the 200 OK response 107 periodically. In fact, if B does not answer within 32 seconds, the 108 call with A times out. 110 2.2 Second Attempt 112 To fix this problem, consider the call flow in Figure 2. The 113 controller first sends an INVITE to the first user whose phone is to 114 ring, user A. This is a standard INVITE, but its SDP contains a 115 single audio media line, with one codec, a random port number (but 116 not zero), and a connection address of 0.0.0.0. This creates an 117 initial media stream "on hold". 119 When A answers, the controller sends an ACK. It then generates a 120 second INVITE. This INVITE is addressed to the second user, B, to be 121 connected in the call. This INVITE contains the SDP as received from 122 the 200 OK from A. When the 200 OK to this second INVITE arrives, the 123 controller ACK s it, takes the SDP, and then re-INVITEs the first 124 user with this updated SDP. 126 This flow has the advtange that all final responses are immediately 127 ACKed. If therefore does not suffer from the timeout and message 128 inefficiency problems of flow 1. However, it too has troubles. First 129 off, it requires that the controller know the media types to be used 130 for the call (since it must generate an "on hold" SDP, which requires 131 media lines). Secondly, the first INVITE to A contains media on hold. 132 The controller expects that the response contains valid SDP for the 133 call. However, experience has shown that many UAs respond to media- 134 on-hold with media-on-hold, which won't work. Lastly, the flow 135 assumes that after the re-INVITE, user A returns the same SDP, SDP A, 136 as was returned to the original INVITE. This may not be the case. If 137 it is not, the controller needs to re-INVITE B, which may result in 138 getting a different SDP, SDP C, in the 200 OK. Then, the controller 139 needs to re-INVITE A again, and so on. The result is an infinite loop 140 of re-INVITEs. It is possible to break this cycle by having very 141 A Controller B 142 | INV no SDP | | 143 |<------------------| | 144 | | | 145 | 200 SDP A | | 146 |-----------------> | INV SDP A | 147 | |----------------->| 148 | | | 149 | | 200 SDP B | 150 | |<-----------------| 151 | | | 152 | | ACK | 153 | ACK SDP B |----------------->| 154 |<------------------| | 155 | | | 156 | | RTP | 157 |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | 158 |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | 159 | | | 160 | | | 161 | | | 162 | | | 163 | | | 164 | | | 165 | | | 166 | | | 168 Figure 1: 3pcc Flow Attempt 1 170 smart UAs which can return the same SDP whenever possible, or really 171 smart controllers that can analyze the SDP to determine if a re- 172 INVITE is really needed. However, we wish to keep this mechanism 173 simple, and avoid SDP awareness in the controller. As a result, this 174 A Controller B 175 | INV held SDP | | 176 |<------------------| | 177 | | | 178 | 200 SDP A | | 179 |-----------------> | INV SDP A | 180 | ACK |----------------->| 181 |<----------------- | | 182 | | 200 SDP B | 183 | |<-----------------| 184 | | | 185 | | ACK | 186 | INV SDP B |----------------->| 187 |<------------------| | 188 | 200 OK SDP A | | 189 |------------------>| | 190 | ACK | | 191 |<------------------| | 192 | | RTP | 193 |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | 194 |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | 195 | | | 196 | | | 197 | | | 198 | | | 199 | | | 200 | | | 201 | | | 202 | | | 204 Figure 2: 3pcc Flow Attempt 2 206 flow is not really workable. We show it here for completeness. 208 2.3 Third Flow 210 The general purpose recommended flow is shown in Figure 3. 212 First, the controller sends an INVITE to the first user, A, without 213 any SDP (which is good, since it means that the controller doesn't 214 need to assume anything about the media of the devices). User A 215 responds with its SDP, A1, in a 200 OK, which is immediately ACKed 216 with an on-hold SDP generated by the controller. 218 A Controller B 219 | INV no SDP | | time t = 0 220 |<------------------| | 221 | | | 222 | 200 SDP A1 | | 223 |-----------------> | | 224 | | | 225 | ACK SDP held | | 226 |<------------------| | 227 | | | 228 | | INV no SDP | 229 | |----------------->| 230 | | | 231 | | 200 SDP B | 232 | |<-----------------| 233 | INV SDP B' | | 234 |<------------------| | 235 | | | 236 | 200 SDP A2 | | 237 |-----------------> | | 238 | | | 239 | | ACK SDP A2' | 240 | ACK |----------------->| 241 |<------------------| | 242 | | | 243 | | RTP | 244 |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | 245 |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | 246 | | | 247 | | | 249 Figure 3: 3pcc Recommended Flow 251 Next, the controller sends an INVITE to the second user, B, also 252 without SDP. The SDP in the 200 OK, SDP B, is used to create a re- 253 INVITE to the first user. That re-INVITE is based on SDP B, but may 254 need to be reorganized to match up media lines. We therefore call 255 that SDP B'. Since this is a re-INVITE, it should complete quickly in 256 the general case. Thats good, since user B is retransmitting their 257 200 OK, waiting for an ACK. The SDP in the 200 OK from A, SDP A2 258 (which may be different than A1), is then passed to user B in the 259 ACK. It may also need reorganization to match up m lines. 261 This flow has many benefits. First, it will usually operate without 262 any spurious retransmissions or timeouts (although this may still 263 happen if a re-INVITE is not responded to quickly). Secondly, it does 264 not require the controller to guess the media that will be used by 265 the participants. Thirdly, it does not assume that a device responds 266 properly to an INVITE with SDP on hold. 268 There are some drawbacks. The controller does need to perform SDP 269 manipulations. Specifically, it must take some SDP, and generate 270 another SDP which has the same media composition, but is on hold. 271 Secondly, it may need to reorder an SDP X, so that its media lines 272 match up with those in some other SDP, Y. Finally, the flow is far 273 more complicated than the simple and elegant flow in Figure 1. 275 As a result of these drawbacks, it is our recommendation that flow 1, 276 shown in Figure 1 be used if, and only if, the controller knows that 277 user B is actually an automata that will answer the call immediately. 278 This is the case for devices such as media servers, conferencing 279 servers, and messaging servers, as described in [2]. Since we expect 280 a great deal of third party call control to be to automata, special 281 caseing this scenario is reasonable. 283 For calls to unknown entities, or to entities known to represent 284 people, it is recommended that the flow in Figure 3 be used for third 285 party call control. It is most likely to be interoperable and most 286 likely to work in the largest number of cases. 288 2.4 Continued Processing 290 Once the calls are established, both participants believe they are in 291 a single point-to-point call with some control system (assuming the 292 controller identified itself as such in the From field of the 293 INVITE). However, they are exchanging media directly with each other, 294 rather than with the controller. The result is that the controller 295 has set up a call between both participants. 297 Since the controller is still a central point for signaling, it now 298 has complete control over the call. If it receives a BYE from one of 299 the participants, it can create a new BYE and hang up with the other 300 participant. This is shown in 4. 302 As an alternative, when the controller receives a BYE from A, it can 303 generate a new INVITE to a third party, C, and connect B to that 304 participant instead. A call flow for this is shown in 5, assuming the 305 case where C represents an end user, not an automata. Note that it is 306 simply the bottom 2/3 of the primitive 3pcc flow of Figure 3. 308 A Controller B 309 | | | 310 | | | 311 | BYE From A | | 312 |-----------------> | BYE From Cont. | 313 | 200 OK |----------------> | 314 |<----------------- | 200 OK | 315 | |<---------------- | 316 | | | 317 | | | 318 | | | 319 | | | 320 | | | 321 | | | 322 | | | 323 | | | 324 | | | 325 | | | 327 Figure 4: Hanging Up with 3PCC 329 From here, new parties can be added, removed, transferred, and so on, 330 as the controller sees fit. 332 The general idea behind the mechanism is that there is a point to 333 point SIP relationship between each participant and the controller. 334 However, by passing the SDP it receives from one participant to 335 another, it can causes users to actually communicate with each other 336 rather than the controller. 338 3 Back to Back User Agents 340 The call flow in Section 2.3 assumes that the controller is the 341 entity that initiates the call. It is possible for the controller to 342 take ownership of a call setup by a different party by acting as a 343 Back to Back User Agent (B2BUA). The call flow in this case is shown 344 in Figure 6. 346 In this call flow, the controller looks deceptively like a proxy, but 347 it is not. The controller acts as a UAS for the INVITE received by A, 348 and then as a UAC when it initiates a call to B. It is this fact 349 which allows the controller to generate its own ringing messages, or 350 A Controller B C 352 | | | | 353 | | | | 354 | BYE From A | | | 355 |-----------------> | INV no SDP | | 356 | 200 OK |------------------------------------>| 357 |<----------------- | | 200 SDP C | 358 | |<------------------------------------| 359 | | | | 360 | | | | 361 | | INV SDP C' | | 362 | |----------------->| | 363 | | 200 SDP B2 | | 364 | |<-----------------| | 365 | | ACK | | 366 | |----------------->| | 367 | | | | 368 | | | ACK SDP B2' | 369 | |------------------------------------>| 370 | | | | 371 | | | | 372 | | | RTP | 373 | | | xxxxxxxxxxxxxxxx | 374 | | | xxxxxxxxxxxxxxxx | 376 Figure 5: Alternative to Hangup 378 to generate an ACK for a 200 OK, both of which are done in this call 379 flow. 381 Once set up, the controller is exactly in the same state as if it had 382 initiated the call as described in Section 2.3. The controller can 383 hang up to one side, hang up to both sides, reconenct the users to 384 media servers, and so on. 386 4 Third party call control and SDP preconditions 388 In unicast sessions there is a number of media streams flowing 389 between two entities. In order to perform resource reservation it is 390 necessary to know the session descriptions from both parties. When 391 third party call control is performed the information needed to 392 establish the QoS required is not available from the beginning. The 394 A Controller B 395 | INV SDP A1 | | time t = 0 396 |------------------>| | 397 | 180 Ringing | | 398 |<------------------| INV SDP A1 | 399 | |----------------->| 400 | | | 401 | | | 402 | | | 403 | | | 404 | | | 405 | | | 406 | | | 407 | | 200 SDP B | 408 | |<-----------------| 409 | | ACK | 410 | 200 SDP B |----------------->| 411 |<------------------| | 412 | ACK | | 413 |-----------------> | | 414 | | | 415 | | | 416 | | RTP | 417 |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | 418 |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | 419 | | | 420 | | | 422 Figure 6: Back to Back User Agent 424 call flow shown in Figure 7 shows how the exchange of SDPs between 425 both parties can be performed. 427 The controller INVITEs A in (1). At this point of time there is no 428 information available about codecs to be used port numbers or IP 429 addresses. The SDP of this INVITE just contains SDP preconditions and 430 the media stream types (audio, video, etc...). As specified in [3], 431 the called UAS returns a 183 immediately containing SDP information 432 needed for QoS signaling (2). 434 INVITE (3) contains the SDP received from A. This INVITE is sent to 435 B. When B responses with (4) 183 it is ready to perform resource 436 reservation. However, B will not start resource reservation until the 437 PRACK (7) is received. This allows B's SDP to be sent to A in (5). 438 This way both parties have all the information needed to perform 439 resource reservation. Note that, since reliable provisional responses 440 are used [4], the 183 (2) is retransmitted until the PRACK (5) 441 arrives from the controller. This PRACK is transmitted only when the 442 183 arrives from B (4). Fortunately, this 183 is generated 443 automatically, so that the first 183 (2) should not be retransmitted 444 that much, if at all. 446 The PRACK matching (2) is sent at (5). This PRACK is not sent before 447 because it is used to send B's SDP to A. The controller does not get 448 this information until (4). 450 When the preconditions from B to the controller and from A to the 451 controller are met two COMETs are received (9) and (11). At this 452 point of time is up to the controller to let the session 453 establishment go on sending a COMET to A (13). When A accepts joining 454 the session (15), a COMET (16) is sent to B so B is alerted. 456 This is really complex; and it also works such that the 457 controller decides whether preconditions are used. Is there 458 a simpler solution? 460 5 Click to Dial 462 The first application of this capability we discuss is click to dial. 463 In this service, a user is browsing the web page of an e-commerce 464 site, and would like to speak to a customer service representative. 465 They click on a link, and a call is placed to a customer service 466 representative. When the representative picks up, the phone on the 467 user's desk rings. When they pick up, the customer service 468 representative is there, ready to talk to the user. 470 We assume for purposes of this discussion that the web server is 471 actually an applications server that contains an http interface. In 472 this case, when the user clicks on the URL, the application server 473 knows, through cookies or some other state mechanism, the addresses 474 of the participants to be connected. 476 The call flow for this service is given in 8. Note that it is 477 identical to that of Figure 3, with the exception that the service is 478 triggered through an http GET request when the user clicks on the 479 link. 481 Controller A B 483 | (1) INVITE | | 484 |------------------>| | 485 | (2) 183 SDP A | | 486 |<------------------| | 487 | (3) INVITE SDP A | | 488 |------------------------------------->| 489 | (4) 183 SDP B | | 490 |<-------------------------------------| 491 | (5) PRACK SDP B | | 492 |------------------>| | 493 | (6) 200 OK (PRACK)| | 494 |<------------------| | 495 | (7) PRACK | | 496 |------------------------------------->| 497 | (8) 200 OK (PRACK)| | 498 |<-------------------------------------| 499 | (9) COMET | | 500 |<-------------------------------------| 501 |(10) 200 OK (COMET)| | 502 |------------------------------------->| 503 | (11) COMET | | 504 |<------------------| | 505 |(12) 200 OK (COMET)| | 506 |------------------>| | 507 | (13) COMET | | 508 |------------------>| | 509 |(14) 200 OK (COMET)| | 510 |<------------------| | 511 |(15) 200 OK (INVITE) | 512 |<------------------| | 513 | (16) COMET | | 514 |------------------------------------->| 515 |(17) 200 OK (COMET)| | 516 |<-------------------------------------| 517 |(18) 200 OK (INVITE) | 518 |<-------------------------------------| 519 | (19) ACK | | 520 |------------------>| | 521 | (20) ACK | | 522 |------------------------------------->| 523 | | | 525 Controller A B 527 Figure 7: Call Flow for Preconditions 528 We note that this service can be provided through other mechanisms, 529 namely PINT [5]. However, there are numerous differences between the 530 way in which the service is provided by pint, and the way in which it 531 is provided here: 533 o The pint solution enables calls only between two PSTN 534 endpoints. The solution described here allows calls between 535 PSTN phones (through SIP enabled gateways) and native IP 536 phones. 538 o When used for calls between two PSTN phones, the solution here 539 may result in a portion of the call being routed over the 540 Internet. In pint, the call is always routed only over the 541 PSTN. This may result in better quality calls with the pint 542 solution, depending on the codec in use and QoS capabilities 543 of the network routing the Internet portion of the call. 545 o The PINT solution requires extensions to SIP (PINT is an 546 extension to SIP), whereas the solution described here is done 547 with baseline SIP. 549 o The PINT solution allows the controller (acting as a PINT 550 client) to "step out" once the call is established. The 551 solution described here requires the controller to maintain 552 call state for the entire duration of the call. 554 6 Mid-Call Announcement Capability 556 The third party call control mechanism described here can also be 557 used to enable mid-call announcements. Consider a service for pre- 558 paid calling cards. Once the pre-paid call is established, the system 559 needs to set a timer to fire when they run out of minutes. When this 560 timer fires, we would like the user to hear an announcement which 561 tells them to enter a credit card to continue. Once they enter the 562 credit card info, more money is added to the pre-paid card, and the 563 user is reconnected to the destination party. 565 We consider here the usage of third party call control just for 566 playing the mid-call dialog to collect the credit card information. 568 We assume the call is set up, perhaps as described in Section 3, so 569 that the controller is in the call. When the timer fires, we wish to 570 connect the caller to a dialog server. The flow for this is shown in 571 Figure 9. 573 When the timer expires, the controller places the called party on 574 hold. It then sends an INVITE without SDP to the the pre-paid caller. 575 The SDP returned from the caller (which should be the same as the SDP 576 it returned previously), is used in an INVITE to the media server 577 which will be collecting digits. The media server offers its SDP in 578 the response. The controller then sends an ACK to the pre-paid user 579 using the SDP returned from the media server. The result is that now, 580 the media server and the pre-paid caller have their media streams 581 connected. The media server plays an announcement, and prompts the 582 user to enter a credit card number. After collecting the number, the 583 card number is validated. The controller can then hang up the call to 584 the media server. How the controller can know when to hang up the 585 call is outside the scope of this document, but is described in 586 complete detail in [2], which discusses the interface between 587 controllers and media servers. 589 After hanging up with the media server, the controller reconnects the 590 user to the original called party. 592 7 Timed Conference Intitation 594 In this service, a conference bridge is booked for some number of 595 participants. In order to make sure the conference begins on time, 596 the conference bridge will call each participant at the time of the 597 call. If a participant doesn't answer, the bridge tries to contact 598 them again (unless they call in) five minutes later. 600 The controller makes use of a conference server for this service. The 601 conference server is of the type described in [2], which means that 602 it will mix together all calls for the same request URI. The 603 controller will use third party call control to get each participant 604 to send media to the conference server. Note that since the 605 conference server is an automata, we use the 3pcc flow of Figure 1. 607 The call flow for this service is shown in Figure 10. The controller 608 calls each participant, then calls the conference server (using the 609 same request URI for all calls to the conference server). The result 610 is that each participant sends media to the conference server, and 611 the conference server sends media back. The third user, user C, does 612 not answer right away, and is re-tried a few minutes later. 614 8 Implementation Notes 616 Most of the work involved in supporting third party call control is 617 within the controller. A standard SIP UA should be controllable in 618 the mechanism described here. However, the mechanism relies on a few 619 features that might not be implemented. As such, we strongly 620 recommend implementors of user agent servers to support the 622 Customer Controller Gateway Users PC 623 Service to 624 Representative Customer 626 | | HTTP GET | | 627 | |<-------------------------------------| 628 | | 200 OK | | 629 | |------------------------------------->| 630 | | | | 631 | | | | 632 | INV no SDP | | | 633 |<------------------| | | 634 | 200 SDP A1 | | | 635 |------------------>| | | 636 | ACK SDP held | | | 637 |<------------------| INV no SDP | | 638 | |----------------->| | 639 | | 200 SDP B1 | | 640 | |<-----------------| | 641 | INV SDP B1' | | | 642 |<------------------| | | 643 | 200 SDP A2 | | | 644 |------------------>| | | 645 | | ACK SDP A2' | | 646 | |----------------->| | 647 | ACK | | | 648 |<------------------| | | 649 | | | | 650 | | RTP | | 651 |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | | 652 |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | | 653 | | | | 654 | | | | 655 | | | | 656 | | | | 657 | | | | 658 | | | | 659 | | | | 660 | | | | 662 Figure 8: Click to Dial Call Flow 664 Pre-paid Controller Called Media 665 Caller Party Server 666 "A" "B" "C" 668 | RTP | | | 669 |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx| | 670 |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx| | 671 | | INV SDP 0 (hold) | | 672 | |----------------->| | 673 | | 200 OK SDP B2 | | 674 | |<-----------------| | 675 | | ACK | | 676 | |----------------->| | 677 | INV no SDP | | | 678 |<------------------| | | 679 | 200 SDP A | | | 680 |------------------>| INV SDP A | | 681 | |------------------------------------->| 682 | | | 200 SDP C | 683 | ACK SDP C |<-------------------------------------| 684 |<------------------| ACK | | 685 | |------------------------------------->| 686 | | | | 687 |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx| 688 |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx| 689 | | BYE | | 690 | |------------------------------------->| 691 | | 200 OK | | 692 | |<-------------------------------------| 693 | | INV no SDP | | 694 | |----------------->| | 695 | | 200 SDP B2 | | 696 | INV SDP B2' |<-----------------| | 697 |<------------------| | | 698 | 200 SDP A3 | | | 699 |------------------>| ACK A3' | | 700 | ACK |----------------->| | 701 |<------------------| | | 702 | | | | 703 | RTP | | | 704 |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx| | 705 |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx| | 706 | | | 707 Figure 9: Mid-Call Announcement 709 o Re-invites that change the port to which media should be sent 711 o Re-invites that change the connection address 713 o Re-invites that add a media stream 715 o Re-invites that remove a media stream (setting its port to 716 zero) 718 o Re-invites that add a codec amongst the set in a media stream 720 o Hold (connection address of zero) 722 o Initial invites on hold 724 o Initial invites with no SDP 726 o Re-invites with no SDP (in which case the UAS returns the same 727 SDP it returned previously) 729 9 Security Considerations 731 The mechanism described here introduces several security 732 considerations. The first issue is the calling party identities 733 delivered to the participants which the controller invites. The 734 controller could indicate that the call is from itself (From: 735 sip:controller@company.com), but in many cases, the service is more 736 usable if it "spoofs" the identity of the participant that is 737 actually calling. However, to differentiate legitimate use of 3pcc 738 from real attacks, user agents SHOULD authenticate the requests. The 739 controller MUST sign the request as itself, not as A or B (it cannot 740 sign as A or B in any case). This will allow both parties to know 741 that the call is actually being established through a controller, but 742 on behalf of another user. User agents SHOULD be configured to 743 authorize requests from entities known to be controllers. 745 Note that this will result in SIP messages whose From field does not 746 match the identity of the signator (as indicated in the signed-by 747 field of the request). 749 The third party mechanism can also have an impact on encryption of 750 the media that is part of the session. If negotiation of session keys 751 is done through some kind of key exchange within SIP, the controller 752 will, in all likelihood, not be able to set it up so that 753 participants in the call arrive at the same key. This means that the 755 User 1 Controller User 3 Conference User 2 756 "A" "X" "C" Server "B" 758 | INV no SDP | | | | 759 |<---------------| | | | 760 | 200 SDP A1 | | | | 761 |--------------->| INV SDP A1 | | | 762 | |------------------------------>| | 763 | | 200 SDP CS1 | | | 764 | |<------------------------------| | 765 | | ACK | | | 766 | ACK SDP CS1 |------------------------------>| | 767 |<---------------| INV no SDP | | | 768 | |---------------------------------------------->| 769 | | 200 SDP B1 | | | 770 | |<----------------------------------------------| 771 | | INV SDP B1 | | | 772 | |------------------------------>| | 773 | | 200 SDP CS2 | | | 774 | |<------------------------------| | 775 | | ACK SDP CS2 | | | 776 | |---------------------------------------------->| 777 | | ACK | | | 778 | |------------------------------>| | 779 | | INV no SDP | | | 780 | |-------------->| | | 781 | | 408 Timeout | | | 782 | |<--------------| | | 783 | | ACK | | | 784 | |-------------->| | | 785 | | | | | 786 | | | | | 787 | | | | | 788 | | INV no SDP | | | 789 | |-------------->| | | 790 | | 200 SDP C1 | | | 791 | |<--------------| | | 792 | | INV SDP C1 | | | 793 | |------------------------------>| | 794 | | 200 SDP CS3 | | | 795 | |<--------------+---------------| | 796 | | ACK SDP CS3 | | | 797 | |-------------->| | | 798 | | ACK | | | 799 | |-------------------------------| | 801 Figure 10: Timed Conference Initiation Call Flow 802 controller may need to act as an RTP translator, decrypting with one 803 key and re-encrypting with another. 805 Third party call control has unfortunate interactions with NATs and 806 firewalls. The problems arise when the controller is on one side of a 807 firewall/NAT that is being controlled by a proxy [6] [7] that 808 receives the controller's requests, and the controlled users are on 809 the other side. Pinholes in the firewall may be opened when, in fact, 810 the media does not pass through the firewall. One way to avoid this 811 is for the firewall controlling proxy to recognize that the address 812 of the media is not within its private network, and so not perform 813 NAT or firewall control in those cases. 815 10 Conclusions 817 We have presented a basic third party call control mechanism that 818 uses SIP. This mechanism does not require any extensions to SIP and 819 is completely backwards compatible. 821 11 Open Issues 823 o Update to handle early media; this depends on how we handle 824 early media. 826 o How to handle the case when the 2nd leg rings (sends a 180) or 827 is busy (therefore sending a 486), and you wish to convey that 828 to the first leg. Since the controller initiated the request 829 to the user, it can't propagate these responses. One way is to 830 use a new reason code/phrase in a reINVITE. Another is to 831 "turn the leg around", so that the controller is the UAS. How 832 to do that? Refer/replaces? 834 o Update interactions with preconditions draft. 836 12 Changes since -02 838 o Added open issues section. 840 13 Changes since -01 842 o Included all the flows which have been discussed, weighing 843 pros and cons. 845 o Made a recommendation for which flows to use in which 846 scenarios. 848 o Updated the flows to be consistent with [2]. 850 o Added open issue with preconditions. 852 o Added B2BUA discussion. 854 14 Authors Addresses 856 Jonathan Rosenberg 857 dynamicsoft 858 72 Eagle Rock Avenue 859 First Floor 860 East Hanover, NJ 07936 861 email: jdrosen@dynamicsoft.com 863 Jon Peterson 864 NeuStar, Inc 865 1800 Sutter Street, Suite 570 866 Concord, CA 94520 867 USA 868 email: jon.peterson@neustar.com 870 Henning Schulzrinne 871 Columbia University 872 M/S 0401 873 1214 Amsterdam Ave. 874 New York, NY 10027-7003 875 email: schulzrinne@cs.columbia.edu 877 Gonzalo Camarillo 878 Ericsson 879 Advanced Signalling Research Lab. 880 FIN-02420 Jorvas 881 Finland 882 Phone: +358 9 299 3371 883 Fax: +358 9 299 3052 884 Email: Gonzalo.Camarillo@ericsson.com 886 Full Copyright Statement 888 Copyright (c) The Internet Society (2001). All Rights Reserved. 890 This document and translations of it may be copied and furnished to 891 others, and derivative works that comment on or otherwise explain it 892 or assist in its implementation may be prepared, copied, published 893 and distributed, in whole or in part, without restriction of any 894 kind, provided that the above copyright notice and this paragraph are 895 included on all such copies and derivative works. However, this 896 document itself may not be modified in any way, such as by removing 897 the copyright notice or references to the Internet Society or other 898 Internet organizations, except as needed for the purpose of 899 developing Internet standards in which case the procedures for 900 copyrights defined in the Internet Standards process must be 901 followed, or as required to translate it into languages other than 902 English. 904 The limited permissions granted above are perpetual and will not be 905 revoked by the Internet Society or its successors or assigns. 907 This document and the information contained herein is provided on an 908 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 909 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 910 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 911 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 912 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 914 15 Bibliography 916 [1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: 917 session initiation protocol," Request for Comments 2543, Internet 918 Engineering Task Force, Mar. 1999. 920 [2] J. Rosenberg, P. Mataga, and H. Schulzrinne, "An application 921 server component architecture for SIP," Internet Draft, Internet 922 Engineering Task Force, Mar. 2001. Work in progress. 924 [3] W. Marshall et al. , "Integration of resource management and 925 SIP," Internet Draft, Internet Engineering Task Force, Aug. 2001. 926 Work in progress. 928 [4] J. Rosenberg and H. Schulzrinne, "Reliability of provisional 929 responses in SIP," Internet Draft, Internet Engineering Task Force, 930 Sept. 2001. Work in progress. 932 [5] S. Petrack and L. Conroy, "The PINT service protocol: Extensions 933 to SIP and SDP for IP access to telephone call services," Request for 934 Comments 2848, Internet Engineering Task Force, June 2000. 936 [6] P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, and A. Rayhan, 937 "Middlebox communication architecture and framework," Internet Draft, 938 Internet Engineering Task Force, Oct. 2001. Work in progress. 940 [7] J. Rosenberg, D. Drew, and H. Schulzrinne, "Getting SIP through 941 firewalls and NATs," Internet Draft, Internet Engineering Task Force, 942 Feb. 2000. Work in progress.