[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Internet Engineering Task Force                             F. M. Burg
INTERNET-DRAFT                                             A. Desimone
draft-burg-pint-framework-00.txt                          K. T. Tewani
                                                             AT&T Labs
                                                       K. Vishwanathan
                                                             Isochrone
                                                         December 1997

 An Architecture and Protocols for Initiation and Control of Telephone Calls
      From Terminals Connected to a CallBroker over a TCP/IP Connection



Status of this Memo



This document is an Internet-Draft. 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."

To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), munnari.oz.au
(Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West
Coast).

Abstract



This Internet Draft describes a framework, consistent with the model defined
in the PINT group in the IETF, for controlling voice and voice-band data
(e.g., FAX) calls on the PSTN from an IP Client. As such, it is solely
concerned with call control and associated functions. It is not concerned
with how to convert packetized voice into a form suitable for carriage over
the PSTN.

We introduce a logical entity (called CallBroker) that initiates and manages
calls on the PSTN and controls the session on behalf of an IP Client to
establish a telephone connection between two or more end points specified by
the customer (i.e., IP Client). By way of this session, as mediated by the
Call Broker, the customer can set up calls and receive notifications
regarding the status of the calls and its participants.

The interface between the CallBroker and the Service Control Function (as
defined in the work on Intelligent Network Standards in ITU-T) in the
Service Node (SN) in the PSTN will be defined and standardized as part of
this activity. The interface between the IP client and the CallBroker also
nees to be defined and standardized as part of this activity.

This Internet Draft further advances the discussion on the issues involved


Burg/Desimone/Tewani/Vishwanathan      Expires 5/98            [Page 1]


INTERNET-DRAFT     draft-burg-pint-framework-00.txt     Dec. 1997

in interconnecting the Internet and the Public Switched Telephone Networks

(PSTNs), focusing on potential interfaces between Internet-based entities
and Intelligent Network (I.N.) entities. The services identified and
discussed earlier (e.g., Click-to-Dial, Click-to-FAX, etc.) can be provided
using the architecture identified here.




Table of Contents
1. Introduction
2. Identification/definition of Services
3. High level architecture
4. IP Client to CallBroker Interface
5. CallBroker to IN Interface


1. Introduction



This Internet Draft defines a framework, consistent with the model defined
in the PINT Working Group in the IETF, for controlling voice and voice-band
data (e.g., FAX), for providing Click-to-dial, etc. type of services
identified in earlier drafts [1] and [2]. It is assumed here that the reader
is familiar with the terminology defined in the Intelligent Network
Standards [3] standardized by ITU-T.

This document brings in the concept of a CallBroker as a logical entity that
acts on behalf of a customer to set up sessions. The CallBroker acts as a
mediator to make requests for PSTN resources. The sessions typically include
initiation of calls between two or more end points specified by the user. In
addition to its interactions with the PSTN/IN for call setup, the CallBroker
is responsible for functions, as necessary, such as authentication, usage
recording, etc. However, this Internet Draft is not concerned with the
CallBroker's interactions with other entities to authenticate the user or
pass usage information.

This document discusses the API's at the two interfaces that need to be
defined in order to provide the above services. The two interfaces are the
Client-to-CallBroker and the interface between the CallBroker and the SCF
Functional Entity (FE) in the Service Node (SN) in the PSTN.

The architecture described in this document is consistent with the model
defined in the PINT Working Group. The current scope of the PINT Working
Group, however, is to define only the interface between

the CallBroker (or Web Server as defined in [1]) and the SCF in the PSTN. As
discussed earlier, this document is also proposing to define the interface
between an IP Client and the CallBroker. The definition of such an interface
will enable service providers to extend the architecture defined here to
serve as a platform for other advanced/value added services (to be
identified later).



Burg/Desimone/Tewani/Vishwanathan     Expires 5/98            [Page 2]


INTERNET-DRAFT     draft-burg-pint-framework-00.txt     Dec. 1997

In addition, the view to date in PINT is that the client is a Web browser,
communicating via http with a Web server which in turn makes requests to
establish connection(s) to a Service Control Function in the Service Node in
the PSTN. The expanded view taken here is that the IP client is more
general, and implements a protocol (described below) for communication with
the CallBroker that allows full two-way communications, something lacking in
the http/Web approach. For example, this is required for the cases where a
called party hangs up and an indication may be necessary to be given to the
IP Client about this status/progress. This is also necessary when
conferencing to give an indication/status of various parties joining the
call, etc.

Thus, we believe that notification(s) from the network about the
status/progress of the call (i.e., in general, asynchronous two-way
communications) is necessary. and should be given to the IP Client. This, in
turn, requires the functionality available on the CallBroker to PSTN
interface be available to the IP client.

