System and method for establishing a communication channel over a heterogeneous network between a source node and a destination node

Abstract

A system and method for establishing a communication channel between a source node and a destination node via a heterogeneous communication network comprising at least one intermediate node is disclosed. A request for a communication channel having specified characteristics is issued by the source node to the most immediately adjacent of a possible plurality of intermediate nodes. Each intermediate node determines whether or not it has the available communication resources to support the request. If so, sufficient communication resources are reserved in order to support the request and the request is forwarded to the next intermediate node. The determination by each intermediate node is continued until the destination is reached. After determination by the intermediate node as to whether or not the communication channel can be supported, an indication reflecting the determination is returned to the source node via the intermediate nodes. If a positive indication is received the communication channel is established.

Claims

We claim:

1. A method for establishing a communication route over a heterogeneous network between a source node and a destination node said route comprising at least one intermediate node, each of said nodes having a support system including a network control subsystem for controlling physical routing of data between nodes and a respective record of available communication resources to adjacent nodes in said route, said method comprising the steps of

receiving, at said support system of said source node, a request, from a first application executing at said source node, to establish a communication channel having specified characteristics between said first application and a second application at said destination node,

transmitting said request from said source node to said at least one intermediate node;

for each intermediate node,

receiving at said intermediate node said request from the preceding node,

determining, at said intermediate node from said respective record of available communication resources, whether or not the request is supported using the available communication resources between said intermediate node and an adjacent node in said route, and

if said request is supported by said intermediate node, transmitting said request from said intermediate node to the next node in said route;

receiving at said destination node said request from said at least one intermediate node,

determining, at said destination node, whether or not to accept the request, and if so, transmitting an indication thereof to said source node; and

establishing said route between said first and second applications in response to said indication.

2. A method as claimed in claim 1, wherein said specified characteristics comprise an indication of a bandwidth for the route.

3. A method as claimed in either of claims 1 or 2, wherein said specified characteristics comprises an indication of an error rate for the route.

4. A method as claimed in claim 1, wherein said specified characteristics further comprise at least one the following: throughput, jitter, latency, data size, data encryption techniques employed, compression methods employed or data re-transmission rate.

5. A method as claimed in claim 1, further comprising the step of modifying said request before said intermediate node transmits said request to said destination node.

6. A method as claimed in claim 5, wherein said step of modifying is responsive to a measure of the cummulative quality of service.

7. A method as claimed in claim 1, further comprising the step of

determining at said destination node from said respective record of available communication resources whether or not the route is supported using the available destination node communication resources between destination node and an adjacent intermediate node.

8. A method as claimed in claim 1, further comprising, at each node, the step of

if said request is not supported using the available intermediate node communication resources, determining whether or not a further application executing at said node will relinquish the node communication resources allocated thereto, and

using any relinquished node communication resources to support said request.

9. A method as claimed in claim 1, further comprising, in response to said indication, the steps of

allocating a quantity of the available destination node comminations resources between destination node and said intermediate node to support said request, and updating the available destination nose communication resources accordingly;

for each intermediate node

allocating a quantity of the available node comminations resources between said intermediate node and said preceding and next nodes to support said request, and updating the available destination node communication resources accordingly; and

allocating a quantity of the available source node comminations resources between said source node and said at least one intermediate node to support said request, and updating the available source node communication resources accordingly.

10. A system for establishing a communication channel over a heterogeneous network between a source node and a destination node via a route comprising at least one intermediate node, each of said nodes having a support system including a network control subsystem for controlling physical routing of data between nodes and a respective record of available communication resources to adjacent nodes in said route, said system comprising

means for receiving, at said support system of said source node, a request, from a first application executing at said source node, to establish a communication channel having specified characteristics between said first application and a second application at said destination node,

means for transmitting said request from said source node to said at least one intermediate node;

for each intermediate node,

means for receiving at said intermediate node said request from the preceding node,

means for determining, at said intermediate node from said respective record of available communication resources, whether or not the request is supported using the available communication resources between said intermediate node and an adjacent node in said route, and if said request is supported by said intermediate node, transmitting said request from said intermediate node to the next node in said route;

means for receiving at said destination node said request from said at least one intermediate node,

means for determining, at said destination node, whether or not to accept the request, and if so, transmitting an indication thereof to said source node; and

means for establishing said communication channel between said first and second applications in response to said indication.

Description

