Managing voice-based data communications within a clustered network environment

This disclosure relates to managing voice-based data communications within a clustered network environment using application-layer functionality, and more particularly to a primary network device within a cluster that manages transmissions related to a communication and synchronizes state information associated with the communication to other network devices within the cluster. One exemplary method includes receiving, by a network device in a cluster, information associated with a data communication between a first user device and a second user device, and analyzing, by the network device, the received information using application-layer functionality to identify a primary network device that manages the data communication. When the network device is not the primary network device, the network device forwards the received information to the primary network device. Upon receipt of the information, the primary network device provides updated state information for the communication with other network devices within the cluster for synchronization purposes.

TECHNICAL FIELD

This disclosure relates to managing one or more data communications within a clustered network environment.

BACKGROUND

In a clustered network environment, two or more network devices typically manage the flow of communication between various external endpoints. For example, a user device in one enterprise system may wish to communicate with a user device of another enterprise system. These two user devices may establish a data communication via the clustered network environment. One or more of the network devices in the cluster may assist in the management of the data flow for this data communication.

In certain cases, users of these user devices may wish to establish a voice-based communication, such as a Voice-Over-Internet-Protocol, or VoIP, call. In managing a VoIP call, network devices within a clustered environment may need to maintain call state information for the duration of that call. Such state information may include session information, address translation information, pinhole information, or other call-related information. In a load-balanced environment, or in a cluster that routes information through various different devices, it is possible that multiple different network devices within the cluster will receive and handle data packets associated with one given call. In these scenarios, state information for the call needs to be synchronized between all of such devices. As a result, due to possible latency in the system, it is possible that one network device may receive a packet for the call before its state has been synchronized, meaning that the packet could be dropped, or that the security of the call could become compromised.

SUMMARY

In general, the disclosure relates to managing data communications within a clustered network environment using application-layer functionality, and more particularly to a primary network device within a cluster that manages transmissions related to a data communication and synchronizes state information associated with the communication to other network devices within the cluster. The clustered network environment may be a high-availability environment that may further provide load-balancing amongst devices in the cluster. The primary network device may be identified when a request is received by the cluster to establish a data communication, such as a voice-based call, with a user device. The primary network device is then activated as a primary device to process subsequent information associated with the data communication, which may be identified by application context information for the data communication, such as, for example, a call identifier. Other network devices within the cluster that may receive information for the communication are responsible for forwarding such information to the primary network device. The primary network device is responsible for continually providing updated state information associated with the communication to other network devices within the cluster for synchronization purposes. Thus, in the case of a failure (e.g., hardware failure, software failure) of the primary network device, another device within the cluster is capable of dynamically taking over responsibility as the primary device for the communication.

In some embodiments, a method includes receiving, by a network device in a cluster, information associated with a data communication between a first user device and a second user device, and analyzing, by the network device, the received information using application-layer functionality to identify a primary network device within the cluster that manages the data communication. When the network device is not the primary network device, the network device forwards the received information to the primary network device.

In some embodiments, a network device includes an engine configured to receive information associated with a data communication between a first user device and a second user device, and further configured to analyze the received information using application-layer functionality to identify a primary network device that manages the data communication within a cluster of network devices. When the network device is not the primary network device, the engine is further configured to forward the received information from the network device to the primary network device.

In some embodiments, a method includes receiving, by a first network device within a cluster of network devices, a request from a first user device using an application-layer protocol (such as, for example, a session-initiation protocol) to establish a voice-based data communication with a second user device, and activating the first network device as a primary device using application-layer functionality, such that the first network device processes subsequent information associated with the data communication between the first and second user devices. The method further includes sending initial state information associated with the request from the first network device to a second network device within the cluster using application-layer functionality, and sending the request from the first network device to establish the data communication with the second user device. In some embodiments, the method further includes experiencing a failure in the first network device, and activating the second network device as the primary device using application-layer functionality, such that the second network device processes subsequent information associated with the data communication.

DETAILED DESCRIPTION

