Monitoring of a packet telephony device via a control device

[0002] This application is a continuation of application Ser. No. 08/787,669 filed Jan. 24, 1997, issued as U.S. Pat. No. 6,128,285, which is included herein in its entirety by reference thereto.

[0003] This invention relates to packet telephony in general and, more particularly, provides a way of increasing reliability of and extending network management and operations to end devices for packet telephony.

[0004] Packet telephony involves the use of a packet network, such as the Internet or an “intranet” (modeled in functionality based upon the Internet and used by a companies locally or internally) for telecommunicating voice, pictures, moving images and multimedia (e.g., voice and pictures) content. Instead of a pair of telephones connected by switched telephone lines, however, packet telephony typically involves the use of a “packet phone” or “Internet phone” at one or both ends of the telephony link, with the information transferred over a packet network using packet switching techniques. A “packet phone” or “Internet phone” typically includes a personal computer (PC) running application software for implementing packetized transmission of audio signals over a packet network (such as the Internet); in addition, the PC-based configuration of a packet or Internet phone typically includes additional hardware devices, such as a microphone, speakers and a sound card, which are plugged or incorporated into the PC.

[0005] Furthermore, packet telephony includes a broad spectrum of media or signal types. Whereas the plain old telephone service (POTS) networks have primarily been concerned with sound (and, over the last several years, data) transmission, packet telephony includes—in addition to voice/data—pictures or images, moving pictures, and multimedia content. Incorporating the capability of handling multimedia content increases the complexity of end devices for packet telephony.

[0006] Regular telephone devices used with POTS networks are simple, highly reliable devices. Users typically do not tamper with them during the life of the telephone. The reliability of regular telephones is limited only by the manufacturing process.

[0007] In contrast, devices used for packet telephony, such as PC-based packet phones, are dynamically-configured machines, with operation controlled (and resources allocated) in part by one or more executable software programs, And much more complex in their operation with higher hardware failure rates. In addition, PCs used for packet phones are not dedicated telephony devices, so the reliability of a PC-based packet phone may well be limited by other applications that may run on the PC; for example, a crash caused by any other application that renders the PC inoperative (i.e., the computer is “hung”) would also render the PC-based packet phone inoperative. While some PC products contain as a feature the ability of a PC to wake up, receive a phone call and go back to sleep, such a feature requires an operational PC; if the PC has crashed, the “wake up” phone call feature will be rendered inoperable.

[0008] While consumers have become accustomed to failures in computers and PC equipment, they have not been accustomed to failures in their telephones; in fact, consumers have become accustomed to a highly reliable, ubiquitous telephone service that has been available for years through POTS. The shift in telephony from POTS networks and telephones to packet networks and PC-based packet telephony devices, thus, brings about the need for increased reliability in packet telephony devices.

[0009] What is desired is a practical way to improve the reliability of packet telephony devices, such as a PC-based packet phone, so that the reliability of network communications through packet telephony approaches the reliability of POTS telephony.

[0010] An illustrative embodiment of the present invention is directed to a control device operationally coupled to both a packet telephony device (such as a PC-based packet phone) and a communications network (e.g., telephone network or packet network). The control device may have its own network address separate from that of the packet telephony device. The control device enables monitoring of the operation of the packet telephony device and basic maintenance, such as rebooting of that device if it is no longer responding to input commands.

[0011] FIG. 1 is a functional diagram illustrating the interconnection between various components used in packet telephony in accordance with the present invention.

[0012] FIGS. 2A and 2B show two embodiments of a control device in accordance with the present invention.

[0013] FIG. 3 shows a structure for functions incorporated in a primary device in accordance with the present invention.

[0014] Embodiments of the present invention enable monitoring of a packet telephony device, such as a PC-based packet phone, and basic maintenance of that device, such as re-setting or re-booting the packet telephony device if it is no longer responding to input commands.

[0015] The invention comprises connection of a control device to both a packet telephony device and a network (e.g., the public switched telephone network or the Internet). For example, the packet telephony device may be a computer (e.g., a PC) attached to a network for computer-computer communications (e.g., an Ethernet or a token-ring) via a network adapter (e.g., a LAN access card or a dial-up voiceband data connection). Network packets destined for the packet telephony device are sent to its network address or, where present, the network address of the adapter.

