Conference Call Services for PINT     [Page 1]


PINT Working Group                                       L. Slutsman                                   		         
Expires: November 1999                                   AT&T Labs


                   Conference Call Services For PINT
                        <draft-slutsman-pint-conf-00.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


   This  documents  contains the description of Conference Call Services
   for PINT (CCSP)  and  defines    the  procedures  for  invoking  PSTN
   teleconferencing services  from an IP host.  In addition, CCSP allows
   for the following options: 
    o automated negotiation of  conference  parameters,  such  as  date,
    agenda, and etc., before the PSTN resources are committed;  
    o  monitoring the real-time conference status, such as keeping track
    of participants leaving/joining the conference bridge.  

   The document also provides the list of basic APIs  to  support  CCSP.
   Mapping  these  APIs into appropriate PINT protocol(s) messages would
   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 the authos.  




<draft-pint-conf                            April  1999

Conference Call Services for PINT     [Page 2]


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: A calling party A, and some remote party B and a  request is 
   sent from an IP host to connect A to B.  
   In this document we discuss PINT conference services.   Specifically,
   we focus  on  conferences   run by a conference host.  The conference
   host is a participant responsible for initiation   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,  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 group chair, relays the conference
   request into  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.  As participants are very likely  to use PCs during
   the conference, it is desirable to  use  Internet  to  monitor  these
    run-time events.  The example above shows that 
    o  PINT Conference service is a natural generalization of Request to
    Call ; 
    o Internet may be used  to  automate  the  process  of  negotiations
    (time, agenda ,etc.) among participants; 
    o  Internet  may  be  used  to control (add/delete participants) and
    monitor a conference in progress (who is speaking, who has left  the
   bridge).  

   The  rest  of this paper is organized as follows:  section 2 provides
   definitions; section 3 specifies the  PINT  functional  architecture,
   and  touches  some  protocol  related  issues;  section 4 defines the
   primitives and APIs  for  PINT  Conference  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 provides Authors addresses.  The
   key  words  "MUST",   "MUST   NOT",   "REQUIRED",   "SHALL",   "SHALL
   NOT","SHOULD",  "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
   this document are 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 possibil ities.  




<draft-pint-conf                            April  1999

Conference Call Services for PINT     [Page 3]


2. Definitions 
   This document uses a number of terms to refer to the roles played  by
   a conference  participants  and  a  conference host.  In addition, we
   need to introduce terms for desctiption  of  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
    host (not necessarily at the same time) and  further  identified  by
    the unique conference_id.  The conference_id is returned in response 
    to  the initial conference request issued by the conference host and
    it 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 parameters of the conference, 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 PINT
    Gateway sends the notification  to  the  PSTN  Executive;  the  PSTN
    Executive allocates the network resources (see Fig-1).  
    4.  Finally, at the agreed date, the PSTN allocates the voice-bridge
    and calls participants and the conference enters the active state.  


3. PINT Reference Architecture 
   The current PINT  high  level  architecture  [1]  is,  in  principle,
   sufficient  to  support  the  PINT  conference call services, briefly
   described in sections above.  Note that a conference call service may 
   require more than one-PINT client, because participants MAY  have  an
    IP presence during the whole conference life cycle: 
    o while in a dormant state a participant may want to suggest changes 
    to conference parameters; 
    o  Certain implementations may allow continuing the negotiation even
    after the conference parameters were committed.  Parameters like the 
    conference agenda, do not affect the PSTN  resources  and  therefore
    may be changed.  
    
    
    o  In  active  state  both participants and the host may want to use
    Internet: a participant may want to broadcast his/her VGs;  and  the
    conference  host  may  want  to  monitor  important  events  on  the
    conference bridge (leaving and joining the conference, etc.) 
   As to protocols, it is conceivable that besides profiled versions  of
   SIP  and  SDP, other IETF protocols (such as SAP) may be profiled for
   use in PINT.  
   
                            /\/\/\/\/\/\/\          /\/\/\/\/\/\/\/\
   ___________              \          __/___    ___\_             \
   |  PINT   |     PINT     \   PINT  | PINT |   |Exec| Telephone  /
   | clients |<------------>|  server |gatewy|===|Syst| Network    \


<draft-pint-conf                            April  1999

Conference Call Services for PINT     [Page 4]


   |_________|  protocols   /  cloud  |______|   |____|  Cloud     /
                           \            \          /              \
                           /\/\/\/\/\/\/\          \/\/\/\/\/\/\/\/
   
   Figure 1: PINT Functional Architecture