FIG. 1is a block diagram illustrating user devices within different enterprise systems that are able to communicate with each other via a clustered network environment, according to certain embodiments. As is shown inFIG. 1, a network cluster106provides a communication pathway between one enterprise system100and another enterprise system101. Enterprise system100includes user devices102A-102N that are each communicatively coupled to proxy server104. Enterprise system101includes user devices103A-103N that are each communicatively coupled to proxy server105. A user may interact with any one of user devices102A-102N in enterprise system100or any one of user devices103A-103N in enterprise system101. For example, if the user wishes to initiate a voice-based call to another remote user, the user may utilize one user device102A of enterprise system100to establish a voice-based call with user device103A of enterprise system101using an application-layer protocol, such as a session-initiation protocol. Network cluster106manages the voice-based call from initiation to termination using application-layer functionality, which includes management of one or more data packets that are communicated between users during the lifetime of the call, as will be discussed in more detail below.

Each enterprise system100and101may be a large-scale or small-scale system. In system100, user devices102A-102N may be co-located or remotely located with respect to each other. In addition, proxy server104may be co-located or remotely located with respect to user devices102A-102N. Similarly, in system101, user devices103A-103N may be co-located or remotely located with respect to each other. And, proxy server105may be co-located or remotely located with respect to user devices103A-103N. Proxy server104manages the interface between user devices102A-102N and network cluster106. As a result, user devices102A-102N send outgoing data through proxy server104, and receive incoming data from proxy server104. Proxy server105manages the interface between user devices103A-103N and network cluster106.

Network cluster106includes network devices108A-108N. Each network device is capable of processing data that is communicated between one enterprise system100and another enterprise system101. In one embodiment, one or more of network devices108A-108N may comprise firewalls. Because network cluster106includes multiple network devices108A-108N that are each capable of processing communicated data, each enterprise system100and101need not identify a specific network device108A-108N when transmitting data through network cluster106. Instead, enterprise systems100and101may provide data to network cluster106, and network cluster106is then dynamically capable of determining which network device108A-108N will process such data. Typically, a data communication between enterprise system100and enterprise system101will include multiple data packets that are exchanged. In some embodiments, network cluster106provides load balancing functionality, such that different network devices within cluster106may handle different data packets associated with the same data communication (such as a voice-based call, for example). In these embodiments, network cluster106determines which network device108A-108N will manage each incoming data packet that is received from enterprise system100or101.

In some embodiments, network cluster106provides a high-availability environment in which each network device108A-108N provides redundancy for failover. For example, if a first network device108A has managed certain data packets within a data communication, this network device108A is capable of synchronizing state data for the communication with other network devices in cluster106using application-layer functionality. If the first network device108A then experiences a failure, one or more of the other network devices108B-108N can continue to manage the data communication between enterprise systems100and101using up-to-date communication data.

In certain embodiments, a primary network device, such as device108A, is identified by network cluster106to manage all data packets associated with a given data communication between enterprise systems100and101. State maintenance and resource management for the data communication are more easily and efficiently achieved when one primary network device108A manages the data communication. In addition, the primary network device108A is also capable of maximizing security for the communication by functioning as a security device at the application layer, according to some embodiments. Different network devices within the set of devices108A-108N may serve as primary devices for separate data communications between the enterprise systems100and101, as well.

In a load-balanced environment, when one enterprise system100sends a first data packet of a data communication to another enterprise system101via network cluster106, cluster106identifies a network device, such as device108A, to manage this first data packet. In some embodiments, the network device that has been identified as the managing device for this first data packet becomes the primary device for all subsequent packets associated with the same data communication. In these embodiments, the primary network device, such as device108A, manages all packets for the data communication, but is also responsible for synchronizing its state data for the communication with other network devices, such as devices108B-108N in this example, within cluster106for redundancy. If other network devices108B-108N within cluster106receive any of the subsequent data packets associated with the data communication, these network devices route, or forward, such packets to primary network device108A for that communication. For example, if the data communication is a voice-based call between a user of enterprise system100and a user of enterprise system101, any non-primary (or secondary) network devices108B-108N within cluster106that receive data packets for the call will forward the packets to primary network device108A. In this example, primary network device108A is then responsible for synchronizing state data for the call with other network devices108B-108N. Thus, as is shown inFIG. 1, each network device108A-108N, in general, is capable of forwarding data to or synchronizing data with other network devices within cluster106using application-layer functionality.

In some embodiments, each network device108A-108N within cluster106is a separate physical device. However, in other embodiments, network cluster106comprises one physical device, and each network device108A-108N comprises a virtual device within cluster106. Also, in certain embodiments, proxy server104within enterprise system100may not be needed or used, and proxy server105in system101may not be needed or used. In these embodiments, the user devices102A-102N (system100) and103A-103N (system101) are capable of directly communicating with network cluster106.