This application is related to U.S. application Ser. Nos. 256,211, and 256,209, by Aldred et al both filed Jun. 27, 1994, now U.S. Pat. No. 5,539,886.

The present invention relates to a system and method for establishing a communication channel over a heterogeneous network between a source node and a destination node.

Personal computers are now widespread throughout the business community and many are able to intercommunicate, either through fixed connections e.g. local area networks, or through dynamically established links e.g. ISDN or async lines over the public switched telephone network. Increasingly, these connected personal computers can be used to enhance collaborative working between remote individuals; a typical example being the use of desk top conferencing software. Successful collaborative work generally requires more than a simple data link between the participants; voice capabilities are normally essential and video links are frequently required. Thus remote collaborative working can often be regarded as an extension to the traditional telephone call--it being enhanced with the data and programs available at the desktop via the personal computer--and, on occasions, enriched with video services.

A broad spectrum of collaborative applications can be envisaged, ranging from utilities taking advantage of the data and applications on a workstation, e.g. sharing of screen windows and files, through to new collaborative applications designed to meet the needs of specific classes of remote user e.g. just-in-time education, remote presentations, executive broadcasts or help desk. The common requirements behind these examples are:

the support of a wide variety of personal computer platforms--both hardware and software,

operation over the existing communication networks,

group communications and multi-media data services.

Conventionally, collaborative working systems are realised using homogeneous communication networks, such as a local area network, in which the physical links between the nodes have the same characteristics and accordingly any communications channels established between nodes can all support a required quality of service for that channel. However, the above cannot be extended to an environment comprising a heterogeneous network in which the links between nodes have different characteristics.

Accordingly, the present invention provides a method for establishing a communication channel over a heterogeneous network between a source node and a destination node via a route comprising at least one intermediate node, each of said nodes having a support system including a network control subsystem for controlling physical routing of data between nodes and a respective record of available communication resources to adjacent nodes in said route, said method comprising the steps of

receiving, at said support system of said source node, a request, from a first application executing at said source node, to establish a communication channel having specified characteristics between said first application and a second application at said destination node,

transmitting said request from said source node to said at least one intermediate node;

for each intermediate node,

receiving at said intermediate node said request from the preceding node,

determining, at said intermediate node from said respective record of available communication resources, whether or not the request can be supported using the available communication resources between said intermediate node and an adjacent node in said route, and

if said request can be supported by said intermediate node, transmitting said request from said intermediate node to the next node in said route;

receiving at said destination node said request from said at least one intermediate node,

determining, at said destination node, whether or not to accept the request, and if so, transmitting an indication thereof to said source node; and

establishing said communication channel between said first and second applications in response to said indication.

The provision of communication channels between nodes which are connected to or via a heterogeneous network allows greater flexibility to be exercised when either initially designing a network or looking to integrate new products or workstations into such an existing network.

Further, the source and intermediate nodes only need to be concerned with the links to immediately adjacent nodes when determining whether or not a requested quality or service or communication channel can be supported. The source node does not have to possess knowledge of all of the physical links which will ultimately support the communication channel to the destination node nor perform all of the calculations necessary to determine whether or not a particular combination of physical links can support a required quality of service.

Accordingly, there is provided a method further comprising the step of modifying said request before said intermediate node transmits it to said destination node.

At an intermediate node the selection of an appropriate link to an adjacent node in the route is conducted by the intermediate node and the intermediate node performs the necessary calculations to ensure that the required quality of service requested by the source node can be supported thereby alleviating the source node of such calculations or selections.

An intermediate node, in prior art systems, while having sufficient communication resources to support the communication channel, may not currently having those resources available and accordingly the request for the communication channel is refused.

Suitably, there is provided a method further comprising, at each node, the steps of

if said request cannot be supported using the available intermediate node communication resources, determining whether or not a further application executing at said node will relinquish the node communication resources allocated thereto, and

using any relinquished node communication resources to support said request .

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 portrays the interaction of two programmable workstations.

FIG. 2 depicts the overall structure of the support system in relation to other software components of the workstation with which it interfaces.

FIG. 3 depicts a number of applications sharing information.

FIG. 4 illustrates the two sharing sets created by the application sharing of FIG. 3.

FIG. 5 is a schematic representation of the communications channels.

FIG. 6 depicts a shared drawing board demonstrating serialization.

FIG. 7 depicts data synchronization using two channels.

