WO2001006740A2

WO2001006740A2 - Method and apparatus for integrating a voice gateway with an ip/pbx telephone system

Info

Publication number: WO2001006740A2
Application number: PCT/US2000/019209
Authority: WO
Inventors: Judith Duffy; Stephen R. Raad; Gordon K. Chang; Richard B. Barry
Original assignee: Starvox, Inc.
Priority date: 1999-07-14
Filing date: 2000-07-14
Publication date: 2001-01-25
Also published as: WO2001006740A3; AU6346500A

Abstract

A system and method are provided for integrating a voice gateway system to incorporate an IP/PBX telephone system (33). The system includes a public switched telephone network (PSTN 2), an internet protocol (IP) network (1), and a gateway network (30) coupled to the (PSTN) and to the IP network to route a telephone call over the (PSTN) or the IP network. The gateway network has a gateway server (31) coupled to the (PSTN 2) and the IP network (1) and coupled to an IP/PBX telephone system (33). The gateway server (31) is configured to automatically select over which of the IP network (1) or the PSTN (2) to route a call. Preferably, the system includes a number of gateway networks (10, 20, 30) coupled to one another via the IP Network (1) and the PSTN (2). In one embodiment, a gateway network (10) includes a PBX telephone system (12) having a voice mail server (32), and the gateway networks (10, 20, 30) are configured to provide voice mail service to a user of an IP telephone (41).

Description

METHOD AND APPARATUS FOR INTEGRATING A VOICE GATEWAY WITH AN IP/PBX TELEPHONE SYSTEM

Cross Reference to Related Applications

This application claims priority from United States Provisional Patent Application

Serial Number 60/143,817 filed July 14, 1999.

Field

The present invention relates generally to communication systems and in particular to a hybrid communication system that integrates an IP/PBX telephone system with a communication system having an internet protocol (IP) network to and a public switched telephone network (PSTN) provide unified voice-mail to users of IP telephones.

Background Telephony, that is voice communication over an internet protocol (IP) network, has gained rapidly in popularity in recent years among both businesses and individuals seeking to minimize the cost of the long distance telephone calls. IP telephony systems are described in, for example, commonly assigned co-pending U.S. Patent application serial number 09/061,802, which is incorporated herein by reference. An IP telephony system typically includes an IP network, such as a wide area network (WAN), a local area network (LAN), or the Internet, with a number of IP telephones connected thereto. The IP telephones can be a stand-alone IP telephone directly connected to the IP network, or a computer workstation with a speaker, microphone and IP telephony software to function as an IP telephone. In addition, the IP telephone can be coupled to the public switched telephone network (PSTN) through a voice gateway that translates between data packets used by IP networks and analog signals used by the PSTN.

One of the problems with current telephony systems, particularly for business users, is their inability to integrate with existing communication networks, such as a private branch exchange (PBX). PBXs, which are well-known and widely used within government and industry, are telecommunications switching systems maintained at one or more user sites that are used to connect internal station to station telephone calls and to the PSTN. In addition, many PBXs provide the users with advanced features such as caller ID, call forwarding, call conferencing, and voice-mail etc. These features have come to play a vital role in business, enabling the users to remain in contact with and better serve their clients and customers. The IP telephones of conventional telephony systems do not connect to a PBX at all, coupling instead to the PSTN through a gateway server, as described above, therefore these advance features are not available to users of IP telephones. Moreover, those systems that do couple to a PBX , as for example taught in U.S. Patent No. 5,867,494, to Krishnaswamy et al., merely teach a voice trunk through which voice and touch-tone (DTMF) signals may be bridged between an IP network and the PSTN via the PBX. Such a path cannot alone function to enable an IP telephone user to access the advanced features of the PBX. Thus, there is a need for an IP telephony system capable of being integrated with conventional existing PBX systems, to make the advanced features of the PBX available to IP telephone users.

Summary

The present invention relates to an apparatus and method for integrating a voice gateway system to incorporate an IP/PBX telephone system. This enables users of IP telephones to access many of the features of the gateway network.

It is an object of the invention to provide an integrated voice gateway system which provides both PBX telephone users and IP telephone users with a common voice- mail system, which supports voice-mail feature transparency for all of the telephone users. It is an object of the invention to provide an integrated voice gateway system with an IP/PBX telephone system, where the IP telephones of the IP/PBX telephone network are used typically by the employees within a company. This gateway system can route a voice telephone call between parties at two different locations over a WAN IP network, where either or both parties are using a PBX telephone or an IP telephone. It is a further object of the invention that the gateway system will automatically select which of the IP network or PSTN over which to route the calls.

It is a further object of the invention to provide a system which can route a telephone call between a calling party using an IP telephone at a first location within the system to a second location within the system via a WAN IP network, and then from the second location to a called party at a third location via the PSTN.

It is an object of the invention to provide an integrated voice gateway system which can place a telephone call over an IP network, and then if, during the telephone call, the quality of the telephone call falls below a predetermined quality level, and the quality degradation is determined to be due to the WAN IP network performance, to be able to reroute the telephone call over to the PSTN, and to do so in a manner that is transparent to both the calling and called parties, either or both of which can be using an IP telephone.

It is an object of the invention to provide an integrated voice gateway system which can track any modifications to a profile of any telephone user in the enterprise. A telephone user includes users of PBX telephones and IP telephones. Modifications to the telephone user profile may include changes to the existing data for a user, addition of new users, and deletion of users. It is a further object of the invention to provide an integrated voice gateway system which can integrate with an enterprise directory to allow single point of entry for user profile modifications and to provide replication of these changes across all enterprise sites.

It is an object of the invention to provide an integrated voice gateway system in which the identification of the calling party (e.g., name, title, department, primary telephone number) can be displayed on the called telephone's display, where the called party is using an IP telephone, and said telephone supports caller ID display. Likewise, the identification of the calling party can be displayed on any other telephone in the integrated voice gateway system, where the calling party is using an IP telephone. In addition, the format of the displayed caller ID information is the same for all said telephones.

It is an object of the invention to provide an integrated voice gateway system in which the identification of the calling party (e.g., name, title, department, primary telephone number) is displayed on a computer screen (rather than on a telephone display) co-located with the called party's telephone, and that such information be displayed regardless of the vendor(s) supplying the telephone equipment used by the calling and called parties. Either or both of the calling and called parties may be using an IP telephone. It is further an object of the invention that such information be provided regardless of the desktop workstation or PC (workstation and PC are referred to interchangeably herein), or operating system used via a WWW browser interface.

It is an object of the invention to provide an integrated voice gateway system which can create a log of incoming telephone calls and call attempts arriving over a WAN IP network, and of outgoing telephone calls and call attempts routed over the WAN IP network, and identify the names of calling and called parties. It is a further object of the invention to provide a log of all incoming and outgoing calls whether the calling and called parties are using a PBX telephone, using a PSTN telephone, or using an IP telephone. It is an object of the invention to provide an integrated voice gateway system in which, when a called party's telephone is busy, the system can automatically set up a call between the calling party and the called party as soon as the called party hangs up, and either or both of calling party and called party can be using a IP telephone. It is a further object of the invention to provide such a capability even when a called party has voice- mail.

It is an object of the invention to provide an integrated voice gateway system in which, when a called party is busy, the calling party may send a computer message which will be immediately displayed on a computer screen co-located with the called party's telephone, for example to explain why the calling party needs to speak with the called party, and one or more of the parties are using an IP telephone.

It is an object of the invention to provide an integrated voice gateway system in which, when a called party does not answer an incoming telephone call, the calling party may forward the call, for example to voice mail, or to an answering station (e.g. a receptionist or other designated party), and the calling party and/or the called party can be using an IP telephone. It is further an object of the invention to provide the capability for a party at an answering station to send a computer message which will immediately be displayed on a computer screen co-located with the called party's telephone.

It is an object of the invention to provide an integrated voice gateway system in which a user of the system may set up the system to forward that user's telephone calls to a different telephone. It is a further object of the invention to forward calls to a PSTN telephone, a cellular telephone in a public wireless network, an IP telephone, a PC-based IP telephone, or a private mobile telephone. It is a further object of the invention to provide the capability for a user to set up the system to forward that user's telephone calls to different telephones according to a time schedule predetermined by the user. It is a still further object of the invention to provide the capability for a user to set up the system to forward telephone calls originating only from one or more calling parties so designated by the user. It is a further object of the invention to provide the capability to setup call forwarding via a browser interface or interactive voice response (IVR).

Brief Description of the Drawings These and various other features and advantages of the present invention will be apparent upon reading of the following detailed description in conjunction with the accompanying drawings, where:

FIG. 1 is a schematic diagram showing an embodiment of high-level network architecture for various gateway network configurations; FIG. 2 is a schematic diagram showing an embodiment of a gateway network configuration which includes a gateway server, a PBX telephone system and an IP/PBX telephone system;

FIG. 3A is a schematic diagram showing call routing for a telephone call made between a PSTN telephone and an IP telephone in the same locale according to an embodiment of the present invention;

FIG. 3B is a schematic diagram showing call setup sequence for a telephone call made from an IP telephone to a PSTN telephone along the route shown in FIG. 3 A;

