Failover mechanisms for remote networked phones

Details Failover mechanisms for remote networked phones Failover mechanisms for remote networked phones

2001-04-27

2003-09-23

Nguyen, Duc (Department: 2643)

Telephonic communications

Diagnostic testing, malfunction indication, or electrical...

Monitoring

C379S001010, C379S015010, C379S016000

Reexamination Certificate

active

06625256

ABSTRACT:

BACKGROUND
1. Field
This disclosure relates to networked phones, more particularly to mechanisms to provide support for remote networked phones after an external link failure.
2. Background
The use of data networks to handle telephone traffic offers several advantages to businesses. This use allows the businesses to use excess capacity in their data network infrastructure for voice traffic, often avoiding toll charges associated with Public Switched Telephone Networks (PSTN) and making the data network more efficient. The ‘telephones’ used in these data networks may be something similar to a traditional telephone, with a base and a receiver, or the combination of a computer with a microphone and speakers.
These telephones, regardless of their configurations, use data networks to communicate. The data network may conform to Internet Protocol (IP), Asynchronous Transfer Mode (ATM), Frame Relay (FR), or other data network protocol. Some may also use a combination, such as IP over FR, or
1
P over ATM. This often occurs when a local node on the network is connected to the network with a Wide Area Network (WAN) link. The WAN link may be ATM or FR, while the phones use IP to communicate. For this reason, these telephones will be referred to as network phones here.
Management of the network telephone system is often done separately from the data network itself. Network telephones have somewhat different requirements that other devices on the network. For example, the telephones must have telephone numbers in addition to network addresses. They must have a way to connect to the PSTN to reach phones not on the network, as another example. In some circumstances, a call manager or handler is used to manage the network phone system.
Many of existing call manager products can handle thousands of network phones. These phones may be distributed across the country, in groups of variable sizes. For example, a company may have a large headquarters on the West Coast with thousands of phones and have research and sales offices scattered to the East Coast each with only a few phones each. The call manager at one location, such as the headquarters, may support all of these phones.
The network phones at the locations remote to the call manager may suffer loss of service if the link between the call manager and the remote location fails. The network phones generally rely upon the WAN link to make calls external to their local site. The system should provide some sort of failover mechanism in this circumstance.
One solution is to place a secondary, stand-by call manager in the remote location. However, the cost of the secondary call manager would be unacceptable, especially if there were only two or three phones at the remote location. Additionally, the system would have to synchronize between the primary and secondary call managers. The amount of data bandwidth required to do this would generally be too large to operate successfully over a typical 64K-28K bits per second remote WAN link.
An alternative approach would be to manually configure the data required by the standby call manager for the small number of network phones located at each branch office. This is not a desirable solution for organizations having several small branch office controlled by a single call manager. The administrator would have to configure and manage several hundred call managers, a prohibitive amount of work.
Therefore, it would seem useful to have an automatic mechanism to distribute only the minimum configuration information required by devices located in each branch office, requiring only low bandwidth.
SUMMARY
One aspect of the disclosure is a method of providing failover service for network phones upon failure of their primary call manager. When a communication link between the network phone and the primary call manager fails, the network phone contacts a default network device and requests failover service. The phone then provides its directory information to the network device. The network device constructs a directory. The network phone then uses the constructed directory for failover service until the link between the phone and the primary call manager can be reestablished. Upon reestablishment of the connection, the network device continues to provide the failover service until only a predetermined number of phones with active calls remain. The network device then sends a message to phones with active calls and requests termination of the calls and migration back to the primary call manager.
Another aspect of the disclosure is a method of providing failover service for network phones. A network device capable of providing failover service receives a failover request from at least one network phone. The network device accesses information resident on each phone and uses that information to build a directory of all the phones relying upon it for failover service. This directory is then used to provide connection and routing for these phones.


REFERENCES:
patent: 5515418 (1996-05-01), Yamaguchi et al.
patent: 5757904 (1998-05-01), Anderson
patent: 5832222 (1998-11-01), Dziadosz et al.
patent: 6005920 (1999-12-01), Fuller et al.
patent: 6434700 (2002-08-01), Alonso et al.

Affiliated with

Also associated with

Rating

Failover mechanisms for remote networked phones does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Failover mechanisms for remote networked phones, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Failover mechanisms for remote networked phones will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3055372