Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

This Best Practice describes how the

Spacevars
0product
 (SBC)  handles handles incoming calls when the Server is down or unreachable. The SBC routes the calls according to general configuration guidelines. The information below includes expected behavior for call routing when there is a problem reaching the server (i.e, registration fails, wrong configuration, etc.).

Info

This Best Practice assumes the following:

  • Incoming call is based on Federated IP/Signaling Group listen port/transport protocol.
  • Incoming call is one of the following: ISDN, SIP, or CAS.

Call Survivability when SIP Server is

...

Down - How

...

Calls are

...

Routed With PSTN Backup (SIP Survivability)

Info

A call route to the PSTN must be created in order for calls to be re-routed to the PSTN as a backup mechanism if the SIP Server is unavailable. See Managing SIP Server Tables and Managing Call Routing Tables.

...

  • Incoming call is allowed. Since the server is down, the Signaling Group's Server Status is set as Down. Instead of attempting to send calls to the server, the call proceeds to the next Destination Signaling Group (if configured based on the routing policy, which must include the PSTN). See Managing Signaling Groups.
  • Based on routing configuration, incoming calls are made without any post dial delay to the configured SIP or ISDN trunk.

Pagebreak

Basic Call Mode with Agent Type as "Back-to-Back User Agent" Configuration - How Incoming Calls are handled

Below are the components of a basic configuration

Scenario 1: Registration to server fails; Monitor using SIP Options for the corresponding SIP Server is incorrectly configured.

The SBC handles the calls as follows:

  • Incoming call is allowed. Since the server is down, the Signaling Group's Server Status is set as Down. Instead of attempting to send calls to the server, the call proceeds to the next Signaling Group (if configured based on the routing policy).
  • Based on routing configuration, incoming calls are made without any post dial delay to the configured SIP or ISDN trunk.

Scenario 2: Registration to server is not configured; Monitor using SIP Options for SIP Server fail

The SBC handles the calls as follows:

  • The incoming call is allowed. Instead of attempting to send calls to the Server (since the Server is down). the call will proceed to the next Signaling Group (if configured based on the routing policy).
  • Based on routing configuration, incoming calls are made without any post dial delay to the configured SIP or ISDN trunk.

Scenario 3: Registration to server succeeds; Monitor using SIP options for SIP Server fail

When a very high registration expires (Global Time to Live TTL) interval is configured (configuration available through the Contact Registrant Table), ensure it is sent more frequently. For example, set the registration interval less than the time set for the Registration to expire.

