Automatic transport detection by attempting to establish communication session using list of possible transports and corresponding media dependent modules

Abstract

The transports available in a local computer system for communicating with a remote computer system are automatically determined at either install time or run time. At install time, a list of transports supported by the local computer system is used to determine which supported transports are actually installed in the local computer system and the media dependent modules (MDMs) that correspond to those installed transports. At run time, a list of the installed transports and corresponding MDMs is used to determine which installed transports (and corresponding MDMs) can actually be used for an impending communications session with the remote computer system.

Claims

What is claimed is:

1. A computer-implemented process for transport detection, comprising the steps of

(a) providing a list of possible transports over which a local computer system communicates with at least one remote computer system; and

(b) automatically identifying, at run time, a subset of the list of possible transports that are available for communications with the remote computer system, wherein:

the list of possible transports corresponds to transports installed in the local computer system and corresponding MDMs;

the subset of the list of possible transports corresponds to transports that can be used by the local computer system for an impending communications session with the remote computer system; and

for each installed transport, step (b) comprises the steps of:

(1) attempting, by a network independent layer of the local computer system, to begin the communications session using a specified transport by calling a begin-session function into a network dependent layer of the local computer system;

(2) attempting, by the network dependent layer, to begin the communications session using the list of installed transports and corresponding MDMs, by loading an MDM corresponding to the specified transport and instructing the MDM to attempt to communicate with a corresponding network stack;

(3) if the MDM's attempt to communicate with the corresponding network stack is successful, then identifying the specified transport as one of the transports that can be used by the local computer system for the impending communications session with the remote computer system; and

(4) if the MDM's attempt to communicate with the corresponding network stack is unsuccessful, then rejecting the specified transport as one of the transports that can be used by the local computer system for the impending communications session with the remote computer system.

2. The process of claim 1, wherein:

step (b)(1) comprises the steps of:

(A) calling, by an application of the local computer system, into a conference manager of the local computer system to begin the communications session using the specified transport;

(B) calling, by the conference manager, into a conferencing application programming interface (API) of the local computer system to begin the communications session using the specified transport;

(C) calling, by the conferencing API, into a communications API of the local computer system to begin the communications session using the specified transport;

(D) causing, by the communications API, a data ink manager corresponding to the specified transport to be loaded; and

(E) calling, by the communications API, into the data link manager to begin the communications session;

step (b)(2) comprises the steps of:

(A) causing, by the data link manager, the MDM to be loaded using the list of installed transports and corresponding MDMs;

(B) calling, by the data link manager, into the MDM to begin the communications session; and

(C) attempting, by the MDM, to communicate with the corresponding network stack;

step (b)(3) comprises the step of passing a success message from the MDM to the data link manager to the communications API to the conferencing API to the conference manager to the application; and

step (b)(4) comprises the steps of:

(A) passing a failure message from the MDM to the data link manager to the communications API to the conferencing API to the conference manager to the application;

(B) causing, by the data link manager, the MDM to be unloaded; and

(C) causing, by the communications API, the data link manager to be unloaded.

3. The process of claim 1, further comprising the step of displaying, by the application, a list of callee addresses for the impending communications session, wherein each callee address corresponds to one of the transports that can be used for the impending communications session as identified in step (b).

4. The process of claim 1, wherein the installed transports and corresponding MDMs are identified in an initialization file.

5. The process of claim 1, wherein:

the installed transports comprise at least one of an ISDN transport and a LAN transport;

the installed transports comprise one or more LAN transports conforming to one or more LAN-transport standards; and

the one or more LAN transports comprise two or more LAN products conforming to a single LAN-transport standard.

6. An apparatus for transport detection, comprising:

(a) a list of possible transports over which a local computer system communicates with at least one remote computer system; and

(b) a network independent layer and a network dependent layer of the local computer system, adapted to automatically identify, at run time, a subset of the list of possible transports that are available for communications with the remote computer system, wherein:

the list of possible transports corresponds to transports installed in the local computer system and corresponding MDMs;

the subset of the list of possible transports corresponds to transports that can be used by the local computer system for an impending communications session with the remote computer system; and

for each installed transport:

the network independent layer attempts to begin the communications session using a specified transport by calling a begin-session function into the network dependent layer;

the network dependent layer attempts to begin the communications session using the list of installed transports and corresponding MDMs, by loading an MDM corresponding to the specified transport and instructing the MDM to attempt to communicate with a corresponding network stack;

if the MDM's attempt to communicate with the corresponding network stack is successful, then the network independent layer identifies the specified transport as one of the transports that can be used by the local computer system for the impending communications session with the remote computer system; and

if the MDM's attempt to communicate with the corresponding network stack is unsuccessful, then the network independent layer rejects the specified transport as one of the transports that can be used by the local computer system for the impending communications session with the remote computer system.

7. The apparatus of claim 6, wherein:

the network independent layer comprises an application, a conference manager, a conferencing application programming interface (API), and a communications API;

the network dependent layer comprises a data link manager, the MDM, and the corresponding network stack;

for each installed transport:

the application calls into the conference manager to begin the communications session using the specified transport;

the conference manager calls into the conferencing API to begin the communications session using the specified transport;

the conferencing API calls into the communications API to begin the communications session using the specified transport;

the communications API causes the data link manager to be loaded; and

the communications API calls into the data link manager to begin the communications session;

the data ink manager causes the MDM to be loaded using the list of installed transports and corresponding MDMs;

the data link manager calls into the MDM to begin the communications session; and

the MDM attempts to communicate with the corresponding network stack;

if the MDM's attempt to communicate with the corresponding network stack is successful, then a success message is passed from the MDM to the data link manager to the communications API to the conferencing API to the conference manager to the application; and

if the MDM's attempt to communicate with the corresponding network stack is unsuccessful, then:

a failure message is passed from the MDM to the data link manager to the communications API to the conferencing API to the conference manager to the application;

the data link manager causes the MDM to be unloaded; and

the communications API causes the data link manager to be unloaded.

8. The apparatus of claim 6, wherein the application displays a list of callee addresses for the impending communications session, wherein each callee address corresponds to one of the transports that can be used for the impending communications session.

9. The apparatus of claim 6, wherein the installed transports and corresponding MDMs are identified in an initialization file.

10. The apparatus of claim 6, wherein:

the installed transports comprise at least one of an ISDN transport and a LAN transport;

the installed transports comprise one or more LAN transports conforming to one or more LAN-transport standards; and

the one or more LAN transports comprise two or more LAN products conforming to a single LAN-transport standard.

11. A computer program embodied in a tangible medium, wherein, when the computer program is loaded into and executed by a local computer system:

the local computer system provides a list of possible transports over which the local computer system communicates with at least one remote computer system; and

the local computer system automatically identifies, at run time, a subset of the list of possible transports that are available for communications with the remote computer system, wherein:

the list of possible transports corresponds to transports installed in the local computer system and corresponding MDMs;

the subset of the list of possible transports corresponds to transports that can be used by the local computer system for an impending communications session with the remote computer system; and

the local computer system comprises a network independent layer of the local computer system and a network dependent layer of the local computer system; and

for each installed transport:

the network independent layer attempts to begin the communications session using a specified transport by calling a begin-session function into the network dependent layer;

the network dependent layer attempts to begin the communications session using the list of installed transports and corresponding MDMs, by loading an MDM corresponding to the specified transport and instructing the MDM to attempt to communicate with a corresponding network stack;

if the MDM's attempt to communicate with the corresponding network stack is successful, then the local computer system identifies the specified transport as one of the transports that can be used by the local computer system for the impending communications session with the remote computer system; and