FIG. 8 demonstrates the overall structure of a standard sending command port.

FIG. 9 demonstrates yet another representation of a sending command port utilized between a system and an application.

FIG. 9a depicts a call manager negotiating with an application to determine what resources are available.

FIG. 9b depicts a more complex scheme for resource allocation required when a collection of applications need to share channel resources between two nodes.

FIG. 9c depicts the scenario when a resource manager needs to negotiate with applications to determine what resources are available.

FIG. 9d depicts the variation in latency and jitter based on the number of frames arriving and the arrival times.

FIG. 9e shows the linkage between the system support link selector, the application channel creation and the link data.

FIG. 9f depicts the channel skew with respect to the number of arriving packets and the arrival times.

FIG. 9g demonstrates the interrelationship between channels, links and routes.

FIG. 9h is a flow chart of the logic when an intermediate node receives a request for support.

FIG. 9i depicts a part of a heterogeneous network containing a source node, multiple intermediate nodes, and a destination node.

FIG. 10 schematically represents the interaction between the application program, the call manager and the application manager in the present invention.

FIG. 11 illustrates an application window of an unaware ampliation to be displayed at a remote node.

FIG. 12 depicts the flows between two applications in the present invention.

FIG. 13 demonstrates the structure of the replaceable application programs or utilities of the present invention.

FIG. 14 depicts the flow of information between the call manager's event handler and the two communicating applications.

FIG. 15 is a graphical representation of the screen interface used in the preferred embodiment of the present invention.

FIG. 16 depicts four nodes involved in two calls using the present invention.

FIG. 17 depicts the interaction between the active processes of the present invention.

An embodiment will now be described, by way of example only, with reference to the figures of the accompanying drawings.

In FIG. 1 are shown two programmable workstations 10 and 12 connected by link 11 in a network, such as a LAN or WAN. The principal components of the workstations are conventionally described as layers, starting with the hardware 13. The hardware which is not illustrated in detail, consists of a processor unit with main memory, secondary storage such as a disk file, a display unit and input/output devices such as keyboard and mouse. Device support software 14 enables the hardware devices to function within a known operating system 15, such as IBM's Operating System/2 (OS/2).

Also part of a conventional workstation, when used in a network, is networking software 16 for supporting connection to the network 11 and communication over the network between workstations. Typical networking software 16 could be the Netbios program product from IBM. Up to this point all that has been described is a conventional networking workstation capable of executing application programs 18.

Each work station includes collaborative application support system software 17 which facilitates the development of application programs for creating a distributed collaborative working environment. In this environment, end-users of the workstation may communicate with users of other workstations in the network over multi-media channels and may work collaboratively on shared data and tasks.

The overall structure of support system 17 in relation to other software components of the workstation with which it interfaces directly is shown in FIG. 2. Further details of the internal structure of the support system are shown in FIG. 10. Broadly speaking, the main functional components of system 17 lie between two interfaces 20 and 21, illustrated by dashed lines.

An application programming interface 20 allows applications 18 to request support services. A device driver interface 21 allows the system to support an extensible range of software and hardware communications subsystems through device drivers such as token ring driver 25, ISDN driver 26, RS232 driver 27 and other device drivers 28. Link support modules 228, 229 interface with the device drivers. These are replaceable, (FIG. 10 shows only a possible selection) depending on the hardware options available at the workstation, and serve to isolate the support system from needing to know precisely which hardware is present. Through an implicit resources interface, (not illustrated) details of the communications network, such as node addresses and directory data may be requested by both the support system, the applications and the device drivers from resource files 29.

The API 20 allows applications 18 to initiate peer applications and share resources, on a variety of hardware and software platforms, located on nodes across a diverse and complex communications networks. It allows them to define multiple dedicated logical data channels between shared applications, suitable to a broad range of multi-media traffic, independently of the structure of the underlying physical network. It allows them to serialise, synchronise, merge or copy the data streaming between shared applications. It also allows them to support a range of attached devices and to allow the interception and redirection of the device data.

The support system includes other components to assist application development such as an extensible set of logical devices 30, interfacing to external applications and devices. Also provided is a set of end-user utilities, written to the API (not illustrated), which can also invoked from applications through a command interface.

Network, nodes and applications