FIG. 2is a block diagram illustrating enterprise systems200and201that each include a network cluster, according to some embodiments. In these embodiments, enterprise system200includes user devices102A-102N, proxy server104, and network cluster106(which is shown as separate from enterprise system100inFIG. 1). Within enterprise system200, user devices102A-102N are communicatively coupled to proxy server104and network cluster106as described previously, but internal to enterprise system200. Enterprise system201includes user devices103A-103N, proxy server105, and network cluster107. User devices103A-103N are communicatively coupled to proxy server105and network cluster107. Network cluster107is similar to network cluster106, and includes network devices109A-109N. Network devices109A-109N function similarly to network devices108A-108N in cluster106. One enterprise system200is capable of communicating with another enterprise system201via network202. User devices102A-102N are capable of communicating with user devices103A-103N, as described previously with respect toFIG. 1, but network clusters106and107within each enterprise system200and201ofFIG. 2, respectively, handles data flow to and from network202during any data communication between the enterprise systems200and201.

FIG. 3is a diagram illustrating various functional components and a repository that may be included within an exemplary network device108A, according to some embodiments. Exemplary network device108A shown inFIG. 3is part of network cluster106, shown in bothFIGS. 1 and 2. In some embodiments, each of the network devices108A-108N in cluster106includes the various functional components and repository shown inFIG. 3. In some embodiments, each of the network devices109A-109N in cluster107(FIG. 2) includes these functional components and repository, as well.

InFIG. 3, network device108A includes functional components of an application layer gateway301, a flow/policy manager306, a resource manager308, and a gate/session manager310. Each functional component is capable of communicating with the other functional components.FIG. 3further shows state information in state information repository312that is maintained by network device108A. This includes state information314and state information316, which are described in more detail below.

Application layer gateway301performs certain gateway functionality at an application layer (such as, for example, with reference to the OSI, or Open Systems Interconnect, communication stack), according to one embodiment. In this embodiment, application layer gateway301performs gateway functions at a layer above layers2and3in the OSI stack. Application layer gateway301includes a forwarding engine300, a synchronization engine302, and a security device manager304, according to the embodiment ofFIG. 3.

Forwarding engine300sends information (such as data packets associated with data communications) to, or receives information from, other entities, such as other network devices within cluster106or enterprise systems100and101. Upon receiving information, forwarding engine300determines whether network device108A needs to forward data packets for a data communication to another network device108B-108N that is currently handling, or managing, that particular data communication. As noted above, a primary network device is the network device within cluster106(or cluster107) that is responsible for processing all data packets for a given data communication. For a first data communication, network device108A may be the primary device, and forwarding engine300may send information directly to external systems, such as system100or101. However, for a second, separate data communication, another network device (such as network device108B) may be the primary device. Forwarding engine300may identify this primary device by analyzing a portion of data contained within the received information, such as a unique communication identifier (such as a VoIP call ID) for the communication, sender's address, recipient's address, communication tags, and/or other identification data contained within the received information.

Forwarding engine300then compares this portion of data with state information maintained within repository312to identify the primary network device. This portion of data can be used as an index into one or more tables of the state information, according to some embodiments, to identify the primary network device. In some embodiments, forwarding engine300accesses state information within at least one of state information314and state information316to identify the primary network device. In some embodiments, security device manager304may be responsible, either separately or in conjunction with forwarding engine300, for analyzing the portion of data contained within the received information to identify the primary network device.

If network device108A receives one or more data packets associated with this second data communication from enterprise system100or101, for example, forwarding engine300forwards such packets to the primary network device of such communication. Forwarding engine300also interacts with state information repository312to retrieve state information for certain communications.

When forwarding engine300has identified that network device108A is not a primary device for a given data communication for which it has received one or more data packets, it may access state information314within repository312, according to some embodiments. State information314includes state information for one or more data communications for which network device108A serves as a non-primary device. Although forwarding engine300forwards packets it has received to the primary device within cluster106that manages that given data communication, it can also access state information within state information314for those packets, such that it knows current state of the communication. In some embodiments, network device108A populates state information314based upon synchronization information for state information that it receives from primary devices within cluster106that manage one or more different data communications.

In some embodiments, application layer gateway301includes a SIP (Session Initiation Protocol) handler to manage VoIP call-based information. (Presently, SIP is defined within Request For Comments, or RFC, 3261, which has been defined by the Internet Engineering Task Force SIP Working Group.)

