PINT Working Group L. Slutsman Expires: July 2000 AT&T Labs A proposal for new PINT building blocks with applications to Conference Calling Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Distribution of this memo is unlimited. Abstract The main purpose of this document is to propose new Conference Call Service for the PINT WG. This document contains a description of a Conference Call Service for PINT (CCSP), provides a non-exhaustive list of PINT requests (PINT Conference Building Blocks) to support them, and describes the needed extensions to the current PINT architecture. Current PINT services, such as Request to Call, use the Internet only to deliver service requests from an IP host to the PSTN to be executed there. However, limiting the PINT Conference service to just delivering the request to allocate the conference bridge to the PSTN, would hardly justify the practicality of the service. The PINT Conference Service described in this document allows for the following functionality: o manual or automated negotiation of conference parameters, such as date, agenda, etc., before the PSTN resources are committed; o requesting the PSTN to allocate the conference bridge; o requesting the PSTN to start the conference automatically by calling each participant at the specified time; Jan 2000 A proposal for new PINT building blocks with applications to Conference Calling [Page 2] o monitoring real-time conference events by keeping track of the current speaker as well as of participants leaving or joining the conference bridge. Unlike the current PINT services, which require exactly one request per service, the proposed Conference Call Service with the above functionality, needs to be mapped into a number of PINT requests. In this paper we propose a non-exhaustive list of PINT requests to support the basic CCSP functionality. We also discuss the extensions to the current PINT architecture that are needed to support the CCSP. If the service proposal is approved by the PINT WG, the protocol issues such as profiling SIP, SDP, etc. w ill be addressed in the forthcoming documents. This document is intended for the PSTN-Internet Interworking (PINT) working group of the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at pint@lists.research.bell-labs.com and/or to the author. 1. Introduction The need to invoke telephone services from the Internet was addressed in the PINT Working Group. To expedite the process only three milestone services were selected: Request to Call, Request to Fax, and Request to Hear Content. All these service involve two parties: calling party A and some remote called party B. A request is sent from an IP host to connect A to B. In this document we discuss PINT conference services that involve multiple parties. Specifically, we focus on conferences run by a conference host. The conference host is the participant responsible for initiating and managing the conference. To illustrate what we mean by a PINT conference service, let us consider the following example. Suppose that the working group of the IETF wants to meet to discuss the latest protocol draft. Through some information exchange mechanism (for example email), the working group chair and/or the area director, acting as the host of the prospective conference, establishes mutually agreeable date, agenda, and list of participants with their telephone numbers. Finally, an IP host, acting on behalf of the conference host, relays the conference request into the telephone network. The PSTN carries out the request by calling each conference participant at the specified time and connecting him or her to a mixing bridge. In the course of the conference participants may join and leave the conference, may want to FAX VGs, etc. Since participants are very likely to use the Internet during the conference, it is desirable to use Internet to monitor these run-time events The example above shows that: o The PINT Conference service is a natural generalization of Request to Call ; o Internet may be used to automate the process of negotiations(time, Jan 2000 A proposal for new PINT building blocks with applications to Conference Calling [Page 3] agenda, etc.) among participants; o Internet may be used to control and monitor a conference in progress (who is speaking, who has left the bridge, etc). The rest of this paper is organized as follows: section 2 provides definitions; section 3 provide a non-exhaustive list of PINT requests required for the PINT Conference Call Service; section 4 describes the PINT architecture; section 5 introduces the conference call mediation service; section 6 contains some security consideration for PINT Conference Service; section 7 provides references; and section 8 lists author's address. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in This document is to be interpreted as described in RFC 2119. In addition, the construct "MUST .... OR ...." implies that it is an absolute requirement of his specification to implement one of the two possibilities stated (represented by dots in the above phrase). An implementation must be able to interoperate with another implementation, which chooses either of the two possibilities. 2. Definitions This document uses a number of terms to refer to the roles played by conference participants and host. In addition, we need to introduce terms describing the conference states during its life cycle. These terms are listed below: 1. A PINT Conference is a set of participants invited by the same source-host (but not necessarily at the same time) and further identified by a unique conference-id. The conference-id is returned in response to the initial conference request issued by the conference host and is broadcast to all current participants. 2. At the time of the initial request the conference enters a dormant state. While in this state, the conference remains invisible to the PSTN: no PSTN resources have yet been allocated, and participants may negotiate conference parameters, such as a list of participants, data, agenda, etc., using, for example,email. 3. At a certain point the host commits the negotiated conference parameters: the conference enters the committed state; the notification is sent to the PSTN, who allocates the network resources (see Fig-1). 4. Finally, at the agreed time and date, the PSTN allocates the voice-bridge, calls participants: the conference enters the active state. 3. Basic PINT Conference Service Requests--PINT Conference Building Blocks The PINT Conference Service allows IP hosts, representing the conference host and participants, to allocate the PSTN conference Jan 2000 A proposal for new PINT building blocks with applications to Conference Calling [Page 4] bridge and manage and control the conference during its entire life cycle. A non-exhaustive list of PINT requests to support the CCSP is given below. 3.1 Initial Conference Request The conference host issues this request to initiate the prospective conference. The purpose of this request is to broadcast the host's initial disposition: his/her openings, agenda, relevant documents, etc. Upon successful execution of this request a unique conference-id is generated and broadcast to all participants, and the conference enters the dormant state. For authentication of subsequent requests issued by the host, he/she may include a cryptographic key in the initial request, which must then itself be encrypted to protect the "secret". All further requests can have an HMAC (RFC2104) field that verifies that the host has issued them. 3.2 Conference Cancellation Request The conference host (and only he) may cancel the conference at any time while it is inactive by sending a Conference Cancellation Request. If the request is issued while in the "committed" state, the PSTN will receive the notification and release all pending resources. Upon successful execution of this request, the notification is broadcast to all participants. 3.3 Conference Modification Request Let us assume that the conference participants, using some unspecified tools such as email, are trying to negotiate date, agenda, and other parameters of the conference. At a certain stage, the conference host needs to issue a Conference Modification Request to formalize changes to the conference parameters. This request must be supported in dormant state and may be supported in committed state. Upon successful execution of this request, the relevant information is broadcast to all participants. 3.4 Conference Mediation Request Instead of (or in addition to) using unspecified tools and procedures to negotiate the conference parameters, the formal automated mediation procedure(and protocol) may be used for that purpose (see section 5 for details). To invoke the Conference Call Mediation Service, the conference host issues a Conference Mediation Request. It is possible to piggyback this request on the Initial Conference Request. 3.5 Conference Commitment Request When conference parameters are negotiated, the conference host issues Jan 2000 A proposal for new PINT building blocks with applications to Conference Calling [Page 5] a Conference Commitment Request to commit the conference parameters and allocate the PSTN resources. Upon successful execution of this request the PINT GW relays the request to the PSTN Executive, the conference enters the committed state, and all participants are notified. 3.6 Undo Commitment Request The conference host may undo the commitment at any time while the conference is inactive by issuing an Undo Commitment Request. Upon successful execution of this request the PSTN releases the allocated resources, the conference returns to the dormant state retaining its current parameters. 3.7 Conference Monitoring The conference host may want to monitor the conference events during the active state of the conference. To accomplish this the host issues a Conference Monitoring Request, that provides the list of the run-time events he/she wants to monitor, such as: a participant has just left the conference; a participant has joined the conference; etc. 3.8 Cancel Monitoring Request To terminate the current monitoring request, the host issues a Cancel Monitoring Request. 3.9 Request to Fetch Conference Parameters In order to fetch conference parameters of interest, a participant issues a Fetch-Conference-Parameters Request. This request must be supported in any state of the conference. A participant should provide the conference-id and the list of parameters he/she wants to inquire about. To protect the conference against Internet eavesdroppers the request must be encrypted. 3.10 Request to FAX Data In order to send a fax to a subset of the conference participants, a participant issues a request to FAX Data. This request must be supported in any state of the conference. Upon successful execution of this request, the specified data is sent to the distribution list, and the sender is notified upon delivery. 4. PINT Reference Architecture The current PINT high level architecture described in [1]. In the core PINT a single PINT request (directly or via a series of SIP servers) reaches the correct PINT Gateway that can actually process Jan 2000 A proposal for new PINT building blocks with applications to Conference Calling [Page 6] the request by passing it to the PSTN Executive System. For conference services, however, the initial conference request, issued by the conference host, in general, will be "parked" for some time in a new server, namely PINT Conference Server (PCS), to allow the prospective conference participants negotiate conference parameters without committing any PSTN resources. When the conference host issues a Conference Commitment Request, the PCS forwards the modified conference request to the appropriate PINT Gateway, which dispatches it to the PSTN Executive. The PCS will maintain the conference state throughout the conference call life cycle. The PINT Gateway and the PCS functions may be collocated. The proposed extended PINT architecture is illustrated in Fig-1. PINT Servers PSTN Cloud ****************** *********** * _______ * _*__ * _______ * | PINT | * | * | * |PINT | * |Gateway|=============|PSTN| * |Clients|++++++++++++++* |_______| * |EXEC| * |_______| * + * |_*__| * * ____+____ * * * * |PINT ConF| * * * +++++ PINT Protocol * | Server | * * * ===== Unspecified * |_________| * *********** Protocol * * ****************** Figure 1: Extended PINT Functional Architecture 5. Conference Call Mediation Service Conference Call Mediation is an automated procedure for reaching consensus on negotiable conference parameters provided by the Initial Conference Request. It is an alternative to informal procedures, such as email lists. Since the conference mediation dealing with calendaring and scheduling information, it is possible to reuse protocols developed in CALSCH WG (see RFC2445). Below is the outline of the Conference Call Mediation Procedure. Upon receiving an Initial Conference Request, the PCS : 1. Creates the unique session ID and returns it in the ACK to the host. 2. Sends requests (for input) along with the relevant information to all participants. 3. Collects responses from the participants. If it does not hear from a participant for a "long time", it will send the reminder to him. Jan 2000 A proposal for new PINT building blocks with applications to Conference Calling [Page 7] 4. Any conference participant and host could modify the original conference attributes, for example, add/delete agenda items or participants. 5. Upon receiving a Conference Commitment Request the PCS changes the conference state to Committed and relays the relevant conference information to the PINT GW. 6. The PINT GW sends a request to the PSTN Executive, asking to allocate the PSTN resources for the required date. 7. Upon ACK from the PSTN, each participant receives the final note and the conference is committed. 8. At the scheduled time and date the PSTN rings the participants phones. The Conference enters the active state. 6. Security Considerations There are at least two security issues related to the proposed service: 1. How does PINT infrastructure know who are the conference host and participants? The authentication of the Conference Call Request, needed to prevent malicious attempts to initiate or cancel a conference call or to eavesdrop, was briefly described in section 3. 2. Is a given party (service provider) is authorized to set up an arbitrary conference call? How is liable for mistakes such as incorrect billing or call routing? How can service providers demonstrate that they have been acting on in good faith? These security issues apply to all PINT services and has been addressed in detail in [1]. Since this paper is just a new PINT service proposal, it focuses on the PINT Conferences Service description and architectural issues and does not address protocols issues such as profiling of SIP and SDP, and possibly other IETF protocols (such as Calendaring and Scheduling protocols), if appropriate. Therefore, the material of this section is of preliminary nature and must be revisited in a forthcoming paper describing protocols. 7. References [1] L. Conroy, S. Petrack "The PINT Profile of SIP and SDP; A Protocol for IP Access to Telephone Call Services", Internet Engineering Task Force, March 1999. Work in progress. [2] M. Handley, E. Schooler, and H. Schulzrinne, "SIP: Session Initiation Protocol", RFC2543, Internet Engineering Task Force, Nov 1998. [3] M. Handley and V. Jacobsen, "SDP: Session Description Protocol", RFC2327, Internet Engineering Task Force, April 1998. [4] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC2246, Internet Engineering Task Force, January 1999. [5] R, Thayer, N. Doraswany, "IP Security Document Roamap", RFC2411, Jan 2000 A proposal for new PINT building blocks with applications to Conference Calling [Page 8] Internet Engineering Task Force, November 1998. [6] R. Housley, W. Ford, W. Polk, D. Solo "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", RFC2459, Internet Engineering Task Force, November 1998. 8. Author's Addresses: Lev Slutsman AT&T Labs Room D5-3D26 200 Laurel Avenue S, Middletown, NJ, USA 07748 Lslutsman@att.com 732-420-3756 Jan 2000