User Interface (With High Availability Mode)
-
OSS/BSS Answers
Access Control Admin Audit B3Network Master Account Channel App Contract App Customer App Discount App Edge Server File Management Finance App Invoice App Number Management Payment Portal Settings Price List Product App Release V2 SMS Gateway Supplier App Support Center Support Hub Business Hub Sales Hub
- App Model - Organization Management
- App Model - Communication Apps Answers
- License Model - Organization Management
-
License Model - CPaaS Solution Answers
Phone System - Admin Guide Phone System - End-user Guide Mobile App Desktop App Web Phone Auto Attendant - Admin Guide Developer Hub - Admin Guide Microsoft Teams Operator Connect - Admin Guide Microsoft Teams Direct Routing - Admin Guide Contact Center - Supervisor Guide Contact Center - Agent Guide Omni-Channel SIP Trunk CPaaS - SIP Trunk Power SIP Trunk CPaaS Fax Contact Dashboard Campaign File Explorer
- Telcoflow
- Integrations Answers
- Updated Regulations
- Ideas Portal
Table of Contents
Requirement
To use the High Availability function, users must purchase a High Availability add-on.
![](https://static.helpjuice.com/helpjuice_production/uploads/upload/image/15042/3224914/1686818227895-Addon.png)
User Behaviour Flow
![](https://static.helpjuice.com/helpjuice_production/uploads/upload/image/15042/3267853/1687761132072-Screenshot%2B2023-06-26%2Bat%2B11.31.48%2BAM.png)
After purchasing a High Availability add-on, users will have a Secondary Sip Account along with the Primary Sip Account to support 2 systems at the same time when using Load Balancing or Auto Fail-over mode.
The High Availability default mode is Only Primary when the customer first purchased a High Availability add-on.
Secondary SIP Account
For the Secondary Sip Account, users can customize:
SIP Label
Authentication Mode
IP Address List
Load Balancing Mode
Business Logic:
- Distribute and balance the traffic of incoming calls following the round-robin mode of both Sip Account
- DO NOT CARE about status of the Sip Account, for instance, if the Primary Sip Account failed, our system will NOT retry
- Share the same concurrent calls flag based on the Primary Sip Account, for instance:
- Primary Sip Account has 30 concurrent calls
- Secondary Sip Account will share 30 concurrent calls with Primary Sip Account
- Primary Sip Account concurrent calls value + Secondary Sip Account concurrent calls value = 30 concurrent calls in total
- Share the same Caller ID for outbound direction based on the Primary Sip Account settings
Auto Fail-over
Business Viewpoint
Technical Constraints
Check Status of SIP Account:
- Before initiating a failover, the system should first check the status of the Primary Sip Account. If the Primary Sip Account is down or unreachable, the system should proceed with the failover process.
Concurrent Calls Logic:
- When failover is triggered, the system should share the same concurrent calls flag based on the Primary Sip Account. For example, if the Primary Sip Account has 30 concurrent calls, the Secondary Sip Account will share 30 concurrent calls with the Primary Sip Account.
- The sum of concurrent calls for both SIP accounts should not exceed the total number of concurrent calls allowed.
Design Logic
We design the Fail-over logic based on sip response code from far-end of the customer side (Inbound Direction) including Wrong credential, Network/Firewall issues at client side, etc.
Example
If the PBX has set up an authentication mechanism on their end that requires them to authenticate with our system for the call to proceed, then the PBX may respond with a 401, 407, 408 or 404 code to prompt the authentication process. If Customer System 1 is unable to authenticate, then it will trigger the Fail-over process to route the call to the Secondary Sip Account to Customer System 2.
The available circumstances for enabling Auto-Failover depending on response code from the client side are listed below:
Response Code from/to SIP Client | Potential Root Cause | Description | Disposition Value on Vendor CDR | Cause Mapping Value to Call Module |
---|---|---|---|---|
401 Unauthorized | Wrong credentials | This response code is triggered when the farend SIP endpoint of Primary SIP account is not authorized to access the requested resource. Failover can be triggered to switch to Secondary SIP account. |
CONGESTION | FAREND_REQUIRE_AUTH |
407 Proxy Authentication Required | Wrong credentials | This response code is triggered when the user needs to authenticate themselves with the Proxy Server before accessing the requested resource. Failover can be triggered to switch to another SIP account. |
CONGESTION | FAREND_REQUIRE_AUTH |
408 Request Timeout | Network/Firewall issue on client side | This response code can occur if the PBX takes too long to respond to the INVITE request sent by B3 SIP server. The SIP server will wait for a certain amount of time for a response from the PBX, and if it doesn't receive a response within that time, it will generate a 408 response code indicating that the request has timed out. In this case, the auto-failover function can be triggered to route the call to the secondary SIP account. |
CONGESTION | FAREND_CONNECTION_ERROR or FAREND_RESPONSE |
404 Not Found | User not registered | SIP response with code 404 indicates that the requested resource could not be found on the server. This can happen if the SIP account is unavailable or not registered. Therefore, a 404 response can be used as an indication to trigger the failover mode. Failover can be triggered to switch to another SIP account. |