InFIG. 3, network device108A also includes security device manager304. In some embodiments, network device108A is a physical device. In these embodiments, security device manager304manages the security for the physical network device108A. In other embodiments, network device108A is a virtual device within cluster106, when each of devices108A-108N are part of one physical network device. In these embodiments, security device manager304functions as a virtual security device to manage security for the virtual device108A. Security device manager304may manage one or more virtual security devices for device108A, wherein the virtual security devices help manage information within repository312.

As noted above, repository312includes state information for various data communications, including data communications for which network device108A serves as either the primary or non-primary device. Security device manager304is capable of managing and updating both state information314, which includes state information of communications for which network device108A serves as a non-primary device, and also state information316, which includes state information of communications for which network device108A serves as a primary device. Security device manager304may also actively manage security protocols used during data transmission through network device108A.

When forwarding engine300receives one or more data packets from an external system, such as enterprise system100or101, and has identified network device108A as the primary device for handling these packets and associated data communication, security device manager304is responsible, in some embodiments, for maintaining and updating state information for the communication within state information316of repository312. This state information can subsequently be sent to, or synchronized with, other non-primary devices within cluster106, such that all devices within cluster106have synchronized state information for the communication.

Synchronization engine302synchronizes information between network device108A and other network devices108B-108N in cluster106. When network device108A is a primary device for a given data communication, thereby managing all data packets associated with that communication, synchronization engine302is responsible for synchronizing all state information associated with the communication in state information316with other devices108B-108N. It may do so by periodically providing such state information to the other devices108B-108N. For example, when network device108A processes the initial data packets for a communication, such as a voice-based call, synchronization engine302may provide initial state information from state information n316to devices108B-108N to initially synchronize all devices within cluster106. Subsequently, as network device108A receives and processes subsequent data packets associated with the communication, synchronization engine302may provide additional state information from state information316to devices108B-108N to continually synchronize all devices within cluster106. Synchronization engine302can provide such information when or after security device manager304has updated state information316, as was described previously. Thus, when network device108A is a primary device, it manages synchronization of state information for the given communication with all other devices through use of synchronization engine302.

When, though, network device108A is not a primary device for a given communication, it may receive synchronization data, such as state information for that communication, from the primary device managing such communication within cluster106. (The synchronization engine302of the primary device may provide this information to device108A, in these instances.) Synchronization engine302of network device108A is responsible, in these instances, for receiving, processing, and storing such incoming synchronization data within state information314for the communication to ensure that network device108A has updated information concerning that communication. Because network device108A maintains such state information314, network device108A provides redundancy within cluster106. For example, in the event that the primary device experiences a failure, cluster106may determine that network device108A is to become the new active, primary device for the communication. Because synchronization engine302has maintained updated state information associated with this communication in state information314, network device108A is in a position to effectively and efficiently take over as the new primary device. If this occurs, security device manager304moves the state information for the communication from state information314to, or re-associated the state information with, state information316, since network device108A is now the primary device.

In some embodiments, the functionality provided by synchronization engine302and security device manager304may be substantially merged, such that one functional component may be responsible for maintaining state information within repository312, synchronizing such state information (e.g., state information314and/or316) with other network devices, and managing security for data communications handled by network device108A. In some embodiments, the functionality provided by forwarding engine300, synchronization engine302, and security device manager304may be substantially merged within application layer gateway301.

In some embodiments, various functional components, such as forwarding engine300, resource manager308, and/or gate/session manager310, are capable of accessing repository312directly and synchronizing relevant state information within state information314and/or316to other network devices108B-108N. In these embodiments, synchronization engine302may oversee the overall synchronization process, or may delegate certain synchronization functions to these functional components.

The state information contained within state information314and/or316provides information related to the state of a given data communication. This information may include resource information for resources that have allocated to the communication, session information, gate information, network-address-translation (NAT) mapping information (if cluster106utilizes NAT), pinhole information (for example, with VoIP calls), or other SIP/application-layer gateway information. As noted above, resource manager308, gate/session manager310, and even forwarding engine300are, in some embodiments, directly involved with the synchronization of state information within repository312, and may interact with synchronization engine302.