FIG. 3C is a schematic diagram showing call setup sequence for a telephone call made from a PSTN telephone to an IP telephone along the route shown in FIG. 3A;

FIG. 4A is a schematic diagram showing call routing for a telephone call made between a PBX telephone and an IP telephone in the same locale according to an embodiment of the present invention;

FIG. 4B is a schematic diagram showing call setup sequence for a telephone call made from an IP telephone to a PSTN telephone along the route shown in FIG. 4A;

FIG. 4C is a schematic diagram showing call setup sequence for a telephone call made from a PBX telephone to an IP telephone along the route shown in FIG. 4A;

FIG. 5 A is a schematic diagram showing call routing for a telephone call made between one IP telephone and another IP telephone in the same locale according to an embodiment of the present invention;

FIG. 5B is a schematic diagram showing call setup sequence for a telephone call made from one IP telephone to another IP telephone along the route shown in FIG. 5A;

FIG. 5C is a schematic diagram showing an alternate call setup sequence for a telephone call made from one IP telephone to another IP telephone along the route shown in FIG. 5A;

FIG. 6A is a schematic diagram showing call routing for a telephone call made between a PSTN telephone and an IP telephone, with the two telephones in different locales according to an embodiment of the present invention;

FIG. 6B is a schematic diagram showing call setup sequence for a telephone call made from an IP telephone to a PSTN telephone along the route shown in FIG. 6A;

FIG. 6C is a schematic diagram showing call setup sequence for a telephone call made from a PSTN telephone to an IP telephone along the route shown in FIG. 6A;

FIG. 7A is a schematic diagram showing call routing for a telephone call made between a PBX telephone and an IP telephone, with the two telephones in different locales according to an embodiment of the present invention;

FIG. 7B is a schematic diagram showing call setup sequence for a telephone call made from an IP telephone to a PBX telephone along the route shown in FIG. 7A;

FIG. 7C is a schematic diagram showing call setup sequence for a telephone call made from a PBX telephone to an IP telephone along the route shown in FIG. 7A;

FIG. 8 A is a schematic diagram showing call routing for a telephone call made between one IP telephone and another IP telephone, with the two telephones in different locales according to an embodiment of the present invention; FIG. 8B is a schematic diagram showing call setup sequence for a telephone call made from one IP telephone to another IP telephone along the route shown in FIG. 8A;

FIG.9A is a schematic diagram showing call routing for a voice-over-IP telephone call made between a PBX telephone at one locale and an IP telephone at another locale according to an embodiment of the present invention; FIG. 9B shows the telephone call from FIG. 9A after it has been automatically rerouted over the PSTN instead of over the WAN IP network, due to degradation in the quality of service over the WAN;

FIG. 10A is a schematic diagram showing call setup sequence for a telephone call made from a PBX telephone to an IP telephone at that same locale, where a caller using the PBX telephone is redirected to a called party's voice-mail system, due to lack of availability of the called party at the time the call is made;

FIG. 1 OB is a schematic diagram showing call routing resulting from the call setup sequence of FIG. 10A, where the caller has been successful directed to the called party's voice-mail system at the same locale; FIG. 11 A is a schematic diagram showing call routing resulting from the call setup sequence for a telephone call made from a PBX telephone to an IP telephone at another locale, where the caller has been successful directed to the called party's voice-mail system;

FIG. 1 IB is a schematic diagram showing call setup sequence for a telephone call made from the PBX telephone at one locale to the called party's voice-mail system at another locale along the route shown in FIG. 11 A;

FIG. 12 shows how the gateway server polls the voice-mail system at regular intervals (the interval being configurable) in order to be able to keep the IP telephone users' telephones current with regard to whether the voice-mail light on the phone is on or off;

FIG. 13 A is a schematic diagram showing call routing for a telephone call made between a PBX telephone and an IP telephone at the same locale;

FIG. 13B is a schematic diagram showing call routing for a telephone call made between the PBX telephone and an IP telephone at another locale - the condition existing following the call transfer operation on the part of the IP telephone being used in FIG. 13 A;

FIG. 13C is a schematic diagram showing call setup sequence for transferring the telephone call from the route used in FIG. 13A to the route shown in FIG. 13B;

FIG. 14 is a schematic diagram showing call routing for a 3-way conference call between a first party at a PBX telephone at a first locale, a second party at an IP telephone at a first locale, and a third party at an IP telephone at a second locale; and

FIG. 15 is a schematic diagram showing call setup sequence for a telephone call made from an IP telephone to a PBX telephone at the same locale, where the call dialing operation was initiated via a browser-based GUI that is associated with the IP telephone.

Detailed Description

FIG. 1 schematically illustrates an enterprise network according to an embodiment of the present invention for passing voice and data communication between a number of different sites within an enterprise or company. The enterprise network typically includes one or more gateway networks, three which are shown, each having a gateway server, and a PBX telephone system, and or an IP/PBX telephone system. The gateway networks communicate with each other over an internet protocol (IP) network, such as a wide area network (WAN) Network 1 and over the public switched telephone network (PSTN) 2.

In gateway network 10, a gateway server 11 operates in conjunction with a PBX telephone system 12, coordinating both PBX telephone calls and public switched telephone network calls. Gateway networks are described in, for example, commonly assigned co-pending U.S. Pat. Application 09/061,802, which is incorporated herein by reference.

Gateway network 20, includes an IP/PBX telephone system 23 that supports IP telephones (not shown) which can be either stand-alone devices or incorporated into computer work stations. The gateway server 21 coordinates the activities of all the company-internal telephone systems: the PBX telephone system 22 and the IP/PBX telephone system 23. This gateway network 20 configuration is of particularly useful where both PBX and IP telephones are used.

In gateway network 30 has an IP/PBX telephone system 33 is present but no PBX telephone system. This situation is particularly useful for a small branch office for which a conventional PBX would be either impracticable or prohibitively expensive. In this configuration the gateway server 31 is configured quite differently than in the above configurations. Namely, the gateway server 31 includes telephony cards that are configured to communicate directly with the PSTN. The gateway server 31 coordinates the activities the IP/PBX telephone system 33, including its IP telephones and the call routing of said telephones. The gateway server 31 may coordinate with another gateway server 11, 21, in order to provide full services to the users in its network, including for example, PBX-based voice-mail.

FIG. 2 shows a more detailed architecture of gateway network 20 of FIG. 1. The gateway server 21 includes gateway server software 111, a PBX CTI (Computer Telephony Integration) driver 112, a station/trunk driver 113 and a VoIP (Voice over IP) driver 114. The gateway server software 111 manages call set up and routing, access to a directory server 28, user graphical user interface (GUI) updates via a web server, and queries and updates to a database of user profiles and call information. In addition, the gateway server software 111 contains an IP/PBX CTI driver 115, which is a piece of interface software used whenever an IP/PBX call manager 40 is addressed. In the remainder of the description, this piece of software, the IP/PBX CTI driver 115, is implicitly assumed to be involved with every interaction between the gateway server software 111 and the IP/PBX call manager 40 and therefore, for simplicity, will not be shown in the other drawings. The IP/PBX CTI driver 115 is implemented so as to adhere to various interface standards, including by not limited to the Microsoft-touted standard TAPI (Telephony Application Programming Interface).

The gateway server software 111 uses the PBX CTI driver 112 software to support advanced call control and voice-mail access functions. The PBX CTI driver 112 software is typically supplied by (and is specific to) the PBX vendor. The PBX CTI driver 112 communicates with the PBX 30 via the local area network (LAN) 3 connection. The station/trunk driver 113 consists of hardware and software that manage a trunk interface and an analog station interface to the PBX 30. The VoIP driver 114 consists of hardware and software that handles the conversion between the voice data in the format required for the station/trunk driver 113 telephony interface and the IP packet format required by the WAN IP network 1. The VoIP driver 114 is also referred to as simply the gateway, as converting voice data between the IP and switched circuit network (SCN), such as the PSTN, is its' fundamental function.

The PBX 30 provides the interface to the PSTN 2. Continuing to refer to FIG. 2, the PBX telephone system 22 consists of the PBX 30 and one or more PBX telephones 31. Operation of the PBXs and PBX telephones is well known and is discussed in detail in co-pending, commonly assigned U.S. patent application number 09/061,802, which is incorporated herein by reference. The voice-mail system operates in conjunction with the PBX 30. Proper operation of voice-mail server 32, requires CTI driver 112.

FIG. 2 also shows an embodiment of an IP/PBX telephone system 23 which is managed by a centralized server called the IP/PBX call manager 40 according to the present invention. The IP/PBX call manager 40 may reside on its own server platform (as shown), or it may reside on the same platform as the gateway server 21.

