Video messaging arrangement

<u>Technical Field</u>

0001This invention relates to telecommunications messaging systems.

<u>Background of the Invention</u>

0002Single-media and multi-media messaging, wherein users create and send or leave voice, binary data, fax, etc. messages for recipients to or in the recipients' mailboxes in the telephone network, are well known in the art. The addition of video as a messaging medium to the existing messaging media creates certain difficulties, however. For purposes of this discussion, video communications include moving pictures, moving pictures with synchronized audio, shared whiteboard, shared applications, or any other communications that include moving images. The difficulties do not arise within the messaging systems themselves --multi-media messaging systems are often internally capable of handling video objects (that is, portions or components of the message that are represented in the video medium) as a direct extension of the manner in which they handle any one or more of the voice objects, binary data objects, fax objects, etc. Rather, the difficulties arise in the interfaces to the messaging systems. Firstly, while video messages and multi-media messages that include video components may be transmitted through telephone networks as video calls, many telephone switching systems do not have the capability of redirecting video calls to coverage. They therefore lack the ability to redirect video calls from their original intended destinations to messaging systems. This prevents the messaging systems from serving one of their principal functions, which is to provide coverage for calls that go unanswered at their destinations. And secondly, even if the switching systems are able to redirect video calls, most existing messaging systems lack the special port circuits that are needed to receive video calls and to play out recorded video messages through the telephone system. Hence, adapting of existing messaging systems to make them capable of serving video messages generally requires extensive and expensive redesign of their telephony interfaces.

0003Local area networks (LANs) and wide area networks (WANs) often provide the capability of transporting files of video information between workstations, and between workstations and network servers, that are connected to the networks, in substantially the same manner as they provide for the exchange of electronic mail (e-mail) messages. While there are substantially no difficulties that arise in these systems as a consequence of the messages including video objects, these systems have inherent limitations that do not make them suitable substitutes for telephony-based messaging systems. First, most of the LAN-based or WAN-based messaging systems also lack message redirection capability. Second, they provide access to messages exclusively through video terminals, as opposed to telephony-based integrated multi-media messaging systems that normally provide access to messages (or at least to message headers and a subset of the media objects of the message) through a variety of terminals, such as PCs, fax machines, telephones, data terminals, etc. And third, they are typically feature-poor, relative to the telephony-based messaging systems, in terms of the number and types of features that they offer to users for creating, retrieving, sending, and receiving of messages. Therefore, extending the capabilities of the LAN-and WAN-based messaging systems to match the capabilities of telephony-based messaging system would be an extensive and an expensive development effort.

<u>Summary of the Invention</u>

0004This invention is directed to solving these and other problems and disadvantages of the prior art. According to an implementation of the invention, a video terminal is employed to perform functions, such as answering of video calls and recording of video messages, on behalf of a telephony messaging system which cannot itself perform those functions, while the telephone messaging system is employed to perform functions, such as providing a rich set of messaging features and providing telephony access from a variety of different types of telephony terminals to at least portions of the video messages, on behalf of the video terminals which cannot themselves perform those functions. This implementation of the invention interfaces video terminals by means of a LAN or a WAN to a telephony multi-media messaging system to provide the telephony messaging system with the ability to receive and transmit video messages, and conversely the telephony multi-media messaging system provides the features and capabilities of conventional telephony-based messaging systems to video messages conveyed via the LAN or WAN. Consequently, the telephony messaging system is made capable of serving video messages without extensive and expensive redesign of its telephony interface, and the messaging capabilities and features of telephony-based messaging systems are extended to LAN-and WAN-based messaging without extensive and expensive development effort. Video messaging and telephony multi-media messaging are thus integrated with a minimum of effort and cost. The result, from the users' viewpoint, is a universal mailbox: one location for accessing all messages regardless of what network delivered the messages, what media the messages are represented in, and what instruments or mechanisms are used to access the messages. This is a significant improvement over conventional messaging arrangements that typically use separate delivery, storage, and access mechanisms for at least video messages and messages represented in other media types.