Flow/policy manager306helps manages the various flows of data that are processed by network device108A. These flows of data may relate to active flows that are processed by network device108A as the primary device, and also to other flows that are processed when network device108A may be a non-primary device. In addition, flow/policy manager306manages one or more rule-based policies for network device108A. These policies may be used by network device108A to determine when or if to take certain actions. For example, these policies may specify that certain actions are forbidden or allowed during processing of data packets for one or more data communications through network device108A. The policies may also specify whether network device108A is allowed or prohibited from communicating with other network devices108B-108N. In certain cases, if a particular network device, such as network device108B, has failed or is down, flow/policy manager306may indicate that network device108A shall not try and communicate with network device108B. Flow/policy manager306may also indicate which network device108A-108N is to take over as the primary device for a communication when the prior primary device is down, has failed, or is otherwise unable to proceed with management of the communication, according to some embodiments. Flow/policy manager306is also communicatively coupled to repository312for accessing and updating relevant state information314and/or316associated with one or more data communications.

Resource manager308manages various resources for network device108A. In some embodiments, resource manager308manages creation or deletion of various groups and resources within network device108A. These groups and resources may be associated with one or more data communications, such as voice-based calls, that are handled by network device108A. Thus, various group and resource information managed by resource manager308comprises state information that is stored within repository312. When network device108A serves as a primary device, such state information is captured within state information316and can be managed and synchronized by synchronization engine302and security device manager304. In some embodiments, resource manager308received delegated authority to directly synchronize its resource management state information within repository312to other network devices108B-108N.

Gate/session310manager manages gate and/or session creation and handling within network device108A. Gate/session manager310is also communicatively coupled to repository312for accessing and updating, if necessary, relevant state information314and/or316associated with one or more data communications, according to some embodiments.

FIG. 4is a block diagram illustrating additional details of an exemplary user device102A, according to some embodiments. User device102A is part of enterprise system100shown inFIG. 1, and is also part of enterprise system200shown inFIG. 1. User device102A shown inFIG. 4includes a computing device400and a VoIP (voice-over-Internet-Protocol) telephone410. In some embodiments, other user devices102B-102N, or user devices103A-103N (FIGS. 1 and 2), also include these components.

A user, such as a human user, may use and interact with user device102A. The user may interact with computing device400to provide data entry and receive data responses. Computing device400includes a processor, a storage medium, an input/output interface, and memory. Computing device400may comprise a PC computer, a portable/laptop computer, a handheld device, or other form of computing device known in the art. Computing device400is coupled to VoIP telephone410in the embodiment ofFIG. 4. The user may interact with VoIP telephone410to place or receive voice-based calls to users of other user devices (such as users of devices103A-103N). In these scenarios, the data communications from enterprise system100or200comprise voice-based calls. Network clusters106and107are each capable of managing IP (Internet Protocol) data associated with these communications, as is network202(FIG. 2).

FIG. 5is a flow diagram illustrating an exemplary method that is performed by a network device, according to some embodiments. For example, the method shown inFIG. 5may be performed by network device108A shown inFIG. 3. In some embodiments, the method may be performed by any of the network devices108A-108N or109A-109N shown inFIGS. 1-2.

The method shown inFIG. 5includes acts500,502, and504. For exemplary purposes only, it will be assumed that first network device108A performs this method, and that a second network device108B is also included within cluster106of devices. In act500, network device108A receives information associated with a data communication, such as a voice-based call, between a first user device102A and a second user device103A. Upon receipt of this information, network device108A analyzes, in act502, the received information using application layer functionality (such as, for example, by using an application layer gateway, such as application layer gateway301shown inFIG. 3) to identify a primary network device within cluster106that manages the data communication. If network device108A is not the primary network device, network device108A, in act504, forwards the received information from network device108A to the primary network device. For example, if network device108B is the primary device for the communication, network device108A forwards the received information to network device108B. Various aspects of this method, along with the operable functional components of network devices108A and108B, will be further described below with respect toFIGS. 6A,6B, and7.

FIG. 6Ais a block diagram illustrating an exemplary mode of operation of two enterprise systems100and101communicating with each other via network cluster106.

FIG. 6Ashows an example of a system such as the one shown inFIG. 1, wherein enterprise system100includes one user device102A, enterprise system101includes one user device103A, and network cluster106includes two network devices108A and108B. User device102A is able to communicate with user device103A via network cluster106. For example, user device102A may be able to establish a data communication, such as a voice-based call, with user device103A. If the network cluster106supports communication using the Internet Protocol (IP), then user device102A is capable of establishing a VoIP call with user device103A. For purposes of illustration, it will be assumed that user device102A wishes to establish such a VoIP call with user device103A in the example shown inFIGS. 6A and 6B, and that user devices102A and103A each include VoIP-activated phones or devices (such as VoIP phone410shown inFIG. 4). However, it shall be well understood that various other forms of data communication may also be implemented by the general techniques described hereinafter.