if the MDM's attempt to communicate with the corresponding network stack is unsuccessful, then the local computer system rejects the specified transport as one of the transports that can be used by the local computer system for the impending communications session with the remote computer system.

12. The computer program of claim 11, wherein:

the network independent layer comprises an application, a conference manager, a conferencing application programming interface (API), and a communications API;

the network dependent layer comprises a data link manager, the MDM, and the corresponding network stack;

for each installed transport:

the application calls into the conference manager to begin the communications session using the specified transport;

the conference manager calls into the conferencing API to begin the communications session using the specified transport;

the conferencing API calls into the communications API to begin the communications session using the specified transport;

the communications API causes the data link manager to be loaded; and

the communications API calls into the data link manager to begin the communications session;

the data link manager causes the MDM to be loaded using the list of installed transports and corresponding MDMs;

the data link manager calls into the MDM to begin the communications session; and

the MDM attempts to communicate with the corresponding network stack;

if the MDM's attempt to communicate with the corresponding network stack is successful, then a success message is passed from the MDM to the data link manager to the communications API to the conferencing API to the conference manager to the application; and

if the MDM's attempt to communicate with the corresponding network stack is unsuccessful, then:

a failure message is passed from the MDM to the data link manager to the communications API to the conferencing API to the conference manager to the application;

the data link manager causes the MDM to be unloaded; and

the communications API causes the data link manager to be unloaded.

13. The computer program of claim 11, wherein the application displays a list of callee addresses for the impending communications session, wherein each callee address corresponds to one of the transports that can be used for the impending communications session.

14. The computer program of claim 11, wherein the installed transports and corresponding MDMs are identified in an initialization file.

15. The computer program of claim 11, wherein:

the installed transports comprise at least one of an ISDN transport and a LAN transport;

the installed transports comprise one or more LAN transports conforming to one or more LAN-transport standards; and

the one or more LAN transports comprise two or more LAN products conforming to a single LAN-transport standard.

16. A computer-implemented process for transport detection, comprising the steps of:

(a) providing a list of possible transports over which a local computer system communicates with at least one remote computer system; and

(b) automatically identifying, at install time, a subset of the list of possible transports that are available for communications with the remote computer system, wherein:

the list of possible transports corresponds to transports supported by the local computer system;

the subset of the list of possible transports corresponds to transports installed in the local computer system; and

for each supported transport, step (b) comprises the steps of:

(1) loading a media dependent module (MDM) corresponding to the supported transport;

(2) attempting to initialize a network transport stack corresponding to the MDM;

(3) if the attempt to initialize is successful, then identifying the supported transport as one of the installed transports and identifying the MDM as corresponding to the installed transport;

(4) if the attempt to initialize is unsuccessful, then determining if there is another MDM for the supported transport;

(5) if there is another MDM for the supported transport, then repeating steps (1)-(4) for the another MDM; and

(6) if there is not another MDM for the supported transport, then determining that the supported transport is not one of the installed transports.

17. The process of claim 16, wherein step (b) comprises the step of saving the installed transports and corresponding MDMs in an initialization file.

18. The process of claim 16, wherein:

the supported transports comprise at least one of an ISDN transport and a LAN transport;

the supported transports comprise one or more LAN transports conforming to one or more LAN-transport standards; and

the one or more LAN transports comprise two or more LAN products conforming to a single LAN-transport standard.

19. An apparatus for transport detection, comprising:

(a) a list of possible transports over which a local computer system communicates with at least one remote computer system; and

(b) a network independent layer adapted to automatically identify, at install time, a subset of the list of possible transports that are available for communications with the remote computer system, wherein:

the list of possible transports corresponds to transports supported by the local computer system;

the subset of the list of possible transports corresponds to transports installed in the local computer system; and

for each supported transport, the network independent layer:

(1) loads a media dependent module (MDM) corresponding to the supported transport;

(2) attempts to initialize a network transport stack corresponding to the MDM;

(3) identifies the supported transport as one of the installed transports and identifying the MDM as corresponding to the installed transport, if the attempt to initialize is successful;

(4) determines if there is another MDM for the supported transport, if the attempt to initialize is unsuccessful;

(5) repeats (1)-(4) for the another MDM, if there is another MDM for the supported transport; and

(6) determines that the supported transport is not one of the installed transports, if there is not another MDM for the supported transport.

20. The apparatus of claim 19, wherein the network independent layer saves the installed transports and corresponding MDMs in an initialization file.

21. The apparatus of claim 19, wherein:

the supported transports comprise at least one of an ISDN transport and a LAN transport;

the supported transports comprise one or more LAN transports conforming to one or more LAN-transport standards; and

the one or more LAN transports comprise two or more LAN products conforming to a single LAN-transport standard.

22. A computer program embodied in a tangible medium, wherein, when the computer program is loaded into and executed by a local computer system:

the local computer system provides a list of possible transports over which the local computer system communicates with at least one remote computer system; and

the local computer system automatically identifies, at install time, a subset of the list of possible transports that are available for communications with the remote computer system, wherein:

the list of possible transports corresponds to transports supported by the local computer system;

the subset of the list of possible transports corresponds to transports installed in the local computer system; and

for each supported transport, the local computer system:

(1) loads a media dependent module (MDM) corresponding to the supported transport;

(2) attempts to initialize a network transport stack corresponding to the MDM;

(3) identifies the supported transport as one of the installed transports and identifying the MDM as corresponding to the installed transport, if the attempt to initialize is successful;

(4) determines if there is another MDM for the supported transport, if the attempt to initialize is unsuccessful;

(5) repeats (1)-(4) for the another MDM, if there is another MDM for the supported transport; and

(6) determines that the supported transport is not one of the installed transports, if there is not another MDM for the supported transport.

23. The computer program of claim 22, wherein the local computer system saves the installed transports and corresponding MDMs in an initialization file.

24. The computer program of claim 22, wherein:

the supported transports comprise at least one of an ISDN transport and a LAN transport;

the supported transports comprise one or more LAN transports conforming to one or more LAN-transport standards; and

the one or more LAN transports comprise two or more LAN products conforming to a single LAN-transport standard.

Description

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to audio/video conferencing, and, in particular, to systems for real-time audio, video, and data conferencing in windowed environments on personal computer systems.

2. Description of the Related Art

It is desirable to provide real-time audio, video, and data conferencing between personal computer (PC) systems operating in windowed environments such as those provided by versions of Microsoft.RTM. Windows.TM. operating system. There are difficulties, however, with providing real-time conferencing in non-real-time windowed environments. It is also desirable to provide conferencing between PC systems over two or more different transports.

It is accordingly an object of this invention to overcome the disadvantages and drawbacks of the known art and to provide real-time audio, video, and data conferencing between PC systems operating in non-real-time windowed environments over two or more different transports.

It is a particular object of the present invention to provide real-time audio, video, and data conferencing between PC systems operating under a Microsoft.RTM. Windows.TM. operating system over ISDN and LAN networks.

Further objects and advantages of this invention will become apparent from the detailed description of a preferred embodiment which follows.

SUMMARY OF THE INVENTION

The present invention comprises a computer-implemented process, apparatus, and computer program for transport detection. A list of possible transports over which a local computer system communicates with at least one remote computer system is provided. A subset of the list of possible transports that are available for communications with the remote computer system is automatically identified. When implemented at install time, the invention determines which supported transports are installed and identifies the corresponding media dependent modules. When implemented at run time, the invention determines which of the installed transports can be used for an impending communications session with the remote computer system.

BRIEF DESCRIPTION OF THE DRAWINGS

Other objects, features, and advantages of the present invention will become more fully apparent from the following detailed description, the appended claims, and the accompanying drawings in which:

FIG. 1 is a block diagram representing real-time point-to-point audio, video, and data conferencing between two PC systems;