Typically, the users of the IP/PBX telephone system 23 are equipped with one of (1) an IP telephone 41, (2) an IP telephone 41 and a work station 50, or (3) a work station 150 that has a built-in IP telephone 141. The IP/PBX call manager 40 first receives a call setup request from an IP telephone user who initiates a call on the IP telephone 41 or 141. If the call is for an extension representing another IP telephone 41 or 141 coupled to the IP/PBX telephone system 23, the IP/PBX call manager 40 connects the two IP telephones so the call can take place. To set up the connection the IP/PBX call manager 40 exchanges information with the gateway server software 111 including caller ID information (normally stored at the gateway server 21). In addition, the gateway server software 111 can log the start of the call to a call log (not shown). If a call is initiated with dialed digits that are not known to the IP/PBX call manager 40, then the IP/PBX call manager 40 passes the call setup request to the gateway server software 111. The gateway server software 111 then determines how to route the call, sets up the other leg of the call, and then returns the information to the IP/PBX call manager 40 of the IP address where the IP telephone 41 or 141 needs to route the IP packets. Throughout the rest of this description, whenever the term "IP telephone" is used, it is understood that this can mean either a stand-alone telephone device or a telephone that is built into a workstation, and these two can be used interchangeably when discussing the function of an "IP telephone". Call Routing and Setup for IP Telephone Calls

There are a number of different paths that must be considered for routing a call involving an IP telephone in IP/PBX telephone system. The different routing paths and the sequence of steps required to establish these routings are described in the next paragraphs. In FIG. 3A an in-progress call is shown between an IP telephone operating in the local network and a PSTN telephone at a location nearby the gateway network's location. Starting with the caller IP telephone 141, the voice data is converted to IP packets there and placed onto the LAN where it is received by the VoIP driver 114 of the gateway server 110. At the VoIP driver 114, the data is removed from the IP packets and the data decoded from whatever encoding and compression format was applied by the caller IP telephone 141. The voice data is then routed via the station/trunk driver 113 to the PBX 130, and the PBX 30 which in turn routes it in an analog format to the PSTN 102 and on through to the PSTN telephone 104.

The voice which travels from the called PSTN telephone 104 to the caller using IP telephone 141 follows the same path, but goes through the process in reverse; at the VoIP driver 114, the voice data is encoded and inserted into IP packets. The data from the IP packets are extracted and decoded by the IP telephone 141.

It should be noted that the same routing path would result if the caller is the PSTN telephone user and the called party is the IP telephone user. In considering how a call such as that shown in FIG. 3A is setup, there are two variations that may be considered, which will result in different sequences of steps in the call setup process. The two variations are (1) when the caller is using the IP telephone 141 and the called party is using the PSTN telephone 104, and (2) when the caller is using the PSTN telephone and the called party is using the IP telephone. The call setup sequence for the caller using an IP telephone calling to a user of a

PSTN telephone is shown in FIG. 3B and described in the subsequent text. Note that in FIG. 3B, and throughout the remainder of the description, the numbered steps are illustrated in the figures by arrows labeled with a corresponding number.

1. User dials on a keypad of the IP telephone 141. The IP telephone 141 communicates with the IP/PBX call manager 140 to request call setup. (Step 301) 2. The IP/PBX call manager 140 communicates to the gateway server software 111 that call setup is requested by an IP telephone 141. The IP/PBX call manager 140 receives the addressing information of the IP telephone 141 in the communication. The gateway server software 111 checks the directory server 28 (shown in FIG. 2), and verifies the user's privilege to access the PSTN 2. (Step 302) 3. The gateway server software 111 communicates call setup request to the station/trunk driver 113. (Step 303)

4. The station trunk driver 113 communicates the setup request to the PBX 30. (Step 304)

5. The PBX 30 dials to the PSTN telephone 104 via the PSTN 102, and the calling party answers the telephone. (Step 305)

6. The gateway server software 111 configures its VoIP driver 114 to begin transmitting voice packets to the address of the IP telephone 141. (Step 306) (Note that step 306 can be done at the same time as steps 303-305.)

7. The gateway server software 111 informs the IP/PBX call manager 140 that the call is going through and provides the addressing information for its VoIP driver

1 14. (Step 307)

8. The IP/PBX call manager 140 informs the IP telephone 141 that the call is going through and passes the addressing information for the VoIP driver 114. The IP telephone is then ready to begin transmitting voice packets to the VoIP driver 114. (Step 308)

The call setup sequence for the caller using a PSTN telephone 104 calling to a user of an IP telephone 141 is shown in FIG. 3C and described in the subsequent text.

1. A user of the PSTN telephone 104 dials an IP telephone user at the company facility with a direct inward dialing (DID) number. The call is routed via the PSTN 102 to the PBX 130. (Step 401)

2. The PBX 30 routes the call to the station/trunk driver 113. (Step 402) 3. The station/trunk driver 113 routes the call setup request to the gateway server software 111. (Step 403)

4. The gateway server software 111 checks its database and finds that the user being dialed has an IP telephone managed by the IP/PBX call manager 140. The gateway server software 111 routes the call setup request to the IP/PBX call manager 140, and it attaches the addressing information of its VoIP driver 114, since the gateway server software 111 determines that the voice stream will need to be routed via that driver. (Step 404)

5. The IP/PBX call manager 140 finds that the particular IP telephone 141 is not currently in use, and thus forwards the call setup request, along with the addressing information of the VoIP driver 114, to the IP telephone 141. The IP telephone 141 configures itself to begin routing IP voice packets to the VoIP driver 114 in the event that the called party answers the call. (Step 405)

6. The IP/PBX call manager 140 sends and acknowledgment back to the gateway server software 111, including the addressing information of the IP telephone

141. (Step 406)

7. The gateway server software 111 commands its VoIP driver 114 to configure itself to begin sending voice packets to the IP telephone 141. (Step 407)

8. The gateway server software 111 configures the station/trunk driver 113 to route the voice stream to the VoIP driver 114. (Step 408)

FIG. 4A shows the call routing for a telephone call made between a PBX telephone and an IP telephone in the same locale.

FIG. 4B shows the call setup sequence for a telephone call made from an IP telephone to a PBX telephone in the same locale. The call setup sequence is as follows: 1. A user of the IP telephone 141 dials, and the IP telephone 141 sends a call setup request to the IP/PBX call manager 140. (Step 501)

2. The IP/PBX call manager 140 receives the call setup request and forwards it to the gateway server software 111. (Step 502)

3. The gateway server software 111 checks its database and finds the called party has a PBX telephone 131 , so it sends a call setup request to the station trunk driver

113. (Step 503) 4. The station trunk driver 113 forwards the call setup request to the PBX 130. (Step 504)

5. The PBX 130 calls the PBX telephone 131 of the called party. (Step 505)

6. The gateway server software 111 configures its VoIP driver with the address of the IP telephone 141, and the VoIP driver gets ready to start transmitting voice

IP packets to that address. (Step 506)

7. The gateway server software 111 responds back to the IP/PBX call manager 140 that its part of the call has been successfully setup, and it forwards the address of its VoIP driver 114. (Step 507) 8. The IP/PBX call manager 140 responds to the IP telephone 141, forwarding it the address of the VoIP driver 114. The IP telephone 141 then configures itself to begin routing IP voice packets to the VoIP driver 114. (Step 508)

The call setup sequence for the caller using a PBX telephone calling to a user of an IP telephone is shown in FIG. 4C and described in the subsequent text. 1. A user of the PBX telephone 131 dials an IP telephone user at the same company facility using the extension only to dial, or using an on-net number. The call is routed to the PBX 130. (Step 601)

2. The PBX 30 routes the call to the station/trunk driver 113. (Step 602)

3. The station/trunk driver 113 routes the call setup request to the gateway server software 111. (Step 603)

4. The gateway server software 111 checks its database and finds that the user being dialed has an IP telephone managed by the IP/PBX call manager 140. The gateway server software 111 routes the call setup request to the IP/PBX call manager 140, and it attaches to the request the addressing information of its VoIP driver 114, since the gateway server software 111 determines that the voice stream will need to be routed via that driver. (Step 604)

5. The IP/PBX call manager 140 finds that the particular IP telephone 141 is not currently in use, and thus forwards the call setup request, along with the addressing information of the VoIP driver 114, to the IP telephone 141. The IP telephone 141 configures itself to begin routing IP voice packets to the VoIP driver 114 in the event that the called party answers the call. (Step 605) 6. The IP/PBX call manager 140 sends an acknowledgment back to the gateway server software 111, including the addressing information of the IP telephone 141. (Step 606)

7. The gateway server software 111 commands its VoIP driver 114 to configure itself to begin sending voice packets to the IP telephone 141. (Step 607)

8. The gateway server software 111 configures the station/trunk driver 113 to route the voice stream to the VoIP driver 114. (Step 608)

FIG. 5A shows the call routing for a telephone call made between one IP telephone 141 and another IP telephone 241 in the same locale. FIG. 5B shows the call setup sequence for a telephone call made from one IP telephone 141 to another IP telephone 241 in the same locale.

1. A user of the IP telephone 141 dials, and the IP telephone 141 sends a call setup request to the IP/PBX call manager 140. (Step 701)

2. The IP/PBX call manager 140 receives the call setup request and forwards it to the gateway server software 111. (Step 702)

3. The gateway server software 111 checks its database and finds that the user being dialed has an IP telephone 241managed by the IP/PBX call manager 140. The gateway server software 111 provides the addressing information to the IP/PBX call manager 140. (Step 703) 4. The IP/PBX call manager 140 begins routing IP voice packets to the IP telephone 241 (Step 704) and to IP telephone 141 (Step 705).