[0016] The control device may have its own network address, separate from that of the packet telephony device, so that the control device can send and receive information even when the packet telephony device is no longer responding to input commands. The control device may also have the same address as the packet telephony device, however such a configuration may not provide the same level of robustness as would be the case with separate addresses.

[0017] The control device monitors the operation of the packet telephony device (e.g., status, faults, etc.) through a control connection between the packet telephony device and the control device, for the purpose of detecting a condition of inoperability. The control device can also apply basic maintenance functions (e.g., reset or boot, cycle power, etc.).

[0018] The monitoring of the packet telephony device can be done in many ways. For example, the packet telephony device could write certain data, e.g. a time stamp, on a regular or periodic basis into, e.g., a memory or register accessible by the control device, and the control device would check the same memory or register periodically, to ensure that the packet telephony device is functioning properly (i.e., making progress). In this example, the control device would detect a condition of inoperability with respect to the packet telephony device if, in checking the memory or register, it found that the packet telephony device had not written the expected data into the memory or register.

[0019] The control device could also monitor operation of the packet telephony device by observing whether or not the packet telephony device is sending responsive signals to the network or to the control device; such a responsive signal could include any type of signal that would ordinarily be sent by the packet telephony device in response to one or more signals received by the packet telephony device from the network or from the control device. A cessation of such responsive signals coming from the packet telephony device would indicate that the packet telephony device is inoperable.

[0020] The control device uses its own network connection to report information about the packet telephony device and receive control commands intended for the packet telephony device. For maximal fault-tolerance, the control device should use a separate network or channel (in addition to a separate adapter, if an adapter required). For example, the control device and the packet telephony device may be attached to separate Ethernets. For an ISDN connection, the control device could use the D-channel, while the packet telephony device could use the B-channel(s). For a POTS-type connection, control via voice band encoded control signals is possible. The control device could further be connected both to a network or channel separate from the packet telephony device as well as to the same network or channel connected to the packet telephony device.

[0021] In its operation, the control device will typically have simple, well-tested software. Furthermore, changes to that software will be very rare and under strict control of the network administrator; software updates could be downloaded over the network. Keeping the software operating on the control device less susceptible to modification (e.g., by use of micro-code) makes it more robust. In contrast, the packet telephony device is vulnerable to crashes which may result from updates of software unrelated or related to packet telephony. To ensure that the packet telephony device returns to a controllable state after being re-booted by the control device, the packet telephony device may be configured to re-boot with only the absolutely necessary software when it is instructed to do so by the control device. Thus, the control device may command the packet telephony device to re-boot or reset with such limited operational functionality. This could ensure that the possibly offending software does not get automatically restarted.

[0022] An Illustrative Embodiment

[0023] Referring to FIG. 1, the embodiment will now be described in more detail. FIG. 1 illustrates the functional role of the various network components with respect to the embodiment. Packet telephony device 100 is connected through network adapter 110 to network 120. Control device 130 is connected to network 120, and is also connected to the packet telephony device through control connection 140. Both the primary and the control device are attached to a network so that they can exchange data and commands with other functional units in the network. Packet telephony device 100 and control device 130 need not be connected to the same network; packet telephony device 100 and control device 130 may be connected to different networks, or even different types of networks, without sacrificing the advantages of the present invention. For example, packet telephony device 100 may be connected to a packet network, such as the Internet, while the control device may be connected to another packet network 160 (such as an intranet). Such a configuration would allow, for example, control of commonly-owned packet phones that are connected to the outside world via the Internet using control devices that are administered through a commonly-owned corporate intranet. Alternatively, the packet telephony device could be connected to a fiber network, while the control device is connected to a wireless network.

[0024] Continuing with FIG. 1, network administration server 150 is a remote network-based server that acts to administer the network. Network server 150 can retrieve information and apply control operations to the packet telephony device, which can be accomplished either directly between network server 150 and packet telephony device 100 or via control device 130. Of course, in certain circumstances, such as when the packet telephony device is not operating, control of the packet telephony device will only be possible through the direct interface between the control device and the packet telephony device.

