Understanding the SRX Series Survivable Call Server

This topic gives an overview of the SRX Series survivable call server (SRX Series SCS) that takes over when the peer call server is unreachable. The SRX Series SCS provides call handling and routing services for analog and SIP phones configured at the branch office when the peer call server is unable to do so.

The SRX Series SCS relies on a dial plan, referred to as the SRX Series SCS dial plan, that, in collaboration with station configurations, determines how calls are routed. Before it routes a call, the SRX Series SCS applies call services configured for the station where the call originated.

Note: To provide a seamless user experience, ensure that your SRX Series SCS call handling and routing services configurations match those of the peer call server.

The SRX Series SCS dial plan can include route patterns and route policies.

• Route patterns specify digit patterns against which called numbers are matched. Route patterns are used in conjunction with the class of restriction (COR) configuration that is assigned directly to a station or to it through a station template. A call is routed out a trunk assigned to a route pattern if the following two conditions exist:
  • The dial plan includes a route pattern with a digit pattern that the called number matches.
  • The COR configuration for the station from which the call is made includes an allow policy for the type of call placed and specified by the route pattern.

    Note: When the SRX Series SCS is active, destination class of restriction call routing is supported to determine rights users have to make types of calls from certain stations.

• Route policies can be used to:
  • Enable the SRX Series SCS to act as a front-end media gateway to a PBX device.
  • Implement toll bypass.

Figure 4 illustrates a case in which the peer call server is unreachable and the SRX Series SCS takes control to provide call handling and routing services. The device also applies firewall, NAT, ALG, and IPsec (FNAI) processes to a call before it is routed out from or into the branch.

There are many reasons why the peer call server could become unreachable. A cable could be disconnected, the network could be congested, there might be routing problems or problems at the transport level, or a successful denial-of-service attack might have been launched against the application server hosting the peer call server.

To determine if the peer call server is unreachable, the SRX Series SCS monitors it using the two configurable parameters for this purpose explained in Table 9.

If it determines that the peer call server is unreachable and cannot recover from the failure, the SRX Series SCS takes control. Then it monitors the peer call server to determine if it has become reachable again and, if so, to determine if it is reliable. It uses the three configurable parameters explained in Table 10 for this purpose.

Note: If, when you configure the peer call server, you specify a FQDN for the server address rather than an IP address so that multiple servers can be used, the SRX Series SCS sends heartbeat messages to all servers to determine which ones are available.

Table 10 shows the keepalive message parameter and the response requirements process that the SRX Series SCS uses to determine if the peer call server is reachable again and reliable. If the peer call server meets the response criteria, the SRX Series SCS returns control to it.

Related Topics

• Understanding the SRX Series Integrated Convergence Services Survivable Call Server Features
• Understanding How the Media Gateway Peer Call Server Handles and Routes Calls Outside the Branch for SRX Series Integrated Convergence Services
• Understanding How the Media Gateway Peer Call Server Handles and Routes Calls Within the Branch for SRX Series Integrated Convergence Services