Avaya Client Failover

Avaya clients (telephones) require notification when the connection between the access Oracle® Enterprise Session Border Controller and the Avaya Session Manager, which provides client subscription/registration services, has been lost. In the absence of such notification, the Avaya client can become unreachable for up to 24 hours. Version E-C[xy]6.4.0M4 addresses this problem by enabling anOracle® Enterprise Session Border Controller that loses connectivity with an Avaya Session manager to transmit a TCP/FIN(ish) to all Avaya clients previously supported by the unreachable Session Manager. The TCP/FIN alerts clients of the need to re-register when connectivity to the Session Manager is restored.

Loss of connectivity between an Oracle® Enterprise Session Border Controller and an Avaya Session Manager can result in Avaya clients (telephones) becoming unreachable for an extended period of time. Version E-C[xy]6.4.0M4 addresses this problem by enabling an E-SBC that loses connectivity with an Avaya Session manager to transmit a TCP/FIN(ish) to all Avaya clients supported by the unreachable Session Manager. The TCP/FIN alerts clients of the need to re-register when connectivity to the Session Manager is restored. In addition to issuing alerts to impacted clients, the Oracle® Enterprise Session Border Controller also deletes all registrations associated with the out-of-service Session manager from the Oracle® Enterprise Session Border Controller's registration cache.

A typical Avaya topology as shown below consists of a single Avaya client (a telephone), a single Oracle® Enterprise Session Border Controller, and a single Avaya Session Manager, which provides subscription/registration services for the telephone. If connectivity between the Oracle® Enterprise Session Border Controller and the Session Manager is lost, the Avaya client requires a TCP/FIN(ish) message that alerts the client to invalidate its subscription status, and to re-subscribe once the TCP connection becomes available. Without receipt of the TCP/FIN, the phone remains unaware of its state change, and will not receive notifies from the Session Manager until it re-subscribes, which by default is 24 hours later).

Support for redundant access topologies, based on RFC 5626, Managing Client-Initiated Connections in the Session Initiation Protocol (SIP), was introduced in Version E-C[xy]6.4.0M2. This topology accomplishes redundancy by registering an Avaya telephone to multiple Session Managers, as shown below.

In this case, the Oracle® Enterprise Session Border Controller maintains connections with two Avaya Session Managers, both of which share state information and act as a registrar and proxy for the Avaya telephone. The client establishes redundancy with two TCP connections to the domain. Redundant connections are differentiated by a unique reg-id contact header field parameter. In the above illustration, two reg-ids TLSRegID 1 and TLSRegID 2 are created for different Session Managers on the same Oracle® Enterprise Session Border Controller. If a Session Manager goes out-of-service, the Oracle® Enterprise Session Border Controller sends a TCP/FIN message to the Avaya client for the reg-id associated with the unavailable Session Agent, and deletes all associated registration cache entries.