To establish a VoIP call, user device102A of enterprise system100sends a request, or a call invitation, to user device103A, using an application protocol, such as SIP (session initiation protocol). This request is routed through proxy server104, network cluster106, and proxy server105so that it may be delivered to user device103A.FIG. 6Ashows a series of numbered arrows to indicate the sequence of data packets, or information, that is sent from one entity to another.

First, user device102A sends the request to proxy server104. Proxy server104is responsible for communicating with entities external to enterprise system100. Proxy server104then routes the request to network cluster106. In some embodiments, where enterprise system100does not include proxy server104, user device102A is capable of sending the request directly to cluster106.

When cluster106receives the request, it determines which network device within cluster106shall process the request, according to some embodiments. In these embodiments, cluster106is able to implement load balancing, such that information flow through cluster106is balanced amongst network devices included within cluster106, such as network devices108A and108B. Proxy server104may generically address the request to cluster106, such as by using an IP address associated with cluster106, and then cluster106determines which device will process the request. In the example shown inFIG. 6A, cluster106has determined to route the message to network device108A.

Because network device108A is initially selected by cluster106when processing the initial request related to the VoIP call, network device108A is identified as the primary, or active, device for the call. As a result, network device108A will manage and process all subsequent information packets related to this specific call, at least as long as it continues to serve as the primary, active device for the call. Network device108A may therefore initially provide the egress interface for the VoIP call.

Because it is the primary device for the call, network device108A maintains all primary state information for the call, and serves as the active virtual security device (VSD) for the call. As shown inFIG. 6A, network device108A manages active VSD600for the call. Security device manager304(FIG. 3) of application layer gateway301in network device108A manages active VSD600. Network device108A is capable of maintaining state information316for the call within repository312. Exemplary state information may include session information, VoIP pinhole information, or event NAT (network-address translation information) information if cluster106implements NAT or includes NAT devices that interact with devices108A and108B.

Before sending the request to enterprise system101, network device108A synchronizes its state information316for the call with network device108B. To do so, synchronization engine302of network device108A sends its state information316to network device108B. Within network device108B, synchronization engine302may receive this information and store it within its repository312as state information314, since network device108B acts as the non-primary (or non-active) device for the call. However, by synchronizing the initial state information for the call, network device108B maintains up-to-date information, in case it may later need to serve as the primary, active device for the call (such as, for example, if there is a failure with network device108A). Flow/policy manager306, resource manager308, and/or gate/session manager310of network device108A may also be involved when processing the request.

Network device108A then sends the request, via forwarding engine300, to proxy server105of enterprise system101. Proxy server then routes the request to user device103A, which may also include a VoIP-activated phone or device. When the VoIP phone rings, user device103A sends a message (which may include one or more data packets) back to proxy server105indicating that the device is ringing. Proxy server105sends this message to cluster106so that it may be delivered to user device102A, such as by addressing the message to an IP address associated with cluster106.

Once again, cluster106determines which network device will process the message. By implementing a load-balancing routine, cluster106determines that network device108B will handle the message. Because cluster106is a high-availability, it routes messages to network devices to achieve load balancing, regardless of which calls to which these messages pertain, according to some embodiments. Cluster106assumes that individual network devices, such as devices108A and108B, will manage the processing of call-specific messages.

When network device108B receives the message, it utilizes its forwarding engine300, and also accesses state information314within its repository312, to determine that it is not the activated, primary device to handle data packets associated with this particular data communication between user device102A and user device103A. It instead identifies network device108A as the primary device. Network device108B may also utilize its flow/policy manager306, resource manager308, and/or or gate/session manger310when analyzing and processing the received message. If it determines that it should forward the message, network device108B uses its forwarding engine300to forward the message to network device108A.

Network device108A receives and processes the message using its forwarding engine300. It may also use its flow/policy manager306, resource manager308, and/or or gate/session manger310when processing the message. In addition, security device manager304manages VSD600, which updates state information316for the call within repository312based upon current state and receipt of the message. Network device108A is thereby able to confirm that it is the primary device for the call. To synchronize call state with network device108B, synchronization engine302of network device108A provides its state information316to network device108B. Synchronization engine302of network device108B stores this information in its repository312as updated state information314associated with the call, since device108B is a non-primary device for the call.

