High availability and workload management with Session Initiation Protocol proxy server

SIP high availability solution assumes that all messages that belong to the same dialog are handled by the same container. If a container fails, all of the sessions that were handled by that container are picked up by the other servers in that container replication domain, and are activated immediately. All subsequent messages that belong to a session from the failed container are sent to the new container in charge of that session.

The SIP proxy server does not administer transaction-level failover, which are calls that are made in the middle of a transaction. The SIP proxy server administers failover of stable calls, which are calls that are not made in the middle of a transaction.

High availability manages the following:

• Scalability - The ability to add more servers to the cluster to handle increased loads.
• Load balancing - The ability to distribute the load across all of the servers in the cluster so no server is overloaded while there are other servers that are not utilized.
• Fail over - The ability to recover from a failure in one or more of the components in the solution.

The SIP high availability solution uses the following components:

• SIP container - Maintains all of the sessions and launches all of the applications.
• SIP proxy server - Manages a large number of client connections, routes incoming messages to the appropriate SIP container, and creates outbound connections to clients and other domains.
• Network Dispatcher - Provides a single IP for the cluster and round-robins between proxies.
• Unified Clustering Framework (UCF) - Communicates routing information between the SIP container and the SIP proxy. Using UCF, the SIP proxy routes messages to the least-loaded SIP container or to a container that is taking over sessions for a failed server.

  If we add SIP containers to a cluster while traffic is flowing, we should add them one container at a time so the system can go through the bootstrap process for the container without draining resources from the entire cluster. If we add one container at a time, only the added container goes through the bootstrap process as opposed to all of the containers in the cluster.

Manage failover in the SIP proxy by:

1. Replicating the data in the sessions between SIP containers so that other containers are able to activate the failed sessions in case of a server failure.
2. Activate the failed sessions on the rest of the servers immediately when a failure is detected because the SIP sessions might have timers associated with them.
3. Routing incoming messages that belong to failed sessions to the new server that is handling the session.