FIG. 2 is a block diagram of the hardware configuration of the conferencing system of each PC system of FIG. 1;

FIG. 3 is a block diagram of the hardware configuration of the video board of the conferencing system of FIG. 2;

FIG. 4 is a block diagram of the hardware configuration of the audio/comm (ISDN) board of the conferencing system of FIG. 2;

FIG. 5 is a block diagram of the software configuration of the conferencing system of each PC system of FIG. 1;

FIG. 6 is a block diagram of the hardware configuration of the audio/comm (ISDN) board of FIG. 4;

FIG. 7 is a block diagram of the conferencing interface layer between the conferencing applications of FIG. 5, on one side, and the comm, video, and audio managers of FIG. 5, on the other side;

FIG. 8 is a representation of the conferencing call finite state machine (FSM) for a conferencing session between a local conferencing system (i.e., caller) and a remote conferencing system (i.e., callee);

FIG. 9 is a representation of the conferencing stream FSM for each conferencing system participating in a conferencing session;

FIG. 10 is a representation of the video FSM for the local video stream and the remote video stream of a conferencing system during a conferencing session;

FIG. 11 is a block diagram of the software components of the video manager of the conferencing system of FIG. 5;

FIG. 12 is a representation of a sequence of N walking key frames;

FIG. 13 is a representation of the audio FSM for the local audio stream and the remote audio stream of a conferencing system during a conferencing session;

FIG. 14 is a block diagram of the architecture of the audio subsystem of the conferencing system of FIG. 5;

FIG. 15 is a block diagram of the interface between the audio task of FIG. 5 and the audio hardware of audio/comm (ISDN) board of FIG. 2;

FIG. 16 is a block diagram of the interface between the audio task and the comm task of FIG. 5;

FIG. 17 is a block diagram of the comm subsystem of the conferencing system of FIG. 5;

FIG. 18 is a block diagram of the comm subsystem architecture for two conferencing systems of FIG. 5 participating in a conferencing session over an ISDN connection;

FIG. 19 is a representation of the comm subsystem application FSM for a conferencing session between a local site and a remote site;

FIG. 20 is a representation of the comm subsystem connection FSM for a conferencing session between a local site and a remote site;

FIG. 21 is a representation of the comm subsystem control channel handshake FSM for a conferencing session between a local site and a remote site;

FIG. 22 is a representation of the comm subsystem channel establishment FSM for a conferencing session between a local site and a remote site;

FIG. 23 is a representation of the comm subsystem processing for a typical conferencing session between a caller and a callee;

FIG. 24 is a representation of the structure of a video packet as sent to or received from the comm subsystem of the conferencing system of FIG. 5;

FIG. 25 is a representation of the compressed video bitstream for the conferencing system of FIG. 5;

FIG. 26 is a representation of a compressed audio packet for the conferencing system of FIG. 5;

FIG. 27 is a representation of the reliable transport comm packet structure;

FIG. 28 is a representation of the unreliable transport comm packet structure;

FIG. 29 are diagrams indicating typical TII-DLM connection setup and teardown sequences;

FIGS. 30 and 31 are diagrams of the architecture of the audio/comm (ISDN) board;

FIG. 32 is a diagram of the audio/comm (ISDN) board environment;

FIG. 33 is a flow diagram of the on-demand application invocation processing of the conferencing system of FIG. 5;

FIG. 34 is a flow diagram of an example of the processing implemented within the conferencing system of FIG. 5 to manage two conferencing applications in a single conferencing session with a remote conferencing system;

FIG. 35 represents the flow of bits between two remote high-resolution counters used to maintain clock values over a conferencing network;

FIG. 36 is a flow diagram of the processing of the conferencing system of FIG. 1 to control the flow of signals over reliable channels;

FIG. 37 is a flow diagram of the preemptive priority-based transmission processing implemented by the communications subsystem of the conferencing system of FIG. 1;

FIG. 38 is a state diagram for the complete rate negotiation processing;

FIG. 39 is a state diagram for the rate negotiation processing for a called node during a 64 KBPS upgrade;

FIG. 40 is a state diagram for the rate negotiation processing for a calling node during a 64 KBPS upgrade; and

FIG. 41 is a state diagram for the rate negotiation processing in loopback mode during a 64 KBPS upgrade;

FIG. 42 is a flow diagram of the processing by the conferencing system of FIGS. 5 and 17 during the automatic transport detection implemented at install time;

FIG. 43 is a block diagram showing the network connections made by the conferencing system of FIGS. 5 and 17 during the automatic transport detection implemented at run time;

FIG. 44 is a representation of the DLMLAN packet header format;

FIG. 45 is a representation of the MDM packet header format for LAN transmissions;

FIG. 46 is a representation of the connection messages for a typical conferencing session from the perspective of the MDMs on the local and remote nodes;

FIG. 47 is a flow diagram of the video negotiation processing between two conferencing systems of FIG. 1;

FIG. 48 is a flow diagram of the call-progress processing when the placement of a conference call is successful;

FIG. 49 is a representation of the interrupt-time processing for receiving data signals by the audio/video conferencing system of FIG. 5;

FIG. 50 is a representation of the interrupt-time processing for transmitting data signals by the audio/video conferencing system of FIG. 5;

FIG. 51 is a representation of the auto registration environment for video conferencing;

FIG. 52 is a representation of the architecture for auto registration and remote confidence testing for the new node of FIG. 51;

FIG. 53 is a flow diagram of the processing for the auto registration and remote confidence testing of the auto registration environment of FIG. 51;

FIG. 54 is a flow diagram of the processing implemented by the client (i.e., a new node) for the auto registration processing of FIG. 53;

FIG. 55 is a flow diagram of the processing implemented by a confidence test server for the auto registration processing of FIG. 53;

FIG. 56 is a representation of the auto registration file format; and

FIG. 57 are connection diagrams that show the interactions between a DLM and an MDM in connection and session establishment and tear-down.

DESCRIPTION OF THE PREFERRED EMBODIMENT(S)

Point-To-Point Conferencing Network

Referring now to FIG. 1, there is shown a block diagram representing real-time point-to-point audio, video, and data conferencing between two PC systems, according to a preferred embodiment of the present invention. Each PC system has a conferencing system 100, a camera 102, a microphone 104, a monitor 106, and a speaker 108. The conferencing systems communicate via network 110, which may be either an integrated services digital network (ISDN), a local area network (LAN), or a wide area network (WAN). Each conferencing system 100 receives, digitizes, and compresses the analog video signals generated by camera 102 and the analog audio signals generated by microphone 104. The compressed digital video and audio signals are transmitted to the other conferencing system via network 110, where they are decompressed and converted for play on monitor 106 and speaker 108, respectively. In addition, each conferencing system 100 may generate and transmit data signals to the other conferencing system 100 for play on monitor 106. The video and data signals are displayed in different windows on monitor 106. Each conferencing system 100 may also display the locally generated video signals in a separate window.

Camera 102 may be any suitable camera for generating NSTC or PAL analog video signals. Microphone 104 may be any suitable microphone for generating analog audio signals. Monitor 106 may be any suitable monitor for displaying video and graphics images and is preferably a VGA monitor. Speaker 108 may be any suitable device for playing analog audio signals and is preferably a headset.

Conferencing System Hardware Configuration

Referring now to FIG. 2, there is shown a block diagram of the hardware configuration of each conferencing system 100 of FIG. 1. Each conferencing system 100 comprises host processor 202, video board 204, audio/comm (ISDN) board 206, LAN board 210, and ISA bus 208.