[0025] FIG. 2A illustrates a structure for an embodiment of the control device in accordance with the present invention. The control device 200 (which is shown as 130 in FIG. 1) includes network interface unit 210 that makes it accessible via a network (e.g., network 120 from FIG. 1). Network interface unit 210 may be constructed as any number of possible combinations of hardware and/or software that implement the operation of providing an interface for the control device with the network. For example, if the control device is attached to an Ethernet network, network interface unit 210 will be an Ethernet-compatible interface unit. The network interface unit 210 in combination with control request handler 220 will execute the hardware/software protocols necessary for communication with other entities on the network. Control request handler 220 also implements the main logic for receiving requests from the network (via the network interface), processing such requests, and sending replies.

[0026] Control data store 230 is a data store including a memory element used to store code and/or data, and also loadable threshold data for automated control device intervention. The control data storage device 230 can be any of a number of known memory units, such as a disk, flash-ram, processor-resident memory, a PROM or any other kind of suitably-defined memory.

[0027] Device interface unit 240 is the interface that connects the control device 200 to the packet telephony device (100 in FIG. 1). This interface may include a serial or a parallel port, etc. Status handler 250 operates under the control of the control request handler 220. For example, if the control request handler 220 determines that it must re-boot the packet telephony device, it instructs the status handler 250 to output the appropriate signals to the packet telephony device via device interface unit 240.

[0028] Controlling the power on the packet telephony device (100, FIG. 1), such as turning it on and off, could in principle be done by sending appropriate control signals to the packet telephony device over the connection between the packet telephony device and the control device via device interface unit 240. This would allow the power management system on the packet telephony device to take appropriate action (e.g., save something on disk). However, because the packet telephony device may be hung, it may not respond to signals received via interface 240 from the control device 200.

[0029] To solve this potential problem, control device 200 may, as shown in an alternate embodiment of the control device in FIG. 2B, include a separate power control handler 260 to control power on the packet telephony device directly. Power control handler 260 would include the necessary associated logic for controlling the power to the packet telephony device, as commanded by control request handler 220 and status handler 250. Those skilled in the art will recognize that, in many conditions, the re-setting effect of turning the packet telephony device power off and on can be accomplished, effectively, by triggering a logical reset through a connection between power control handler 260 and a logical reset input within the packet telephony device, such as that typically included with microprocessors or microcomputers used in PCs or other computer-based devices.

[0030] One potential problem may arise if a full reset, or re-boot, of the packet telephony device is initiated. It is possible that the re-boot may retrigger the condition that had rendered the packet telephony device fully or partially inoperable. For example, the packet telephony device may be a PC-based packet phone which is also programmed to run other non telephony-related software, which software is the cause of the PC entering the hung state; re-booting the PC may cause the offending software to be executed again and re-create the hung scenario. As an alternative to attempting a full re-boot of the packet telephony device, a special command or series of commands can be issued, through device interface unit 240 or through power control handler 260, to initiate a limited restoration of operation of the packet telephony device so that the device manages only a limited set of functions. To. continue with the packet telephone example above, device interface unit 240 or power control handler 260 can issue a special command (or set of commands) which would initiate a limited re-boot of the PC, such that only telephony-related functions of the PC would be enabled. Alternatively, the packet telephony device could be configured such that any attempt to reset or re-boot that comes directly from power control handler 260 would result in the limited function reset described above.

[0031] Control request handler 220, status handler 250, control data store 230 and, with respect to the alternative embodiment described above, power control handler 260 are, in combination, the logic unit (depicted as 270 in FIGS. 2A and 2B) for the control device of the present invention. Those skilled in the art will recognize that control request handler 220, status handler 250 and, where present, power control handler 260 included with logic unit 270 could be implemented using one or more logic circuits or one or more programmable processors that are programmed to implement the functions for each handler, as described above, or a combination of logic circuits and processors; and further that control data store 230 could, as described above, include a separate memory element or be included as part of a logic circuit and/or processor.

[0032] Turning now to FIG. 3, illustrated in that figure are the components of the packet telephony device that are relevant to the present invention. Interface to packet telephony device bus 310 is the component that allows the functional components of FIG. 3 to communicate with the rest of the packet telephony device's components (not shown in FIG. 3). Control interface unit 320 is a special dedicated interface for connecting the packet telephony device to the control device of FIGS. 2A and 2B (which control device is also shown as 100 in FIG. 1). Through control interface unit 320, the packet telephony device reports status information to the control device and receives control commands from the control device. Request buffer and control 330 handles the logic for communications between the packet telephony device and the control device.