0005Generally according to the invention, a video messaging system is configured as follows. A multi-media message server is connected to both a LAN or a WAN (or some other video communications network) and at least one telephone line. The multi-media message server (such as a telephony multi-media messaging system, for example) stores messages that have a plurality of message portions, and at least some of those message portions may be represented in any one of a plurality of different media, including a video medium. (An illustrative structure of such a message is shown in FIG. 2.) In other words, the multi-media message server can handle video objects. The multi-media message server has a first interface connected to the at least one telephone line for providing access over the at least one telephone line to at least some portions of the messages stored in the multi-media message server. This is illustratively the conventional telephony messaging interface. The multi-media message server has a second interface connected to the video communications local area or wide area network for receiving video messages (i.e., messages having portions represented in the video medium) via the video communications network and storing them in the multi-media message server, and also for retrieving the stored video messages and transmitting them via the video communications network. Furthermore, one or more video communications terminals are connected to the video communications network. The video communications terminals are, for example, video workstations. At least a first one of the video communications terminals handles video communications incoming to the first terminal and which an intended recipient of the video communications has not answered (illustratively, either at the first terminal itself, or at another video terminal from which the video communication has been forwarded). Illustratively, an unanswered incoming video communication may be incoming to the first terminal either via the video communications network (for example, from one of the other video communications terminals), or via a video communications line, such as an ISDN telephone line, that is connected to the first terminal (for example, from some remote video caller). The first terminal includes means for answering the incoming video communication and recording a video message component from the video communication. The first terminal further includes means responsive to the recording, for transmitting the recorded video message via the video communications network to the multi-media message server, and causing the second interface of the multi-media message server to receive and store the transmitted video message in the multi-media message server. (This is illustratively the call-answer scenario shown in FIG. 3.) At least a second one of the video communications terminals includes means for causing the second interface of the multi-media message server to retrieve and transmit the stored video message, and for receiving the video message transmitted from the multi-media message server via the video communications network for presentation of the received video message to a user of the second terminal. (This is illustratively the message-retrieval scenario shown in FIG. 4.) The first and second terminals may be different terminals, or they may be the same terminal. Preferably, one or more of the video communications terminals include means for a user of the terminal to create a video message on the terminal, sending the created message via the video communications network to the multi-media message server, and causing the second interface of the multi-media message server to receive and store the sent message in one or more mailboxes in the multi-media message server. (This is illustratively the mail-message scenario shown in FIG. 5.)

0006A message server and a video communications terminal for use in such a video messaging system are also characterized.

0007A video messaging system configured in the manner characterized above may advantageously be constructed from substantially conventional elements or may be retrofitted into conventional messaging infrastructure without extensive redesign or modification of the elements or infrastructure. This allows video messaging having telephony-like messaging features and capabilities to be implemented with minimal effort and at low cost.

0008These and other advantages and features of the invention will become more apparent from the following description of an illustrative embodiment of the invention taken together with the drawing.

<u>Brief Description of the Drawing</u>

0009<ul id="ul0001" list-style="none" compact="compact"><li>FIG. 1 is a block diagram of a telecommunications system which includes a first illustrative embodiment of the invention;</li><li>FIG. 2 is a block diagram of a multi-media message of the system of FIG. 1;</li><li>FIG. 3 is a block diagram of a call-answer scenario of the system of FIG. 1;</li><li>FIG. 4 is a block diagram of a message-retrieval scenario of the system of FIG. 1;</li><li>FIG. 5 is a block diagram of a mail-message scenario of the system of FIG. 1;</li><li>FIG. 6 is a flow diagram of operations of a workstation of the system of FIG. 1 involved in the call-answer scenario of FIG. 3;</li><li>FIG. 7 is a flow diagram of the operations involved in "Put large" and "Get large" commands in the system of FIG. 1;</li><li>FIG. 8 is a flow diagram of operations of a workstation of the system of FIG. 1 involved in the message-retrieval scenario of FIG. 4;</li><li>FIG. 9 is a flow diagram of operations of a workstation of the system of FIG. 1 involved in the mail-message scenario of FIG. 5;</li><li>FIG. 10 is a block diagram of a telecommunications system which includes a second illustrative embodiment of the invention; and</li><li>FIGS. 11-13 illustrate the messaging graphical user interface of a workstation of the system of FIG. 1.</li></ul>