Referring now to FIG. 3, there is shown a block diagram of the hardware configuration of video board 204 of FIG. 2. Video board 204 comprises industry standard architecture (ISA) bus interface 310, video bus 312, pixel processor 302, video random access memory (VRAM) device 304, video capture module 306, and video analog-to-digital (A/D) converter 308.

Referring now to FIG. 4, there is shown a block diagram of the hardware configuration of audio/comm (ISDN) board 206 of FIG. 2. Audio/comm (ISDN) board 206 comprises ISDN interface 402, memory 404, digital signal processor (DSP) 406, and ISA bus interface 408, audio input/output (I/O) hardware 410.

LAN board 210 of FIG. 2 may be any conventional LAN card that supports standard driver interfaces and is preferably an Intel.RTM. EtherExpress.TM. 16C LAN Combo Card.

Conferencing System Software Configuration

Referring now to FIG. 5, there is shown a block diagram of the software configuration each conferencing system 100 of FIG. 1. Video microcode 530 resides and runs on pixel processor 302 of video board 204 of FIG. 3. Comm task 540 and audio task 538 reside and run on DSP 406 of audio/comm (ISDN) board 206 of FIG. 4. The one or more network stacks 560 reside and run partially on host processor 202 of FIG. 2 and partially on LAN board 210 of FIG. 2. All of the other software modules depicted in FIG. 5 reside and run on host processor 202.

Video, Audio, and Data Processing

Referring now to FIGS. 3, 4, and 5, audio/video conferencing application 502 running on host processor 202 provides the top-level local control of audio and video conferencing between a local conferencing system (i.e., local site or endpoint) and a remote conferencing system (i.e., remote site or endpoint). Audio/video conferencing application 502 controls local audio and video processing and establishes links with the remote site for transmitting and receiving audio and video over the ISDN or LAN network 110. Similarly, data conferencing application 504, also running on host processor 202, provides the top-level local control of data conferencing between the local and remote sites. Conferencing applications 502 and 504 communicate with the audio, video, and comm subsystems using conference manager 544, conferencing application programming interface (API) 506, LAN management interface (LMI) API 556, LMI manager 558, video API 508, comm API 510, and audio API 512. The functions of conferencing applications 502 and 504 and the APIs they use are described in further detail later in this specification.

Audio Processing

During conferencing, audio I/O hardware 410 of audio/comm (ISDN) board 206 digitizes analog audio signals received from microphone 104 and stores the resulting uncompressed digital audio to memory 404 via ISA bus interface 408. Audio task 538, running on DSP 406, controls the compression of the uncompressed audio and stores the resulting compressed audio back to memory 404.

Audio Processing for ISDN-Based Processing

For ISDN-based conferencing, comm task 540, also running on DSP 406, formats the locally-generated compressed audio for ISDN transmission and transmits the compressed ISDN-formatted audio to ISDN interface 402 for transmission to the remote site over ISDN network 110.

During ISDN-based conferencing, ISDN interface 402 also receives from ISDN network 110 compressed ISDN-formatted audio generated by the remote site and stores the compressed ISDN-formatted audio to memory 404. Comm task 540 then reconstructs the compressed audio format and stores the compressed audio back to memory 404. Audio task 538 controls the decompression of the compressed audio and stores the resulting decompressed audio back to memory 404. ISA bus interface then transmits the decompressed audio to audio I/O hardware 410, which digital-to-analog (D/A) converts the decompressed audio and transmits the resulting analog audio signals to speaker 108 for play.

Thus, for ISDN-based conferencing, audio capture/compression and decompression/playback are performed entirely within audio/comm (ISDN) board 206 without going through the host processor. As a result, audio is continuously played during an ISDN-based conferencing session regardless of what other applications are running on host processor 202.

Audio Processing for LAN-Based Processing

For LAN-based conferencing, audio task 538 passes the locally-generated compressed audio to the audio manager 520, which sends the compressed audio via comm API 510 to the comm manager 518 for transmission by the network stack 560 to the remote site via the LAN network 110.

During LAN-based conferencing, the network stack 560 also receives from LAN network 110 compressed LAN-formatted audio generated by the remote site and passes the compressed LAN-formatted audio to comm manager 518. Comm manager 518 then reconstructs the compressed audio format and passes the compressed audio via audio API 512 to audio manager 520, which stores the compressed audio into memory 404 of the audio/comm (ISDN) board 206 of FIG. 4. As in ISDN-based conferencing, audio task 538 controls the decompression of the compressed audio and stores the resulting decompressed audio back to memory 404. ISA bus interface then transmits the decompressed audio to audio 1/0 hardware 410, which digital-to-analog (D/A) converts the decompressed audio and transmits the resulting analog audio signals to speaker 108 for play.

Video Processing

Concurrent with the audio processing, video A/D converter 308 of video board 204 digitizes analog video signals received from camera 102 and transmits the resulting digitized video to video capture module 306. Video capture module 306 decodes the digitized video into YUV color components and delivers uncompressed digital video bitmaps to VRAM 304 via video bus 312. Video microcode 530, running on pixel processor 302, compresses the uncompressed video bitmaps and stores the resulting compressed video back to VRAM 304. ISA bus interface 310 then transmits via ISA bus 208 the compressed video to video/host interface 526 running on host processor 202.

Video/host interface 526 passes the compressed video to video manager 516 via video capture driver 522. Video manager 516 calls audio manager 520 using audio API 512 for synchronization information. Video manager 516 then time-stamps the video for synchronization with the audio. Video manager 516 passes the time-stamped compressed video to comm manager 518 via comm API 510.

Video Processing for ISDN-Based Conferencing

For ISDN-based conferencing, comm manager 518 passes the locally-generated compressed video through digital signal processing (DSP) interface 528 to ISA bus interface 408 of audio/comm (ISDN) board 206, which stores the compressed video to memory 404. Comm task 540 then formats the compressed video for ISDN transmission and transmits the ISDN-formatted compressed video to ISDN interface 402 for transmission to the remote site over ISDN network 110.

During ISDN-based conferencing, ISDN interface 402 also receives from ISDN network 110 ISDN-formatted compressed video generated by the remote site system and stores the ISDN-formatted compressed video to memory 404. Comm task 540 reconstructs the compressed video format and stores the resulting compressed video back to memory 404. ISA bus interface then transmits the compressed video to comm manager 518 via ISA bus 208 and DSP interface 528. Comm manager 518 passes the compressed video to video manager 516 via video API 508. Video manager 516 passes the compressed video to video decode driver 548 for decompression processing. Video decode driver 548 passes the decompressed video to video playback driver 550, which formats the decompressed video for transmission to the graphics device interface (GDI) (not shown) of the Microsoft.RTM. Windows.TM. operating system for eventual display in a video window on monitor 106.

Video Processing for LAN-Based Conferencing

For LAN-based conferencing, comm manager 518 formats the locally-generated compressed video for LAN transmission and transmits the LAN-formatted compressed video to the network stack 560 for transmission to the remote site over LAN network 110.

During LAN-based conferencing, the network stack 560 also receives from LAN network 110 LAN-formatted compressed video generated by the remote site system and passes the LAN-formatted compressed video to comm manager 518. Comm manager 518 then reconstructs the compressed video format and passes the compressed video via video API 508 to video manager 516. As in ISDN-based conferencing, video manager 516 passes the compressed video to video decode driver 548 for decompression processing. Video decode driver 548 passes the decompressed video to video playback driver 550, which formats the decompressed video for transmission to the graphics device interface (GDI) (not shown) of the Microsoft.RTM. Windows.TM. operating system for eventual display in a video window on monitor 106.

Data Processing

For data conferencing, concurrent with audio and video conferencing, data conferencing application 504 generates and passes data to comm manager 518 using conferencing API 506 and comm API 510.