FIG.5C shows an alternate (and less preferred) call setup sequence for a telephone call made from one IP telephone 141 to another IP telephone 241 in the same locale.

1. A user of the IP telephone 141 dials, and the IP telephone 141 sends a call setup request to the IP/PBX call manager 140. (Step 801)

2. The IP/PBX call manager 140 receives the call setup request and finds that the user being dialed has an IP telephone 241managed by the IP/PBX call manager 140.

(Step 802)

3. The IP/PBX call manager 140 provides the addressing information to IP telephone 141, and IP telephone 141 begins routing IP voice packets to IP telephone 241.

(Step 803) FIG. 6A shows the call routing for a telephone call made between a PSTN telephone 104 and an IP telephone 241, with the two telephones in different locales.

FIG. 6B shows the call setup sequence for a telephone call made from an IP telephone 241 to a PSTN telephone 104, with the two telephones in different locales. L A user of the IP telephone 141 dials, and the IP telephone 141 sends a call setup request to the IP/PBX call manager 140. (Step 901)

2. The IP/PBX call manager 140 receives the call setup request and forwards it to the gateway server software 111. (Step 902)

3. The gateway server software 111 checks its database and finds that the user being dialed has a PSTN telephone 104 nearby another gateway network 110. The gateway server software 211 connects to gateway server software 111 in the other gateway network via the WAN 101. (Step 903)

4. The gateway server software 111 sends a call setup request to the station/trunk driver 113. (Step 904) 5. The station/trunk driver 113 forwards the call setup request to the PBX

130. (Step 905)

6. The PBX 130 calls the PSTN telephone 104 of the called party. (Step 906)

7. The gateway server software 111 configures its VoIP driver with the address of the IP telephone 141, and the VoIP driver gets ready to start transmitting voice IP packets to that address. (Step 907)

8. The gateway server software 111 responds back to the gateway server software 211 that its part of the call has been successfully setup, and it forwards the address of its VoIP driver 214. (Step 908)

9. The gateway server software 211 forwards the address of its VoIP driver 214 to the IP/PBX call manager 240. (Step 909)

10. The IP/PBX call manager 240 responds to the IP telephone 241, forwarding it the address of the VoIP driver 214. The IP telephone 241 then configures itself to begin routing IP voice packets to the VoIP driver 114. (Step 910)

FIG. 6C shows the call setup sequence for a telephone call made from a PSTN telephone 104 to an IP telephone 241, with the two telephones in different locales.

1. A user of the PSTN telephone 104 dials and sends a call setup request to the PBX 130 via the PSTN 102. (Step 1001)

2. The PBX 130 routes the call to the station/trunk driver 113. (Step 1002)

3. The station/trunk driver 113 routes the call setup request to the gateway server software 111. (Step 1003) 4. The gateway server software 111 checks its database and finds that the user being dialed has a PSTN telephone 104 nearby another gateway network 210. The gateway server software 111 connects to gateway server software 211 in the other gateway network via the WAN 101. (Step 1004)

5. The gateway server software 211 checks its database and finds that the user being dialed has an IP telephone managed by the IP/PBX call manager 240. The gateway server software 211 routes the call setup request to the IP/PBX call manager 240, and it attaches to the request the addressing information of its VoIP driver 214, since the gateway server software 211 determines that the voice stream will need to be routed via that driver. (Step 1005) 6. The IP/PBX call manager 240 responds to the IP telephone 241, forwarding it the address of the VoIP driver 214. The IP telephone 241 then configures itself to begin routing IP voice packets to the VoIP driver 114. (Step 1006)

7. The IP/PBX call manager 240 sends an acknowledgment back to the gateway server software 211, including the addressing information of the IP telephone 241. (Step 1007)

8. The gateway server software 211 responds back to the gateway server software 111 that its part of the call has been successfully setup, and it forwards the address of its VoIP driver 114. (Step 1008)

9. The gateway server software 111 configures its VoIP driver 114 with the address of the IP telephone 241 , and the VoIP driver gets ready to start transmitting voice

IP packets to that address. (Step 1009)

FIG. 7A shows the call routing for a telephone call made between a PBX telephone 131 and an IP telephone 241, with the two telephones in different locales.

FIG. 7B shows the call setup sequence for a telephone call made from an IP telephone 241 to a PBX telephone 131, with the two telephones in different locales.

1. A user of the IP telephone 241 dials, and the IP telephone 241 sends a call setup request to the IP/PBX call manager 240. (Step 1101)

2. The IP/PBX call manager 240 receives the call setup request and forwards it to the gateway server software 211. (Step 1102)

3. The gateway server software 211 checks its database and finds that the user being dialed has a PBX telephone 131 managed by another gateway network 110. The gateway server software 211 connects to gateway server software 111 in the other gateway network via the WAN 101. (Step 1103)

4. The gateway server software 111 sends a call setup request to the station trunk driver 113. (Step 1104) 5. The station/trunk driver 113 forwards the call setup request to the PBX

130. (Step 1105)

6. The PBX 130 calls the PBX telephone 131 of the called party. (Step 1106)

7. The gateway server software 111 configures its VoIP driver 114 with the address of the IP telephone 241 , and the VoIP driver gets ready to start transmitting voice IP packets to that address. (Step 1107)

8. The gateway server software 111 responds back to the gateway server software 211 that its part of the call has been successfully setup, and it forwards the address of its VoIP driver 114. (Step 1108)

9. The gateway server software 211 forwards the address of its VoIP driver 214 to the IP/PBX call manager 240. (Step 1109)

10. The IP/PBX call manager 240 responds to the IP telephone 241, forwarding it the address of the VoIP driver 214. The IP telephone 241 then configures itself to begin routing IP voice packets to the VoIP driver. (Step 1110)

FIG. 7C shows the call setup sequence for a telephone call made from a PBX telephone 131 to an IP telephone 241, with the two telephones in different locales.

1. A user of the PBX telephone 131 dials and sends a call setup request to the PBX 130. (Step 1201)

2. The PBX 130 routes the call to the station/trunk driver 113. (Step 1202)

3. The station/trunk driver 113 routes the call setup request to the gateway server software 111. (Step 1203)

4. The gateway server software 111 checks its database and finds that the user being dialed has an IP telephone 241 managed by another gateway network 210. The gateway server software 111 connects to gateway server software 211 in the other gateway network via the WAN 101. (Step 1204)

5. The gateway server software 211 checks its database and finds that the user being dialed has an IP telephone managed by the IP/PBX call manager 240. The gateway server software 211 routes the call setup request to the IP/PBX call manager 240, and it attaches to the request the addressing information of its VoIP driver 214, since the gateway server software 211 determines that the voice stream will need to be routed via that driver. (Step 1205) 6. The IP/PBX call manager 240 responds to the IP telephone 241, forwarding it the address of the VoIP driver 214. The IP telephone 241 then configures itself to begin routing IP voice packets to the VoIP driver 114. (Step 1206)

7. The IP/PBX call manager 240 sends an acknowledgment back to the gateway server software 211, including the addressing information of the IP telephone 241. (Step 1207)

8. The gateway server software 211 responds back to the gateway server software 111 that its part of the call has been successfully setup, and it forwards the address of its VoIP driver 114. (Step 1208)

IP packets to that address. (Step 1209)

FIG. 8A shows the call routing for a telephone call made between one IP telephone 141 and another IP telephone 241, with the two telephones in different locales.

FIG. 8B shows the call setup sequence for a telephone call made from one IP telephone 141 to another IP telephone 241, with the two telephones in different locales.

1. A user of the IP telephone 241 dials, and the IP telephone 241 sends a call setup request to the IP/PBX call manager 240. (Step 1301)

2. The IP/PBX call manager 240 receives the call setup request and forwards it to the gateway server software 21 1. (Step 1302) 3. The gateway server software 211 checks its database and finds that the user being dialed has an IP telephone 141 managed by another gateway network 110. The gateway server software 211 connects to gateway server software 111 in the other gateway network via the WAN 101. (Step 1303)

4. The gateway server software 111 sends a call setup request to the IP/PBX call manager 140. (Step 1304) 5. The IP/PBX call manager 140 forwards the call setup request to the IP telephone 141. (Step 1305)

6. The gateway server software 111 responds back to the gateway server software 211 that its part of the call has been successfully setup, and it forwards the address of its VoIP driver 114. (Step 1306) 7. The gateway server software 211 forwards the address of its VoIP driver

214 to the IP/PBX call manager 240. (Step 1307)

8. The IP/PBX call manager 240 responds to the IP telephone 241, forwarding it the address of the VoIP driver 214. The IP telephone 241 then configures itself to begin routing IP voice packets to the VoIP driver. (Step 1308)

Features

In this section we discuss the various features that can be provided features to users of IP telephones 141 , 241 , coupled to the IP/PBX telephone system 33 in accordance with an embodiment of the present invention. Many of these features are also described in co-pending, commonly assigned U.S. patent application number 09/061 ,802, which is incorporated herein by reference. Automated Call Control Features

Quality of Service Monitoring

