WO2002039681A1

WO2002039681A1 - Unified communications client

Info

Publication number: WO2002039681A1
Application number: PCT/US2001/044106
Authority: WO
Inventors: Terence White; David Sullivan; Aurelio Arcese; John Jamieson
Original assignee: Ip Blue Llc
Priority date: 2000-11-10
Filing date: 2001-11-05
Publication date: 2002-05-16
Also published as: EP1340346A4; EP1340346A1; WO2002039681A9; AU2002217859A1

Abstract

A configurable computer telephony application that supports multiple lines of data/voice communication with terminals (5-10) operating in heterogeneous packet and circuit switched networks. The application includes a graphical interface (100a). Telecommunication commands (100) are processed and converted into messages, and data is input to perform a plurality of call processing and data management services.

Description

UNIFIED COMMUNICATIONS CLIENT

FIELD OF THE INVENTION

The present invention relates to telecommunications, and in particular to computer telephony.

BACKGROUND INFORMATION

Currently, widespread standard telecommunication protocols provide the underlying framework required for a personal computer ("PC") to emulate the operation of a traditional multiple-line telephone terminal. Such an emulation is referred to as a virtual terminal. More specifically, packet voice protocols such as H.323 and SIP enable a PC that is equipped to support multimedia communication to simulate a telephone equipped with a variety of service features. Such telephone service features may include 3-way conferencing, call forwarding, voice messaging and intercom. Call control protocols such as TAPI (Telephone Application Programming Interface) support communication between computer networks and PBXs (Private Branch Exchanges) and thereby facilitate interaction between IP networks and the PSTN (Public Switched Telephone Network). In addition, owing to their information processing capabilities, computers can provide extra functionality such as video conferencing, whiteboarding, directory-based management, instant messaging, and user configurability. However, as various protocols compete to some extent in the marketplace, both hardware and software must often be adapted to operate under a particular protocol. For many organizations, access to telephone terminals that provide a wide range of features and services is crucial. Due to the advent of wireless telecommunications systems, such terminals can be mobile, and used remotely from home office equipment. Given the vast functionality associated with computer telephony, it would accordingly be advantageous to provide an intuitive, easy-to-use virtual terminal application that incorporates this functionality and can operate with a variety of protocols currently supplied or envisioned for the future.

SUMMARY OF THE INVENTION

The present invention attains these advantages by providing a configurable computer telephony application that supports multiple lines of data/voice communication with terminals operating in heterogeneous packet and circuit switched networks. The application includes a graphical user interface that displays graphical features corresponding to a set of telecommunication commands and notifications. The telecommunication commands can be accessed through the graphical features. The telecommunication commands are processed and converted into messages, and data is input to perform a plurality of call processing and data management services. The application is adapted to function over multiple data and voice communication protocols, and is thereby enabled to transmit communication messages and data to and from the user interface and the heterogeneous network.

A technique of recording a multimedia data stream communicated to or from a terminal using the configurable computer telephony application is provided. When the application is configured to do so, a data stream is captured and stored as an encrypted, unalterable computer file. The stored file is linked to the call's entry in a call log.

A method of controlling redirection of calls or messages inbound to a remote terminal from a terminal using the configurable computer telephony application is also provided. The terminal using the application registers with the remote terminal's network node and monitors its inbound traffic. Once an inbound call or message is monitored, the terminal using the application causes the network node to redirect the inbound call or message away from the remote terminal to an alternate answering position.

A method of facilitating establishment of calls outbound from a terminal using the configurable computer telephony application is also provided. Alphanumerical information that is related to a prospective call destination is input. Databases are searched for matches to the input information, and matching addresses are then listed. When one of the entries is selected, the application automatically initiates a call to the selected address.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 schematically illustrates an IP telephony communication network including both a public switched telephone network and packet telephony components.

FIG. 2 shows the VT/ALL virtual terminal graphical interface according to an embodiment of the invention.

FIG. 3 shows the VT/ALL virtual terminal graphical interface according to an alternative embodiment of the invention and also shows the dialpad feature according to the invention.

FIG. 4 shows the architecture of the VT/ALL application and its interaction with lower layers in the protocol stack according to the invention.