<u>Detailed Description</u>

0010FIG. 1 shows a block diagram of an illustrative telecommunications system constructed according to the principles of the invention. In keeping with the objective of the invention to avoid extensive redesign or modification of existing infrastructure, all of the system hardware is conventional. The invention lies in this illustrative embodiment in the interconnection of the hardware and in video-handling enhancements to their conventional software.

0011The system of FIG. 1 includes one or more video communications workstations 103-105. These are, illustratively, the AT&amp;T Vistium® station, the Intel Proshare station, or a conventional UNIX® operating system workstation equipped with the Insoft Communique! software and video processing boards. Each station 103-104 includes a video display screen 130, a video camera 132, loudspeakers 131, and a microphone 133. These are connected to media processing circuits 138, which are illustratively implemented as digital signal processors (DSPs). An integrated services digital network (ISDN) port 136 couples each video workstation 103-105 to a respective one of telephone ISDN lines 153-155. ISDN lines 153-155 connect the video workstations 103-104 to a network 170 --such as the public telephone network, a private telephone network, or some other network --for purposes of transmitting and receiving telecommunications, including video communications. The video workstation further includes a general-purpose processor 135, and a memory 137 that stores programs for execution and data for use by processor 135. A local area network (LAN) interface 134 connects at least some video workstations 103-104 to a LAN 100, or alternatively to a wide area network (WAN). Video workstations 103-104 can communicate with each other over LAN 100, including placing video calls to each other over LAN 100. LAN 100 illustratively implements the terminal control protocol/internet protocol (TCP/IP).

0012The system of FIG. 1 further includes a multi-media messaging system 101. Messaging system 101 is illustratively either the AT&amp;T Intuity® system or the AT&amp;T Definity® Audix® system. These systems structure a multi-media message 700 in the manner shown in FIG. 2. Message 700 has a message header component 701 that comprises a plurality of header elements 702. Each element 702 provides some information about the message, such as who it is for, who it is from, whether it is a private or a priority message, and what message-body components it contains. Message 700 further has a message body 703 that contains one or more message-body components 704 each expressed in a different medium. Supported media include voice, text, fax, binary data, and video. The video component of the message can contain moving pictures, moving pictures with synchronized audio, shared whiteboard, shared applications, or any other communications that include moving images. Message-body components 704 are usually separate files that are linked to message header component 701 by pointers.

0013Returning to FIG. 1, messaging system 101 includes a mass memory 111 that implements a plurality of message mailboxes 120-121 for messaging service subscribers, at least some of whom are also users/owners of video workstations 103-104. Messaging system 101 further includes a processor 112, and a memory 113 that stores programs for execution and data for use by processor 112. A plurality of DSP-based voice and Touch-Tone ports 114-115 couple system 101 to a plurality of telephone lines 164-165 by means of which callers and subscribers can access messaging system 101 in the conventional manner. A LAN interface 110 connects messaging system 101 to LAN 100.

0014The system of FIG. 1 also preferably includes an adjunct mass store 102. Mass store 102 is illustratively a disk-storage system controlled by the UNIX® operating system. It functions as an adjunct to messaging system 101 to extend the capacity of mass memory 111. Conventional network file system (NFS) connectivity between messaging system 101 and mass store 102 turns mass memory 122 into an extension of mass memory 111. Mass store 102 includes a mass memory 122, a processor 123, a memory 124 that stores programs for execution and data for use by processor 123, and a LAN interface 125 that connects mass store 102 to LAN 100.

