idnits 2.17.1 draft-rosenberg-sip-3pcc-01.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 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 540: '... RECOMMENDED that if a re-INVITE doe...' RFC 2119 keyword, line 542: '...of that stream in the response MUST be...' RFC 2119 keyword, line 545: '...-INVITE response MUST be the same as i...' RFC 2119 keyword, line 568: '...cks, user agents SHOULD authenticate t...' RFC 2119 keyword, line 569: '... controller MUST sign the request as...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 4 has weird spacing: '...-01.txt dyn...' -- 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 22, 2000) is 8549 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 647 looks like a reference -- Missing reference section? '2' on line 651 looks like a reference -- Missing reference section? '3' on line 655 looks like a reference -- Missing reference section? '4' on line 659 looks like a reference -- Missing reference section? '5' on line 663 looks like a reference -- Missing reference section? '6' on line 667 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 8 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-01.txt dynamicsoft,Level3,Columbia U.,Ericsson 5 November 22, 2000 6 Expires: May 2001 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 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. Consider 76 first the case of just connecting two users in a call. The controller 77 first sends an INVITE to the first user whose phone is to ring. This 78 is a standard INVITE, but its SDP contains a single audio media line, 79 with one codec, a random port number (but not zero), and a connection 80 address of 0.0.0.0. This creates an initial media stream "on hold". 82 When the first user answers, the controller sends an ACK. It then 83 generates a second INVITE. This INVITE is addressed to the second 84 user to be connected in the call. This INVITE contains the SDP as 85 received from the 200 OK of the first user. When the 200 OK to this 86 second INVITE arrives, the controller ACK s it, takes the SDP, and 87 then re-INVITEs the first user with this updated SDP. A flow diagram 88 for this mechanism is given in 1. 90 At this point, both participants believe they are in a single point- 91 to-point call with some control system (assuming the controller 92 identified itself as such in the From field of the INVITE). However, 93 they are exchanging media directly with each other, rather than with 94 A Controller B 95 | INV held SDP | | 96 |<------------------| | 97 | | | 98 | 200 SDP A | | 99 |-----------------> | INV SDP A | 100 | ACK |----------------->| 101 |<----------------- | | 102 | | 200 SDP B | 103 | |<-----------------| 104 | | | 105 | | ACK | 106 | INV SDP B |----------------->| 107 |<------------------| | 108 | 200 OK SDP A | | 109 |------------------>| | 110 | ACK | | 111 |<------------------| | 112 | | RTP | 113 |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | 114 |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | 115 | | | 116 | | | 117 | | | 118 | | | 119 | | | 120 | | | 121 | | | 122 | | | 124 Figure 1: Basic Third Party Call Control 126 the controller. The result is that the controller has set up a call 127 between both participants. 129 Since the controller is still a central point for signaling, it now 130 has complete control over the call. If it receives a BYE from one of 131 the participants, it can create a new BYE and hang up with the other 132 participant. This is shown in 2. 134 As an alternative, when the controller receives a BYE from A, it can 135 generate a new INVITE to a third party, C, using the SDP from B. When 136 the 200 OK arrives from C, the controller sends a re-INVITE to B, 137 A Controller B 138 | | | 139 | | | 140 | BYE From A | | 141 |-----------------> | BYE From Cont. | 142 | 200 OK |----------------> | 143 |<----------------- | 200 OK | 144 | |<---------------- | 145 | | | 146 | | | 147 | | | 148 | | | 149 | | | 150 | | | 151 | | | 152 | | | 153 | | | 154 | | | 156 Figure 2: Hanging Up with 3PCC 158 using the SDP from C. If the 200 OK to the re-INVITE contains the 159 same SDP as it used in the INVITE to C, the controller has 160 sucessfully connected B to C, transparently to B. A call flow for 161 this is shown in 3. 163 From here, new parties can be added, removed, transferred, and so on, 164 as the controller sees fit. 166 The general idea behind the mechanism is that there is a point to 167 point SIP relationship between each participant and the controller. 168 However, by passing the SDP it receives from one participant to 169 another, it can causes users to actually communicate with each other 170 rather than the controller. 172 3 Third party call control and SDP preconditions 174 In unicast sessions there is a number of media streams flowing 175 between two entities. In order to perform resource reservation it is 176 necessary to know the session descriptions from both parties. When 177 third party call control is performed the information needed to 178 establish the QoS required is not available from the beginning. The 179 A Controller B C 181 | | | | 182 | | | | 183 | BYE From A | | | 184 |-----------------> | INV SDP B | | 185 | 200 OK |------------------------------------>| 186 |<----------------- | | 200 SDP C | 187 | |<------------------------------------| 188 | | ACK | | 189 | |------------------------------------>| 190 | | INV SDP C | | 191 | |----------------->| | 192 | | 200 SDP B | | 193 | |<-----------------| | 194 | | ACK | | 195 | |----------------->| | 196 | | | | 197 | | | RTP | 198 | | | xxxxxxxxxxxxxxxx | 199 | | | xxxxxxxxxxxxxxxx | 200 | | | | 201 | | | | 202 | | | | 203 | | | | 205 Figure 3: Alternative to Hangup 207 call flow shown in Figure 4 shows how the exchange of SDPs between 208 both parties can be performed. 210 The controller INVITEs A in (1). At this point of time there is no 211 information available about codecs to be used port numbers or IP 212 addresses. The SDP of this INVITE just contains SDP preconditions and 213 the media stream types (audio, video, etc...). As specified in [2], 214 the called UAS returns a 183 immediately containing SDP information 215 needed for QoS signaling (2). 217 INVITE (3) contains the SDP received from A. This INVITE is sent to 218 B. When B responses with (4) 183 it is ready to perform resource 219 reservation. However, B will not start resource reservation until the 220 PRACK (7) is received. This allows B's SDP to be sent to A in (5). 221 This way both parties have all the information needed to perform 222 resource reservation. Note that, since reliable provisional responses 223 are used [3], the 183 (2) is retransmitted until the PRACK (5) 224 arrives from the controller. This PRACK is transmitted only when the 225 183 arrives from B (4). Fortunately, this 183 is generated 226 automatically, so that the first 183 (2) should not be retransmitted 227 that much, if at all. 229 The PRACK matching (2) is sent at (5). This PRACK is not sent before 230 because it is used to send B's SDP to A. The controller does not get 231 this information until (4). 233 When the preconditions from B to the controller and from A to the 234 controller are met two COMETs are received (9) and (11). At this 235 point of time is up to the controller to let the session 236 establishment go on sending a COMET to A (13). When A accepts joining 237 the session (15), a COMET (16) is sent to B so B is alerted. 239 4 Click to Dial 241 The first application of this capability we discuss is click to dial. 242 In this service, a user is browsing the web page of an e-commerce 243 site, and would like to speak to a customer service representative. 244 They click on a link, and the phone on the desk (a normal telephone) 245 rings. When the user picks up, the phone of the customer service 246 representative (an IP phone) rings. When they pick up, the service 247 representative is talking to the user. 249 We assume for purposes of this discussion that the web server is 250 actually an applications server that contains an http interface. In 251 this case, when the user clicks on the URL, the application server 252 knows, through cookies or some other state mechanism, the addresses 253 of the participants to be connected. 255 The call flow for this service is given in 5. Note that it is 256 identical to that of Figure 1, with the exception that the service is 257 triggered through an http GET request when the user clicks on the 258 link. 260 We note that this service can be provided through other mechanisms, 261 namely PINT [4]. However, there are numerous differences between the 262 way in which the service is provided by pint, and the way in which it 263 is provided here: 265 o The pint solution enables calls only between two PSTN 266 endpoints. The solution described here allows calls between 267 PSTN phones (through SIP enabled gateways) and native IP 268 phones. 270 Controller A B 272 | (1) INVITE | | 273 |------------------>| | 274 | (2) 183 SDP A | | 275 |<------------------| | 276 | (3) INVITE SDP A | | 277 |------------------------------------->| 278 | (4) 183 SDP B | | 279 |<-------------------------------------| 280 | (5) PRACK SDP B | | 281 |------------------>| | 282 | (6) 200 OK (PRACK)| | 283 |<------------------| | 284 | (7) PRACK | | 285 |------------------------------------->| 286 | (8) 200 OK (PRACK)| | 287 |<-------------------------------------| 288 | (9) COMET | | 289 |<-------------------------------------| 290 |(10) 200 OK (COMET)| | 291 |------------------------------------->| 292 | (11) COMET | | 293 |<------------------| | 294 |(12) 200 OK (COMET)| | 295 |------------------>| | 296 | (13) COMET | | 297 |------------------>| | 298 |(14) 200 OK (COMET)| | 299 |<------------------| | 300 |(15) 200 OK (INVITE) | 301 |<------------------| | 302 | (16) COMET | | 303 |------------------------------------->| 304 |(17) 200 OK (COMET)| | 305 |<-------------------------------------| 306 |(18) 200 OK (INVITE) | 307 |<-------------------------------------| 308 | (19) ACK | | 309 |------------------>| | 310 | (20) ACK | | 311 |------------------------------------->| 312 | | | 314 Controller A B 316 Figure 4: Call Flow for Preconditions 318 PSTN Controller Customer Users PC 319 GW Service 320 Representative 322 | | HTTP GET | | 323 | |<-----------------+-------------------| 324 | | 200 OK | | 325 | |------------------+------------------>| 326 | | | | 327 | | | | 328 | | | | 329 | | | | 330 | INV SDP held | | | 331 |<------------------| | | 332 | | | | 333 | 200 SDP A | | | 334 |-----------------> | INV SDP A | | 335 | |----------------->| | 336 | | | | 337 | | 200 SDP B | | 338 | |<-----------------| | 339 | | | | 340 | | ACK | | 341 | INV SDP B |----------------->| | 342 |<------------------| | | 343 | 200 SDP A | | | 344 |------------------>| | | 345 | ACK | | | 346 |<------------------| | | 347 | | | | 348 | | RTP | | 349 |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | | 350 |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | | 351 | | | | 352 | | | | 353 | | | | 354 | | | | 355 | | | | 356 | | | | 357 | | | | 358 | | | | 360 Figure 5: Click to Dial Call Flow 361 o When used for calls between two PSTN phones, the solution here 362 may result in a portion of the call being routed over the 363 Internet. In pint, the call is always routed only over the 364 PSTN. This may result in better quality calls with the pint 365 solution, depending on the codec in use and QoS capabilities 366 of the network routing the Internet portion of the call. 368 o The PINT solution requires extensions to SIP (PINT is an 369 extension to SIP), whereas the solution described here is done 370 with baseline SIP. 372 o The PINT solution allows the controller (acting as a PINT 373 client) to "step out" once the call is established. The 374 solution described here requires the controller to maintain 375 call state for the entire duration of the call. 377 5 Mid-Call Announcement Capability 379 The third party call control mechanism described here can also be 380 used to enable mid-call announcements. The call is set up by the 381 controller as desribed above. 383 It is actually not necessary for the controller to set up 384 the call. However, if a participant initiates the call, the 385 controller must step in as a virtual UAC/UAS, and act as a 386 termination and re-initiation point 388 Perhaps the call is through a payphone, in which case the controller 389 determines that the call is to be terminated after some amount of 390 time if the user doesn't add more money to the phone. When this timer 391 expires, the controller places the called party on hold. It then 392 sends an INVITE to the media server which will be collecting digits. 393 It then sends a re-INVITE to the user on the payphone, connecting its 394 media streams with the media server. The media server plays an 395 announcement, and prompts the user to enter a credit card number, for 396 example. After collecting the number and validating the card, if the 397 call can continue, the media server hangs up. The controller takes 398 this as a cue and reconnects the user to the original called party, 399 and takes the original called party off hold. 401 A call flow for this service is shown in 6. 403 We have assumed that the media server and the controller have agreed, 404 ahead of time, that a hangup implies that the desired service 405 (extending the lifetime of the call) has succeeded. This is 406 effectively allowing a call control interface between the controller 407 and the media server. Parameters needed between the elements, such as 408 the new expiration of the call, can be passed in the BYE. A separate 409 draft, forthcoming, will discuss call control interfaces to media 410 services in more detail. 412 6 Timed Conference Intitation 414 In this service, a conference bridge is booked for some number of 415 participants. In order to make sure the conference begins on time, 416 the conference bridge will call each participant at the time of the 417 call. If a participant doesn't answer, the bridge tries to contact 418 them again (unless they call in) five minutes later. 420 In the call flow described here, we assume that the controller acts 421 as the media bridge. This is not strictly necessary; some kind of 422 control interface could be used to separate the media function from 423 the controller. 425 The call flow, shown in 7, is, not surprisingly, remarkably like that 426 of Figure 1. The only difference is that the SDP listed in the INVITE 427 s generated by the controller always contain SDP that points to the 428 conference bridge, rather than one of the other participants. In the 429 call flow diagram, user 1 is invited first, then user 2, and then 430 user 3. User 3 is not available, but is called again five minutes 431 later. 433 7 Implementation Notes 435 Most of the work involved in supporting third party call control is 436 within the controller. A standard SIP UA should be controllable in 437 the mechanism described here. However, the mechanism relies on a few 438 features that might not be implemented. As such, we strongly 439 recommend implementors of user agents to support the following: 441 o Re-invites that change the port to which media should be send 443 o Re-invites that change the connection address 445 o Re-invites that add a media stream 447 o Re-invites that remove a media stream (setting its port to 448 zero) 450 o Re-invites that add a codec amongst the set in a media stream 452 o Hold (connection address of zero) 454 Payphone Controller Called Media 455 "A" Party Server 456 "B" "C" 458 | RTP | | | 459 |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx| | 460 |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx| | 461 | | INV SDP 0 (hold) | | 462 | |----------------->| | 463 | | 200 OK | | 464 | |<-----------------| | 465 | | ACK | | 466 | |----------------->| | 467 | | INV SDP A | | 468 | |------------------------------------->| 469 | | | 200 SDP C | 470 | INV SDP C |<-------------------------------------| 471 |<------------------| ACK | | 472 | 200 SDP A |------------------------------------->| 473 |------------------>| | | 474 | ACK | | | 475 |<------------------| | | 476 | | | | 477 |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx| 478 |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx| 479 | | | BYE | 480 | |<-------------------------------------| 481 | | 200 OK | | 482 | |------------------------------------->| 483 | | INV SDP A | | 484 | |----------------->| | 485 | | 200 SDP B | | 486 | INV SDP B |<-----------------| | 487 |<------------------| ACK | | 488 | 200 SDP A |----------------->| | 489 |------------------>| | | 490 | ACK | | | 491 |<------------------| | | 492 | | | | 494 User 1 Controller User 2 User 3 495 "A" "X" "B" "C" 497 | INV SDP X | | | 498 |<------------------| | | 499 | | INV SDP X | | 500 | 200 SDP A |----------------->| | 501 |-----------------> | | | 502 | | 200 SDP B | | 503 | ACK |<-----------------| | 504 |<------------------| | | 505 | | ACK | | 506 | |----------------->| | 507 | | | | 508 | | INV SDP X | | 509 | |--------------------------------------->| 510 | | | 408 Timeout | 511 | |<---------------------------------------| 512 | | ACK | | 513 | |--------------------------------------->| 514 | | | | 515 | | | | 516 | | INV SDP X | | 517 | |--------------------------------------->| 518 | | | 408 Timeout | 519 | |<---------------------------------------| 520 | | ACK | | 521 | |--------------------------------------->| 522 | | | | 523 | | | | 524 | | | | 525 | | | | 526 | | | | 528 Figure 7: Timed Conference Initiation Call Flow 530 o Initial invites on hold 532 In addition, note that in Figure 1, the controller sends a re-INVITE 533 to A with the SDP from B. The response to this re-INVITE is a 200 OK 534 that contains "SDP A". If the SDP returned in the re-INVITE response 535 were not the same, the controller would need to initiate a re-INVITE 536 to B with that new SDP. This means that a UA which returns a 537 different SDP (for example, by changing the ports) in the response to 538 every re-INVITE will trigger an infinite re-INVITE loop from the 539 controller to each controller entity. As such, it is STRONGLY 540 RECOMMENDED that if a re-INVITE does not require a UAS to modify the 541 formulation of the SDP description for a specific stream in the 542 response, the SDP description of that stream in the response MUST be 543 the same. In other words, if a UA was in a session with a single 544 stream, using codec A, and it received a re-INVITE modifying the port 545 to send to, the re-INVITE response MUST be the same as it was to the 546 initial request. However, if the re-INVITE forces the UAS to change 547 codecs, it is acceptable in that case to use a different port in the 548 SDP in the response. 550 In a previous draft, the flow of Figure 1 used a delayed ACK instead 551 of a re-INVITE to update the SDP with the first user. The delayed ACK 552 approach results in fewer messages (a savings of two), but has 553 timeout problems. Specifically, If the second user does not answer 554 within 32 seconds, the first user will timeout (as it did not receive 555 an ACK), and the call will not be established. Since this will happen 556 in practice, we strongly recommend the procedure described above 557 rather than the delayed ACK mechanism. 559 8 Security Considerations 561 The mechanism described here introduces several security 562 considerations. The first issue is the calling party identities 563 delivered to the participants which the controller invites. The 564 controller could indicate that the call is from itself (From: 565 sip:controller@company.com), but in many cases, the service is more 566 usable if it "spoofs" the identity of the participant that is 567 actually calling. However, to differentiate legitimate use of 3pcc 568 from real attacks, user agents SHOULD authenticate the requests. The 569 controller MUST sign the request as itself, not as A or B. This will 570 allow both parties to know that the call is actually being 571 established through a controller. User agents SHOULD be configured to 572 authorize requests from entities known to be controllers. 574 Note that this will result in SIP messages whose From field does not 575 match the identity of the signator (as indicated in the signed-by 576 field of the request). 578 The third party mechanism can also have an impact on encryption of 579 the media that is part of the session. If negotiation of session keys 580 is done through some kind of key exchange within SIP, the controller 581 will, in all likelihood, not be able to set it up so that 582 participants in the call arrive at the same key. This means that the 583 controller may need to act as an RTP translator, decrypting with one 584 key and re-encrypting with another. 586 Third party call control has unfortunate interactions with NATs and 587 firewalls. The problems arise when the controller is on one side of a 588 firewall/NAT that is being controlled by a proxy [5] [6] that 589 receives the controller's requests, and the controlled users are on 590 the other side. Pinholes in the firewall may be opened when, in fact, 591 the media does not pass through the firewall. One way to avoid this 592 is for the firewall controlling proxy to recognize that the address 593 of the media is not within its private network, and so not perform 594 NAT or firewall control in those cases. 596 9 Conclusions 598 We have presented a basic third party call control mechanism that 599 uses SIP. This mechanism does not require any extensions to SIP and 600 is completely backwards compatible. 602 10 Changes since -00 604 o Modified basic flow to use re-INVITE instead of delayed ACK. 606 o Included preconditions interactions. 608 o Added implementation considerations section. 610 o Updated security considerations to talk about NAT/firewall 611 control, and to introduce the notion of signing requests when 612 the signator is not the user in the From field. 614 11 Authors Addresses 616 Jonathan Rosenberg 617 dynamicsoft 618 72 Eagle Rock Avenue 619 First Floor 620 East Hanover, NJ 07936 621 email: jdrosen@dynamicsoft.com 623 Jon Peterson 624 Level 3 Communications 625 1025 Eldorado Blvd 626 Broomfield, CO 80021 627 email: Jon.Peterson@level3.com 629 Henning Schulzrinne 630 Columbia University 631 M/S 0401 632 1214 Amsterdam Ave. 633 New York, NY 10027-7003 634 email: schulzrinne@cs.columbia.edu 636 Gonzalo Camarillo 637 Ericsson 638 Advanced Signalling Research Lab. 639 FIN-02420 Jorvas 640 Finland 641 Phone: +358 9 299 3371 642 Fax: +358 9 299 3052 643 Email: Gonzalo.Camarillo@ericsson.com 645 12 Bibliography 647 [1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: 648 session initiation protocol," Request for Comments 2543, Internet 649 Engineering Task Force, Mar. 1999. 651 [2] B. Marshall et al. , "Integration of resource management and 652 SIP," Internet Draft, Internet Engineering Task Force, Nov. 2000. 653 Work in progress. 655 [3] J. Rosenberg and H. Schulzrinne, "Reliability of provisional 656 responses in SIP," Internet Draft, Internet Engineering Task Force, 657 July 2000. Work in progress. 659 [4] S. Petrack and L. Conroy, "The PINT service protocol:extensions 660 to SIP and SDP for IP access to telephone call services," Internet 661 Draft, Internet Engineering Task Force, Feb. 2000. Work in progress. 663 [5] J. Kuthan and J. Rosenberg, "Firewall control protocol framework 664 and requirements," Internet Draft, Internet Engineering Task Force, 665 June 2000. Work in progress. 667 [6] J. Rosenberg, D. Drew, and H. Schulzrinne, "Getting SIP through 668 firewalls and NATs," Internet Draft, Internet Engineering Task Force, 669 Feb. 2000. Work in progress.