FIG. 5 shows an alternative embodiment of the VT/ALL graphical interface and also shows the directory dialog box feature according to the invention.

FIG. 6 shows an alternative embodiment of the VT/ALL graphical interface and also shows an exemplary entry in the call status display bar according to the invention. FIG. 7 shows an alternative embodiment of the VT/ALL graphical interface and also shows an activated tools menu according to the invention.

FIG. 8 shows an alternative embodiment of the VT/ALL graphical interface and also shows the instant messaging dialog box featured according to the invention.

DETAILED DESCRIPTION

In accordance with the present invention, a virtual terminal application suite referred to as VT/ALL (Virtual Terminal Application Linking and Launching) is provided for multimedia PCs. The VT/ALL suite provides secure, standards based multimedia communications including features such as directory functions, IP telephony, application sharing, instant messaging and a multicast conference component capable of transmitting and receiving audiovisual data via a multicast enabled network, among others. The application can be configured to support an unlimited number of line presentations with the total number of simultaneous calls subject to available bandwidth. The application also provides for compliance with Quality of Service ("QoS") policies enforced in the communication networks.

These capabilities are delivered as a software package on multimedia PCs using standard protocols. The VT/ALL application software, which includes a graphical user interface, underlying functional programs and lower- level protocol handlers, is adaptable to various operating systems such as Windows NT 4.0 and Windows 2000. The lower level protocol handlers may be implemented as COM (Component Object Model) objects, allowing a separation between the user interface and feature functionality from the lower level protocols such as H.323 and SIP. This modular architecture allows for rapid adaptation to protocols that may emerge in the future. Although the telecommunication system and application are described below specifically in association with the H.323 family of protocols, it is emphasized that the VT/ALL application maintains protocol independence by incorporating translation modules tailored to multiple protocols including both H.323 and SIP.

The application supports the features mentioned above via transparent, simultaneous interaction with both the public switched telephone service ("PSTN") and with packet telephony platforms such as the Internet. FIG. 1 schematically illustrates an IP telephony network 2 with which VT/ALL may interact. It is emphasized that the figure is illustrative of the functions of the various devices and connections that may be present in an IP telephony network 2 and is not meant to indicate the number or scale of the various devices that might be implemented in an actual network. Various VT/ALL terminals 5, 6, 7 . . . 10 are shown. The terminals 5, 6, 7 ... 10 may be PCs, or other equipment such as personal digital assistants ("PDAs") that have the processing capabilities required to run the VT/ALL software. Terminals 5, 6, and 7 are shown coupled by respective connections 51 , 52 and 53 to a LAN network Hub 15. The LAN Hub 15 communicates IP traffic with a larger IP network 25 through interconnection 78. For illustrative purposes, in an exemplary embodiment, it is assumed that the larger IP network 25 operates on a packet-switched platform, but is not the Internet as commonly defined.

Terminal 8, unlike terminals 5, 6 and 7, is not connected to a LAN and uses a dialup connection to communicate IP traffic with a routing and addressing server 18 ("RAS/VPN server") that may or may not also be the server for a virtual private network. The RASA PN server 18 is coupled to the larger IP Network 25 through interconnection 71. Terminals 9 and 10 are directly coupled to the Internet 20 through cable modem and DSL connections respectively. There is a connection between the Internet 20 and the IP network 25 through a virtual private network shown simply as a connection line 61 that terminates at a firewall/proxy server 19. The firewall/proxy server 19 provides security and authentication services for the IP network 25. Various distributed databases are represented by database 21 which can be accessed through the IP network 25. The telecommunications services provided by VT/ALL are mediated by the set of devices and servers 23, 24, 27, 28 and 29 that together or separately perform such tasks as multiplexing, database look-ups, registration and data storage required to execute the services featured by VT/ALL. VT/ALL server 23 mediates many VT/ALL functions. Specifically, all multicasting, instant messaging, voice mail and license serving functions are conducted through the VT/ALL server 23. To illustrate an example of how the VT/ALL server may interact in the IP telephony system 2, let us assume a user at VT/ALL terminal 8 wishes to contact VT/ALL terminal 6 and there is no one to receive the call at terminal 6. After the call is placed through dialup connection 55, the signaling message is communicated through RASΛ/PN server 18, IP network 25, LAN Hub 15 and finally to terminal 6. After, a certain number of ring signals are executed at the terminal 6, a no answer signal is sent back to terminal 8. In addition, the VT/ALL application at terminal 6 also alerts the VT/ALL server 23 that there is no answer to a call placed to terminal 6. The VT/ALL server 23 then executes the voice mail application which includes sending a recorded voice mail greeting to calling terminal 8, receiving a voice mail message, recording the message and setting a software flag so that a message waiting indication appears at terminal 6.