As discussed in co-pending, commonly assigned U.S. patent application number 09/061,802, which is incorporated herein by reference, there are quality of service indicators which are placed in the IP voice packets at the time when the packets are generated in preparation for routing onto the LAN. At the later point in the call path routing, when the data in the IP packets are extracted and decoded, the quality of service indicators are assessed to determine if a reasonable quality for the voice conversation is being maintained. In U.S. patent application number 09/061,802, the VoIP call routing paths and the voice IP packets are generated/encoded by the VoIP driver 114 in one gateway server 110 and extracted/decoded by the VoIP driver in another gateway server 120.

With the introduction of the IP/PBX telephone system 33, the quality of service (QoS) determination may involve two separate legs of the IP network. For example, consider the call path shown in FIG. 9A; the voice IP packets that are generated at the IP telephone 241 are de-packetized decoded at the VoIP driver 114. Thus, it is important that the multiple vendors agree on the required QoS threshold. Assuming that both the VoIP driver vendor and the IP telephone vendor agree on how to use QoS, then an assessment must be made as to where in the call path the quality degradation is taking place. If it is determined that the degradation is occurring on the WAN IP Network 101, (as opposed to on the LAN), then the communication stream currently using the WAN IP Network can be moved out onto the PSTN 102, fallback to PSTN, as is described below and in U.S. patent application number 09/061,802, which is incorporated herein by reference. In order to detect a problem of the WAN, the VoIP driver 114 of the invention continues to monitor QoS for the entire path segment over which voice IP packets travel. For example, referring to FIG. 9 A, the VoIP driver 114 monitors the QoS of packets generated at IP telephone 241. If the QoS for this entire segment degrades to a given threshold, the VoIP driver communicates this to the gateway server software 111. The gateway server software 111 then initiates a secondary simple test of the QoS between the two gateway servers (the gateway server 210 of the caller and the gateway server 110 of the called party). This secondary test may involve sending bursts of IP packets over the WAN IP network 101 and having the VoIP drivers 114 and 214 on either end assess the QoS. Alternatively the test may be more simplistic, such as issuing a series of "ping" commands across the WAN IP network 101, between the two gateway servers 110 and 210. If the secondary QoS test indicates performance degradation on the WAN 101 , then fallback to PSTN is initiated. If the secondary QoS indicates no degradation, then the problem is on the LAN. In this case there is little that the gateway server can do to alleviate said problem, other than alarm to an external system, such as a network management system. Such an alarm, in more sophisticated network configurations, could activate load-balancing algorithms which might eliminate high-load network activities or users.

Fallback to PSTN

Five different methods for the fallback to PSTN are discussed in co-pending, commonly assigned U.S. patent application number 09/061,802, which is incorporated herein by reference, page 44 line 1 through page 49 line 31. The differences between the methods are related primarily to the variations in PBX configurations. In considering how a fallback would be enacted in a VoIP call routing path involving an IP telephone, reference FIG. 9A. The methods in U.S. patent application number 09/061,802, are the same when applied to the PBX telephone user at one end of the call. For the IP telephone user at the other end of the call, some additional method must be described.

Consider that FIG. 9A illustrates an original VoIP call involving an IP telephone 241, and that FIG. 9B illustrates the modified call path once the fallback to PSTN operation has been completed. The path of the call now flows from PBX telephone 131 at a first location through the PBX 130, loops through the station trunk driver 113 and back into the PBX 130 (using a second port in the PBX 130) and out into the PSTN 102. The PSTN 102 at the second site feeds the call into PBX 230 and then into station/trunk driver 213, where it is routed through VoIP driver 214 and finally on to the IP telephone 241. One way that the fallback to PSTN operation can be accomplished is as follows.

The sequence of events starts when the VoIP driver 114 in gateway server 110 detects QoS degradation on the call path (between VoIP driver 114 and IP telephone 214), and gateway server software 111 is notified of this issue. Next, gateway server software 111 coordinates the execution of a secondary test by exchanging packets between its VoIP driver 114 and the VoIP driver 214 of the gateway server 210. This test again indicates serious degradation, so the gateway server software 111 initiates a fallback to PSTN. First it announces its intention via a notification sent to the caller gateway server software 211. The caller gateway server 210 then coordinates with the called gateway server 110 to setup a PSTN call between the two gateway servers 110 and 210 via the PBXs 130 and 230. (Further details of this can be found in co-pending, commonly assigned U.S. patent application number 09/061,802, at page 46, line 24 through page 47, line 11) As soon as the PSTN call is setup between the two gateway servers, the gateway server software 211 must command the IP telephone 241, via its associated IP/PBX call manager 240, to start routing its packets to the local VoIP driver 214 instead of the remote VoIP driver 114. The modified call path is now complete and the users' conversation can continue.

Multiple IP/PBX System Vendors Supported

The invention supports more than one equipment vendor for the IP/PBX system 33. For example, the vendor of the IP/PBX system 33 associated with one gateway network 20 may differ from the vendor of the IP/PBX system associated with another gateway network 30. To accomplish this both IP/PBX systems must support and be using the same kind of encoding and compression algorithms and they must further support the same voice over IP protocol, for example H.323.

Usability Features Direct Inward Dialing for IP Telephone Users

The gateway server 31 of the present invention, with its tight integration to the PBX 30, and its ability to coordinate call setup with the IP/PBX call manager 40 of the IP/PBX telephone system 33, also provides a unique capability to support direct inward dialing (DID) to the IP telephone users. Current IP/PBX telephone systems 33 support a direct inward dialing capability only via another specialized piece of equipment which must be separately purchased. A cheaper solution, made possible by the gateway server of the present invention, is to configure phantom PBX ports (not shown) on the PBX 30. A PSTN phone number is associated with a PBX phantom port for each IP telephone user, and (as the PBX 30 has already been configured to operate with the gateway server 20, 30), all calls incoming from the PSTN 2 are routed from the phantom port to the gateway server 20, 30. The gateway server 20, 30, maintains the association of the PBX DID phone number to the IP telephone extension, and thus routes the call to the IP/PBX call manager 40 for processing, and the IP/PBX call manager in turns routes the call to the IP telephone. In the event that the IP/PBX call manager determines that the IP telephone 41 is for some reason unavailable, i.e. the user may already be engaged in a telephone conversation, then the gateway server 20, 30 of the present invention further provides voice-mail capability for the IP telephone user.

Unified Voice-mail

The current integration implementation of IP/PBX telephone systems with PBX telephone systems has a major drawback in that separate voice-mail systems are used for the IP telephone users and the PBX telephone users. For example, the users of the PBX telephones use the PBX-associated voice-mail. For PBX voice-mail, there are currently two major vendors, Octel and Audix, which have both been in the business for a long time and have quite matures products. For the IP-based voice-mail, there is less standardization, and the available products are less mature and do not scale as well as the PBX voice-mail products do. Having two different voice-mail systems at the same company site creates problems for the users. For example, a user cannot forward voice- mail between the systems, and the voice-mail features and commands are likely to differ between the different systems. Furthermore, the multiple voice-mail systems require separate system administration for the each different voice-mail system.

The invention solves this problem by allowing all users, including the IP/PBX telephone users, access to the fully scalable and mature PBX voice-mail system. The system of the invention can be configured to automatically re-route to the PBX voice-mail if the IP/PBX telephone user does not pick up after a certain number of rings (such as 4 or 5), or if the called party is otherwise unavailable. The method of implementation involves assigning each IP telephone user a port in the PBX telephone system. Since the port is not physically connected with a telephone, it is termed a "phantom" port.

FIG. 10A shows a sample call setup flow for a call attempt from a caller PBX telephone 130 to the called IP telephone 141, where the IP telephone 141 is found to be busy, and the call is thus routed to the called party's voice-mail system 125. Both caller and called parties are located at the same site and associated with the same gateway server

110.

1. A user at the caller PBX telephone 131 dials to the called IP telephone 141 user at the same company facility using the extension to dial. The call is routed to the PBX 130. (Step 1401)

2. The PBX 130 finds that the called number corresponds to an extension it manages, so it routes to that extension's port. The called party's port (actually a phantom port with no telephone attached) is configured to automatically forward all calls over to the gateway server 110, so the call is routed to the station trunk driver 113. (Step 1402)

3. The station/trunk driver 113 routes the call setup request to the gateway server software 111. (Step 1403)

4. The gateway server software 111 checks its database and finds that the user being dialed has an IP telephone 141 managed by the IP/PBX call manager 140. The gateway server software 111 routes the call setup request to the IP/PBX call manager 140, and it attaches to the request the addressing information of its VoIP driver 114, since the gateway server software 111 determines that the voice stream will need to be routed via that driver. (Step 1404)

5. The IP/PBX call manager 140 finds that the particular IP telephone 141 is unavailable for use (for example, it may be busy, or a "do not disturb" setting may have been enabled by the user). The IP/PBX call manager 140 thus responds back to the gateway server software 111 that the called IP telephone 141 is unavailable, and thus the call cannot be handled. (Step 1405)

6. The gateway server software 111 now decides to route the call to the voice- mail system, so it first commands the CTI driver 112 to reconfigure the PBX 130 so that the forwarding of the call on that port goes directly to voice-mail. (Step 1406) 7. The CTI driver 112 commands the PBX 130 to reconfigure itself so that the forwarding of the call on that port goes directly to voice-mail. (Step 1407)

