Internet Draft
PINT Working Group                                       L. Slutsman                                   		         
Expires: July 2000                                  AT&T Labs


                 A proposal for new PINT building blocks
                 with applications to Conference Calling 
                        <draft-ietf-pint-conf-01.txt>

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