At the highest level, the programming model presented by the API consists of a communicating set of nodes. A node is the addressable entity representing a user, and comprises an instance of the support system software, and a set of resources such as application programs, data etc. Usually a node is typically a dedicated programmable workstation 10, capable of communicating with its peers; in a multi-user system a node is associated with each user.

Nodes are either supported nodes or non-supported nodes; a supported node is one where the support system software 17 is being executed. A collection of inter-communicating supported nodes is called a supported network.

Nodes are identified by name; ideally all node names should be unique but duplicates can be tolerated as long as their associated nodes are never required to inter-communicate. The choice of node naming scheme is not directly relevant to the present invention, although a hierarchical system such as that defined by the Internet protocol has many benefits. It is fundamental to the architecture that a node can dynamically join or leave the network.

Nodes can contain logical devices 30. A logical device is a software extension to the support system that allows an application to manipulate or manage software or equipment, in a manner consistent with other entities in the architecture. There is an extensive range of possible logical devices including: presentation windows, printers, disk drives, modems, and application programs.

Multiple applications can be executed at a node, subject to the constraints imposed there by the operating and windowing system. Applications are either aware or unaware; an aware application uses the services of the API; an unaware application does not. Both aware and unaware applications will generally be executing simultaneously at a node.

When the support system is fully active at a node, one particular aware application must be running at that node. This application plays a unique role at that node and is known as call manager 32. Many call managers may be available for execution at a particular node but only one can execute at a time. The distinguishing feature of a call manager is that it responds to certain events generated by the support system; for example, it resolves any requests that are not directed specifically at an instance of an application, and optionally it may also handle resource management for the node. Call manager responsibility can be transferred from one call manager to another; also the role can be combined with user application function if that is appropriate.

The support software 17 may request that the resources of one node are made available for communication between two other nodes; this is termed passive operation and permission is controlled by the call manager at the passive node. As an example, consider two nodes A and B on a LAN, with a third node C connected to B by an asynchronous communications link. If applications at A and C wish to communicate, the traffic will need to be routed via B. The consent of the call manager at B is required for this use of its node.

Aware applications can share data and resources with other aware applications at the same or different nodes. A collection of applications sharing is called a sharing set. An aware application initiates a share request, naming an application sharing set, a target application and a destination node. This request is first passed by the support software to the call manager at the sending node, which will typically transfer it to the call manager at the destination node. Usually this second call manager will launch the requested application and the source application will be informed. The participation of the call managers in this process allows both local control of the sharing process and other actions to be initiated if necessary. The call managers play a vital role in resolving the names used by applications to identify other nodes and applications. The sharing mechanism can be cascaded; for example, if two applications are already sharing, one of them can initiate a share with a third application naming the same sharing set, with the result that all three applications are then sharing with each other.

Applications may also make local share requests on behalf of other applications thereby allowing membership control of the sharing set to be delegated. Facilities exist for either the issuer, or the target of the share request, to name the application sharing set. These names are not required to be unique: thus multiple sharing sets with the same name can exist.

Individual applications can cease sharing at any time, withdrawing from a sharing set; the other applications in the set are informed of the withdrawal. FIG. 3 shows a number of applications A-E sharing. This results in two sharing sets, irrespective of the order in which the shares were requested, as illustrated in FIG. 4.

Communications, channels and ports

As illustrated in the schematic example of FIG. 5, applications in a sharing set such as 40, 41 and 42 can establish data communication links with each other known as channels. Channels such as 43 and 44 are logically dedicated and uni-directional pipes, with application specified transmission characteristics. A channel is always defined by the sending application and it goes from a sending application to a receiving application. The ends of channels are known as ports; thus all channels have one sending port and one receiving port. A sending port such as 45 sends data packets down the channel; a receiving port such as 46 receives data packets from the channel in the order in which they were sent. There may be no direct mapping between the logical channel structure seen by the aware applications and the physical communication network in existence between the nodes.

An application may establish multiple channels to another application as a convenient way to separate data traffic of different types. The system network manager 31, FIG. 2 may map some or all of the logical channels on to a single physical link such as link 11, FIG. 1 but this will be invisible to the application.

Channels have a number of quality of service characteristics, initially negotiated with the support system 17 during the creation process, which allow data transmission characteristics to be tailored to the requirements of the expected traffic. These characteristics include encryption, compression hints. Encryption allows the data to be encrypted during transmission along the channel; compression hints allow the system the option of compressing the data over narrow bandwidth links.