0015The software of messaging system 101 includes a voice session controller (VSC) 118 that implements a conventional Touch-Tone user interface to messaging system 101 over telephone lines 164-165. The software also includes an application database (ADATA) 117, which is a database mechanism that implements a messaging database, including mailboxes 120 and 121. ADATA 117 includes video as one of its defined message media objects, along with audio, fax, binary data, and any other media objects that are defined for messaging system 101. The software of messaging system 101 further includes an application interaction server (AIS) 116, which functions as a TCP/IP remote procedure call (RPC) server for communications over LAN 100 to and from messaging system 101.

0016The software of adjunct mass store 102 includes a video file transfer process (VFT) 126. VFT 126 communicates with AIS program 116 over LAN 100 and responds to its requests to either accept video files from messaging system 101 for storage in mass memory 122 or retrieve stored video files from mass memory 122 for return to messaging system 101.

0017The software of video workstations 103-104 includes a multi-media messaging application program interface (MMAPI) 140, which implements communications between the video workstations and AIS 116 of messaging system 101. Communications between MMAPI 140 and messaging system 101 are implemented as TCP/IP RPCs using the conventional client/server request/response model of interaction. MMAPI 140 includes video file transfer among its file transfer capabilities, along with audio file transfer, binary data file transfer, and file transfer capability of any other desired media. If messaging system 101 is the Intuity system or the Definity Audix system, MMAPI 140 is preferably a version of the AT&amp;T Intuity MAPI (IMAPI) or AT&amp;T Audix MAPI (AMAPI). The IMAPI or AMAPI is a TCP/IP RPC implementation which supports access to the Intuity or Audix system from client application processes that are interconnected with the Intuity or Audix system by a LAN or a WAN. The IMAPI or AMAPI interface is specified as a set of C-language function calls, either in a standard UNIX system archive or library on UNIX® operating system client machines, or in a Dynamic Link Library (DLL) on Windows® or OS/2® operating system client machines.

0018The software of video workstations 103-104 also includes a message manager (MM) 141 that implements a graphical user interface (GUI) for a user of video workstation 132 to messaging system 101. Like ADATA 117 of messaging system 101, MM 141 includes video as one of its defined message media objects. If messaging system 101 is the Intuity system or the Definity Audix system, MM 141 is preferably a version of the AT&amp;T Intuity Message Manager application. FIGS. 11-13 illustrate the interface that the Intuity Message Manager presents to the user. FIG. 11 shows message retrieval. FIG. 12 shows message playback. And FIG. 13 shows mail-message creation.

0019The software of video workstations 103-104 further includes a video call answer agent (VCAA) 143 which interacts with ISDN port 136 to answer video calls incoming over the respective one of ISDN lines 153-154 that are not answered by the users of video workstations 103-104. VCAA 143 implements in software an answering machine for video calls at workstations 103-104.

0020Finally, the software of video workstations 103-104 includes a video control application program interface (VCAPI) 142. VCAPI 142 implements the ability to record video from camera 132 or ISDN line 153 into a file in memory 137 and to play video from a file in memory 137 on display 130 or ISDN line 153. VCAPI 142 is illustratively either the Lotus ScreenCam multimedia screen and sound capture utility, or the AT&amp;T Vistium software developer kit, or the Insoft Communique! developer's toolkit.

0021Configured as described above, the telecommunications system of FIG. 1 enables messaging system 101 to provide video messaging services for video workstations 103-104. Specifically, it enables messaging system 101 to support the call scenarios of FIGS. 3-5. FIG. 3 shows an illustrative call-answer scenario. A video call from video workstation 104 comes to video workstation 103 over ISDN line 153 or LAN 100, and the call either gets a busy indication or is not answered by the user of workstation 103 within a predetermined time. Workstation 103 provides call coverage for the user. It answers the call, records a video message, and sends the recorded message to MMMS 101 for storage in the user's mailbox. FIG. 4 shows an illustrative message-retrieval scenario. When a video message is stored in the mailbox of the user of workstation 103 in MMMS 101, the user can use workstation 103 to access MMMS 101 via LAN 100, retrieve the message, and view it on workstation 103. Or, the user can access MMMS 101 by telephone over a telephone line 169 and retrieve the video message's header and non-video components. FIG. 5 shows an illustrative mail-message scenario. The user of workstation 103 can create a video message on workstation 103 and then transfer it via LAN 100 to MMMS 101 and cause MMMS 101 to store copies of the message in one or more mailboxes.