4. PINT Conference Service Primitives
   In the following sections we will present a  non-exhaustive  menu  of
   PINT Conference  primitives  using  API-like  notations.  Mapping the
   APIs into PINT protocol messages is out of scope of this paper.  

 4.1 Initial Conference Request.  
   To initiate the prospective conference, the host issues the following 
   command: 
      Host-Invite (participants, negotiable, mediation, commitment).
   Where: 
    o Participants is a list of participant records.  Each  record  MUST
    provide  at least the following fields: a participant name; an email
    address; a telephone number, and a fax number to be used during  the
    conference.  
    o  Negotiable  is  a  record  of  information that may be negotiated
    during the dormant state among participants.  The record  MUST  have
    the  following  fields:  Availability Dates; Agenda; and the list of
    documents to be used during conference.  
    o Mediation is a Boolean variable.  When "true", it  indicates  that
    the automated conference mediation (see section 3) is enabled.  
    o Commitment  is a Boolean variable.  When "true", it indicates that
    the PINT Gateway immediately relays the conference  request  to  the
    PSTN Executive, which commits the PSTN resources.  
   Semantic.  Upon  successful  execution  of  this request, the PINT GW
   generates the conference-id and broadcasts it  to  all  participants.
   In  addition,  the  arguments of the request may be also broadcast to
   the participants.  The conference enters either dormant or  committed
   state.  

 4.2 Conference Cancellation 
   In  order  to  cancel  an  inactive conference request, the host must
   issue the following Command: 
                     Host-Cancellation (Conference-Id)
   Semantic. Only the conference host may  cancel  the  conference,  and
   only inactive conferences may be canceled.  Upon successful execution 
   of this command, the notification is broadcast to all participants.  

 4.3 Conference Modification 
   In order to change conference parameters, such as add prospective new 
   participants,  change  the date, etc., the conference host must issue
   the following command: 
   Host-Modifies-Conference (Conference-Id,[participants], [negotiable], 
   [mediation], [commitment]) 


<draft-pint-conf                            April  1999

Conference Call Services for PINT     [Page 5]


   Semantic. This command MUST be supported in dormant state, and may be 
   supported in committed state.   Upon  successful  execution  of  this
   command, the relevant information is broadcast to all participants.  

 4.4 To Commit Conference 
   In  order to commit a conference parameters, the conference host MUST
   issue the following command: 
                  Host-Commits-Conference (Conference-Id)
   Semantic. This command MUST be supported  in  dormant  state.    Upon
   successful  execution of this command: the PINT GW relays the request
   to the PSTN Executive, the conference enters committed state, and all 
   participants are notified.  

 4.5 Fetching Conference Parameters 
   In order to fetch conference parameters of  interest,  a  participant
   MUST issue the following command: 
   Fetch-Conference-Parameters            (Conference-Id,[participants],
   [negotiable], [state],[bridge]) 
   Where  
    o Bridge is a telephone number/code of the conference bridge.  
    o State is a conference state.  
   Semantic. This command MUST be supported in any state.  A Participant 
   MUST supply the Conference-Id.  Upon  successful  execution  of  this
   command, a participant will receive desired conference parameters.  

 4.6 To FAX Data 
   In  order to send a fax to a subset of the conference participants, a
   participant MUST issue the following command: 
            Fax-Data (Conference-Id, Source-Data, distribution)
   Where: 
    o Source-Date is a reference to the data to be sent (for  example  a
    URL); 
   o Distribution is a list of recipients desired.  
   Semantic. This  command  MUST  be  supported  in  any  state.    Upon
   successful execution of this command the specified data  is  sent  to
   the distribution list and the sender is notified upon delivery.  

 4.7 Conference Monitoring 
   In order to monitor events during the active state of the conference, 
   the conference host MUST issue the following command: 
                 Host-Monitors - Conference(Conference-Id)
   Semantic.  This  command  MUST  be  supported  in  active  state of a
   conference  (monitor  would  be  active  at   host   for   conference
   duration).   A  list  of  events MUST include, but is not necessarily
   limited to, the following: a participant has left the  conference,  a
   participant  has  joined the conference, Upon successful execution of
   this command, an appropriate window will appear on the host PC.  

 4.8 To Cancel Monitoring 
   In order to cancel monitoring application, , the conference host MUST 


<draft-pint-conf                            April  1999

Conference Call Services for PINT     [Page 6]


   issue the following command: 
                  Host-Cancels-Monitoring (Conference-Id)
   Semantic. This command  MUST  be  supported  in  active  state  of  a
   conference.    Upon   successful   execution  of  this  command,  the
   monitoring application on the host PC will be terminated.  