Quality of service parameters are defined according to signal type, which distinguishes analog from digital data. They need not be specified explicitly, but can be notified to the support system in terms of data classes. This mechanism allows video-channels, voice channels and other data channels to be sensibly established. Channel characteristics can be re-negotiated after channel creation. The data transmission characteristics are implemented in the real network by means of the data transformation manager 32, FIG. 2 in response to the characteristics specified in the channel creation calls over the API.

Four types of channel are supported: standard, merged, synchronous and serialised. Standard channels are the default case; the other types are used in conjunction with collections of channels, known as channel sets. Through a merged channel set data packets are combined from multiple channels and delivered to each receiving application through a single port. There is no guarantee that each application receives all the data packets in the same sequence, only that each application receives all the packets. Through a serialising channel set data packets are combined from different channels, serialised, and delivered to each application such that each receiving port receives the same sequence of data. Through a synchronising channel set data is synchronised, so that the data packets on separate channels are tied together in time (for example voice with video), but delivered through the individual ports belonging to the channels.

An example of data serialisation is illustrated by a shared drawing board application illustrated in FIG. 6. Two identical applications, A and B (50 and 52), allow their users to draw on a single shared surface. In order that the users at A and B see identical results, all the drawing orders at A must be sent to B via ports 53 and 54, and vice versa via ports 55 and 56, in such a way that the sequence processed at A and B is identical. This is accomplished by each transmitting their own data both to each other and to themselves, over two channels 57 and 58 which are members of a common serialising channel set 59.

With reference to FIG. 4, data synchronisation is illustrated by an application A (60), that needs to send lip-synchronised video and voice to application B (61). Two channels 62 and 63 are used for the transmission, each being a member of the same synchronising channel set 64.

Channels can be explicitly created by an API call to the support system, specifying the required channel characteristics, and new channels can also be added to an existing port. The latter mechanism allows a port to be shared across channels belonging to different channel sets; for example data can be sent from a single port to one set of destinations belonging to a merged channel set, and to a second set of destinations belonging to a serialised channel set. Digital channels and analog channels cannot be members of the same channel set. A channel can be deleted, the channel being uniquely identified by specifying its sending and receiving ports.

Channels can be implicitly created as a consequence of an application being, or becoming, a member of an application sharing set. For example, if unshared applications already have a merged or serialized channel, and the channel set name used is identical across these applications, then when the applications share with each other, the additional channels required will be created automatically. Applications are notified of channels implicitly created in this way.

Ports have an assigned connect type: event, command or null. Event ports generate an event when data is either available or is required; command ports allow the application to drive the receipt or supply of data to the port. Mull ports are reserved for ports that are unable to supply data to an application e.g. ports associated with analogue channels, such as the sending port of a video camera. Ports can be controlled through "signal.sub.-- port" commands sent to their port event handler. These can be issued to the local port and can be passed to any other port in the channel. Normally, the signal commands for channel ports will be sent to the port event handler of the application either supplying or receiving data, and may be used for example to stop, start, decrease or increase the data flow. The order of signals between a source and target is maintained. Signals sent to receiving ports in a serialising channel set are serialised themselves, so that all sources receive the same sequence of commands. Other typical signals are "rewind" or "pause" to a tape drive, or "change paper size" to a printer device.

User exits can be optionally associated with ports. This allows monitoring or manipulation of the data, after it has been supplied to a sending port, or before being presented by a receiving port. In the case of synchronised channels, synchronisation is performed from after the data leaves the sending port user exit, and up to the data being presented to the receiving port user exit.

The overall structure of a standard sending command port is shown in FIG. 8. In response to a "send.sub.-- data" command from an application, data is queued in a buffer 71 of port 70. The application empties the buffer to send data asynchronously over a channel 73 via a user exit 72. Incoming "signal.sub.-- port" commands are received by the port event handler 74, independently of channel 73 on line 75 and can be retransmitted outwardly on line 76.

Receiving ports are effectively the mirror image of the corresponding sending port. For a standard receiving event port the structure is similar, but in this case the event handler processes both the data and the port commands.

The situation is more complex when synchronisation is involved. In this case a standard receiving buffered port must be modified by the inclusion of the synchronisation process on the incoming channel prior to the user exit and the buffer.