0022The call-answer scenario is effected in the manner shown in FIG. 6 and described below. References below to software performing certain functions will be understood to mean a processor performing those functions in response to executing the named software.

0023When a call incoming either on LAN 100 or on ISDN line 153 is answered, it is handled in the conventional manner by application software of video workstation 103. However, when the call is not answered by the user of video workstation 103 within a predetermined period of time, execution of VCAA 143 is invoked, at step 300. VCAA 143 invokes MMAPI 140 to access messaging system 101 and interact through AIS 116 with ADATA 117 to cause ADATA 117 to return the personal greeting that is stored in mailbox 120 of the user of video workstation 103, at step 302. MMAPI 140 stores the returned personal greeting in a temporary file in memory 137, at step 304. VCAA 143 then answers the call on ISDN line 153 or LAN 100, at step 306. VCAA 143 invokes VCAPI 142 to play out the personal greeting from the temporary file onto ISDN line 153 through ISDN port 136 or onto LAN 100 through LAN interface 134, at step 308. VCAA 143 then waits for the caller to either hang up the call or to record a message, at step 310. If the caller hangs up, execution of VCAA 143 ends, at step 312. If the user chooses to record a message, VCAA 143 stores information about the call, such as date, time, and caller identification, at step 314, and invokes VCAPI 142 to record and store the message in a temporary file in memory 137, at step 316. When the caller completes recording and hangs up, VCAPI 142 reports additional information about the message, such as its length and what media components it includes, to VCAA 143, at step 318. VCAA 143 again invokes MMAPI 140 to access messaging system 101 and interact through AIS 116 with ADATA 117 to create a header for the message in mailbox 120 from the information stored about the call and message by VCAA 143 at step 320. VCAA 143 further causes MMAPI 140 to interact through AIS 116 with ADATA 117 to transfer the message from the temporary file in memory 137 into mailbox 120, at step 322. Execution of VCAA 143 then ends, at step 324.

0024If MMAPI 140 is the Audix MAPI or Intuity MAPI, a file transfer from video workstation 103 to messaging system 101 is normally accomplished using the AMAPI or IMAPI "Put" command, which effects the transfer in individual 8-kilobyte chunks over LAN 100. Since video files tend to be large, their transfer can take many individual 8-kilobyte transfers and adversely affect the performance of AIS 116. To alleviate this problem, the AMAPI or IMAPI is enhanced to provide a "Put large" command for transferring large files.

0025The "Put large" command is diagrammed in FIG. 7. It relies upon the standard socket (logical port) mechanism of the TCP/IP UDP datagram protocol. When MMAPI 140 issues the "Put large" command for the first time, at step 400, the UDP mechanism creates a socket for video workstation 103 on LAN 100, at step 402. This socket is then reused for all subsequent 'large" commands issued by MMAPI 140. The command issued at step 400 includes the socket's address, and a message ID of the video file. AIS 116 receives the "Put large" command, at step 404, and in response validates the request and gets a filename that corresponds to the received message ID from ADATA 117, at step 405. AIS 116 then creates a record in shared memory (a portion of memory 113 that is accessible to, and hence is shared with, processor 123 of mass store 102), at step 406, in which it stores the address of the socket of workstation 103 and the filename of a file in mass memory 122 which it obtained from ADATA 117, at step 408. AIS 116 then sends an acknowledgment of the "Put large" command to MMAPI 140, at step 410, that conveys to MMAPI 140 the record index of the record created at step 406. MMAPI 140 receives the acknowledgement, at step 412, and in response, it makes a standard TCP/IP Intemet service request containing the record index at the socket of workstation 103 on LAN 100, at step 414. The request is received by the standard RPC "Bind" process of the UNIX operating system of mass store 102, at step 416. If this is the first time that such a request has been received, the RPC mechanism creates a socket for mass store adjunct 102 on LAN 100, at step 417. This socket is then reused for all subsequent requests. In response to receipt of the request, processor 123 creates ("spawns") a copy of VFT 126 to serve the request, at step 418.