2. Identification/definition of Services



Click to Dial: The premise here is that a user has generated a request at an
IP Client, asking for a telephone call to be placed between two telephones
connected to the PSTN. After receiving the IP Client's request, it is sent
from the CallBroker to the SCF Functional Entity (FE) in the PSTN, and that
FE instructs the Call Control Functional (CCF) Entity in the PSTN to place
the call between the telephones whose number(s) were specified by the user.
>From the customer perspective (i.e, the client), the request has been made;
the implementation of that request is carried out by the CallBroker and the
PSTN. Indications about the progress of satisfying that request shall be
passed back to the IP Client.

Conferencing: The premise here is that Client has requested a conference
call be set up between three or more telephones. This request is sent from
the CallBroker to the SCF Functional Entity (FE) in the PSTN, and that FE
instructs the Call Control Functional (CCF) Entity in the PSTN to place the
call between two or more telephones whose number(s) were specified by the
user. From the customer perspective (i.e, the IP client), the request has
been made; the implementation of that request is carried out solely by the
CallBroker and the PSTN. One could consider the call between two telephones,
as discussed above, is a specific case of a conference call between multiple
telephones. Here, however, there would be more information to pass back to
the IP Client regarding the status of participants on the call.

Click to Fax:. The premise here is that Client has some data that it would
like converted into a fax and sent to a fax machine connected to the PSTN.
This service is more involved than Click to Dial, as it requires data to be
collected from the IP Client, together with the fax number of the intended
destination. The request and the data to be sent are passed to the PSTN in a
form suitable for sending as a fax, which initiates the call to the
destination fax machine, and sends the generated facsimile to it.

In all of the examples above, it is necessary that indication(s) be given to
the IP Client regarding the progress/status of the call.


Burg/Desimone/Tewani/Vishwanathan     Expires 5/98            [Page 3]


INTERNET-DRAFT     draft-burg-pint-framework-00.txt     Dec. 1997

3. High Level Architecture



A high level architecture depicting various logical entities and the
Interfaces among these logical Entities and the IP Client is shown in
Figure 1.

                             ________________
                            /
          1        _____   / 2   _____
 /|________________|    |________|    |   PSTN
                   |____|  \     |____|
                   Call     \    / SCF\
                   Broker    \  /  SN  \
                              \_____________
                             /          \
                            /            \
                           /              \
                          __              __
                          /\              /\

                        Calling       Participant
                         Party      (Called Party)

*Interfaces Labeled 1 and 2 above are considered part of
this activity.

  Figure 1: High Level Architecture of the various logical Entities of the
                             Call Broker Model

The CallBroker, in addition to the initiation and control of calls on behalf
of the user, performs additional functions. These functions include
authenticating the IP Client, usage recording, management of the session for
the IP Client for the telephony call. The notion of the session requires
that a client state machine be maintained in the CallBroker. This also helps
in notifying the IP Client about the status/progress of the requests
generated from the IP Client.

>From the perspective of the IP Client, the logical entities needed for the
above functions are within the CallBroker and are as shown in Figure 2
below. These correspond to the functions already discussed: Usage Recording
Function, Session Management Function, Bridge, and the Authentication
Function. The fact that some of these functions may be physically separate







Burg/Desimone/Tewani/Vishwanathan    Expires 5/98            [Page 4]


INTERNET-DRAFT     draft-burg-pint-framework-00.txt     Dec. 1997

from the CallBroker (such as the Bridge being in the PSTN), is not
inconsistent witht the general view adopted here. Thus, the CallBroker Model
mediates requests for network services and enables us to define various
value added services in the future.

llllllllllllllll
l              l
l Call Broker  l                  Authentication
l  Server      l                  Function
l  ______      l    Interface 2a   ______
l |      |x x xlx x x x x x x x x  |    |
l |______|x    l                   |____|
l       x    x  l
l        x    xl  Interface 2b
lSession State lx
l   Mnmgt. x   l  x            Usage Recording
l  Function    l     x             Function
l _______    x l       x          ______
l |     |      l          x  x x  |    |
l |_____|     xl                  |____|
llllllllllllllll
               x
                x Interface 2c
                x
              _______
              |     |
              |_____|

               Bridge

              Figure 2: Functional Entities in the Call Broker

Various interfaces (i.e., 2a, 2b, 2c in Figure 2) between different
functional entities in the CallBroker may also be standardized. The Session
State Management Function may be physically realized as part of the
CallBroker Server.

IP Client to CallBroker Interface