An H.323 Gateway 24 acts as a bridge between IP Network 25 and the PSTN. Gateway 24 connects through T1 line 81 to a PBX 30, which is a node of the PSTN. Hand-set telephones 31 , 32 are shown connected by circuit- switched connections 41 and 42 respectively to the PBX 30. The Gateway 24 transcodes the signaling messages and data transported between the two systems and also provides calling and called party information from one system to the other. TAPI (Telephony Application Programming Interface) server 35 connects to both the IP network 25 and the Gateway 24, and enables specific services through its interaction with the PBX 30 and the IP network 25. H.323 Gatekeeper 27 controls registration and QoS functions for all VT/ALL terminals 5, 6, 7 ... 10 coupled to the IP network 25. Through registration, a terminal 5, 6, 7 ... 10 is authenticated and attributed with a series of identification addresses. Gatekeeper 27 provides for address translation so that IP addresses of each terminal 5, 6, 7 ... 10 can be ascertained from another type of identification stored at the Gatekeeper. Being equipped with such address and identification information, the Gatekeeper 27 also provides support for directory, call control, routing and call modification services such as add-on conferencing, call transferring and call forwarding for all VT/ALL terminals 5, 6, 7 ... 10.

LDAP (Lightweight directory access protocol) directory server 28 is an accessible and searchable public or private directory database. As will be explained below, VT/ALL terminals 5, 6, 7 ... 10 can establish data communication with LDAP directory server 28, and search for telephone numbers or IP addresses stored within the directory using personal or business name, other identification, or by categorized indexes. Such services as AltaVista or online Yellow White Pages are examples of LDAP directories.

Multipoint control unit ("MCU") 29 acts in conjunction with VT/ALL server 23 to support multipoint conferencing. The functions of the MCU are defined according to the H.323 family of protocols. The MCU multiplexes and coordinates the data streams from multiple terminals in conference, enabling each terminal to receive and transmit data to all other terminals simultaneously.

A VT/ALL terminal is equipped with a microphone handset/headset for voice input, a set of speakers for audio output and one or more sound cards (digital cameras and video cards may also be included for video conferencing applications). As such, a conventional telephone need not accompany a VT/ALL terminal to transmit and receive voice communication. Using multiple sound cards can improve the quality of services. For instance, if two sound cards are used, one may be dedicated to telephony functionality while the other may be dedicated to multicast reception.

The VT/ALL application uses a range of codecs such as, among others, the G-series of codecs as defined by ITU (International Telecommunications Union). Each codec compresses voice data to a different degree and can be more or less suitable depending on the bandwidth of the connection from a VT/ALL terminal to the IP network. VT/ALL allows the user to configure the type of network connection the PC is utilizing and provides an automatic codec selection feature that selects the most appropriate codec based upon the user configuration.

VT/ALL facilitates the configuration of other parameters, such as, for example, Gatekeeper or Gateway address, proxy or firewall presence and address aliases such as email name, through a set up wizard that guides the user through the configuration process.

The VT/ALL telephony features are presented in a graphical user interface that simulates the appearance of a full service multi-line telephone. FIG. 2 shows an embodiment of the main program window 100 of the VT/ALL user interface shown on a PC screen. The main program window 100 can be reduced to occupy a toolbar located at the edge of the screen. The various features shown can be activated using a PC mouse, or by keyboard short cuts allowing the user to modify the state of a call without leaving the keyboard.