0026The copy of VFT 126 uses the record index to access the record in the shared memory portion of memory 113 and retrieves from the record the address of the workstation 103 socket and the filename, at step 420. The copy of VFT 126 then interacts with MMAPI 140 through the sockets of video workstation 103 and mass store adjunct 102 in a sequence of repeated reads, writes, and acknowledgments of data, using standard TCP/IP UDP datagrams, until an end-of-file is encountered, to effect the file transfer between workstation 103 and mass store adjunct 102, and stores the file in mass memory 122 under the filename designated by AIS 116 in the retrieved record, at steps 422 and 424. When the file transfer is completed, the copy of VFT 126 that was created to accomplish this transfer is destroyed, at step 426.

0027With the "Put large" command available to it, MMAPI 140 uses the "Put" command to transfer the message header information and the non-video portions of the message to messaging system 101, at steps 320 and 322 of FIG. 6, and uses the "Put large" command to transfer the video portion of the message to MMMS 101 or mass store 102, at step 322 of FIG. 6.

0028Once the message is stored either in its entirety in messaging system 101, or partly in messaging system 101 and partly in mass store 102, the subscriber/owner of mailbox 120 has conventional access to all parts of the message, except for the video object, via telephone lines 164 and any instrumentalities (e.g. telephones, terminals) associated therewith. To gain access to the video object of the message, the subscriber must use video workstation 103. The subscriber can also access the entire message through video workstation 103.

0029To obtain access to his or her mailbox 120 at video workstation 103, the subscriber/owner of mailbox 120 invokes execution of MM 141, at step 500 of FIG. 8. MM 141 responds by presenting a user menu to the subscriber on the display screen of video workstation 103, at step 502. The subscriber makes a selection from the menu and MM 141 receives it, at step 504, and checks whether it is a request to terminate execution of MM 141, at step 506. If so, MM 141 proceeds to step 528 to terminate; if not, MM 141 checks whether the request is to display message headers waiting for retrieval in the subscriber's mailbox or some other request, at step 508. If it is some other request, MM 141 undertakes to perform the selected action in a conventional manner, at step 510, and then returns to step 502. If the request is a request to display message headers, MM 141 invokes MMAPI 140 to access messaging system 101 and interact through AIS 116 with ADATA 117 to cause ADATA 117 to return the headers of messages stored in mailbox 120, at step 512. MM 141 then presents the headers to the user via display 130, at step 514. If the user decides to retrieve one of the messages 120 and so indicates to MM 141, at step 516, MM 141 responds by again invoking MMAPI 140 to access messaging system 101 and interacting through AIS 116 with ADATA 117 to retrieve the message body components from mailbox 120, at step 518, and stores them in a temporary file in memory 137, at step 520. If the message includes a video component, MM 141 invokes VCAPI 137 to present (play) the video component to the user through display 130 and speakers 131, at step 522. If the user decides to act upon the message in some way, such as to forward it to another user's mailbox 121 or to delete it from mailbox 120, the user informs MM 141, at step 524, and MM 141 responds by invoking MMAPI 140 to interact through AIS 116 with ADATA 117 to cause ADATA 117 to undertake the desired action, at step 526. MM 141 then returns to step 502.

0030If MMAPI 140 is the Audix MAPI or Intuity MAPI, a file transfer from messaging system 101 is normally accomplished using the AMAPI or IMAPI "Get" command which, like the above-described "Put" command, effects the transfer in individual 8-kilobyte chunks, with the same deleterious affect on the performance of AIS 116. To alleviate this problem, the AMAPI or IMAPI is enhanced to provide a "Get large" command for transferring large files. Except for the direction of file transfer, the "Get large" command works the same way as the "Put large" command, and hence is also diagrammed in FIG. 7 and described by the accompanying description.

