Internet Engineering Task Force R. Mahy Internet Draft Cisco Systems Document: draft-mahy-sip-peer-3pcc-00.txt Nov 2000 Individual Submission Expires: Apr 2001 Using SIP for Peer-to-Peer Third-Party Call Control Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Abstract The 3rd party call control draft [2] demonstrates a usage of SIP [3] with some of the enhancements of RFC2543bis [4]. This usage requires that a 3pcc controller remain in the signaling path and maintain state for the duration of the call. While this is necessary in certain situations (ex: protocol translation: H.323 [5] to SIP, SIP to RTSP [6], HTTP [7] to SIP), it is sub-optimal in pure SIP environments. This draft demonstrates a usage of the REFER method [8] and SIP for presence [9] to allow authorized peers to participate in call control. Note that much of the functionality described in PHONECTL [10] can be duplicated using the proposed usage. Also note that this is not an extension of SIP, merely a usage of SIP and existing extensions. 3. Example Usage Our example is a desktop call control application "Dialer" which is controlling and monitoring the status of an IP phone (a SIP UA) labeled "Phone". For brevity, the headers of some packets are omitted; and only the request line, the Call-ID header and the Peer-to-Peer Third Party Call Control Nov 2000 Refer-To header are shown for REFER requests. Escaping of nested brackets is not shown for clarity. First the Dialer requests that Phone REGISTER, and SUBSCRIBEs to the presence state of Phone. Dialer Phone Bob Chris Reg Server | | | | | F1 |--REFER------>| | | | F2 | |-----------REGISTER------------------------->| F3 | |<----------200(REG)--------------------------| F4 |<-200(REFER)--| | | | | | | | | F5 |--SUBSCRIBE-->| | | get user's | F6 |<-200(SUB)----| | | presence | | | | | | F1 Dialer -> Phone REFER sip:phone.foo.com SIP/2.0 Call-ID: 1@dialer.foo.com Refer-To: F2 Phone - Registration Server REGISTER sip:user@foo.com SIP/2.0 Call-ID: 100@phone.foo.com F5 Dialer -> Phone SUBSCRIBE sip:user@phone.foo.com SIP/2.0 Call-ID: 2@dialer.foo.com F6 Phone -> Dialer SIP/2.0 200 OK Call-ID: 2@dialer.foo.com Content-Type: application/xpidf+xml Content-Length: ...
Peer-to-Peer Third Party Call Control Nov 2000 Now the dialer application asks the phone to place a call Dialer Phone Bob Chris Reg Server F7 |--REFER------>| | | | F8 | |----INVITE--->| New Call | | F9 |<--NOTIFY-----| | | Phone in | F10 |--200(NTFY)-->| | | inuse state | F11 | |<----180------| | | F12 | |<--200(INV)---| | | F13 | |-----ACK----->| | | F14 |<-200(REFER)--| | | | | | | | | F7 Dialer -> Phone REFER sip:phone.foo.com SIP/2.0 Call-ID: 3@dialer.foo.com Refer-To: F8 Phone -> Bob INVITE sip:bob@foo.com SIP/2.0 Call-ID: 101@phone.foo.com F9 Phone -> Dialer NOTIFY sip:user@phone.foo.com Call-ID: 2@dialer.foo.com Content-Type: application/xpidf+xml Content-Length: ...
Now the dialer places the call with Bob on hold Dialer Phone Bob Chris Reg Server | | | | | F15 |---REFER----->| | | | F16 | |----INVITE--->| Hold | | F17 | |<--200(INV)---| | | F18 | |-----ACK----->| | | F19 |<-200(REFER)--| | | | | | | | | Peer-to-Peer Third Party Call Control Nov 2000 F15 Dialer -> Phone REFER sip:phone.foo.com SIP/2.0 Call-ID: 3@dialer.foo.com Refer-To: F16 Phone -> Bob INVITE sip:bob@foo.com SIP/2.0 Call-ID: 101@phone.foo.com c=0.0.0.0 The dialer places a new call to Chris Dialer Phone Bob Chris Reg Server | | | | | F20 |---REFER----->| | | | F21 | |----------INVITE------------>| New Call | F22 | |<-----------180--------------| | F23 | |<---------200(INV)-----------| | F24 | |------------ACK------------->| | F25 |<-200(REFER)--| | | | | | | | | F20 Dialer -> Phone REFER sip:phone.foo.com SIP/2.0 Call-ID: 4@dialer.foo.com Refer-To: F21 Phone -> Chris INVITE sip:chris@foo.com SIP/2.0 Call-ID: 102@phone.foo.com The dialer application begins a transfer Dialer Phone Bob Chris Reg Server | | | | | F26 |---REFER----->| | | | F27 | |---REFER----->| | | F28 | | |----INVITE--->| Begin | F29 | | |<--200(INV)---| Transfer | F30 | | |-----ACK----->| | F31 | |<--200(REFER)-| | | F32 |<-200(REFER)--| | | | | | | | | Peer-to-Peer Third Party Call Control Nov 2000 F26 Dialer -> Phone REFER sip:phone.foo.com SIP/2.0 Call-ID: 3@dialer.foo.com Refer-To: > F27 Phone -> Bob REFER sip:bob@foo.com Call-ID: 101@phone.foo.com (Bob recognizes this Call-ID) Refer-To= F28 Bob -> Chris INVITE sip:chris@foo.com Call-ID: 102@phone.foo.com (Chris recognizes this Call-ID) The dialer asks the phone to send BYEs to Bob and Chris, since we want to be "out of the loop". Dialer Phone Bob Chris Reg Server | | | | | F33 |---REFER----->| | | | F34 |---REFER----->| | | | F35 | |-----BYE----->| | Complete | F36 | |----------------BYE--------->| Transfer | F37 | |<---200(BYE)--| | | F38 | |<--------------200(BYE)------| | F39 |<-200(REFER)--| | | | F40 |<--NOTIFY-----| | | Phone in | F41 |--200(NTFY)-->| | | open state | | | | | | F33 REFER sip:phone.foo.com SIP/2.0 Call-ID: 101@phone.foo.com Refer-To: F34 REFER sip:phone.foo.com SIP/2.0 Call-ID: 4@dialer.foo.com Refer-To: Peer-to-Peer Third Party Call Control Nov 2000 F40 NOTIFY sip:user@phone.foo.com SIP/2.0 Content-Type: application/xpidf+xml Content-Length: ...
If the dialer subscribed to more detailed state of Phone, the dialer could accept incoming calls as well. Dialer Phone Bob Chris Reg Server | | | | | F42 | |<--INVITE-----| | Call arrives | F43 | |----180------>| | | F44 |<--NOTIFY-----| | | Notify Dialer | F45 |--200(NTFY)-->| | | | | | | | | F46 |----REFER---->| | | Accept call | F47 | |---INVITE---->| | (reINVITE) | F48 | |<--200(INV)---| | | F49 | |-----ACK----->| | | F50 |<-200(REFER)--| | | | | | | | | F42 Bob -> Phone INVITE sip:user@phone.foo.com SIP/2.0 Call-ID: 300@bob.foo.com F44 Phone -> Dialer NOTIFY sip:dialer.foo.com Call-ID: 2@phone.foo.com Content-type: application/sip INVITE sip:user@phone.foo.com SIP/2.0 ... F46 Dialer -> Phone REFER sip:phone.foo.com SIP/2.0 Call-ID: 103@phone.foo.com Refer-To: Peer-to-Peer Third Party Call Control Nov 2000 F47 Phone -> Bob INVITE sip:bob@foo.com Call-ID: 300@bob.foo.com Finally the Dialer could REFER the phone to unREGISTER (Logout) by sending a REFER with a Refer-To URI such as this: 4. Future work Include these use cases: - Send Digits to be rendered as DTMF - More detailed status by subscribing to SIP headers - Retrieve from hold - Conferencing 5. Security Considerations This usage of REFER greatly expands the scope of potential attacks. For example, a REFER with the method=BYE parameter in the Refer-To header is an obvious and trivial form of Denial of Service if REFER requests are not authenticated. UASs which allow this usage MUST require authentication. Authentication and other security issues are discussed in [4], [8], [9] and [11]. 6. References [1] S Bradner, "The Internet Standards Process -- Revision 3", RFC2026 (BCP), IETF, October 1996. [2] J. Rosenberg, J. Peterson, H. Schulzrinne, "Third Party Call Control in SIP", Internet Draft , IETF; March 2000. Work in progress [3] M. Handley, E. Schooler, and H. Schulzrinne, "SIP: Session Initiation Protocol", RFC2543, Internet Engineering Task Force, Nov 1998. [4] M. Handley, E. Schooler, H. Schulzrinne, J. Rosenberg, "SIP: Session Initiation Protocol", Internet Draft , Internet Engineering Task Force, September 2000. Work in progress [5] H. Schulzrinne, A. Rao, and R. Lanphier, _Real time streaming protocol (RTSP),_ RFC2326, Internet Engineering Task Force, Apr. 1998. Peer-to-Peer Third Party Call Control Nov 2000 [6] International Telecommunication Union, _Visual telephone systems and equipment for local area networks which provide a non-guaranteed quality of service,_ Recommendation H.323, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, May 1996. [7] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, and T. Berners-Lee, _Hypertext transfer protocol _ HTTP/1.1,_ Request for Comments 2616, Internet Engineering Task Force, June 1999. [8] R. Sparks, "SIP Call Control Transfer", Internet Draft , Internet Engineering Task Force, November 2000. Work in progress. [9] J Rosenberg, et al., "SIP Extensions for Presence", Internet Draft , IETF, June 2000. Work in progress. [10] R. Dean, R. Belkind, "PHONECTL Protocol", Internet Draft , IETF; September 2000. Work in Progress. [11] Adam Roach, "Event Notification in SIP", Internet Draft , IETF; August 2000. Work in progress. [12] J Rosenberg, et al., "A Data Format for Presence Using XML", Internet Draft , IETF, June 2000. Work in progress. 7. Acknowledgments Thanks to Robert Sparks for making the REFER method so flexible; Adam Roach, and the authors of the SIP presence proposal. 8. Author's Address Rohan Mahy Cisco Systems 170 W Tasman Dr MS: I/2/3 San Jose, CA 95134 USA Phone: +1 408 526 8570 Email: rohan@cisco.com Peer-to-Peer Third Party Call Control Nov 2000 Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into