...

  • The incoming call is allowed. If Registration is still valid, the Server and corresponding Signaling Group's Server status is not marked as Down. Calls are attempted to the Server. If no response, the call proceeds to the next Signaling Group if configured based on routing policy. 
    • Case 1. The Far end supports Monitor using SIP options and the Registration interval is configured to be higher than the option interval. The Options response fails, which indicates the Server is down (there may be a post dial delay as the Signaling Group's Server status is not set to Down).
    • Case 2. The far end does not support Monitor using SIP options and the Registration Interval (Global Time to Live or Failed Registration Retry Timer) is configured to be higher than the registration interval. In this case, the Monitor using SIP options response failure is not an indication that the Server is down. Since the Signaling Group's Server Status is not set to Down, the call proceeds normally.

Scenario 4: Registration to server fails; Monitor using SIP Options for SIP Server are successful

The SBC handles the calls as follows:

  • Incoming calls are allowed. If Registration (through Contact Registrant Table) fails, but Option responses (through the SIP Server Table) are successful, the Signaling Group's Server status is not set to Down. Possibilites for the registration failure could be that the Registration was misconfigured and the Server may still be up (as evident from successful Options responses).

Scenario 5: Both Registration and Monitor using SIP Options for SIP Server fail

The SBC handles the calls as follows:

  • Incoming calls are allowed. Since the Server is down, the Signaling Group's Server status is set to Down.
  • Calls proceed to the next Signaling Group if configured based on routing policy.
  • Based on routing configuration, incoming calls are made without any post dial delay to the configured SIP or ISDN trunk.

Scenario 6: Receiving a 3xx/4xx/5xx/6xx response to Register with a Retry after header

The SBC handles the calls as follows:

  • The corresponding session fails.
  • The retry-handling is relevant only for Registrations; it will still allow registrations to be retried to the corresponding server but the Invite requests will not route if all the corresponding sessions fail and the Signaling Group's Server status is set to Down.

Scenario 7: Receiving final 5xx/6xx (without Retry after header) failure responses to Register

The SBC handles the calls as follows:

  • The corresponding session fails.
  • The retry-handling is relevant only for Registrations; it will still allow registrations to be retried to the corresponding server but the Invite requests will not route if all the corresponding sessions fail and the Signaling Group's Server status is set to Down.

Scenario 8: Receiving 3xx/4xx (without Retry after header) response to Register

The SBC handles the calls as follows:

  • The corresponding session is up.
  • Invite requests are routed to the corresponding Signaling Group (the status is set to Up).

Pagebreak

Forward Register after Local Processing Mode - How Incoming Calls are handled in the SBC

Below are the components of a configuration that includes Forward Register after Local Processing Mode (configured through the SIP Signaling Group).

  • Endpoint is registerd with the SBC.
  • SBC has a Signaling Group configured to send requests to a Server.
  • Signaling Group is configured with Fwd Register After Local Processing as the SIP Mode.
  • A signaling group is assocated with both call origination and termination device.

Scenario 1: Registration fails; Fwd Register Option not configured

The SBC handles the calls as follows:

  • Even through the Server is down (and single Signaling group is used), the Signaling Group's Server status is not set to Down.
  • The incoming call will not attempt to reach the Server and will follow the routing policy to try the next SIP/ISDN/CAS trunk using the associated Signaling Group.

Scenario 2: Fwd Register Option fails; Registration not configured

The SBC handles the calls as follows:

  • Even through the Server is down (and single Signaling group is used), the Signaling Group's Server status is not set to Down.
  • The incoming call will not attempt to reach the Server and will follow the routing policy to try the next SIP/ISDN/CAS trunk using the associated Signaling Group.

Scenario 3: Registration fails; Fwd Register Option succeeds

The SBC handles the calls as follows:

  • Normal call flow for incoming call. In case the Server is down, there may be post dial delay in attempting to call the Server.

Scenario 4: Registration succeeds; Fwd Register Option fails

The SBC handles the calls as follows:

  • Normal call flow for incoming call. In case the Server is down, there may be post dial delay in attempting to call the Server.

Pagebreak

Troubleshoot Configuration for connection to a Server

To troubleshoot a server failure due to configuration, verify the current Registration and SIP Server Options configured on the SBC.

Verify Signaling Group

In the Signaling Group screen, the selections available in the SIP Server Table drop down list are derived from the entries configured in the SIP Server Table. This signaling group is used in the SIP Server Table and corresponds to the Server being contacted.

...

Panel
borderStylenone

Caption
0Figure
1Verify Signaling Group

 

Verify Registration/Monitor for SIP Options (for SIP Server)

Through the SIP Server Table, you choose the Contact Registrant table that will be used by a Signaling Group to register one or more contacts to a registrar. Contact Registrant Tables are used to manage contacts that are registered to a SIP server. When Monitor using SIP options is selected, an Options message is sent to the server with more detailed information, such as how often the SBC queries the server with an Options message to determine the server's availability.

...

Panel
borderStylenone

Caption
0Figure
1Verify Registration/Monitor for SIP Options

Pagebreak

Verify Configuration for Contact Registrant

The configuration configured in the Contact Registrant Tables is used to manage contacts that are registered to a SIP server. If registration to a Server is successful, but the Monitor using SIP Options fail, verify the following configuration.

...

Panel
borderStylenone

Caption
0Figure
1Verify Configuration for Contact Registrant

 

Verify Forward Register Option

If registration to a Server is successful, but the Forward Register option fails, verify the following configuration:

...