To place an outbound call, a user has several options as to how to proceed. A user may activate (click on) call address field 101 and enter a computer name, IP address or phone number, and then press the call key 103 located beneath the call address field. Alternatively, the user may make use of the dialpad feature offered by VT/ALL. FIG. 3, which shows an alternative embodiment of the VT/ALL graphical interface 100a, contains a dialpad call-up key 170, which activates dialpad 175 when pressed. The dialpad shown emulates the key-buttons found on a DTMF (Dual Tone Multiple Frequency) pad on regular telephone hand-sets and also provides for sending DTMF signals to DTMF dependent systems after a call is established. The dialpad 175 may also contain a local call address field (not shown).

The architecture of the VT/ALL application is shown in FIG. 4. The top of the figure above the dashed line marked X, represents the VT/ALL application interface. The primary interface is the telephony system 200, which includes the graphical user interface 100 described above. The telephony system 200 can be implemented, for example, in Visual Basic. When the features of the interface 100 and system 200 are activated, procedure calls and various interrelated subroutines are executed and information is passed down to lower layers in the architecture.

For example, to commence execution of an outgoing phone call, the dialpad 175 may be activated, a destination number entered, and a line key pressed. During execution, information is passed from the telephony system 200 to the Stack Abstraction Layer ("SAL") 250 below. The SAL includes numerous modular programs implemented as COM Objects. The programs act as an intermediary and translator between the protocol handler 300 and the telephony system 200, and also coordinate procedures that are invoked to provide the featured services. Upon receipt of the outgoing call request, the call control module 251 within the SAL reformats the request into a call initiation request format compatible, in this example, with the H.225 call setup protocol component of the H.323 protocol suite.

The call is then directed to the H.323 layer 300 which can be implemented, for example, as the RADVision™ H.323 V.2 Stack Suite. The Control component 310 of the H.323 layer 300 then opens a communication channel for delivering the appropriate call messages to the lower protocol stack layers 400 in TCP/IP packet format, which are sent over the IP network 25 through a Network Interface Card 450. If the message reaches the target destination, several messages are sent back and forth between the endpoints, first to establish that a connection can be made, and then to negotiate over the properties of the ensuing communication, such as quality of service and codecs employed. Once a call is established and negotiations are complete, the Media component 320 of the H.323 layer 300 opens media stream channels for outgoing and incoming communication, implemented using Real Time Protocol (RTP), and for data monitoring, which is implemented using Real Time Control Protocol (RTCP). Outgoing and incoming media streams are encoded or decoded respectively within the Media component 320 using incorporated codecs. As shown in the figure, the H.323 Media component 320 includes both audio and visual codecs enabling receipt of either types of content. Incoming video content is passed up to the SAL 250 and through a media control player 225 where it is processed before being passed to a Multimedia Broadcast Reception sub-interface 215 that controls the display of incoming video content.

VT/ALL provides multi-line functionality by coordinating multiple RTP media channels within the SAL 250. State management 252 and call list management 253 modules within the SAL 250 keep track of which communication lines are activated on the graphical user interface and select a specific RTP stream to process and send to the mixer 255 and sound card 257, while other RTP streams are blocked, and put on hold. As a result of the coordination performed by these modules, a single active communication can occur without interference from the other lines. Additionally, the SAL 250 can control mixing of audio and/or visual streams, so that, for example, a telephone conversation, an incoming audio/visual broadcast, and a CD music player can all occur simultaneously on a user's PC.

In addition to the SAL 250 which supports the upper-level telephony system 200, VT/ALL provides a Signaling Network Management Protocol ("SNMP") Agent interface 290. This allows a VT/ALL terminal to communicate with a SNMP Agent through a LAN Hub 15 or IP network 25. The SNMP agent provides network management and error correction capabilities.

Supplemental services provided by VT/ALL such as call transfer, 3-way conferencing are supported by the call control capabilities of the SAL 250 and by the H.450 Supplemental Services module included in the H.323 control component 310. For example, to execute a call transfer, the SAL 250 and H.450 coordinate such actions as putting an existing communication on hold, initiating a new call, and sending instructions to the counterpart in the first communication to accept the media streams incoming from the newly called party.