Communication on the IP Client to CallBroker Interface (Interface 1 in
Figure 1) is a simple ASCII based protocol running directly on TCP. The
messages on this interface are primarily requests from the client to the
CallBroker, responses from the CallBroker to the IP client responding to the
requests and unsolicited events from the CallBroker to the IP client. Since
the communication is not strictly transaction oriented, traditional
encapsulation protocols like HTTP cannot be used. There has been some
ongoing work attempting to use multiple concurrent HTTP POST requests to
support event delivery but, without too much difficulty, the ASCII protocol
specified here can easily be mapped to the POST payload of the HTTP
protocol.





Burg/Desimone/Tewani/Vishwanathan    Expires 5/98            [Page 5]


INTERNET-DRAFT     draft-burg-pint-framework-00.txt     Dec. 1997

4. Protocol



4.1.1 Basic Format

The basic format of the protocol is as follows.

[header]<<LF>

<<LF>

[body]<<LF>

<<LF>

<<LF>

The header and body of the protocol are separated by 2 line feed characters.
The format of the header and the body is described below. Line feed
characters in the header or body will be escaped using simple URL encoding.

4.1.2 Header

[session-id | 0]<<LF>

[message-id]<<LF>

[version-info]<<LF>

All CallBroker transactions are identified by sessions. A session is not
necessarily governed by a TCP session. If the IP client is attempting to
initiate a new session with the CallBroker the session-id field is populated
with '0' to indicate session creation request. Every session request needs
to be accompanied by sufficient information regarding authentication for the
CallBroker to create the session.

Message-id represents the operation of the message. An appendix is provided
describing the different message-ids supported by the current release of the
CallBroker system.

Version-info contains optional version information of the protocol. This is
to aid possible version mismatch detection and graceful error recovery.

4.1.3 Body

The body of the protocol messages consist of name value pairs. These
name-value pairs are interpreted with reference to the message-id which
signifies the operation to be performed by the CallBroker.

4.2 APIs exposed to the IP client



The APIs exposed to the IP client of the CallBroker are distinct and
different from the APIs that the CallBroker uses from the different
supporting subsystems including the authentication subsystem and the usage


Burg/Desimone/Tewani/Vishwanathan   Expires 5/98            [Page 6]


INTERNET-DRAFT     draft-burg-pint-framework-00.txt     Dec. 1997

recording subsystem. The IP client APIs enable clients to effectively
control voice conferencing. The APIs described below is an initial set of
APIs identified for the application in mind.

The API is implemented as an asynchronous library which involves the user of
the API to implement the callback interface to support asynchronous
completion of the IP client requests.

4.2.1 Session creation

CreateSession

