SIP Routing with Server Clusters Overview

The use of server clusters as SIP routing destinations provides many scaling and performance options. The servers in clusters assigned as routing destinations can be checked for availability based on configurable options. Available servers are assigned based on priority and weight within priority.

This topic consists of the following sections:

• Availability Checking for Server Clusters
• Server Definition for Server Clusters
• Server Cluster Definition

Availability Checking for Server Clusters

The Junos OS keeps track of server availability by sending SIP options messages to the server and waiting for a response. When your server is down, it is added to a blacklist. You can create availability checking profiles for assignment servers. The profile includes the following:

• keepalive strategy—When to send availability checking ping requests: always, only when the server is down, or never.
• keepalive interval—The number of seconds between ping requests.
• transaction-timeout—The number of seconds from the initiation of a ping request after which, if no reply was received from the pinged server, the pinged server is considered to be down.

Related Topics

• Creating Availability Profiles for Servers

Server Definition for Server Clusters

You define servers so that you can later include them in server clusters to be used as routing destinations. When you define a server, you must include the following:

• IP address
• Service point name
• Admission control profile name
• Availability profile name

When you use server clusters as routing destinations, the IP address and service point name for a server replace the function of the next-hop address and egress service-point in other destination options.

When a server cluster is selected as a routing destination in a new transaction policy, the admission control profile for the policy is applied first to incoming transactions and a 403 (forbidden) response is sent if the new transaction is rejected. Subsequently, the transaction is routed to servers in the cluster, starting with the servers with the highest priority level and the highest weight within a priority level. The servers are checked for availability (meaning that they are not in the server blacklist) and the admission control policy for the server is applied to the incoming transactions. If the transaction cannot be processed by any server due to unavailability or admission control criteria, a 502 (server unavailable) response is sent if the transaction is rejected.

Server Cluster Definition

To define a server cluster, you must list each server assigned to the cluster, along with its scheduling priority and weight. The priority indicates the first level of routing preference. The weight indicates relative proportion of routing within a priority group. If you want all servers to receive equal distribution of incoming transactions (round robin scheduling), give them the same weight.

Related Topics

• Using New Transaction Policies to Route SIP Requests Using Server Clusters in Session Border Control Solutions Guide Using BGF and IMSG