Data Processing for ISDN-Based Conferencing

For ISDN-based conferencing, comm manager 518 passes the locally-generated data through board DSP interface 532 to ISA bus interface 408, which stores the data to memory 404. Comm task 540 formats the data for ISDN transmission and stores the ISDN-formatted data back to memory 404. ISDN interface 402 then transmits the ISDN-formatted data to the remote site over ISDN network 110.

During ISDN-based conferencing, ISDN interface 402 also receives from ISDN network 110 ISDN-formatted data generated by the remote site and stores the ISDN-formatted data to memory 404. Comm task 540 reconstructs the data format and stores the resulting data back to memory 404. ISA bus interface 408 then transmits the data to comm manager 518, via ISA bus 208 and DSP interface 528. Comm manager 518 passes the data to data conferencing application 504 using comm API 510 and conferencing API 506. Data conferencing application 504 processes the data and transmits the processed data to Microsoft.RTM. Windows.TM. GDI (not shown) for display in a data window on monitor 106.

Data Processing for LAN-Based Conferencing

For LAN-based conferencing, comm manager 518 formats the locally-generated data for LAN transmission and transmits the LAN-formatted data video to the network stack 560 for transmission to the remote site over LAN network 110.

During LAN-based conferencing, the network stack 560 also receives from LAN network 110 LAN-formatted data generated by the remote site system and passes the LAN-formatted data to comm manager 518. Comm manager 518 then reconstructs the data and passes the data to data conferencing application 504 using comm API 510 and conferencing API 506. As in ISDN-based conferencing, data conferencing application 504 processes the data and transmits the processed data to Microsoft.RTM. Windows.TM. GDI (not shown) for display in a data window on monitor 106.

Hardware Configuration for Conferencing System

LAN board 210 of FIG. 2 may be any suitable board for transmitting and receiving digital packets over a local (or wide) area network and is preferably an Intel.RTM. EtherExpress.TM. 16 card with appropriate control and network protocol software. Conferencing system 100 is capable of supporting LAN-based conferencing under different LAN transport standards (e.g., Novell IPX, Internet User Datagram Protocol (UDP), and/or NetBIOS standards). Furthermore, conferencing system 100 is capable of supporting LAN-based conferencing with different LAN products for a single LAN transport standard (e.g., LAN WorkPlace (LWPUDP) by Novell and FTPUDP by FTP Software, Inc., both of which conform to the LAN UDP standard). Thus, LAN board 210 corresponds to the LAN transports that are supported in conferencing system 100. Those skilled in the art will understand that more than one network stack 560 may be used to interface with a single LAN board 210.

Referring now to FIG. 6, there is shown a block diagram of the hardware configuration of audio/comm (ISDN) board 206 of FIG. 4. Referring now to FIGS. 30 and 31, there are shown diagrams of the architecture of the audio/comm (ISDN) board 206. Referring now to FIG. 32, there is shown a diagram of the audio/comm (ISDN) board environment. The description for the rest of this section is the same as the description for the section of the same name in U.S. patent application Ser. No. 08/157,694, now U.S. Pat. No. 5,506,954.

Software Architecture for Conferencing System

The software architecture of conferencing system 100 of FIGS. 2 and 5 has three layers of abstraction. A computer supported collaboration (CSC) infrastructure layer comprises the hardware (i.e., video board 204, audio/comm (ISDN) board 206, and LAN board 210) and host/board driver software (i.e., video/host interface 526, DSP interface 528, and network stack 560) to support video, audio, and comm, as well as the encode method for video (running on video board 204) and encode/decode methods for audio (running on audio/comm (ISDN) board 206). The capabilities of the CSC infrastructure are provided to the upper layer as a device driver interface (DDI).

A CSC system software layer provides services for instantiating and controlling the video and audio streams, synchronizing the two streams, and establishing and gracefully ending a call and associated communication channels. This functionality is provided in an application programming interface (API). This API comprises the extended audio and video interfaces and the communications APIs (i.e., conference manager 544, conferencing API (VCI) 506, LAN management interface (LMI) API 556, LMI manager 558, video API 508, video manager 516, video capture driver 522, video decode driver 548, video playback driver 550, comm API 510, comm manager 518, Wave API 514, Wave driver 524, PWave API 552, audio API 512, and audio manager 520).

A CSC applications layer brings CSC to the desktop. The CSC applications may include video annotation to video mail, video answering machine, audio/video/data conferencing (i.e., audio/video conferencing application 502 and data conferencing application 504), and group decision support systems.

Audio/video conferencing application 502 and data conferencing application 504 rely on conference manager 544 and conferencing API 506, which in turn rely upon video API 508, comm API 510, and audio API 512 to interface with video manager 516, comm manager 518, and audio manager 520, respectively. Comm API 510 and comm manager 518 provide a transport-independent interface (TII) that provides communications services to conferencing applications 502 and 504. The communications software of conferencing system 100 may be designed to support different transport mechanisms, such as ISDN, SW56, and LAN (e.g., SPX/IPX, TCP/IP, or NetBIOS). The TII isolates the conferencing applications from the underlying transport layer (i.e., transport-medium-specific DSP interface 528). The TII hides the network/connectivity specific operations. In conferencing system 100, the TII hides the ISDN and LAN layers. The DSP interface 528 is hidden in a datalink module (DLM). The LAN interface is hidden within a media dependent module (MDM). The TII provides services to the conferencing applications for opening communication channels (within the same session) and dynamically managing the bandwidth. The bandwidth is managed through a transmission priority scheme.

In an embodiment in which conferencing system 100 performs software video decoding, AVI capture driver 522 is implemented on top of video/host interface 526 (the video driver). In an alternative embodiment in which conferencing system 100 performs hardware video decoding, an AVI display driver is also implemented on top of video/host interface 526.

The software architecture of conferencing system 100 comprises three major subsystems: video, audio, and communication. The audio and video subsystems are decoupled and treated as "data types" (similar to text or graphics) with conventional operations like open, save, edit, and display. The video and audio services are available to the applications through video-management and audio-management extended interfaces, respectively.

Conferencing system 100 is implemented mostly in the C++ computer language using the Microsoft.RTM. Foundation Classes (MFC) with portions implemented in the C7.0 computer language.

Audio/Video Conferencing Application

The description for this section is the same as the description for the section of the same name in U.S. patent application Ser. No. 08/340,171, filed Nov. 15, 1994, now abandoned.

CMIF.LIB

The description for this section is the same as the description for the section of the same name in U.S. patent application Ser. No. 08/340,171, filed Nov. 15, 1994, now abandoned.

CCm

The description for this section is the same as the description for the section of the same name in U.S. patent application Ser. No. 08/340,171, filed Nov. 15, 1994, now abandoned.

Loading and Unloading

The description for this section is the same as the description for the section of the same name in U.S. patent application Ser. No. 08/340,171, filed Nov. 15, 1994, now abandoned.

Registering and Unregistering

The description for this section is the same as the description for the section of the same name in U.S. patent application Ser. No. 08/340,171, filed Nov. 15, 1994, now abandoned.

Call Support

The description for this section is the same as the description for the section of the same name in U.S. patent application Ser. No. 08/340,171, now abandoned.

Channel Pair Support

The description for this section is the same as the description for the section of the same name in U.S. patent application Ser. No. 08/340,171, filed Nov. 15, 1994, now abandoned.

Stream Support

The description for this section is the same as the description for the section of the same name in U.S. patent application Ser. No. 08/340,171, filed Nov. 15, 1994, now abandoned.

CMDLL Callback

The description for this section is the same as the description for the section of the same name in U.S. patent application Ser. No. 08/340,171, filed Nov. 15, 1994, now abandoned.