5. Conference Call Mediation Service 
   Conference Call Mediation is  an  automated  procedure  for  reaching
   consensus    on  negotiable  conference  parameters  provided  by the
   Host-Invites (participants,  negotiable, mediation,  and  commitment)
   command.  It is an alternative to informal procedures,  such as email 
   lists.    By  setting "mediation" parameter to "true", the conference
   host selects the Conference Call Mediation  alternative.    If  ,  in
   addition,  the host sets  "commitment" parameter to "true" the output
   of the  automated  procedure  will  be  committed,    otherwise,  the
   conference host has chance to modify the conference parameters before 
   the commitment.      Below  is  the  outline  of  the Conference Call
   Mediation Procedure.  Upon receiving the Host-Invites  (participants,
   negotiable, true, commitment) command PINT GW : 
    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.  
    4. Each participant and the host may modify the original  conference
    attributes, for example, add/delete agenda items or participants.  
    5.  When  the  majority  of participants has agreed all items in the
    negotiation section on, the PINT GW sends the negotiated  conference
    parameters to  all participants.  If "commitment" is set to "false",
    that is it.  
    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 day the PSTN rings the participants phones.  


6. Security Considerations 
   This paper is focused on the PINT Conferences Services and  does  not
   address  protocols  issues  such  as  profiling  of  SIP and SDP, and
   possibly other  IETF  protocols  if  appropriate.    Therefore,   the
   material  of  this  section  is  of  preliminary  nature  and MUST be
   revisited in the paper describing protocols.  Meanwhile, this section 
   borrows heavily from the  corresponding  section  in  [1],  including
   copying actual text.  

 6.1 Responsibility for Conference service requests 


<draft-pint-conf                            April  1999

Conference Call Services for PINT     [Page 7]


   The capability of making a PSTN-based Conference call to participants 
   specified  in  the  PINT Conference request, however, comes with some
   risks.  The Conference Request may be bogus to begin  with.    It  is
   also  possible that the Requester (Conference Host) has entered wrong
   information by  mistake.    Finally,  the  request  may   have   been
   intercepted   on   its  way  through  any  intervening  PINT  or  SIP
   infrastructure and the request may have been  altered.    In  any  of
   these cases, the result may be that: Internet and PSTN reso urces are 
   wasted; a call is placed incorrectly; a billing is incorrect.  In any 
   case, someone  may  be  liable for mistaken or incorrect calls.  If a
   conference request can be  shown  to  have  come  from  a  particular
   Requester and to have been acted on in good faith by the PINT service 
   provider,  then  Responsibility  for making requests may well fall to
   the Requester.  Therefore, it may be important for the  PINT  service
   provider  to be able to show that they act only on requests for which
   they have some degree of assurance of origin.  It  follows  that  the
   PINT  service provider may require that the identity of the Requester
   be confirmed.  If such confirmation is not available, then  they  may
   be forced (or choose) not to provide service.  

 6.2 Authority to make requests 
   PINT  Gateway  MUST provide a mechanism to confirm the authority of a
   Requester to make a PINT Conference Call request.  PINT  service  may
   be  provided on a subscription basis, and there are a number of other
   models.  And again, if such confirmation is not available,  then  the
   PINT Gateway may choose to reject the request.  

 6.3 Privacy 
   Even  if  the identity of the Requester and the Authority under which
   they make their request is known, there remains the possibility  that
   the  request  is  either  corrupted,  maliciously  altered,  or  even
   replaced  while  in  transit  between  the  Requester  and  the  PINT
   Gateway.   Similarly,  information  on  the  Authority  under which a
   request is  made may well be carried within that request.   This  can
   be sensitive information, as an eavesdropper might steal this and use 
   it within their own requests.  Such Authority SHOULD be treated as if 
   it  were financial information (such as a Credit card number or PIN).
   The data authorizing a Requesting User to make a PINT request  SHOULD
   be known  only  to  them  and  the  service  provider.  However, this
   information may be in a form that does not match the schemes normally 
   used within the Internet. For example,  X.509  certificates  [6]  are
   commonly used for secured transactions on the Internet both in the IP 
   Security  Architecture[4]  and  in  the TLS protocol[5], but the PSTN
   provider may only store an account code and PIN (i.e. a fixed  string
   of numbers).    A  Requester  has a reasonable expectation that their
   requests for service are confidential.  For PINT Conference  services
   both  content  data  and  address  information, such as telephone/fax
   numbers and email addresses  may  be  considered  sensitive.    As  a
   result,  it  may  be  that  the  Requester  (and  their  PINT service
   provider) will require that any  request  that  is  sent  across  the


<draft-pint-conf                            April  1999

Conference Call Services for PINT     [Page 8]


   Internet  be  protected against eavesdroppers; in short, the requests
   may need to be encrypted.  

 6.4 Security mechanisms and implications on PINT service 
   PINT is a profile on SIP[2] and SDP[3], and  will  use  the  security
   procedures described in SIP. The implications of that are detailed in 
   [1].  


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,
   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                            April  1999