[Search] [txt|pdfized|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]
Versions: 01 02                                                         
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 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

   The list of Internet-Draft Shadow Directories can be accessed at

   Distribution of this memo is unlimited.


   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;

<draft-ietf-pint-conf>                            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
    o The PINT Conference service is a natural generalization of Request
    Call ;
    o Internet may be used to automate the process of negotiations(time,

<draft-ietf-pint-conf>                            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
   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

   3. Basic PINT Conference Service Requests--PINT Conference Building
   The PINT Conference Service allows IP hosts, representing the
   conference host and participants, to allocate the PSTN conference

<draft-ietf-pint-conf>                            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

   3.5 Conference Commitment Request
   When conference parameters are negotiated, the conference host issues

<draft-ietf-pint-conf>                            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

   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;

   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

<draft-ietf-pint-conf>                            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
                          ******************           ***********
                          *     _______    *          _*__       *

    _______               *    | 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
    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

<draft-ietf-pint-conf>                           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
    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
    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
    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
   [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,

<draft-ietf-pint-conf>                          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

<draft-pint-conf>                             Jan 2000