A user may also utilize the extensive directory services available on VT/ALL to establish an outgoing call. The directory allows users to quickly locate entities by name, number, or email address and quickly initiate a phone call or send a message. FIG. 5 shows directory activation key 180 and directory user interface 185 ("directory"), which contains entries 186a, 186b ... 186f from a particular database sorted according to an alphabetical or numerical order. The directory services interface 185 may be a local directory, such as MS Outlook Contacts or Symantec™ ACT, that is integrated within the telephony system of the graphical interface. Entries can be drawn from a list 186a, 186b ... 186f stored within the local directory. In addition, the directory services interface 185 supports the lookup of entries in public LDAP (Lightweight Directory Access Protocol) based directory services offered by services such as AltaVista and Bigfoot as well as private LDAP directory sources such as MS Exchange and Novell Directory Service. Entries located in these external databases can be added to local contact managers and updated from the VT/ALL directory 185.

An LDAP directory search proceeds by activating a search key 188 and entering search criteria in call address line 101 (in FIG.2) or selecting an entry already present in the local directory. The input or selected entry consists of one or more fields or attributes 187a...187d, which store values such as a name, a business telephone number, a home telephone number, and an Internet address.

The search request is passed along with the attributes and values of the selected entry to an LDAP module 285, shown in FIG. 4. Upon receiving the request entries and entries, the LDAP module 285 establishes communication through the lower network layers 400 and NIC 450 with one or more external LDAP servers (not shown) coupled to IP network 25. If communication is established, a library session is set up between the LDAP module 285 and the one or more LDAP servers, the LDAP module reformats the entry attributes and values into an LDAP search command, and the command is sent by the module through the network to the LDAP servers. The LDAP servers process the request, perform searches of directory libraries, and return entries that match the values and attributes of the search criteria through the IP network 25 to the LDAP module 285. The LDAP module 285 reformats the retrieved search information and shares it with the directory services interface 185. The user is then given an opportunity to select one of the displayed search results for initiating a call.

When an inbound call is received the application may present a call notification box that displays who is calling by name and number, on which line the call is presenting itself, offers an answer call button and offers a redirect to voice mail or other destination. Alternatively or in addition to the call notification box, the application may provide a distinctive ringing sound when a call presents itself to certain lines. The particular lines and the specific tones used can be configured through options on the menu bar 152 (of FIG. 2). Optionally, automatic directory call lookup may occur whereby the calling party's entry in a local directory is retrieved during call notification.

Once a call is established, the user can use several call control buttons to change the status of the call. Calls may be transferred by pressing the transfer key 104 and by entering a transfer destination in the call address line 101 (or using the other address specification means described above). An add-on conference call may be established in a similar manner using the conference key 107. The call may be put on hold through the hold key 108 and released by pressing the release key 105. Alternatively, short cut keys may be implemented to allow these call control commands to be entered on the keyboard. A call forwarding button 106 allows the user to forward all incoming calls to a destination entered using the call address line, dialpad or directory features. Conditional call forwarding is also provided and will be described in greater detail below. Volume controls 112, 114 can be used to adjust the volume outputs from the microphone and speakers respectively. VT/ALL also provides for the muting of other audio streams, such as from a CD player, when an incoming call is received.

A large portion of the VT/ALL graphical interface 100 is occupied by columns of line appearances 120, 130, and 140, each button presented representing a phone line. Each line is capable of initiating PC to phone and PC to PC calls, and receiving phone to PC and PC to PC calls. Each column of lines 120, 130 and 140 contains at least 10 lines, but other lines can be accessed through other pages of line appearances. The total number of lines permitted is not limited by the application and is only subject to the bandwidth that is available. Lines shown in column contain a default label, in this case "Line 1", "Line 2", etc. Line 1 is not a private or broadcast line, and therefore it is non-mapped, and can be associated with general incoming calls as can other lines shown in line column 120. Each line contains an LED emulation that varies in color depending upon the status of the call. LED emulation 124 on Line 1 is gray when the line is inactive, green when the line is active, yellow if a call to or from the line is in progress and red if the line is on hold. When a hold condition last for a certain amount of time the LED emulation 124 starts to flash red on and off at a certain configurable speed.

Inbound non-mapped calls will search for the first idle non-mapped line. When the call becomes active caller identification may replace the line label for the duration of the call. For outbound calls, audible ringing and busy signals are generated.