STATUS CreateSession (AuthInfo authinfo, Phonenumber host_`phone) ;

CB_CreateSession

void CB_CreateSession (String sessionId, ErrorMessage err) ;

4.2.2 Adding parties to an existing conference

AddParty

STATUS AddParty (String session_id, Phonenumber participant) ;

CB_AddParty

void CB_AddParty (String session_id, Phonenumber participant, ErrorMessage err) ;

4.2.3 Deleting participants from a conference

DropParty

STATUS DropParty (String session_id, Phonenumber participant) ;

CB_DropParty

void CB_DropParty (String session_id, Phonenumber participant, ErrorMessage err) ;

4.2.4 Destroying sessions

DestroySession

STATUS DestroySession (String session_id) ;

CB_DestroySession

void CB_DestroySession (String session_id, ErrorMessage err) ;

4.2.5 Events

Currently the only event supported is the phone hangup event for any of the
participants in the session. The current implementation reports this
asynchronous event through the overloaded CB_DropParty callback function.



Burg/Desimone/Tewani/Vishwanathan    Expires 5/98            [Page 7]


INTERNET-DRAFT     draft-burg-pint-framework-00.txt     Dec. 1997

5. CallBroker to IN Interface



5.1 Voice-Bridge Control API



The Voice Bridge Control API is used by CallBroker applications to access
voice bridging functionality. The API distinguishes between sessions and
calls. Calls represent actual voice calls placed from/to the voice bridge.
These calls can be grouped together in sessions. All the calls that belong
to a session are bridged. Calls have a significance outside the scope of
sessions. Every call can be associated with multiple sessions with different
weights at the same time. The advantage of this approach is the ability to
support concepts like whispering in a conference call. Calls can also be
dropped from a conference session and bridged together in a new session to
give the notion of a sub-conference. These calls can later be re-added to
the main conference session.

The API functions of the voice bridge can be classified into five groups:
initialization and termination routines, the control functions, the response
callback functions, the event notification functions and the socket event
interest request functions. The control functions are used to issue commands
to the bridge for requesting a new session etc. We provide some examples of
the control fucntions here: a complete description is being developed.

5.1.1 CreateSession

CreateSession  (SESSION_HANDLE* session_handle, void* param) ;

Parameters
     session_handle
          handle to the new session to be created
     param
          a callback parameter that is passed back uninterpreted to
          CB_CreateSession

Remarks
     Creates a new bridge session. If this call completes asynchronously, it
     returns pending and later completes the session creation and returns
     the new session through the function CB_CreateSession. At any time
     multiple session creation requests can be pending. The user can make
     use of the callback parameter param to identify the request that has
     completed.

5.1.2 DestroySession

DestroySession  (SESSION_HANDLE session_handle) ;

Parameters
     session_handle
          handle of the session to be destroyed

Remarks
     Destroys the bridge session specified by session_handle. This call
     returns synchronously.


Burg/Desimone/Tewani/Vishwanathan  Expires 5/98            [Page 8]


INTERNET-DRAFT     draft-burg-pint-framework-00.txt     Dec. 1997

5.1.3 CreateCall

CreateCall  (CALL_HANDLE* call_handle, void* param) ;

Parameters
     call_handle
          handle to the new call to be created
     param
          a callback parameter that is passed back uninterpreted to
          CB_CreateCall

Return Values
     SUCCESS on successful completion, PENDING if the operation is pending
     and FAILURE if the operation failed. If the operation fails the error
     code is included in the status code. Possible error codes:
     ERR_INSUFFICIENT_RESOURCES - insufficient resources to create new call.
Remarks
     Creates a new voice call. If the function call returns pending the
     completion is signaled through the function CB_CreateCall. At any time
     multiple call creation requests can be active. The user can determine
     which of the identity of the completing request through the callback
     parameter param. The hardware port on the bridge is allocated but not
     yet in use. This call is used to reserve all the hardware resources
     necessary to make a voice call. The voice call is originated by the
     DialCall API function.

5.1.4 DestroyCall

DestroyCall (
                CALL_HANDLE call_handle
        ) ;

Parameters
     call_handle
          handle to the call to be destroyed

Return Values
     SUCCESS on successful completion and FAILURE if the operation failed.
     If the operation fails the error code is included in the status code.
     Possible error codes: ERR_INVALID_PARMS - the call handle specified is
     incorrect.
Remarks
     Destroys the voice call specified by call_handle and all resources
     associated with it.

5.1.5 ConnectCall

ConnectCall  (
                CALL_HANDLE call_handle,
                unsigned char use_caller_phone,
                PHONE_NUMBER caller_phone_number,
                PHONE_NUMBER callee_phone_number,
                unsigned int timeout,
                void *param
        ) ;

Burg/Desimone/Tewani/Vishwanathan  Expires 5/98            [Page 9]


INTERNET-DRAFT     draft-burg-pint-framework-00.txt     Dec. 1997

Parameters
     call_handle
          the call handle on which the dialing is to be done
     use_caller_phone
          If set to non-zero, the caller's phone number is made available to
          the callee, else the caller identification is not sent.
     caller_phone_number
          The phone number of the originator of the call
     callee_phone_number
          The phone number to be dialed, the callee.
     timeout
          the number of seconds to wait for an answer after the ringing has
          commenced
     param
          a callback parameter that is passed back uninterpreted to
          CB_ConnectCall

Return Values
     SUCCESS on successful completion, PENDING if the operation is pending
     and FAILURE if the operation failed. If the operation fails the error
     code is included in the status code. Possible error codes:
     ERR_LINE_BUSY
          call could not complete since the line was busy.
     ERR_LINE_NO_ANSWER
          no answer after timeout seconds
     ERR_INVALID_PARMS
          the call handle or phone number specified is incorrect.

Remarks
     This function is used to dial a phone number on a specific call handle.
     Until the phone number is actually dialed the hardware port on the
     bridge is allocated but not used. If the call does not complete
     synchronously, the bridge provider signals completion of this call by
     calling the callback function CB_ConnectCall.

5.1.6 DisconnectCall

DisconnectCall  (
                CALL_HANDLE call_handle
                ) ;

Parameters
     call_handle
          the call handle on which the call is to be disconnected.

Return Values
     SUCCESS on successful completion, PENDING if the operation is pending
     and FAILURE if the operation failed. If the operation fails the error
     code is included in the status code. Possible error codes:
     ERR_INVALID_PARMS
          the call handle specified is incorrect.
     ERR_CALL_INACTIVE
          the call handle specified is not connected.

Burg/Desimone/Tewani/Vishwanathan  Expires 5/98            [Page 10]


INTERNET-DRAFT     draft-burg-pint-framework-00.txt     Dec. 1997

Remarks
     Used to disconnect an active call on a given call handle. The call
     handle itself is still valid and can be used to originate other calls.
     If the call does not complete synchronously, the bridge provider
     signals completion of this call by calling the callback function
     CB_DisconnectCall.. Note: The call_handle is valid even after the call
     has been disconnected. The user of the API is free to reuse the
     call_handle in another ConnectCall operation.

5.1.7 AddCallsToSession

AddCallsToSession (
                SESSION_HANDLE session_handle,
                unsigned int num_calls,
                CALL_HANDLE* call_handles,
                void *param
        ) ;

Parameters
     session_handle
          session to which calls are to be added
     num_calls
          number of call handles to be added
     call_handles
          array containing num_calls call handles to be added to the
          session.
     param
          a callback parameter that is passed back uninterpreted to
          CB_AddCallsToSession

Return Values
     SUCCESS on successful completion, PENDING if the operation is pending
     and FAILURE if the operation failed. If the operation fails the error
     code is included in the status code. Possible error codes:
     ERR_INVALID_PARMS
          the call handle or session handle specified is invalid.

Remarks
     This function is used to add weighted call handles to a session. The
     significance of adding weights to a call handle is to permit bridging
     of different users with different characteristics. The weight controls
     the voice input from the particular call handle that it is associated
     with. Call handles with a weight of WEIGHT_ZERO cannot be heard by
     other members of a session while call handles with a weight of
     WEIGHT_MAX are heard more loudly than call handles with a weight of
     WEIGHT_HALF. All call handles belonging to a session at any point of
     time are 'bridged'. A call handle can be participating in multiple
     sessions with different weights at the same time.

5.1. 8 DropCallsFromSession

DropCallsFromSession (
                SESSION_HANDLE session_handle,
                UINT   num_calls,
                CALL_HANDLE* call_handles,
                void *param
        ) ;

Burg/Desimone/Tewani/Vishwanathan  Expires 5/98            [Page 11]


INTERNET-DRAFT     draft-burg-pint-framework-00.txt     Dec. 1997

Parameters
     session_handle
          handle to the new call to be created
     num_calls
          number of call handles to be added
     call_handles
          array containing num_calls call handles to be dropped from the
          session.
     param
          a callback parameter that is passed back uninterpreted to
          CB_DropCallsFromSession

Return Values
     SUCCESS on successful completion, PENDING if the operation is pending
     and FAILURE if the operation failed. If the operation fails the error
     code is included in the status code. Possible error codes:
     ERR_INVALID_PARMS
          the call handle or session handle specified is invalid.

Remarks
     This function is used to drop voice calls from a bridged session. The
     calls themselves still remain active and can be made part of a new
     session to support the concept of whispering in a multi-party
     conference.

References



  1. Fayenberg, et. al., "A proposal for Internet and Public Switched
     Telephone Networks (PSTN) Internetworking",
     <draft-faynberg-telephone-sw-net-00.txt>, March 1997.
  2. Conroy, et. al., "Analysis of Services and Interfaces used when
     Interworking Between the Internet and the Intelligent Network
     (I.N.)", <draft-conroy-interfaces-in-net-00.txt>, July 1997.
  3. ITU-T Q.12xx Series Recommendations, Geneva, 1995.
  4. Petrack, "IP Access to PSTN Services: Basic Service Requirements,
     Definitions, and Architecture", <draft-ietf-pint-basics-01.txt>,
     Nov. 1997.

Author's Addresses

F. M. Burg
AT&T Labs
Room 1N-117
307 Middletown Lincroft Road
Lincroft, NJ 07738
USA
email: fburg@hogpb.att.com
Tel: +1 732 576 4322
FAX: +1 732 576 4317


Burg/Desimone/Tewani/Vishwanathan  Expires 5/98            [Page 12]

INTERNET-DRAFT     draft-burg-pint-framework-00.txt     Dec. 1997

A. DeSimone
AT&T Labs
Room 1N-113
307 Middletown Lincroft Road
Lincroft, NJ 07738
USA
email: tds@att.com
Tel: +1 732 576 5655
FAX: +1 732 576 4317

Kamlesh T. Tewani
AT&T Labs
Room 1K-334
101, Crawfords Corner Rd.
HOLMDEL NJ - 07733
USA
email: tewani@att.com
Tel: +1 732 949 5369
Fax: +1 732 949 8569

Kumar Vishwanathan
Isochrone
Tel: +1 732 544 5477
e-mail: kumar@isochrone.com