How Incoming Calls are Handled when Server is Unreachable

This Best Practice describes how the SBC Edge Portfolio (SBC)  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.).

Call Survivability when SIP Server is down - How calls are routed with PSTN Backup (SIP Survivability)

When the SIP server (SIP Signaling Group) is down or unavailable, the call is routed to the PSTN 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 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.

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

• Endpoint is registered with the SBC (see Creating and Modifying Entries in Contact Registrant Tables).
• SBC's Signaling Group is configured to send requests to a server (see Creating and Modifying Entries in SIP Server Tables).

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 SBC handles the calls as follows: 

• 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. Possibilities 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).

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.

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.

Verify the Signaling Group Server Table selected for this specific signaling group as follows: 

1. In the WebUI, click the Settings tab.
2. In the left navigation pane, go to Signaling Groups.
3. Click on the desired SIP Signaling Group.
4. In the SIP Channels and Routing portion, verify the SIP Server Table selected.
   
5. Change or update as necessary. See Creating and Modifying SIP Signaling Groups.

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.

When a Server is unreachable and the problem is registration failing or SIP options not being successful, you can verify the configuration as follows:

1. In the WebUI, click the Settings tab.
2. In the left navigation pane, go to SIP > SIP Server Table.
3. Select the desired SIP Server table that corresponds to the Server being contacted.

4. Click the Contact Registrant Table drop down box. All available registration tables listed in the Contact Registrant Tables are displayed. 

   When a challenge (401/407) is issued by the server, the table selected from the Remote Authorization drop down list is used by a SIP Server Table.

5. From the Monitor drop down list, select SIP options.
6. Verify the configuration and adjust, if necessary. See Creating and Modifying Entries in SIP Server Tables.

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.

1. In the WebUI, click the Settings tab.
2. In the left navigation pane, go to SIP > Contact Registrant Table.
3. Click the table that corresponds to the Server.
4. Verify the configuration (i.e. Global Time to Live) and adjust, if necessary. See Creating and Modifying Entries in Contact Registrant Tables.

Verify Forward Register Option

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

1. In the WebUI, click the Settings tab.
2. In the left navigation pane, go to Signaling Groups.
3. Click on the desired Signaling group that corresponds to the Server.
4. From the SIP Mode drop down list, select Fwd Reg. after Local Processing.