A column of private lines 130 is also shown. Each private line is associated with underlying properties consisting of a first name, last name, organization, display label, destination address and incoming call ID for mapping to a private line key. Incoming calls will be screened for these criteria and if a match is found the call is directed to the matching private line key.

Phone line column 140 contains broadcast lines. For instance, if a user presses the London Call broadcast button, an ongoing broadcast from the London Call origination point will be received. Line column 140 can also contain Hoot and Holler lines 145 more clearly illustrated in FIG. 3. Hoot and Holler lines present the audio stream of an ongoing conference call with the ability to respond, as opposed to a broadcast, which is transmitted by a single entity and operates in a listen-only mode.

A call status display window 150 is shown which displays all calls that are active, in progress or on hold. The call status display window 150 displays information about each call such as whether it is inbound or outbound, the status of the call, and caller and called party identification. FIG. 6 shows a call status display window 150a where the start time and duration of a call are displayed.

VT/ALL also supports conditional call forwarding. Rather than automatically forwarding all calls directed to the terminal, calls are forwarded to a predefined voice mail application when a busy or no answer condition at the terminal occurs. The voice mail application may reside on the user's PC or it may be based at the VT/ALL server within the IP network.

Through functionality provided by TAPI that allows PCs to interact with PSTN components, a VT/ALL terminal can remotely monitor calls directed to a telephone extension on a PBX. To accomplish this a remote VT/ALL terminal must register with the PBX. The user can then instruct the PBX to redirect calls intended for the phone extension to the VT/ALL terminal, or alternatively to a voice mail application.

To illustrate the operation of remote monitoring, let us assume that a person working at a VT/ALL terminal (5, 6, 7 . . .10 in FIG. 1) that is associated with an extension number 4000 wishes to monitor calls at a PBX extension numbered 3000. When the user at extension 4000 logs in to VT/ALL application, the terminal registers with the Gatekeeper 27. The Gatekeeper 27 creates a mapping of the IP address of the registering terminal with the extension number 4000. The mapping is dynamic, so that if the user begins work at a desk top terminal, and then leaves work and logs in with a lap top PC or PDA, the Gatekeeper 27 can map the new IP address of the portable terminal with the same extension 4000.

Once the VT/ALL terminal has logged in and has been mapped to an IP address, remote monitoring can be established. The full phone number and extension (3000) of the number that is to be monitored is entered into a remote phone control and monitoring module 220 (in FIG. 4) within the VT/ALL application. The remote phone control and monitoring module 220 passes the entered information to the TAPI application programming interface 280. The TAPI interface 280 sends a command to 1 ) activate monitoring and call forwarding at extension 3000, and 2) to direct the forwarded calls from extension 3000 back to the VT/ALL terminal through a VoIP (Voice over IP) Gateway 24, coupled to PBX 30.

The command is reformatted in the lower-level protocol layers 400 and transported through IP network 25 to TAPI server 35. The TAPI server extracts the information it receives from the VT/ALL terminal and reformulates it into a signaling message appropriate to cause the PBX 30 to monitor incoming calls to extension 3000 and direct them to the Gateway 24. In one implementation, the appropriate message is a Nortel Meridian™ Link Message targeted for a Nortel Meridian PBX. This Link Message is sent over a Computer Telephone Integration ("CTI") link between the TAPI server 35 and the PBX 30. Authentication of the Link Message registers the VT/ALL extension 4000 with the PBX 30.

After the PBX 30 has processed the instructions of the Link Message, incoming calls to PBX extension 3000 are forwarded to the VoIP Gateway 24 on the way to the destination extension 4000. From the Gateway, the call is sent through IP network 25, where it is intercepted by the Gatekeeper 27, which associates the extension 4000 with an IP address of a registered VT/ALL terminal, allowing the incoming call to reach its destination.

Referring again to the graphical interface 100 shown in FIG. 2, the resident answering machine on the VT/ALL terminal allows the user to record a greeting and define the number of ring cycles before the greeting begins. Caller messages are recorded as an audio file in the format received. The file is linked to an entry in a call log maintained by the application. A message waiting indication 111 will flash red when recorded messages remain unplayed.