NO VCI Support

The description for this section is the same as the description for the section of the same name in U.S. patent application Ser. No. 08/340,171, filed Nov. 15, 1994, now abandoned.

Miscellaneous

The description for this section is the same as the description for the section of the same name in U.S. patent application Ser. No. 08/340,171, filed Nov. 15, 1994, now abandoned.

CImageSize

The description for this section is the same as the description for the section of the same name in U.S. patent application Ser. No. 08/340,171, filed Nov. 15, 1994, now abandoned.

CImageState

The description for this section is the same as the description for the section of the same name in U.S. patent application Ser. No. 08/340,171, filed Nov. 15, 1994, now abandoned.

PSVIDEO.EXE

The description for this section is the same as the description for the section of the same name in U.S. patent application Ser. No. 08/340,171, filed Nov. 15, 1994, now abandoned.

Frame, View, and Image

The description for this section is the same as the description for the section of the same name in U.S. patent application Ser. No. 08/340,171, filed Nov. 15, 1994, now abandoned.

Class Descriptions

The description for this section is the same as the description for the section of the same name in U.S. patent application Ser. No. 08/340,171, filed Nov. 15, 1994, now abandoned.

CCyApp

The description for this section is the same as the description for the section of the same name in U.S. patent application Ser. No. 08/340,171, filed Nov. 15, 1994, now abandoned.

CCyFrameWnd

The description for this section is the same as the description for the section of the same name in U.S. patent application Ser. No. 08/340,171, filed Nov. 15, 1994, now abandoned.

CCyAppFrame

The description for this section is the same as the description for the section of the same name in U.S. patent application Ser. No. 08/340,171, filed Nov. 15, 1994, now abandoned.

CVideoFrame

The description for this section is the same as the description for the section of the same name in U.S. patent application Ser. No. 08/340,171, filed Nov. 15, 1994, now abandoned.

CVideoController

The description for this section is the same as the description for the section of the same name in U.S. patent application Ser. No. 08/340,171, filed Nov. 15, 1994, now abandoned.

Auto-Sizing of Video Windows

The description for this section is the same as the description for the section of the same name in U.S. patent application Ser. No. 08/340,171, filed Nov. 15, 1994, now abandoned.

Split and Combined Modes

The description for this section is the same as the description for the section of the same name in U.S. patent application Ser. No. 08/340,171, filed Nov. 15, 1994, now abandoned.

Control Channel Management

The description for this section is the same as the description for the section of the same name in U.S. patent application Ser. No. 08/340,171, filed Nov. 15, 1994, now abandoned.

Mute Message

The description for this section is the same as the description for the section of the same name in U.S. patent application Ser. No. 08/340,171, filed Nov. 15, 1994, now abandoned.

High-Quality Snapshot Message

The description for this section is the same as the description for the section of the same name in U.S. patent application Ser. No. 08/340,171, filed Nov. 15, 1994, now abandoned.

Application Launch

The description for this section is the same as the description for the section of the same name in U.S. patent application Ser. No. 08/340,171, filed Nov. 15, 1994, now abandoned.

Application Launch Response

The description for this section is the same as the description for the section of the same name in U.S. patent application Ser. No. 08/340,171, filed Nov. 15, 1994, now abandoned.

CChanPair

The description for this section is the same as the description for the section of the same name in U.S. patent application Ser. No. 08/340,171, filed Nov. 15, 1994, now abandoned.

Video View Class Relationships

The description for this section is the same as the description for the section of the same name in U.S. patent application Ser. No. 08/340,171, filed Nov. 15, 1994, now abandoned.

Handset Class Relationships

The description for this section is the same as the description for the section of the same name in U.S. patent application Ser. No. 08/340,171, filed Nov. 15, 1994, now abandoned.

Dialog Boxes

The description for this section is the same as the description for the section of the same name in U.S. patent application Ser. No. 08/340,171, filed Nov. 15, 1994, now abandoned.

Helper Classes

Dialog Helper

The description for this section is the same as the description for the section of the same name in U.S. patent application Ser. No. 08/340,171, filed Nov. 15, 1994, now abandoned.

Fast Bitmap Buttons

The description for this section is the same as the description for the section of the same name in U.S. patent application Ser. No. 08/340,171, filed Nov. 15, 1994, now abandoned.

Data Conferencing Application

The description for this section is the same as the description for the section of the same name in U.S. patent application Ser. No. 08/340,171, filed Nov. 15, 1994, now abandoned.

Conference Manager

The description for this section is the same as the description for the section of the same name in U.S. patent application Ser. No. 08/340,171, filed Nov. 15, 1994, now abandoned.

Conference Manager Overview

The description for this section is the same as the description for the section of the same name in U.S. patent application Ser. No. 08/340,171, filed Nov. 15, 1994, now abandoned.

Implementation Details

The description for this section is the same as the description for the section of the same name in U.S. patent application Ser. No. 08/340,171, filed Nov. 15, 1994, now abandoned. Additional information on the conference manager API is found in APPENDIX A of this specification.

Conference Application Installation

The description for this section is the same as the description for the section of the same name in U.S. patent application Ser. No. 08/340,171, filed Nov. 15, 1994, now abandoned.

Conference Application Registration

The description for this section is the same as the description for the section of the same name in U.S. patent application Ser. No. 08/340,171, filed Nov. 15, 1994, now abandoned.

VCI Call Handler Callback

The description for this section is the same as the description for the section of the same name in U.S. patent application Ser. No. 08/340,171, filed Nov. 15, 1994, now abandoned.

Channel Pair Establishment

The description for this section is the same as the description for the section of the same name in U.S. patent application Ser. No. 08/340,171, filed Nov. 15, 1994, now abandoned.

Critical Sections

The description for this section is the same as the description for the section of the same name in U.S. patent application Ser. No. 08/340,171, filed Nov. 15, 1994, now abandoned.

Call Notification and Caller ID

The description for this section is the same as the description for the section of the same name in U.S. patent application Ser. No. 08/340,171, filed Nov. 15, 1994, now abandoned.

Audible Call Progress

The description for this section is the same as the description for the section of the same name in U.S. patent application Ser. No. 08/340,171, filed Nov. 15, 1994, now abandoned.

On Demand Application Invocation

Referring now to FIG. 33, there is shown a flow diagram of the on-demand application invocation processing of conferencing system 100 of FIG. 5. The description for this section is the same as the description for the section of the same name in U.S. patent application Ser. No. 08/340,171, filed Nov. 15, 1994, now abandoned.

Managing Multiple Applications

Referring now to FIG. 34, there is shown a flow diagram of an example of the processing implemented within conferencing system 100 of FIG. 5 to manage two conferencing applications in a single conferencing session with a remote conferencing system. The description for this section is the same as the description for the section of the same name in U.S. patent application Ser. No. 08/340,171, filed Nov. 15, 1994, now abandoned.

Conferencing API

Referring now to FIG. 7, there is shown a block diagram of conference manager 544 and conferencing API 506 between conferencing applications 502 and 504, on one side, and comm API 508, LMI API 556, video API 510, and audio API 512, on the other side. The description for this section is the same as the description for the section of the same name in U.S. patent application Ser. No. 08/340,171, filed Nov. 15, 1994, now abandoned. Additional information on the conferencing API is found in APPENDIX B of this specification.

Interfacing with the Comm Subsystem

Conferencing API 506 supports the following comm services with the comm subsystem:

Comm initialization--initialize a session in the comm subsystem on which the call will be made.

Call establishment--place a call to start a conference.

Channel establishment--establish two comm channels for video conferencing control information, two comm channels for audio (incoming/outgoing), four comm channels for video (incoming data and control and outgoing data and control).