Serialisation logically involves the collection of all events in a central point, followed by the broadcast of each event to all the destinations for that event. Diagrammatically, this is represented by FIG. 9 for the case of two ports A and B on channels 80 and 81, serialising their output at 82 and 83 to port C (84) and another port (not shown) in serialising process 85. Serialisation can be implemented at a single central point with all data being sent there for serialisation and subsequent distribution; alternatively the serialisation process itself can be distributed.

A receiving port can cause the sending port to stop sending data down the channel, with the option to either discard or deliver the remaining data in the channel. Suspended data transmission can be resumed subsequently.

An alternative method of application inter-communication, avoiding the use of channels and ports, is provided through a "signal" command which allows control information to be sent between applications.

Ports are associated with a data class which specifies data type and data sub-type. The date type identified the nature of the data, e.g. voice, video, file etc. and also distinguishes analogue from digital date. The data types are further subdivided according to the precise format of the data; thus examples of voice sub-types are G.711, G.721, G.722.

The data class may be queried by an application to obtain the data format, independently of the data stream itself, without relying on other applications. Additionally, the data type may be different at the sending and receiving ports, with the support system performing the conversions below the API.

Certain characteristics of ports and channels can be changed after they have been initially established; for example, quality of service, data class and compression hints. This provides the flexibility for an application to modify its communications usage during execution; an example being the temporary degradation of video quality to improve file exchange performance.

Ports can be connected together to establish extended communication links, so that an application may route its inputs through to another application for processing. When ports are connected in this way, and providing user exits have not been established, no further application involvement is required after the routing has been established. This allows the streaming of data between applications and devices. Connection is permitted between channels in different channel sets, of different types, having different quality of service characteristics, of different data class or different connect types (unless one of the ports is null), provided only that one port is sending and one port is receiving. Connected ports can also be welded, so that the connection is permanent and persists even when the local application has terminated. The channel behaves in all respects as though it had been originally created from its source directly to its destination. Any user exits which may be present are removed.

Logical Devices

Logical Devices 30 (FIG. 2) are supported by the support system to enable (i) easier access to system resource and devices, such as clipboard, DDE, printer and video devices, (ii) unaware applications to be used for collaborative working, for example by giving access to the window contents and file activity of an aware application, and (iii) end to end data streaming without application involvement. Frequently used devices include: video capture, video playback, audio playback etc. and facilities are provided for additional devices to be defined.

Logical devices are identified by type; the type names are local to a node. When opened, they present a port to the application; a single logical device can have multiple ports, moreover a device can simultaneously present ports to different applications at the same node. The relevant API call to open a port allows characteristics to be established, peculiar to that device, for example the data formats to be used. Opened logical devices can be controlled through commands sent to the signal port, the commands being specific to the particular logical device. Typical commands to a device port are rewind or pause to a tape drive. The device status, for example whether data is available, can also be queried.

Devices are exactly like channel ports, except that no user exit is present. Applications can connect ports on logical devices to a channel port; this enable data to flow to or from the device and across the channel. This data flow does not require further application involvement once the connection has been made. For example, data can be streamed from a camera through a camera logical device, across a channel, and displayed by a window logical device. The application can control the two logical devices via there signal ports; when the transmission is no longer required, the application can disconnect the ports, close the devices and remove the channel.

Device ports cannot be welded to channel ports, since this would allow a device to exist outside the control of a local application. Logical devices are permitted to issue API calls to the support system, and in this regard act on behalf of the owning application (ie the application which opened the device). Devices for example can cause their owning application to share with other applications, create channels, and send or receive data.

Potential devices include:

    ______________________________________
    system clipboard     LPTx
    DDE                  window
    shared clipboard     printer
    serial emulator      file
    video                codec
    audio                telephone
    ______________________________________

                  TABLE 1
    ______________________________________
    Node    Resource % used    Resource set using resources
    ______________________________________
    A       ISDN     50        APP1, APP2, APP3
    B       ASYNC    90        APP2, APP4
    C       ISDN     20        APP2
    .       .        .         .
    A       TCP/IP   10        APP3
    ______________________________________

    ______________________________________
    event.sub.-- handler
                 the event handler to be invoked for call
                 manager events.
    event.sub.-- word
                 A user specified data pointer paused to the
                 call manager event handler on all call
                 manager events.
    call.sub.-- manager.sub.-- info
                 (returned). The value returned by the current
                 call manager in response to the
                 SET.sub.-- CALL.sub.-- MANAGER event.
    ______________________________________