[0033] Power control handler 340 is the component that controls power to the packet telephony device. In one embodiment of the present invention, power control handler 340 connects internally to the packet telephony device and may receive commands from the control device through the path consisting of control interface unit 320, request buffer and control 330, and interface to primary bus 310. Alternatively, there could be a path directly from control interface unit 320 or from request buffer and control 330 to power control handler 340.

[0034] Through one of these equivalent control paths, power would normally be controlled by the control device. Thus, if the control device instructed the packet telephony device to shut down, it would preferably do so by sending a command through one of the above-enumerated pathways, so that the control logic within the power control handler 340 would decode the command and shut down, possibly after causing appropriate action to take place (e.g., save current status or memory on disk).

[0035] Another embodiment of the present invention includes (in conjunction with the embodiment shown in FIG. 2B above) a separate control line that comes into the power control handler directly from the control device; this is essentially in function a power on/off switch or a power reset control line. Because of the hung device scenario mentioned above, it may be preferable to include this direct power reset control so that the packet telephony device can successfully be restarted even if it is non-responsive to other external controls. Implementation of the functions of FIG. 3 may be accomplished, for example, by using an adapter card that attaches to the packet telephony device's system bus.

[0036] In order to lower the cost of this configuration, another embodiment of the present invention combines the control device with the regular primary network adapter. In this embodiment, the control device is, essentially, built or installed into the primary network. Such a configuration would sacrifice some of the fault tolerance (e.g, a single adapter failure could render both the primary and the control devices inaccessible). The combined device adapter would respond to two addresses (where the control device has an address separate from that of the packet telephony device) such that packets destined for the packet telephony device would be passed on following the normal route, while packets addressed to the control device would be intercepted and interpreted locally by the micro-code running on the combined device.

[0037] Similarly, in yet another embodiment of the present invention, the control device is combined with the packet telephony device itself (i.e., built or installed into the packet telephony device). This configuration also sacrifices some of the fault tolerance as, e.g., a single power failure could render both the packet telephony device and the control device inoperable.

[0038] Those with experience and skill in the art will readily appreciate that network security methods in the prior art can be used to ensure only authorized access to the control device. Those with experience in the art will also readily appreciate that the primary and the control devices do not need to be supported by the same power source. The control device might be a standalone battery powered device or might be supported by the POTS network power—much like a POTS handset is today. Such a configuration may be particularly useful to ensure continuous connectivity even in the presence of line power failures or when a PC crashes, making the packet phone inaccessible. The latter may be a consideration, since a PC-based packet phone will be limited by the unreliability of the host PC, such that a reliable second access to the network may be critical.

[0039] Those skilled in the art will further recognize that re-setting or re-booting of the packet telephony device when it becomes inoperable, in accordance with the present invention, is a form of basic maintenance of the packet telephony device, and that other forms of basic maintenance activities, such as updating programmable elements or features of the packet telephony device, are also enhanced by present invention. Thus, software updates intended, e.g., for a packet phone can be scheduled and implemented by the control device in a way that minimizes interruption of the availability of the packet phone.

[0040] The benefits of the present invention can be extended to other primary network devices used in connection with communications networks. Large numbers of computer-based primary network devices (such as, e.g., private branch exchange communications equipment or any other form of network terminal) are attached to these networks. It is often the case, however, that a computer-based primary network device has entered a state in which it is no longer capable of normal operation (e.g., it has crashed), and may require manual intervention. Also, it may not be easily determinable whether the fault has been the result of a network or adapter failure or the result of a computer crash. Accordingly, a control device may be utilized in conjunction with a primary network device in accordance with the methods and architectures described above with respect to packet telephony devices, in order to obtain improvements in reliability and network management for primary network devices similar to those that may be obtained for packet telephony devices.

[0041] In summary, the present invention describes a way of improving the reliability of packet telephony using a control device attached to both a packet telephony device (such as a PC-based packet phone) and a network (e.g., telephone network or packet network). The control device enables monitoring of the operation of the packet telephony device and basic maintenance (such as re-booting) of that device if it is no longer responding to input commands.

[0042] What has been described is merely illustrative of the application of the principles of the present invention. Other arrangements and methods can be implemented by those skilled in the art without departing from the spirit and scope of the present invention.