Call termination--hang up a call and close all active channels.

Comm Initialization/Uninitialization

Initialization of a session in the comm subsystem on which a call may be made by the user of conferencing system A of FIG. 1 and the user of conferencing system B of FIG. 1 is implemented as follows:

Conferencing APIs A and B call LMI.sub.-- AddLANTransport to initialize their LAN management interface (LMI) subsystems.

Conferencing APIs A and B receive a LMI.sub.-- ADDTRANS.sub.-- RESPONSE callback from the LMI subsystem.

Conferencing APIs A and B call BeginSession to initialize their comm subsystems.

Conferencing APIs A and B receive a SESS.sub.-- BEGIN callback from the comm subsystem.

Conferencing APIs A and B then notify the conferencing applications with a CFM.sub.-- INIT.sub.-- TRANSP.sub.-- NTFY callback.

Uninitialization of a session in the comm subsystem is implemented as follows:

Conferencing APIs A and B call LMI.sub.-- DeleteLANTransport to uninitialize their LAN management interface (LMI) subsystems.

Conferencing APIs A and B receive a LMI.sub.-- DELTRANS.sub.-- RESPONSE callback from the LMI subsystem.

Conferencing APIs A and B call EndSession to uninitialize their comm subsystems.

Conferencing APIs A and B receive a SESS.sub.-- CLOSED callback from the comm subsystem.

Conferencing APIs A and B then notify the conferencing applications with a CFM.sub.-- UNINIT.sub.-- TRANSP.sub.-- NTFY callback.

Call Establishment

Establishment of a call between the user of conferencing system A of FIG. 1 and the user of conferencing system B of FIG. 1 is implemented as follows:

Conferencing API A calls LMI.sub.-- RequestPermission to request permission to make the conference call from the management computer.

Conferencing API A receives a LMI.sub.-- PERM.sub.-- RESPONSE callback from the LMI subsystem. If permission is denied, conferencing API A notifies the conferencing application with a CFM.sub.-- REJECT.sub.-- NTFY callback. If permission is granted, establishment of the call is continued.

Conferencing API A calls LMI.sub.-- CallCommit to indicate to LMI that the call will be made.

Conferencing API A calls MakeConnection to dial conferencing API B's number.

Conferencing API B receives a CONN.sub.-- REQUESTED callback from the comm subsystem.

Conferencing API B calls LMI.sub.-- RequestPermission to request permission to accept the conference call from the management computer.

Conferencing API B receives a LMI.sub.-- PERM.sub.-- RESPONSE callback from the LMI subsystem. If permission is denied, conferencing API B rejects the call with RejectConnection, and notifies the conferencing application with a CFM.sub.-- DENIAL.sub.-- NTFY callback. If permission is granted, establishment of the call is continued.

Conferencing API B sends the call notification to the graphic user interface (GUI) with a CFM.sub.-- CALL.sub.-- NTFY callback; and, if user B accepts the call via the GUI, conferencing API B proceeds with the following steps.

Conferencing API B calls LMI.sub.-- CallCommit to indicate to LMI that the call will be accepted.

Conferencing API B calls AcceptConnection to accept the incoming call from conferencing API A.

Conferencing APIs A and B receive CONN.sub.-- ACCEPTED callback from the comm subsystem.

Conferencing API A calls OpenChannel to open its outgoing conferencing control channel.

Conferencing API B receives the CHAN.sub.-- REQUESTED callback for the incoming control channel and accepts it via AcceptChannel. Then conferencing API B calls OpenChannel to open its outgoing conferencing control channel.

Conferencing API A receives the CHAN.sub.-- ACCEPTED callback for its outgoing control channel and calls RegisterChanHandler to receive channel callbacks from the comm subsystem. Then conferencing API A receives the CHAN.sub.-- REQUESTED callback for the incoming control channel and accepts it via AcceptChannel.

Conferencing API B receives the CHAN.sub.-- ACCEPTED callback for its outgoing control channel and calls RegisterChanHandler to receive channel callbacks from the comm subsystem.

Conferencing API A sends a Login Request on the control channel, which conferencing API B receives.

Conferencing API B sends a Login Response on the control channel, which conferencing API A receives.

Conferencing APIs A and B negotiate conference capabilities between themselves. Capabilities that are negotiated include: negotiation protocol version, audio compression algorithm, video compression algorithm, video frame rate, video capture resolution, video bitrate, and data sharing capabilities.

Conferencing API A sends a Capabilities Request on the control channel, specifying conference requirements, which conferencing API B receives.

Conferencing API B sends a Capabilities Response on the control channel, accepting or modifying conference requirements, which conferencing API A receives.

When conferencing APIs A and B agree upon conference capabilities, the capabilities are saved and will be communicated to the application via the CFM.sub.-- ACCEPT.sub.-- NTFY callback.

Conferencing API A calls OpenChannel to open its outgoing audio channel.

Conferencing API B receives the CHAN.sub.-- REQUESTED callback for the incoming audio channel and accepts it via AcceptChannel.

Conferencing API A receives the CHAN.sub.-- ACCEPTED callback for the outgoing audio channel.

The last three steps are repeated for the video data channel and the video control channel.

Conferencing API B then turns around and repeats the above 4 steps (i.e., opens its outbound channels for audio/video data/video control).

Conferencing API A sends Participant Information on the control channel, which conferencing API B receives.

Conferencing API B sends Participant Information on the control channel, which conferencing API A receives.

Conferencing APIs A and B call LMI.sub.-- ConferenceCommit to indicate to LMI that the conference is in progress.

Conferencing APIs A and B then notify the conferencing applications with a CFM.sub.-- ACCEPT.sub.-- NTFY callback.

Channel Establishment

Video and audio channel establishment is implicitly done as part of call establishment, as described above, and need not be repeated here. For establishing other channels such as data conferencing, the conferencing API passes through the request to the comm manager, and sends the comm manager's callback to the user's channel manager.

Call Termination

Termination of a call between users A and B is implemented as follows (assuming user A hangs up):

Conferencing API A unlinks local/remote video/audio streams from the network.

Conferencing API A calls LMI.sub.-- ConferenceLeave to indicate to LMI that the conference is being closed.

Conferencing API A then calls the comm subsystem's CloseConnection.

The comm subsystem implicitly closes all channels, and sends CHAN.sub.-- CLOSED callbacks to the conferencing API A.

Conferencing API A closes its remote audio/video streams on receipt of the CHAN.sub.-- CLOSED callback for its inbound audio/video channels, respectively.

Conferencing API A then receives the CONN.sub.-- CLOSE.sub.-- RESP callback after the call is cleaned up completely. Conferencing API A notifies its conferencing application with a CFM.sub.-- HANGUP.sub.-- NTFY callback.

In the meantime, conferencing API B would have received the CHAN.sub.-- CLOSED callbacks from the comm subsystem for all the closed channels.

Conferencing API B closes its remote audio/video streams on receipt of the CHAN.sub.-- CLOSED callback for its inbound audio/video channels, respectively.

Conferencing API B unlinks its local audio/video streams from the network on receipt of the CHAN.sub.-- CLOSED callback for its outbound audio/video channels, respectively.

Conferencing API B then receives a CONN.sub.-- CLOSED callback from the comm subsystem.

Conferencing API B calls LMI.sub.-- ConferenceLeave to indicate to LMI that the conference is being closed.

Conferencing API B then notifies its conferencing application with a CFM.sub.-- HANGUP.sub.-- NTFY callback.

Interfacing with the Audio and Video Subsystems

The description for this section is the same as the description for the section of the same name in U.S. patent application Ser. No. 08/340,171, filed Nov. 15, 1994, now abandoned.

