idnits 2.17.1 draft-rosenberg-sip-3pcc-00.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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 300 has weird spacing: '...ary for the ...' == Line 302 has weird spacing: '...er must step ...' == Line 303 has weird spacing: '...S, and act ...' -- 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 (March 10, 2000) is 8806 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 444 looks like a reference -- Missing reference section? '2' on line 300 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 4 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 J.Rosenberg,J.Peterson,H.Schulzrinne 4 draft-rosenberg-sip-3pcc-00.txt dynamicsoft,Level3,Columbia U. 5 March 10, 2000 6 Expires: September, 2000 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 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document discusses the usage of SIP for third party call 34 control. Third party call control refers to the ability of one entity 35 to create a call in which communications is actually between other 36 parties. We present a SIP mechanism for accomplishing third party 37 call control that does not require any extensions or changes to SIP. 39 1 Introduction 41 In the traditional telephony context, third party call control refers 42 to the ability of one entity (which we call the controller), to 43 create, modify, or terminate calls between other participants. Third 44 party call control is often used for operator services (where an 45 operator creates a call that connects two participants together), and 46 conferencing. 48 On the Internet, a wider range of services are enabled through a 49 third party session control mechanism. This is because other IP 50 applications, such as web, email, presence, instant messaging, and 51 chat can now be brought into the picture. An excellent example is 52 click-to-dial. This service allows a user to click on a web page when 53 they wish to speak to a customer service representative. The web 54 server then creates a call between the user and a customer service 55 representative. The call can be between two phones, a phone and an IP 56 host, or two IP hosts. 58 In order to support third party call control applications, a 59 mechanism is needed that allows a controller to create, modify, and 60 terminate calls with other entities. In this document, we present a 61 mechanism using SIP which allows a controller to execute third party 62 services. The mechanism is not an extension to SIP. It is merely an 63 application of the tools enabled through RFC 2543. A controller can 64 create calls between any entity that contains a normal SIP user 65 agent. After desribing the mechanism, we present three third party 66 services which take advtantage of this mechanism. One is click-to- 67 dial, the second is a feature that enables a mid-call announcement, 68 and the third is a timed conference bridge initiation. 70 2 Third Party Control 72 The basic idea behind the third party mechanism is simple. Consider 73 first the case of just connecting two users in a call. The controller 74 first sends an INVITE to the first user whose phone is to ring. This 75 is a standard INVITE, but it contains no SDP.[1] send an ACK. It 76 generates a second INVITE. This INVITE is addressed to the second 77 user to be connected in the call. This INVITE contains the SDP as 78 received from the 200 OK of the first user. When the 200 OK to this 79 second INVITE arrives, the controller ACK s it, takes the SDP, and 80 includes that in the ACK for the first call. A flow diagram for this 81 mechanism is given in Figure 1. 83 | INV no SDP | | 84 |<------------------| | 85 | | | 86 | 200 SDP A | | 87 |-----------------> | INV SDP A | 88 _________________________ 89 [1] RFC 2543 does allow for the initial INVITE to not 90 contain a session description 91 | |----------------->| 92 | | | 93 | | 200 SDP B | 94 | |<-----------------| 95 | | | 96 | | ACK | 97 | ACK SDP B |----------------->| 98 |<------------------| | 99 | | | 100 | | RTP | 101 |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | 102 |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | 103 | | | 104 | | | 105 | | | 106 | | | 107 | | | 108 | | | 109 | | | 110 | | | 112 A Controller B 114 Figure 1 116 At this point, both participants believe they are in a single point 117 to point call with some control system (assuming the controller 118 identified itself as such in the From field of the INVITE). However, 119 they are exchaning media directly with each other, rather than with 120 the controller. The result is that the controller has set up a call 121 between both participants. 123 Since the controller is still a central point for signaling, it now 124 has complete control over the call. If it receives a BYE from one of 125 the participants, it can create a new BYE and hang up with the other 126 participant. This is shown in Figure 2. 128 | | | 129 | | | 130 | BYE From A | | 131 |-----------------> | BYE From Cont. | 132 | 200 OK |----------------> | 133 |<----------------- | 200 OK | 134 | |<---------------- | 135 | | | 136 | | | 137 | | | 138 | | | 139 | | | 140 | | | 141 | | | 142 | | | 143 | | | 144 | | | 146 A Controller B 148 Figure 2 150 As an alternative, when the controller receives a BYE from A, it can 151 generate a new INVITE to a third party, C, using the SDP from B. When 152 the 200 OK arrives from C, the controller sends a re-INVITE to B, 153 using the SDP from C. If the 200 OK to the re-INVITE contains the 154 same SDP as it used in the INVITE to C, the controller has 155 sucessfully connected B to C, transparently to B. A call flow for 156 this is shown in Figure 3. 158 | | | | 159 | | | | 160 | BYE From A | | | 161 |-----------------> | INV SDP B | | 162 | 200 OK |------------------------------------>| 163 |<----------------- | | 200 SDP C | 164 | |<------------------------------------| 165 | | ACK | | 166 | |------------------------------------>| 167 | | INV SDP C | | 168 | |----------------->| | 169 | | 200 SDP B | | 170 | |<-----------------| | 171 | | ACK | | 172 | |----------------->| | 173 | | | | 174 | | | RTP | 175 | | xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | 176 | | xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | 177 | | | | 178 | | | | 179 | | | | 180 | | | | 182 A Controller B C 184 From here, new parties can be added, removed, transferred, and so on, 185 as the controller sees fit. 187 The general idea behind the mechanism is that there is a point to 188 point SIP relationship between each participant and the controller. 189 However, by passing the SDP it receives from one participant to 190 another, it can causes users to actually communicate with each other 191 rather than the controller. 193 3 Click to Dial 195 The first application of this capability we discuss is click to dial. 196 In this service, a user is browsing the web page of an e-commerce 197 site, and would like to speak to a customer service representative. 198 They click on a link, and the phone on the desk (a normal telephone) 199 rings. When the user picks up, the phone of the customer service 200 representative (an IP phone) rings. When they pick up, the service 201 representative is talking to the user. 203 We assume for purposes of this discussion that the web server is 204 actually an applications server that contains an http interface. In 205 this case, when the user clicks on the URL, the application server 206 knows, through cookies or some other state mechanism, the addresses 207 of the participants to be connected. 209 The call flow for this service is given in Figure 4. Note that it is 210 identical to that of Figure 1, with the exception that the service is 211 triggered through an http GET request when the user clicks on the 212 link. 214 | | HTTP GET | | 215 | |<-----------------+-------------------| 216 | | 200 OK | | 217 | |------------------+------------------>| 218 | | | | 219 | | | | 220 | | | | 221 | | | | 222 | INV no SDP | | | 223 |<------------------| | | 224 | | | | 225 | 200 SDP A | | | 226 |-----------------> | INV SDP A | | 227 | |----------------->| | 228 | | | | 229 | | 200 SDP B | | 230 | |<-----------------| | 231 | | | | 232 | | ACK | | 233 | ACK SDP B |----------------->| | 234 |<------------------| | | 235 | | | | 236 | | RTP | | 237 |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | | 238 |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | | 239 | | | | 240 | | | | 241 | | | | 242 | | | | 243 | | | | 244 | | | | 245 | | | | 246 | | | | 248 PSTN Controller Customer Users PC 249 GW Service 250 Representative 252 Figure 4 254 We note that this service can be provided through other mechanisms, 255 namely PINT [1]. However, there are numerous differences between the 256 way in which the service is provided by pint, and the way in which it 257 is provided here: 259 o The pint solution enables calls only between two PSTN 260 endpoints. The solution described here allows calls between 261 PSTN phones (through SIP enabled gateways) and native IP 262 phones. 264 o When used for calls between two PSTN phones, the solution here 265 may result in a portion of the call being routed over the 266 Internet. In pint, the call is always routed only over the 267 PSTN. This will probably result in better quality calls with 268 the pint solution. 270 o The PINT solution requires extensions to SIP (PINT is an 271 extension to SIP), whereas the solution described here is done 272 with baseline SIP. 274 o The PINT solution allows the controller (acting as a PINT 275 client) to "step out" once the call is established. The 276 solution described here requires the controller to remain in 277 the picture for the entire duration of the call. 279 4 Mid-Call Announcement Capability 281 The third party call control mechanism described here can also be 282 used to enable mid-call announcements. The call is set up by the 283 controller as desribed above.[2] payphone, in which case the 284 controller determines that the call is to be terminated after some 285 amount of time if the user doesn't add more money to the phone. When 286 this timer expires, the controller initiates places the called party 287 on hold. It then sends an INVITE to the media server which will be 288 collecting digits. It then sends a re-INVITE to the user on the 289 payphone, connecting its media streams with the media server. The 290 media server plays an announcement, and prompts the user to enter a 291 credit card number, for example. After collecting the number and 292 validating the card, if the call can continue, the media server hangs 293 up. The controller takes this as a cue and reconnects the user to the 294 original called party, and takes the original called party off hold. 296 A call flow for this service is shown in Figure 5 298 | RTP | | | 299 _________________________ 300 [2] It is actually not necessary for the controller 301 to set up the call. However, if a participant initiates 302 the call, the controller must step in as a virtual 303 UAC/UAS, and act as a termination and re-initiation 304 point 305 |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx| | 306 |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx| | 307 | | INV SDP 0 (hold) | | 308 | |----------------->| | 309 | | 200 OK | | 310 | |<-----------------| | 311 | | ACK | | 312 | |----------------->| | 313 | | INV SDP A | | 314 | |------------------------------------->| 315 | | | 200 SDP C | 316 | INV SDP C |<-------------------------------------| 317 |<------------------| ACK | | 318 | 200 SDP A |------------------------------------->| 319 |------------------>| | | 320 | ACK | | | 321 |<------------------| | | 322 | | | | 323 |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx| 324 |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx| 325 | | | BYE | 326 | |<-------------------------------------| 327 | | 200 OK | | 328 | |------------------------------------->| 329 | | INV SDP A | | 330 | |----------------->| | 331 | | 200 SDP B | | 332 | INV SDP B |<-----------------| | 333 |<------------------| ACK | | 334 | 200 SDP A |----------------->| | 335 |------------------>| | | 336 | ACK | | | 337 |<------------------| | | 338 | | | | 340 Payphone Controller Called Media 341 "A" Party Server 342 "B" "C" 344 Figure 5 346 We have assumed that the media server and the controller have agreed, 347 ahead of time, that a hangup implies that the desired service 348 (extending the lifetime of the call) has succeeded. This is 349 effectively allowing a call control interface between the controller 350 and the media server. Parameters needed between the elements, such as 351 the new expiration of the call, can be passed in the BYE. A separate 352 draft, forthcoming, will discuss call control interfaces to media 353 services in more detail. 355 5 Timed Conference Intitation 357 In this service, a conference bridge is booked for some number of 358 participants. In order to make sure the conference begins on time, 359 the conference bridge will call each participant at the time of the 360 call. If a participant doesn't answer, the bridge tries to contact 361 them again (unless they call in) five minutes later. 363 In the call flow described here, we assume that the controller acts 364 as the media bridge. This is not strictly necessary; some kind of 365 control interface could be used to separate the media function from 366 the controller. 368 The call flow, shown in Figure 6, is, not surprisingly, remarkably 369 like that of Figure 1. The only difference is that the SDP listed in 370 the INVITE s generated by the controller always contain SDP that 371 points to the conference bridge, rather than one of the other 372 participants. In the call flow diagram, user 1 is invited first, then 373 user 2, and then user 3. User 3 is not available, but is called again 374 five minutes later. 376 | INV SDP X | | | 377 |<------------------| | | 378 | | INV SDP X | | 379 | 200 SDP A |----------------->| | 380 |-----------------> | | | 381 | | 200 SDP B | | 382 | ACK |<-----------------| | 383 |<------------------| | | 384 | | ACK | | 385 | |----------------->| | 386 | | | | 387 | | INV SDP X | | 388 | |--------------------------------------->| 389 | | | 408 Timeout | 390 | |<---------------------------------------| 391 | | ACK | | 392 | |--------------------------------------->| 393 | | | | 394 | | | | 395 | | INV SDP X | | 396 | |--------------------------------------->| 397 | | | 408 Timeout | 398 | |<---------------------------------------| 399 | | ACK | | 400 | |--------------------------------------->| 401 | | | | 402 | | | | 403 | | | | 404 | | | | 405 | | | | 406 User 1 Controller User 2 User 3 407 "A" "X" "B" "C" 409 Figure 6 411 6 Future Work 413 We plan on considering other mechanisms which might be used for third 414 party call control, and discuss the pros and cons for each for 415 providing numerous services. 417 7 Conclusions 419 We have presented a basic third party call control mechanism that 420 uses SIP. This mechanism does not require any extensions to SIP and 421 is completely backwards compatible. 423 8 Authors Addresses 425 Jonathan Rosenberg 426 dynamicsoft 427 200 Executive Drive 428 Suite 120 429 West Orange, NJ 07052 430 email: jdrosen@dynamicsoft.com 432 Jon Peterson 433 Level 3 Communications 435 Henning Schulzrinne 436 Columbia University 437 M/S 0401 438 1214 Amsterdam Ave. 439 New York, NY 10027-7003 440 email: schulzrinne@cs.columbia.edu 442 9 Bibliography 444 [1] S. Petrack and L. Conroy, "The PINT service protocol: Extensions 445 to SIP and SDP for IP access to telephone call services," Internet 446 Draft, Internet Engineering Task Force, June 1999. Work in progress. 448 Full Copyright Statement 450 Copyright (c) The Internet Society (2000). All Rights Reserved. 452 This document and translations of it may be copied and furnished to 453 others, and derivative works that comment on or otherwise explain it 454 or assist in its implementation may be prepared, copied, published 455 and distributed, in whole or in part, without restriction of any 456 kind, provided that the above copyright notice and this paragraph are 457 included on all such copies and derivative works. However, this 458 document itself may not be modified in any way, such as by removing 459 the copyright notice or references to the Internet Society or other 460 Internet organizations, except as needed for the purpose of 461 developing Internet standards in which case the procedures for 462 copyrights defined in the Internet Standards process must be 463 followed, or as required to translate it into languages other than 464 English. 466 The limited permissions granted above are perpetual and will not be 467 revoked by the Internet Society or its successors or assigns. 469 This document and the information contained herein is provided on an 470 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 471 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 472 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 473 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 474 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.