8. The gateway server software 111 commands the station/trunk driver 113 to route the call to the PBX 130. (Step 1408)

9. The station/trunk driver 113 routes the call to the PBX 130. (Step 1409) 10. The PBX 130 has been configured with a phantom PBX port for the called party. Since there is no physical telephone attached to that port, the call is routed directly to the voice-mail system 125. (Step 1410)

11. Meanwhile, the gateway server software 111 commands the CTI driver 112 to have the PBX 130 re-configure the phantom port of the called party back to its original state, which is to forward calls to the gateway server software 111. (Step 1411)

12. The CTI driver 112 commands the PBX 130 to re-configure the phantom port of the called party back to its original state. The PBX 130 performs the reconfiguration, so it is now ready for the next incoming call for that extension. (Step 1412)

FIG. 1 OB shows the completed call routing from the caller ' s PBX telephone to the called party's voice-mail. The voice routing is from the caller PBX telephone 131 through the caller ' s PBX port in the PBX 130, loops through the station/trunk driver 113, back into the PBX 130, and finally into the voice-mail system 125 via the called party's

PBX phantom port.

The case for routing between different sites is somewhat more complex. FIG. 11 A shows the completed routing of a call made by a PBX user at one site, through the VoIP network, to the voice-mail system of an IP telephone user at a remote site. In more detail, the voice routing is from the caller PBX telephone 131 through the caller's PBX port in the PBX 130, through the station/trunk driver 113 and the VoIP driver 114, through the WAN IP network 101 to the other site, through the VoIP driver 214 and the station/trunk driver 213, to the PBX 230, and finally into the voice-mail system 225 via the called party's PBX phantom port.

FIG. 1 IB shows a call setup flow corresponding to the voice path shown in FIG. 11 A. The caller at caller PBX telephone 131 makes a call to the called IP telephone 241 , where the called IP telephone 241 is found to be unavailable, and the call is thus routed to the called party's voice-mail system 225. 1. A user at the caller PBX telephone 131 dials to the called IP telephone 241 user at a different company facility using an on-net number to dial. The call is routed to the PBX 130. (Step 1501)

2. The PBX 130 routes the call to the station trunk driver 113. (Step 1502)

3. The station/trunk driver 113 routes the call setup request to the gateway server software 111. (Step 1503)

4. The gateway server software 111 checks its database and finds that the user being dialed is located at another company facility, under the purview of the gateway server 210. The gateway server software 111 forwards the call setup request to the gateway server software 211 via the WAN IP network 101. (Step 1504) 5. The gateway server software 211 checks its database and finds that the user being dialed has an IP telephone managed by the IP/PBX call manager 240. The gateway server software 211 routes the call setup request to the IP/PBX call manager 240, and it attaches to the request the addressing information of the VoIP driver 114, since the gateway server software 211 determines that the voice stream will need to be routed via that driver (assuming the called party is available for the call). (Step 1505) 6. The IP/PBX call manager 240 finds that the particular IP telephone 241 is currently unavailable, and thus responds back to the gateway server software 211 that the called IP telephone 241 is busy, and thus the call cannot be handled. (Step 1506)

7. The gateway server software 211 now decides to route the call to the voice- mail system 225, so it first commands the CTI driver 212 to reconfigure the PBX 230 so that the forwarding of the call on that port goes directly to voice-mail. (Step 1507)

8. The CTI driver 212 commands the PBX 230 to reconfigure itself so that the forwarding of the call on that port goes directly to voice-mail. (Step 1508)

9. The gateway server software 211 commands the station/trunk driver 213 to route the call to the PBX 230. (Step 1509) 10. The station trunk driver 213 routes the call to the PBX 230. (Step 1510)

11. The PBX 230 has been configured with a phantom PBX port for the called party. Since there is no physical telephone attached to that port, the call is routed directly to the voice-mail system 225.

12. The gateway server software 211 configures its VoIP driver 214 to begin routing voice packets to the address of VoIP driver 114. (Step 1512)

13. The gateway server software 211 responds back to the gateway server software 111 with the addressing information of the VoIP driver 214. (Step 1513)

14. The gateway server software 111 configures its VoIP driver 114 to begin routing voice packets to the address of VoIP driver 214. (Step 1514) 15. The gateway server software 111 configures its station trunk driver 113 to route the call over to the VoIP driver 114. The call routing is now complete. (Step 1551)

16. Meanwhile, the gateway server software 211 commands the CTI driver 212 to have the PBX 230 re-configure the phantom port of the called party back to its original state, which is to forward calls to the gateway server software 211. (Step 1516) 17. The CTI driver 212 commands the PBX 230 to re-configure the phantom port of the called party back to its original state. The PBX 230 performs the re- configuration, so it is now ready for the next incoming call for that extension. (Step 1517)

FIG. 12 shows how the gateway server 110 polls the voice-mail system 125 at regular intervals (the interval being configurable) in order to be able to keep the IP telephone users' telephones current with regard to whether the voice-mail light on the phone is on or off.

1. The gateway server software 111 makes a request to the CTI driver 112 to request the status of the voice-mail for a particular user. (Step 1601)

2. The CTI driver 112 passes on the voice-mail status request to the PBX 130. (Step 1602)

3. The PBX 130 commands the voice-mail server 125 to return the information of whether said user has voice-mail in the voice mailbox. (Step 1603)

4. The voice-mail server 125 responds to the PBX 130 with a yes/no status. (Step 1604) 5. The PBX 130 routes the status response back to the CTI driver 112. (Step

1605)

6. The CTI driver 112 routes the status response to the original requestor of the status, the gateway server software 111. (Step 1606)

7. The gateway server software 111 maintains the state voice-mail status for each voice-mail-enabled IP telephone user. It now checks its database to see if the new status represents a change from the previous status. If there is no change, the next two steps are not executed. If there is a change, the gateway server software 111 logs the change into its database and forwards the status update to the IP/PBX call manager 140. (Step 1607) 8. The IP/PBX call manager 140 commands the IP telephone to turn its voice- mail indicator light to either ON or OFF, depending on the received status. (Step 1608) Unified Dialing Plan

The discussion of numbering plans described in co-pending, commonly assigned U.S. patent application number 09/061,802, which is incorporated herein by reference, page 33, line 14 to page 35, line 31 apply equally to the embodiment of the invention which includes an IP telephone network. For example, a UNP (unified numbering plan) or an ETN (enterprise telephone number) scheme can be implemented using the voice gateway system of the invention coupled with the IP telephone system.

A configuration where some users in a network are equipped with IP telephones as their primary telephones, while others have PBX telephones, can be handled seamlessly by the gateway server invention. The dialing plan can be coordinated such that both PBX telephone users and IP telephone users at the same site can have the same location ID, with possibly different extension ranges. At a site, any user (PBX or IP telephone) can call any other user (PBX or IP telephone) using the extension only to dial. Users at other enterprise sites make calls to both kinds of telephones, dialing 8 + location ID + extension (in an ETN scheme), and the callers are not required to know which kind of telephone a particular user has.

Alternatively, if some or all of the IP telephone users are at a small branch site, the telephones at the branch site may be configured with a different location ID. The invention could then be configured such that users at the main site would be able to dial either 8 + location ID + extension or simply an extension. Having either scheme available might be a good transition for an enterprise that is moving toward the more flexible and easy to manage ETN type plan.

The invention implements the dialing plan within the gateway server.

In one embodiment of the invention, all calls made by IP telephone users to other IP telephone users in the same IP/PBX telephone system are handled completely within the IP/PBX telephone system coordinated by the IP/PBX call manager, while all other calls are routed to the gateway server for interpretation or translation. Existing IP/PBX telephone systems are generally designed to follow such a scheme, where dialing IP telephone to IP telephone is handled within the IP/PBX telephone system by the IP/PBX call manager (refer to FIG. 2), and such systems typically support different variations for how other calls are handled. In fact, the lack of a standard way to handle calls to non-IP telephones calling out can create difficulties and complexity for the network administrator when integrating an IP telephone system (or multiple IP telephone systems) into the existing telephone system. Use of the invention makes this easier, since the dialing plan for the entire enterprise is coordinated in one place, in the gateway server.

In another embodiment of the invention, all calls made by IP telephone users are routed by the IP/PBX call manager directory into the gateway server for interpretation or translation. This preferred embodiment of the invention has the same advantages as the previously described embodiment, and furthermore has additional integration advantages, including the ability to have a complete and unified call log, and the ability to have a consistent caller ID format across the enterprise. If not every call goes to the gateway server, then the logging done by the gateway server will be missing some calls, which renders the call log data less useful. Similarly, if the caller ID information is always inserted or appended into the call setup request, as is possible with this preferred embodiment, then the format of the caller ID information as well as the actual caller ID data can be maintained in a single central location. The alternative (as would be required in the previously described embodiment) would be to maintain caller ID format in the both the call manager and the centralized gateway server, and to maintain the IP telephone user directory information in both the call manager and in the enterprise directory. Caller ID As described in co-pending, commonly assigned U.S. patent application number

