Problem statement

There is a remote facility (e.g., a branch office) that requires telephony to be organized within a single numbering space with the head office. Under normal conditions, subscribers at the facility should be able to use all the telephony services of the head office. In the case of a failure of communication lines to the head office, subscribers must be provided with telephone communication within the facility and have access to external telephone networks (e.g., PSTN).

To solve this problem, we suggest installing an SMG IP PBX at the remote site, configured in transit subscriber registration mode, whereby subscribers will work through the main PBX when it is available or through the SMG itself when the main PBX is unavailable. In this case, the SMG becomes a “survival server” that ensures call routing.

Operation description

Operating in normal mode

In normal operation, subscriber SIP terminals send a registration request to the survival node (SMG), which registers the subscriber and sends a registration request to the higher-level server. As can be seen from the above, for transit registration to work, subscribers must be created on both the survival node and the main PBX. They must also have the same login and password.

All requests from SIP subscribers go to the main PBX, and responses from the main PBX pass through the survival node (Figure 1). All services, such as DVO, call recording, CDR recording, and call history, are handled by the higher-level PBX.

It is recommended to organize access to external telephone networks via channels from the survival node (Figure 3). In some cases, if the external PBX is ready to accept calls from the survival node's number capacity via channels from the main PBX, it is possible to configure routing to external networks via channels from the main PBX. Incoming calls must pass through channels organized from the survival node (Figure 4). 

Working when the main PBX is unavailable

In case of communication channel failure to the main PBX or failure of the main PBX itself, the survival node detects that the main PBX is unavailable and processes all requests from SIP subscribers independently. CDR, call history, and conversation records are stored on the survival node. After access to the main PBX is restored, the records are not synchronized. VAS is also performed by the survival node. Access to external telephone networks is provided through channels organized from the survival node (Figure 5 and Figure 6).

Transit registration

Configuration

To implement this scheme, it is necessary to:

1. On the main PBX:
   1. Set up trunk routing to the remote site;
   2. Create subscribers;
   3. Enable and activate additional services for subscribers.
2. On the survival node:
   1. Create a trunk group, SIP interface for communication with the head office;
   2. Create a SIP profile specifying the transit registration interface to the head office;
   3. Create SIP subscribers with the same numbers as on the main PBX using the SIP profile created in the previous step.

Verification

Registered subscribers on SMG can be viewed in the “Subscribers → SIP subscribers → Monitoring” section. These same subscribers must also be registered on ECSS-10 at the same time. Registered subscribers can be viewed in the “Subscriber card” application or in the output of cocon commands:

domain/<domain_name>/sip/user/list --active
domain/<domain_name>/sip/user/registered

Access to external networks

Configuration

It is recommended to configure outgoing traffic to external networks and incoming traffic from external networks through channels organized from the survival node. This will allow maintaining connectivity with external networks in the absence of communication with the main PBX. Basic settings:

1. On the main PBX: 
   1. Configure call routing from survival node numbers via trunk to the survival node (SIP trunk in diagrams).
2. On the survival node: 
   1. Create and configure SIP interfaces and trunk groups in the direction of external networks;
   2. Configure the dial plan for access to external networks.

How it works

In normal operating mode

Outgoing call:

1. The call is initiated by an internal subscriber (telephone set) and goes to the survival node (SMG).
2. The survival node, realizing that the call came from a device for which transit registration is enabled and that the channel to the main PBX is operational, ignores the local dial plan and forwards the call to the main PBX.
3. The main PBX, having received a call from the transit registration number to an external number via routing, sends the call back to the SMG (survivability node) via the SIP trunk.
4. SMG, having received a call from the trunk, sends the call to the trunk to the external PBX in accordance with the dial plan.
5. Further processing of the call, carried out outside our area of responsibility, reaches the external subscriber.

Incoming call:

1. The call is initiated by an external subscriber, passes through an external PBX, and reaches the Survival node (SMG) via an external trunk.
2. The survival node, realizing that the call is intended for a subscriber registered on the main PBX, sends the call to the main PBX via SIP trunk.
3. The main PBX, having received a call from the SIP trunk, processes the call (VAS, call recording and CDR, etc.) and sends the call to the internal subscriber via the survival node.

When the main PBX is unavailable

Outgoing call:

1. The call is initiated by an internal subscriber (telephone set) and goes to the survival node (SMG).
2. The survival node, realizing that the main PBX is unavailable, forwards the call to the trunk to the external PBX according to the dial plan.
3. Further processing of the call, carried out outside our area of responsibility, reaches the external subscriber.

Incoming call:

1. The call is initiated by an external subscriber, passes through an external PBX, and reaches the Survival node (SMG) via an external trunk.
2. The survival node, realizing that the main PBX is unavailable, uses its own subscriber registration table, processes the call (VAS, call recording, CDR, etc.) and sends the call to the internal subscriber.

Redundancy of higher-level automatic telephone exchanges

In some cases, during transit registration, it is convenient to be able to automatically switch to a backup server of a higher-level IP PBX if the connection to the current one is lost. If the ECSS-10 Softswitch cluster acts as the higher-level IP PBX, switching between servers is implemented using the VRRP protocol. The IP address of the first server simply “moves” to the second. In some other cases, the switch must be initiated by the survival node. For example, when using geo-reservation. This functionality is implemented on SMG starting with software version 3.405.1.

Configuration

The configuration principle is similar to configuring transit registration for a single parent server:

1. On the main PBX:
   
   1. Set the trunk direction towards the remote object;
   2. Create subscribers;
   3. Enable and activate additional services for subscribers.
2. On the survival node:
   
   1. Create a trunk group, SIP interface for communication with the first server at the head office;
   2. Create a trunk group, SIP interface for communication with the next head office server;
   3. If there are more than two higher-level servers, repeat the previous step;
3. Create a SIP profile. Add all necessary SIP interfaces to it;
   

       4. Create SIP subscribers with numbers identical to those on the main PBX using the SIP profile created in the previous step.

Verification

To verify that the reservation is working, it is necessary to first check the registration in normal operating mode. The check is performed using the command: 

domain/<имя_домена>/sip/user/registered * <number>@<domain_name>

The “Registration info” column shows which node the phone number is registered on.

After that, it is necessary to interrupt the network connection of the survival node with this node, but leave the connection with the backup node. This can be done, for example, by blocking all traffic from the survival node to the desired node using the built-in firewall.

After the timeout period for checking the availability of the other party (30 seconds by default), recheck the phone registration with the command:

domain/<domain_name>/sip/user/registered * <number>@<domain_name>

The node must change.

Media server on the survival node

In some cases, for example, when the communication channel to the main PBX is of poor quality, it is advisable not to send media traffic from local calls and calls to external networks to the main PBX. To do this, a local media server can be enabled on the SMG-3016, and all media traffic from local subscribers can be processed on this media server. In this case, all signaling traffic will continue to pass through the main PBX as before.

It should be noted that with this solution, conversations will be recorded on the survival node, not on the Main PBX.

To use the SMG-3016 media server on the survival node, it is necessary to:

1. Configure the local media server on the SMG-3016 according to the instructions in Appendix H. Configuring a software media server.
2. Create and configure a separate site for the survival node.
3. Set the created site for subscribers of the survival node.