The menu bar 152 allows the user to access and configure VT/ALL's features and services. In FIG. 7, a menu bar 152a is shown with a drop-down Tools menu 155 containing a "Skins" sub-menu 158. "Skins" are the various graphical interface layouts for the telephony features that the user may choose from. FIG. 2 shows one skin, while FIGS. 3 and 5 through 8 show another. Skins can be configured using software development tools known in the art. Skins sub-menu 158 contains 4 skin choices, but an unlimited number of skins are possible.

The call log is shown as one of the listings in the drop-down menu 155. The location of the log file is one of the configurable parameters. The file stores the line identification, time, date, destination or origination address and duration of the call. The user can also limit the type of calls logged based upon whether the call is inbound or outbound, and answered or unanswered.

While the call log stores information about the call, it does not necessarily store the voice content communicated during the call. The VT/ALL application includes both manual and automatic voice recording capability. A user can activate a manual recording interface on a per call or ad hoc basis. The automatic recording feature can be programmed to record calls based on criteria such as the time of day, the called or calling party, the date of the call, and whether the call is a conference or two-party communication, among others. These criteria can be set using the options sub-menu of the Tools drop-down menu 155. Such programmed or rules-based recording is useful for organizations that require a record of the voice content of a specific subset of the total set of inbound and outbound calls. Recordings are stored in an encrypted wave file format. A pointer to the location of the audio file is stored in a field in the call log database for future retrieval and playback. The file storage path is also configurable.

The mechanism of automatic call recording is described with reference to FIG. 4. The call logging 202 and audio recording 204 features of the telephony system 200 can be configured to record all communication with a particular client, which, as described, may be associated with a particular line representation displayed on the interface 100. The selected recording rules are stored in a configuration control rules module 205. When a call is initiated from the graphical interface 100, the low-level recording module 260 in the SAL 250 is activated. A line key is then selected and this selection is passed to the configuration control rules module 205 which determines based upon the selected line key and other pre-set factors whether recording should be enabled during the call. If recording is appropriate, once the call is established, the low-level recording module 260 extracts the incoming and outgoing RTP streams from the H.323 media module 320, and reformats the RTP streams and stores the data in wave file format in conjunction with the low-level wave file management module 261 of the SAL 250. When the call terminates, the state management module of the SAL 250 instructs the call audio recording module 204 of the telephony system 200 to stop recording. The call audio recording module 204 then instructs the low-level recording and wave file management modules 260, 261 to stop recording and close the recorded wave file.

The audio data and the storage location of the wave file are passed back to the call audio recording module 204 which performs public key encryption on the data within the file. The storage location of the file is passed to the call logging module 202 where the location is tied to the call entry stored in the log file. In this manner, the communicating parties, time, date, and duration of the call are associated with a pointer to the storage location of the audio content of the call. The actual call log of a VT/ALL terminal may be maintained externally in a database server. The call logging module 202 passes information to an Open Database Connectivity ("ODBC") interface 270 that, in turn, communicates information through the lower-level protocol layers 400 and over IP network 25 to various database servers.

VT/ALL also includes an instant messaging and point of presence component that provides the capability to find an online user, adapt to changes in their online status, and send them text messages. The application will also support integration with the lmbot.com messaging service. This component enables the immediate or future delivery of text or voice messages. An Imbot instant messenger application component is shown in FIG. 8. The component can be activated through the messenger button 190 and contains a called party number filed 196, a text entry window 197, and a delivery scheduling option section 198. At the receiving end, the application plays an announcement and converts the message text into speech. A log file entry is also stored at the Imbot site. The instant messaging processes are facilitated by access to a limited number of predefined messages, and a transparent interface with the application directory functions.

Claims

WHAT IS CLAIMED IS:

1. A system for telecommunication comprising: a user interface; a heterogeneous packet and circuit switched network comprised of a plurality of network elements; and a processor adapted to: a) receive communication messages and data from the user interface and from the heterogeneous network; b) process communication messages and data to perform a plurality of call processing and data management services; c) provide access to multiple data and voice communication protocols for facilitating communication to the network elements; and d) transmit communication messages and data to the user interface and to the heterogeneous network.

2. The system of claim 1 , wherein the processor is further adapted for communicating simultaneously with multiple parties through the heterogeneous network on multiple communication lines that are displayed on the user interface, switching between the multiple communication lines being provided by a line switching means accessible through the user interface.

