Redundancy Server

Owned by HTEK_admin (Unlicensed)
Last updated: Feb 17, 2022 by HTEK
6 min read

1. Preface

This guide provides detailed information on how to configure and use server redundancy on Htek IP phones. The information applies to Htek phones running firmware version 1.0.3.61 or later.

2. Introduction

Server redundancy is often required in VoIP deployments to ensure continuity of phone service, for events where the server needs to be taken offline for maintenance, the server fails, or the connection between the IP phone and the server fails. Two types of server redundancy are possible. In some cases, a combination of the two may be used:

  • Failover Server Use DNS-SRV or DNS-NAPTR(FSUSN): In this mode, the full phone system functionality is preserved by having a second equivalent capability call server take over from the one that has gone down or off-line. This mode of operation should be done using the DNS-SRV or DNS-NAPTR from the primary to the secondary server.

  • Failover Server Use DNS-A(FSUA): In this mode, a second less featured call server (FSUA) with SIP capability takes over call control to provide basic calling capability, but without some advanced features offered by the working server (for example, shared lines, call recording and MWI). IP phones support configurations of two SIP servers per SIP registration for this purpose.

3. Redundancy Server Implementation

To assist in explaining the server redundancy behavior, an illustrative example of how an IP phone may be configured is shown as below. In the example, server redundancy for FSUA and FSUSN purposes is deployed. Three separate SIP servers (a working server and Two FSUA server) are configured for per line registration.

  • Sip Server 1
    SIP Server 1 is configured with the domain name of the working server. For example,as.iop1.broadworks.net, DNS mechanism is used such that the working server is resolved to multiple SIP servers for failover purpose. The working server is deployed in redundant pairs, designated as primary and secondary servers. The primary server has the highest priority in a cluster of servers resolved by the DNS server. The secondary server backs up a primary server when the primary server fails and offers the same functionality as the primary server.

  • Sip Server 2 and Sip Server 3
    Sip Server 2 and Sip Server 3 is Work when we set the DNS-MODE as DNS-A, And its often offers less functionality than the working server.

4. Phone Function Implementation

Phone Registration

The IP phone must always register to the primary server first. If this is unsuccessful, the phone will re-register as many times as configured until the registration is successful. When the primary server registration is unavailable, the secondary server will serve as the working server.
Registration methods of the fallback mode include:

  • Concurrent registration: The IP phone registers to two SIP servers (working server and fallback server) at the same time. In a failure situation, a fallback server can take over the basic calling capability, but without some advanced features offered by the working server (default registration method).

  • Successive registration: The IP phone only registers to one server at a time. The IP Phone first registers to the working server. In a failure situation, the IP phone registers to the fallback server.

Sip Server Domain Name Resolution

If a domain name is configured for a SIP server, the IP address(es) associated with that domain name will be resolved through DNS as specified by RFC 3263. The DNS query involves NAPTR, SRV and A queries, which allows the IP phone to adapt to various deployment environments. The IP phone performs NAPTR query for the NAPTR pointer and transport protocol (UDP, TCP and TLS), the SRV query on the record returned from the NAPTR for the target domain name and the port number, and the A query for the IP addresses.
If an explicit port (except 0) is specified and the transport type is set to DNS-NAPTR, A query will be performed only. If a SIP server port is set to 0 and the transport type is set to DNS-NAPTR, NAPTR and SRV queries will be tried before falling to A query. If no port is found through the DNS query, 5060 will be used.

Configuring Htek IP Phones

You can configure server redundancy feature for the IP phone via web user interface or using configuration files. The followings take configurations of a Htek IP phone.
Running firmware version 1.0.3.61 as examples.
To configure server redundancy for FSUSN purpose via web user interface:
Step 1: Click on Account->Basic.
Step 2: Select the desired account from the pull-down list of Account
Step 3: Configure parameters of Primary SIP Server or Failover SIP Server Second Failover Sip Server in the corresponding fields.
Step 4: Select DNS-mode for DNS-A, DNS-SRV, DNS-NAPTR
Step 5: SaveSet and Restart

5. Using Redundancy Server on Htek IP Phone

FSUA Scenario

The following introduces a REGISTER FSUA scenario. We set the Primary SIP Server, Failover SIP Server and Second Failover Sip Server

  • Register
    The phone has ability to register to a failover server when the Primary SIP Server has no response to a REGISTER request.
    1) The phone sends a REGISTER request to the Primary SIP Server.
    2) The phone retries to send REGISTER requests to the Primary SIP server (three times by default).
    3) After no response from the Primary SIP server, the phone sends a REGISTER request to the failover server.
    4) The phone retries to send REGISTER requests to the Failover SIP server (three times by default).
    5) After no response from the Failover SIP server, the phone sends a REGISTER request to the Second Failover server.
    6) The Failover server responds with 200 OK to the REGISTER request.

  • Invite
    The phone has ability to register to a failover server when the Primary SIP Server has no response to a INVITE request.
    Phone A places a call to Phone B, Then Phone B answers the call.
    1) The phone sends a INVITE request to the Primary SIP Server.
    2) The phone retries to send INVITE requests to the Primary SIP server (three times by default).
    3) After no response from the Primary SIP server, the phone sends a REGISTER request to the failover server.
    4) The Failover server responds with 200 OK to the REGISTER request.
    5) The phone sends a INVITE request to the Failover server.

Phone A sends REGISTER requests to the working server to detect whether the server is available. When the working server recovers, the phone has ability to fail back the INVITE request to the working server.

FSUSN Scenario

The following introduces a REGISTER FSUSN scenario. The SIP server 1 is configured with the domain name of the working server. The working server is resolved to two SIP servers (primary server and secondary server) using the DNS mechanism. The parameter DNS-mode set to DNS-SRV or DNS-NAPTR

  • Register
    The phone has ability to fail over to a secondary server when the primary server has no response to a REGISTER request.
    1) The phone sends REGISTER request to the primary server.
    2) The phone retries REGISTER requests to the primary server (three times by default).
    3) After no response from the primary server, the phone sends a REGISTER request to
    the secondary server.
    4) The secondary server responds with 200 OK to the REGISTER request.
    The phone waits until next REGISTER attempt and then sends next REGISTER request to the primary server. When the primary server recovers, the phone has ability to fail back next REGISTER request to the primary server.

  • Invite
    The phone has ability to fail over to a secondary server when the primary server has no response to an INVITE request.
    Phone A places a call to Phone B, Phone B answers the call.
    1) Phone A sends an INVITE request to the primary server.
    2) Phone A retries INVITE requests to the primary server (three times by default).
    3) After no response from the primary server, the phone sends an INVITE request
    to the secondary server.
    4) The secondary server responds with 200 OK to the INVITE request.
    When phone A places a call to Phone B again, the phone sends an INVITE request to the primary server first. When the primary server recovers, the phone has ability to immediately fail back INVITE request to the primary server after failing over to the secondary server.