Capture/Monitor/Transmit Local Streams

The description for this section is the same as the description for the section of the same name in U.S. patent application Ser. No. 08/340,171, filed Nov. 15, 1994, now abandoned.

Receive/Play Remote Streams

The description for this section is the same as the description for the section of the same name in U.S. patent application Ser. No. 08/340,171, filed Nov. 15, 1994, now abandoned.

Control Local/Remote Streams

The description for this section is the same as the description for the section of the same name in U.S. patent application Ser. No. 08/340,171, filed Nov. 15, 1994, now abandoned.

Snap an Image from Local Video Streams

Referring now to FIG. 8, there is shown a representation of the conferencing call finite state machine (FSM) for a conferencing session between a local conferencing system (i.e., caller) and a remote conferencing system (i.e., callee). Referring now to FIG. 9, there is shown a representation of the conferencing stream FSM for each conferencing system participating in a conferencing session. The description for this section is the same as the description for the section of the same name in U.S. patent application Ser. No. 08/340,171, filed Nov. 15, 1994, now abandoned. Differences include changes to the CF.sub.-- Init function and new functions CF.sub.-- Uninit, CF.sub.-- InitTransport, CF.sub.-- UninitTransport, and CF.sub.-- ChangeTransportMaxVideoBitrate, as follows:

    ______________________________________
    CF.sub.-- Init     Initializes the LAN management
                       interface (LMI), audio and video
                       subsystems, and initializes data
                       structures required for
                       conferencing.
    CF.sub.-- Uninit   Uninitializes the LMI, audio,
                       and video subsystems.
                       If a conference
                       call is in progress, it is
                       gracefully destroyed.
    CF.sub.-- InitTransport
                       Initializes a LAN or ISDN
                       transport stack so that
                       conference calls may be
                       made or received on a
                       particular transport type.
                       The maximum video bitrate
                       allowed on this transport is
                       specified.
    CF.sub.-- UninitTransport
                       Uninitializes a transport
                       stack, so calls may
                       no longer be made or
                       received on a particular
                       transport type.
    CF.sub.-- ChangeTransportMaxVideoBitrate
                       Changes the maximum video
                       bitrate allowed on a transport.
    ______________________________________

    ______________________________________
    CFM.sub.-- INIT.sub.-- TRANSP.sub.-- NTFY
                     Indicates that transport stack
                     initialization has completed
                     successfully or unsucessfully.
    CFM.sub.-- UNINIT.sub.-- TRANSP.sub.-- NTFY
                     Indicates that transport stack
                     uninitialization has completed.
    CFM.sub.-- UNINIT.sub.-- NTFY
                     Indicates that the conferencing API
                     subsystem uninitialization
                     has completed.
    CFM.sub.-- DENIAL.sub.-- NTFY
                     Indicates that a call request initiated
                     from the remote site has
                     been received,
                     but the local site was denied
                     permission to accept the call by the
                     management computer.
    CFM.sub.-- ERROR.sub.-- NTFY
                     Indicates that an error has occurred in
                     the comm subsystem.
    CFM.sub.-- KILL.sub.-- NTFY
                     Indicates that the management
                     computer has demanded the con-
                     ference call be terminated.
    ______________________________________

    ______________________________________
    CUSTOM.sub.-- SET.sub.-- DATA.sub.-- RATE
                       Sets the data rate of the
                       communications channel.
    CUSTOM.sub.-- SET.sub.-- FPS
                       Sets the desired capture
                       frame rate.
    CUSTOM.sub.-- SET.sub.-- QUAL.sub.-- PERCENT
                       Sets the minimum image quality
                       value (IRV only).
    CUSTOM.sub.-- SET.sub.-- MOTION.sub.-- EST
                       Enables or disables motion
                       estimation (MRV only).
    CUSTOM.sub.-- SET.sub.-- SPATIAL.sub.-- FILT
                       Enables or disables spatial
                       filtering (MRV only).
    CUSTOM.sub.-- SET.sub.-- TEMPORAL.sub.-- FILT
                       Sets the level of tem-
                       poral filtering (MRV only).
    ______________________________________

    __________________________________________________________________________
    DRV.sub.-- LOAD
            Reads any configuration parameters associated with the driver.
            Allocates any
            memory required for execution. This call is only made the first
            time the driver is
            opened.
    DRV.sub.13 ENABLE
            Ensures that an audio/comm board is installed and functional. For
            audio/comm
            board 206 of FIG. 2, this means the DSP interface 532 is
            accessible. This call is
            only made the first time the driver is opened.
    DRV.sub.-- OPEN
            This call is made each time OpenDriver is called. The audio
            manager can be opened
            once for input, once for output (i.e., it supports one full
            duplex conversation), and
            any number of times for device capablilities query. This call
            allocats the per
            application data. This includes information such as the callback
            and the application
            instance data and buffers for transferring audio between the host
            and the audio
            board for LAN connections. If this is an input or output call, it
            starts the DSP audio
            task and sets up communication between host and DSP audio task
            (e.g. setup mail
            boxes, register callbacks). If this is the first open of an input
            or output stream, it
            starts the commstub task.
    __________________________________________________________________________

    ______________________________________
    DRV.sub.-- CLOSE
                 Frees the per application data allocated in
                 DRV.sub.-- OPEN message.
    DRV.sub.-- DISABLE
                 Ignored.
    DRV.sub.-- FREE
                 Ignored
    ______________________________________

    ______________________________________
           typedef struct.sub.-- ALinkStruct {
           BOOL           ToLink;
           CHANID         ChanId;
           } ALinkStruct, FAR * 1pALinkStruct;
    ______________________________________

    ______________________________________
           typedef struct.sub.-- ALinkStruct {
           BOOL           ToLink;
           CHANID         ChanId;
           } ALinkStruct, FAR * 1pALinkStruct;
    ______________________________________

    ______________________________________
    ALINKIN.sub.-- TMSG:
                   Connects/disconnects the audio task with
                   a virtual circuit supported by the
                   network task. The local and
                   remote channel
                   IDs (valid on the board) are
                   passed to the audio task in the first two
                   DWORDs of the dwArgs array.
                   The flag specifying whether to link or
                   unlink is passed in the third DWORD.
    ALINKIN.sub.-- HOST.sub.-- TMSG:
                   Connects/disconnects the audio task with
                   the commstub task to receive
                   audio to the host. The flag specifying
                   whether to link or unlink is passed to
                   the audio task in the third DWORD
                   of the dwArgs array. The first two
                   DWORDS are ignored.
    ALINKOUT.sub.-- TMSG:
                   Connects the audio task with a virtual
                   circuit supported by the network
                   task. The local and remote channel
                   IDs (valid on the board) are passed to
                   the audio task in the first two DWORDs
                   of the dwArgs array. The flag
                   specifying whether to link or unlink is
                   passed in the third DWORD.
    ALINKOUT.sub.-- HOST.sub.-- TMSG:
                   Connects the audio task with a virtual
                   circuit supported by the network
                   task. The flag specifying whether
                   to link or unlink is passed to the audio
                   task in the third DWORD
                   of the dwArgs array. The
                   first two DWORDS are ignored.
    ______________________________________

    ______________________________________
    #define AS.sub.-- CAPTURE.sub.-- PIPE "/null"
    #define AS.sub.-- PLAYBACK.sub.-- PIPE "/null2"
    #define AS.sub.-- HOST.sub.-- CAPTURE.sub.-- PIPE "/null3"
    ______________________________________

    ______________________________________
           driver NULLDEV.sub.-- driver {
           "/null":      devid = 0;
           "/nu112":     devid = 1;
           "/null3":     devid = 2;
           };
    ______________________________________