09/061,802, which is incorporated herein by reference, the integration of the gateway server with an enterprise directory provides a central repository for modifying user information. User information includes many different attributes describing the particular user, including name and office extension number for the user; (refer to "Table 9: White Pages" in co-pending, commonly assigned U.S. patent application number 09/061,802, which is incorporated herein by reference, which shows attributes of user records within the directory). Additional attributes are added to support the additional user information required to be maintained regarding a user's IP telephone. Table 1 shows a set of additional attributes that are used to support the IP/PBX telephone system's inclusion in

the gateway server's network.

Table 1 : New White Pages Attributes for Extended Invention On Calls Incoming to IP Telephones

Since, (in the preferred embodiment of the invention), the call setup for all calls made to the IP telephones is done under the coordination of the gateway server software, which accesses the enterprise directory, the caller ID and name display information are always added to the incoming call setup request, which flows from the gateway server to the IP/PBX call manager to the IP telephone, where it is shown on the IP telephone display. On Calls Outgoing from IP Telephones

Outgoing calls from the IP telephone can support the caller ID, as long as the call is routed to the gateway server, which can then look up the caller ID information in its database and forward it to the called party, and the information can thus be displayed as described in the invention of co-pending, commonly assigned U.S. patent application number 09/061,802, which is incorporated herein by reference. At Browser Application, Incoming Calls

Calls which are routed through to either IP telephones or mobile telephones are routed through the gateway server. The gateway server has the knowledge as to which users currently are logged in to the gateway server via the browser GUI interface on the users' PCs. If a browser interface is up for the given user, the gateway server will cause the browser GUI to display the caller ID and name display information for the call as part of a pop-up dialog window. Common Caller ID Format A unique advantage of the approach described, for always relying on the caller ID and name information to be inserted by the voice gateway invention, is that a common format for the identification information can be maintained across several different departments and phone systems of an enterprise. Call Control Features Available at IP Telephone

Since the IP telephone should be a convenient alternative to having a PBX telephone, the same call control features generally available to the PBX telephone user should also be available to the IP telephone user. Hold/Retrieve If the IP/PBX telephone system supports it, a second call can be routed to the user while a call is already in progress. The second call may be signaled to the IP telephone user by another ring or by a special tone played over the incoming voice, and the caller ID for the new caller may be shown on the display of the IP telephone. If the IP telephone user wishes to, he may verbally ask the original caller to hang on, and then dial a sequence, such as "*5" to put the first caller on hold and answer the new caller. Subsequently, the IP telephone user may dial another sequence, such as "*6" to retrieve the original and resume that conversation. Transfer

The transfer of a call from the called party using an IP telephone to another caller in the enterprise can be accomplished by the invention under coordination of the gateway server. Consider FIG. 13 A and 12B. FIG. 13 A shows a call in progress from a caller on a PBX telephone 131 to a called party using an IP telephone 141 in the network of the same gateway server. FIG. 13B shows the end result of the IP telephone 141 user's action to transfer the call to another user at IP telephone 241 within the enterprise. In this case the second called user is located at another site, and thus the resulting routing is accomplished via the IP network 101.

An example of the steps describing how the transfer of the call is accomplished by the system are shown in FIG. 13C and described in the following sequence of steps:

1. During a conversation with the caller at PBX telephone 131 , the called user at IP telephone 141 determines that the caller should be transferred to speak with a third party at IP telephone 241 at another site. So the caller keys a special sequence, such as "*3" followed by the location ID and extension of the third party (on-net dialing), and the transfer request is passed on to the IP/PBX call manager 140. (Step 1701)

2. The key sequence is interpreted by the IP/PBX call manager 140 which forwards the transfer request to the gateway server software 111. (Step 1702) 3. The gateway server software 111 forwards the transfer setup request to the remote gateway server software 211 with the given location ID defined in the dialed digits and the extension. (Step 1703)

4. The remote gateway server software 211 checks its database and determines that the called party is in its gateway network, and on an IP telephone. The remote gateway server software 211 makes a call setup request to the IP/PBX call manager 240, and passes also the address of the VoIP driver 114 of the gateway server 110. (Step 1704)

5. The IP/PBX call manager 240 issues a call setup request to the IP telephone 241, which in turns rings the telephone and configures itself to begin shipping voice packets back to the VoIP driver 114. (Step 1705)

6. The IP/PBX call manager 240 responds back to the gateway server software 211 and includes the addressing information for IP telephone 241. (Step 1706)

7. The remote gateway server software 211 sends a response back to the local gateway server software 111 with the address of the IP telephone 241. (Step 1707) 8. The gateway server software 111 commands its VoIP driver 114 to start routing the voice packets to the IP telephone 241. (Step 1708)

9. The gateway server software 111 messages to the IP/PBX call manager 140 that it can take down its leg of the call. (Step 1709)

10. The IP/PBX call manager 140 relays this information to the IP telephone 141, and the user at this telephone now knows that the transfer has completed OK. (Step

1710) Forwarding

Call forwarding is handled by the gateway server as is discussed in co-pending, commonly assigned U.S. patent application number 09/061,802, which is incorporated herein by reference. The model is easily extended to handle the IP telephones. As an example, consider a user who has his "follow-me" configured to route calls first to his IP telephone, and secondly to a secretary's desk. An incoming call is routed by the gateway server to the IP/PBX call manager, and in turn to the IP telephone. If after several rings the IP telephone user doesn't answer, the IP/PBX call manager stops the ringing and routes a negative acknowledgment back to the gateway server. The gateway server receives the acknowledgment and then routes the call via PBX to the secretary's desk telephone. Conferencing

Call conferencing is also coordinated through the gateway server. If both the IP/PBX telephone system and the PBX telephone system support conference calling, then conferencing of multiple callers can be supported. FIG. 14 shows an example of a 3-way conference call in progress. The first caller at the PBX telephone 131 has called a co- worker at an IP telephone 141 (the second party). After their call was established, a third party, calling from an IP telephone 241 at a remote office, joins the conversation. In the implementation shown, there are three call paths setup. In the integrated system shown, each of PBX telephone 131, IP telephone 141, and IP telephone 241 have the capability to combine the two incoming voice streams as needed, or select the stream with voice on it and provide that to the user. At the PBX telephone 131, the CTI driver 112 may be working with the PBX 130 to implement the conferencing, for example, selecting the higher volume of the two incoming voices and patching that voice to the first party. With the gateway server invention, the usage protocol for conferencing can be offered in the same way for the different kinds of telephone users.

An alternative implementation of conferences involves the use of a Multipoint Conference Unit (MCU) such as that defined by the ITU H.323 standard recommendation. Call Control At Browser Application Call control features can also be offered to the IP telephone user who is logged into the internal network and running the browser application that provides a call control interface to the gateway server. The IP telephone may be the user's primary telephone, and for convenience, the user may want to control the telephone's features through the browser GUI on the user's personal computer. (Refer to co-pending, commonly assigned U.S. patent application number 09/061 ,802, which is incorporated herein by reference for a detailed description.) Refer to FIG. 15 , and consider the example of a user clicking on the "Dial" button on the PC's browser-based GUI in order to make a call from his IP telephone to another user's PBX telephone. This call setup sequence results in the same call routing path as that shown already in FIG. 4A. The call setup sequence is defined with the following steps which are also shown graphically in FIG. 15:

1. The user of the PC's browser-based GUI 142 clicks on the "Dial" button. The software notifies the web server of the gateway server software 111 of this event. (Step 1801)

2. The gateway server software 111 sends a notification to the IP/PBX call manager 140 that a user associated with one of its IP telephones has just issued a call setup request, and it forwards the VoIP driver 114 address with the request. (Step 1802)

3. The IP/PBX call manager 140 forwards the request to dial to the appropriate IP telephone 141. The IP telephone 141 then initiates the dialing sequence and plays the appropriate feedback tones for the user to hear, and configures itself to begin transmitting IP voice packets to the VoIP driver 114. (Step 1803)

4. The IP/PBX call manager 140 responds back to the gateway server software 111 with an indication that the call is progressing successfully. (Step 1804)

5. The gateway server software 111 checks its database and finds the called party has a PBX telephone 131, so it sends a call setup request to the station/trunk driver 113. (Step 1805)

6. The station/trunk driver 113 forwards the call setup request to the PBX 130. (Step 1806)

7. The PBX 130 calls the PBX telephone 131 of the called party. (Step 1807)

8. The gateway server software 111 configures its VoIP driver with the address of the IP telephone 141, and the VoIP driver gets ready to start transmitting voice

IP packets to that address. (Step 1808)

9. The gateway server software 111 sends an acknowledgment back to the browser-based GUI 142, so it can provide a display update with feedback to the GUI user. (Step 1809) Most of the other major call control functions are handled similarly, by the gateway server coordinating with the IP/PBX call manager, and updating the browser GUI at the completion of the operation. The call control functions handled in this manner include dial, answer, hold/retrieve, hang up, transfer, and conferencing. It is important to note that the IP/PBX telephone system must support this functionality in order to provide such call control from the PC. The "do not disturb" and forwarding functions are handled simply by the browser messaging the request to the gateway server. Since both these actions are simply state changes that will affect future calls, the gateway server notes this information in its database and will use it to make routing decisions when incoming calls arrive for the user. Destination Busy Handling At Browser Application Destination Busy handling features with browser-based GUI control for IP telephones can be handled in an equivalent way to what has been described in co-pending, commonly assigned U.S. patent application number 09/061,802, which is incorporated herein by reference, for PBX telephones. Refer to co-pending, commonly assigned U.S. patent application number 09/061,802, which is incorporated herein by reference, page 65 line 1 to page 69 line 18.