0031The user of workstation 103 can also create a mail message in his or her mailbox 120 and then send it to a mailbox 121 of another user. To do so, the user of workstation 103 invokes MM 141, at step 600 of FIG. 9, and selects message creation, at step 604, from the user menu presented by MM 141 at step 602. In response, MM 141 invokes VCAPI 142 to record the user's message, using camera 132 and microphone 133, into a temporary file in memory 137, at step 606. When the recording is completed, VCAPI 142 gives information about the message, such as its length and what media objects it contains, to MM 141, at step 608, and exits. MM 141 now invokes MMAPI 140 to access messaging system 101 and interact through AIS 116 with ADATA 117 to transfer the message from the temporary file in memory 137 into mailbox 120, at step 610. If the message has a video object, "Put large" is used to accomplish the transfer, in the manner described previously. MM 141 also uses MMAPI 140 to interact through AIS 116 with ADATA 117 to create a header for the message, step 612, to invoke any desired features for the message (e.g., "make private" or "priority"), at step 614, and to address the message and schedule it for delivery, at step 616. The user may then terminate MM 141 at the user's option, at step 618.

0032A drawback of the implementation illustrated in FIG. 1 is that it does not readily allow for a caller who has reached either a powered-down or a busy video workstation 103-104, or who has called a video workstation that is disconnected from the system of FIG. 1. A way to implement this capability is to designate at least one of the workstations 103-104 to act as a messaging server (essentially an answering machine) on behalf of other workstations in the system of FIG. 1, and to redirect to it all calls that go unanswered at the destination workstations 103-104 for longer than a predetermined amount of time. In the case of calls incoming on ISDN lines 153-154, such redirection may be accomplished by a switching system with video-Call redirection capability --such as an AT&amp;T 5ESS® switching system-- that is a part of network 170. In the case of calls incoming on LAN 100, such redirection may be accomplished by the server workstation itself monitoring all call-origination traffic on LAN 100 and taking on itself the identity, with respect to LAN 100, of any non-answering workstation.

0033Instead of using a plurality of video workstations as servers, an alternative embodiment is shown in FIG. 10. Here, a video call server 200 is added to the system of FIG. 1. (Elements in FIG. 10 that are the same as in FIG. 1 retain the same numerical designations as in FIG. 1). Video call server 200 is a stored-program-controlled machine that includes a processor 205 for executing programs, a memory 203 that stores programs for execution and data for use by processor 205, and a mass memory 204 for storing video messages. Mass memory 204 serves the function of adjunct mass store 102 of FIG. 1, and hence adjunct mass store 102 is not needed in the system of FIG. 6. Video call server 200 includes database manager (DBM) 208 software that implements NFS connectivity between messaging system 101 and mass memory 204 to turn mass memory 204 into an extension of mass memory 111. Illustratively, DBM 208 need involve no more than the conventional database management functions of the UNIX operating system kernel (i.e., the basic UNIX file system read/write/directory access functionality). Video call server 200 includes a plurality of ISDN ports 201-202, each one of which is an equivalent of ISDN port 136 of video workstation 103. ISDN ports 201-202 are connected by respective ISDN lines 211-212 to network 170 that includes a switching system with video call-redirection capability. Video call server 200 is connected to LAN 100 by a LAN interface 206 that is an equivalent of LAN interface 110 of messaging system 101. For communicating with messaging system 101, video call server includes MMAPI 207 that is an equivalent of MMAPI 140.

0034Video call server 200 answers all calls that are not answered at workstations 103-104 within a predetermined period of time. Hence, workstations 103-104 no longer need VCAA 103. For this purpose, video call server 200 includes a video session controller (VSC) 209. Functionally, VSC 209 is equivalent to multiple copies of VCAA 143 and VCAPI 142, whereby multiple ports 201-202 may be served at the same time.

0035Of course, various changes, modifications, and extensions to the illustrative embodiment described above will be apparent to those skilled in the art. For example, network 170 may be an ATM network instead of an ISDN network. Such changes and modifications can be made without departing from the spirit and the scope of the invention and without diminishing its attendant advantages. It is therefore intended that such changes and modifications be covered by the following claims.