After synchronization, network device108A sends the message for the call to proxy server104using its forwarding engine300. Proxy engine104then routes the message to user device102A, indicating that a VoIP-activated phone connected to user device103A is ringing.

Once a user of user device103A picks up the phone, a media session is established between user device102A and user device103A for the call. All information, including data packets, associated with the call are handled and managed by network device108A as the primary, active device for the call. Any information associated with the call that is received by network device108B is forwarded to network device108A as the primary device, as shown inFIG. 6A. However, before the call ends, it is possible that network device108A experiences a failure or some sort, such as a hardware or software failure. For example, network device108A may experience some form of device failure, or may experience a failure related to operation of VSD600or security operations within the device. In this case, for fail-over purposes, network device108B may need to take over as the active, primary device for the call in case of such a failure.

FIG. 6Bis a block diagram illustrating an exemplary mode operation in the case of such a failure. In this example, network device108A experiences a failure, such as a failure in implementing VSD600. As a result, there is a failover of VSD600to network device108B, such that network device108B becomes the primary, active device for the call, and takes over management of VSD600as the active device. Security device manager304of network device108B controls management of VSD600. Because network device108B has received updated state information from network device108A up to this point, network device108B has up-to-date information for the call, and is capable of taking over as the primary managing device for the call in moving forward. Because it is now the primary device, network device108B moves, or re-designates, the state information for the call as state information316within its repository312. In addition, because network device108A is no longer the primary device for the call, it can move, or re-designate, the state information for the call as state information314within its repository312.

InFIG. 6B, the next message, or set of data packets, is sent by user device103A to proxy server105. Proxy server105then sends the message to cluster106. Within the load-balancing environment, cluster106determines to route the message to network device108A in the example ofFIG. 6B. However, network device108A analyzes the message, accesses its repository312, and identifies network device108B as the current, primary device handling information for the call. As a result, network device108A forwards the message to network device108B.

Upon receipt of the message, network device108B confirms that it is the primary device for the call. It then updates its state information316for the call based upon receipt of the message and any information associated with the message. In addition, it provides synchronization with network device108A by sending its state information316to network device108A. Network device108A stores this information within its repository312as state information314, since it is no longer the primary device.

Network device108B then sends the message to proxy server104. Proxy server104routes the message to user device102A. In this fashion, network device108B is capable of taking over as the primary device for the call when the previous primary device108A experiences some form of a failure. As a result, network devices108A and108B provide failover and redundancy capabilities to help implement a high-availability network environment when managing one or more data communications between enterprise systems100and101.

FIG. 7is an interaction diagram further illustrating the operations shown inFIGS. 6A and 6B.FIG. 7shows an initial flow of information from user device102A to network device108A via cluster106, when network device108A has been initially identified as the primary device. (Proxy servers104and105are not included withinFIG. 7.) Network device108A synchronizes network device108B by providing state information for the call to network device108B. Network device108A then sends the information (labeled “INFORMATION A”) to user device103A.

User device103A then sends “INFORMATION B” to cluster106, which determines, for load-balancing reasons, that network device108B will initially process the information. Because it is not the primary device, network device108B forwards the information to network device108A. Upon receipt of “INFORMTATION B”, network device108A provides updated state information to network device108B, and then routes the information to user device102A.

Subsequently, network device108A experiences a failure, and network device108B takes over as the primary device, thereby taking over active management of VSD600. User device103A then later sends “INFORMATION C” to cluster106, which determines, for load-balancing reasons, that network device108A will initially process the information. Because network device108A is no longer the primary device, it forwards the information to network device108B. Network device108B confirms that it is the primary device, and provides updated state information to network device108A. Network device108B then sends “INFORMATION C” to user device102A.

In one or more exemplary embodiments, the functions described above may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium that may be executed by a processor, such as a processor of one or more of network devices108A-108N and109A-109N. Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A storage media may be any available media that can be accessed by a computer. By way of example, and not limitation, such computer-readable media can comprise random-access memory (RAM), read-only memory (ROM), Electrically Erasable Programmable ROM (EEPROM), Compact Disc ROM (CD-ROM) or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. Also, any connection is properly termed a computer-readable medium. For example, if the software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), and floppy disk. Combinations of the above should also be included within the scope of computer-readable media.