3. The system of claim 1 , wherein the processor is the microprocessor of a personal computer.

4. The system of claim 1 , wherein the multiple data and voice communication protocols include H.323, SIP and TAPI.

5. The system of claim 1 , wherein the plurality of call processing services include call transfer, call forwarding, 3-way add-on conferencing, and voice mail.

6. The system of claim 1 , wherein the plurality of data management services includes: searching for addresses of prospective called parties using directory databases; initiating calls to selected addresses found during searching; storing a record of telecommunication events; and storing data streams transmitted and received.

7. The system of claim 6, wherein the plurality of call processing services further includes: monitoring a node within a circuit switched network for calls or notifications inbound to an extension of the circuit switched network; redirecting the calls or notifications to a location other than the extension.

8. A method of securely recording a data stream transmitted during a call between at least two telecommunication terminals, the method comprising the steps of: capturing the data stream if a capture command is executed using a user interface; storing the captured data stream as a computer file; encrypting the file so that the stored data stream cannot be subsequently altered; storing a call identification label in an entry in a call log specific to the call; determining a time and a duration of the call, and storing the time and duration in the said entry with the identification label; and linking the computer file storing the data stream associated with the call with the entry in the call log.

9. The method of claim 8, wherein the capture command is executed manually on a per call basis by users interacting with the user interface.

10. The method of claim 8, wherein the capture command is configured to capture the data stream according to a set of criteria.

11. The method of claim 10, wherein the set of criteria include a time of day of the call, a called or calling party, a date of the call, and whether the call is a conference or two-party communication.

12. A method of redirecting communication inbound to a first telecommunication terminal residing within a network from a remote terminal residing outside the network, the method comprising the steps of: registering the remote terminal with a node in the network connected to the remote terminal; monitoring the communication inbound to the first terminal at the network node; and causing the network node to redirect communication inbound to the first terminal to an entity other than the first terminal.

13. The method of claim 12, wherein the first terminal resides within a computer network.

14. The method of claim 12, wherein the first terminal resides within the public switched telephone network.

15. The method of claim 12, wherein the said entity other than the first terminal is the remote terminal.

16. The method of claim 12, wherein the entity other than the said first terminal is a voice mail application residing within the network to which the remote terminal is connected.

17. A method of providing a telecommunication address for establishing an outbound call from a terminal, the method comprising the steps of: inputting alphanumeric searching criteria; searching at least one database for matches to the input alphanumeric criteria; listing at least one entry corresponding to at least one match found in the at least one database; selecting one of the at least one entry listed as a destination for a call; and automatically initiating a call to the selected entry.

18. The method of claim 17, wherein the at least one database includes at least one local database and at least one external database accessible through a computer network.

19. The method of claim 18, further comprising the step of: adding a selected entry derived from any of the at least one external database to one of the at least one local database.

20. The method of claim 18, wherein searching of the at least one external database occurs using the LDAP protocol.

21. A telecommunication system comprising: multiple terminals, each of the multiple terminals including a processor; a data network; a telephone network; a gateway node couple to both the data network and the telephone network; a gatekeeper node coupled to the data network; wherein the multiple terminals are each coupled to the data network, the multiple terminals each register with the gatekeeper node, the gatekeeper node associates each terminal with a data network communication address, and each multiple terminal can establish and maintain multiple lines of communication with other terminals coupled to the data network, and simultaneously establish and maintain multiple lines of communciation through the gateway node with extensions coupled to the telephone network.

22. The system of claim 21 , further comprising: an application server that supports multicast communication among the multiple terminals coupled to the data network, and supports instant messaging between between the terminals.

23. The system of claim 21 , further comprising: a directory server accessible through the data network from any of the multiple terminals, the directory servers providing information based upon requests communicated by any of the multiple terminals.

24. The system of claim 21 further comprising: a TAPI server, the TAPI server coupled to the data network and the gateway node, the server communicating messages through the gateway node to the telephone network, the messages allowing a terminal in the data network to: a) monitor incoming calls at an extension coupled to the telephone network; and b) redirect the incoming calls at the extension to the terminal.