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;
<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
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,
<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
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
<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
Request.
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
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
<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
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.
<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
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,
<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
Lslutsman@att.com
732-420-3756
<draft-pint-conf> Jan 2000