In the case where the originator of the call is on an IP telephone and the caller is using the PC browser application, and a busy signal is reached at the called party (say the called party is on a PBX telephone), the caller is provided with several options by the GUI, including (as described in co-pending, commonly assigned U.S. patent application number 09/061,802, which is incorporated herein by reference) "send alert", "request callback", "ring through", and "cancel call"(equivalent to hanging up).

Each of the options is handled the same way as in co-pending, commonly assigned U.S. patent application number 09/061,802, which is incorporated herein by reference, except that the "ring through" option to voice-mail is implemented in a slightly different way, since the voice-mail for the IP telephones is associated with a PBX; this has already been discussed earlier in the description. Phone Directory At Browser Application

For IP telephone users, the "white pages" telephone directory associated with the browser can be used for convenience when dialing to other users, or when transferring a call. Refer to co-pending, commonly assigned U.S. patent application number 09/061,802, which is incorporated herein by reference, for a detailed discussion. Call Log

The call log is described in co-pending, commonly assigned U.S. patent application number 09/061 ,802, which is incorporated herein by reference, page 64, lines 10 to 23. The logging of calls to and from IP telephones follows a similar flow. It is critical that the gateway server know when a call is being setup, and when a call is terminated, and also when a call changes state (such as when a call is transferred, for example). By considering the call setup flows for setup of IP telephone calls described previously, it is clear that the gateway server has the knowledge of when calls are initially setup, and thus can write the needed log information for the call initiation event. On the other hand, it is not so obvious that the gateway server would be aware of call termination events. For example, consider the case of an IP-to-IP telephone call as shown in FIG. 5 A. A call could be handled entirely within the IP/PBX telephone system. In order for the call log to operate seamlessly regardless of the kind of telephone the various users are operating, the software object that first discovers that the termination has occurred must send out a notification to its controller (i.e. IP/PBX call manager in the case of an IP telephone) which the controller must in turn route to the gateway server. Follow Me Control

At Browser Application As described in co-pending, commonly assigned U.S. patent application number

09/061,802, which is incorporated herein by reference, there are several options for call control. Those discussed relevant to PBX telephones are also relevant to IP telephones. Given that the invention can now coordinate multiple types of telephone systems, part of the data stored for each user will include which telephone is the primary telephone for the user. The primary telephone might be the PBX office telephone (the default), or a mobile telephone, or an IP telephone. Which telephone is the primary would be entered into the gateway server database by a system administrator. This knowledge of the user's primary telephone type is used for "follow-me" routing. The default routing of any incoming call for an enterprise user will always be to route it to the primary telephone; if primary telephone is not answered, the default secondary routing is to voice-mail. However, there are several ways that more flexible routing can be enabled. Firstly, users could be given access to modify their "default" routing via the browser interface. For example, if a user's default was (1) IP telephone, and (2) voice- mail, the user might modify to (1) IP telephone, (2) mobile telephone, and (3) voice-mail. Alternatively, only a system administrator might be given the option to modify the user's default routing.

Filters can also be stacked one upon the other. For example, a user might have a certain filter applied all the time, such as the following: Filter ALWAYS_AVOID

If caller is "ex-husband" then Route to voice-mail.

End if Smart Filters for Follow-Me Scheduling

Users may be given the ability to setup filters on how to route their calls at certain times of the day. For example, the user may want to route directly to voice-mail during nights and weekend times. This can be accomplished by building call filters. A user can build up a set of favorite call filters and apply these at different times of the day. For example, a software engineer user may want to take only particular calls during the 7:00 to 9:00 a.m. time frame to guarantee uninterrupted work time. A filter such as the following could be constructed by the user, using simple point-and-click methods on the browser-based GUI:

Filter UNINTERRUPTED WORK TIME

If caller is one of the following: ("Spouse", "Boss", "Child's School") then

Route to Primary Office telephone, then Voice-mail. Else if caller is ("Customer X") Route to "Joe Green"

Else

Route to Voice-mail End This filter could then be applied to the hours of 7:00 to 9:00 a.m. in the user's calendar.

Integrated OA&M (Operations, Administration, and Maintenance) An advantage of the gateway server is the consistency of service that can be provided across the multiple different kinds of telephones, including IP telephones. The invention provides a common browser based interface, by which typical OA&M functions can be managed from a single point. User Management

User management is one of the most common administrative functions which is typically carried out on a daily basis at an enterprise. The enterprise directory, which is the central point for managing all information about a user or employee, is also used to enter all kinds of information regarding usage of different kinds of telephone systems. For example, an administrator could, from the browser-based GUI, add a new employee/user, including name, department info, e-mail address, and the information that an IP telephone is the user's primary telephone and secondary telephone is a private mobile, the mobile's ID, and what location ID and extension is associated with the user. Previous telephone systems have not been integrated in this way. For example, an administrator might have to log into several different systems; a call manager server for specifying the IP address, another OA&M monitor for setting up the IP telephone user, and so on. Alarming and Alarm Monitoring

The invention supports open standards for alarms, including SNMP. Alarms from the gateway can be sent to a commercially available network management system, or alternatively all alarms can be monitored on the browser-based OA&M monitor.

It is to be understood that even though numerous characteristics and advantages of various embodiments of the present invention have been set forth in the foregoing description, together with details of the structure and function of various embodiments of the invention, this disclosure is illustrative only, and changes may be made in detail, especially in matters of structure and arrangement of parts within the principles of the present invention to the full extent indicated by the broad general meaning of the terms in which the appended claims are expressed.

Claims

What is claimed is:

1. In an IP/PBX telephone system (33) coupled via a gateway server (31 ) to a PBX (12) having a voice-mail system (125) and a plurality of unused, phantom ports, gateway server software (111) comprising: means for configuring at least one of the phantom ports on the PBX (12) to forward calls directed to the phantom port to an IP telephone (41) via the gateway server (31); means for receiving a call set up request for a call directed to the phantom port; means for forwarding the call set up request to the gateway server software (111) in the gateway server (31); means for forwarding the call set up request from the gateway server software (111) to an IP/PBX call manager (40) in the IP/PBX telephone system (33); means for determining that the IP telephone (41 ) is unavailable using the

IP/PBX call manager (40); means for reconfiguring the phantom port on the PBX ( 12) to forward calls to the voice-mail system (125); and means for forwarding the call to the voice-mail system (125).

2. A system according to claim 1 , wherein the gateway server (31 ) comprises a CTI driver (115) and wherein the means for reconfiguring the phantom port on the PBX (12) comprises the gateway server software (111) having means for instructing the CTI driver (115) to direct the PBX (12) to reconfigure the phantom port.

3. A system according to claim 1, wherein the means for forwarding the call set up request from the gateway server software ( 111 ) to an IP/PBX call manager (40) comprises means for attaching to the call set up request addressing information of a VoIP driver (114) in the gateway server (31).

4. A system according to claim 1 , wherein the gateway server software (111) further comprises means for restoring the configuration of the phantom port on the PBX (12) to forward calls directed to the phantom port to the IP telephone (41).

5. A method of providing voice-mail to an IP telephone (41 ) on an IP/PBX telephone system (33), the IP/PBX telephone system (33) coupled via a gateway server (31) to a

PBX (12) having a voice-mail system (125) and a plurality of unused, phantom ports, the method comprising steps of: configuring at least one of the phantom ports on the PBX (12) to forward calls directed to the phantom port to an IP telephone (41) via the gateway server (31); receiving a call set up request for a call directed to the phantom port; forwarding the call set up request to gateway server software (111) in the gateway server (31); forwarding the call set up request from the gateway server software (111) to an IP/PBX call manager (40) in the IP/PBX telephone system (33); determining that the IP telephone (41 ) is unavailable using the IP/PBX call manager (40); reconfiguring the phantom port on the PBX (12) to forward calls to the voice-mail system (125); and forwarding the call to the voice mail system.

6. A method according to claim 5, wherein the step of reconfiguring the phantom port on the PBX (12) is accomplished using the gateway server software (111).

7. A method according to claim 6, wherein the gateway server (31) comprises a CTI driver (115) and wherein the step of reconfiguring the phantom port on the PBX (12) comprises the step of the gateway server software (111) instructing the CTI driver (115) to direct the PBX (12) to reconfigure the phantom port.

8. A method according to claim 5, wherein the step of forwarding the call set up request from the gateway server software ( 111 ) to an IP/PBX call manager (40) comprises the step of attaching to the call set up request addressing information of a VoIP driver (114) in the gateway server (31).

9. A method according to claim 5, further comprising the step of restoring the configuration of the phantom port on the PBX (12) to forward calls directed to the phantom port to the IP telephone (41).