Overview

Last Updated : Oct 09, 2023 |
Prolog information
Metadata
Keywords:
The SIP trunk optimization feature eliminates the need for provisioning trunks for redundancy. This feature frees up trunks so that the available trunks can be used by SIP agents, SIP stations, or PSTN bound SIP trunk calls. The following illustration explains the problem of trunk consumption due to redundancy.
Figure: Scenario 1 of trunk consumption due to redundancy
The above figure provides the following two scenarios:
  • First scenario: When the connection between Communication Manager and Session Managers work fine.
  • Second scenario: When the connection between Communication Manager and Session Manager fails.
In the first scenario, if Communication Manager wants to reach the red agents (agent pool 1), it can do so by utilizing the red trunk between Communication Manager and Session Manager-1. Similarly, if Communication Manager wants to reach the blue agents (agent pool 2), it can do so by utilizing the blue trunk between Communication Manager and Session Manager-2.
In the second scenario, if Session Manager- 1 and Communication Manager connection is broken, or if Session Manager-1 fails, then Communication Manager has an alternate path to reach the red agents through Session Manager-2 using the blue trunk. With 2500 trunk members between Communication Manager and Session Manager-2, 5000 agents from both the agent pools cannot be supported. Same is the case if the blue agents fail over to Session Manager-1.
To address the issue on the second scenario, additional trunks must be administered between Communication Manager and Session Manager-1 and also between Communication Manager and Session Manager-2. To support failover of 2500 red agents over to Session Manager-2, additional 2,500 trunk members must be administered between Communication Manager and Session Manager-2. Similarly, to support failover of blue agents over to Session Manager-1, additional 2,500 trunk members must be administered between Communication Manager and Session Manager-1. To support the second scenario, additional trunks are shown by the dotted lines in the following figure.
Figure: Scenario 2 of trunk consumption due to redundancy
In the second scenario, administering additional trunks provide a solution for giving service to red and blue agents, but introduces few other problems.
  • The additional trunk members administered for redundancy remain unused in the first scenario when entity links to Session Manager-1 and Session Manager-2 are in service.
    Note:
    When the policy-based assignment is enabled in System Manager, you can administer up to four Session Managers for a SIP station.
  • Double the number of trunks must be provisioned to cover a rarely occurring second scenario. Given the limited trunk members on Communication Manager, using trunks for redundancy reduces the trunks required for actual traffic.
  • Routing and administration of route patterns become complex.
For provisioning connectivity to Session Manager-1 and Session Manager-2, Communication Manager has to create two signaling groups:
  • Signaling group to Session Manager-1: Near-End as procr and Far-End as Session Manager-1
  • Signaling group to Session Manager-2: Near-End as procr and Far-End as Session Manager-2
Each signaling must have 5000 trunks provisioned with Session Manager-1 and 5000 trunks to be provisioned with Session Manager-2 as described earlier.
SIP trunk optimization feature enables each signaling group to point to multiple Session Managers. In this particular case, a signaling group will point to both Session Manager-1 and Session Manager-2. This is achieved by pointing the signaling group to a cluster of Session Managers. An SM cluster can have 28 Session Managers. With a Session Manager cluster, it is assumed that all Session Managers share a similar configuration, and any Session Manager can route a call to the far end station or far-end trunk.
The ability of the signaling group to point to both Session Managers reduces the required trunks to be administered on Communication Manager by half while achieving full redundancy. If the link to Session Manager-1 fails, the Signaling group uses the link to Session Manager-2 to route all the outgoing traffic. The effect of one signaling group pointing to multiple Session Managers is as follows:
  • Signaling group remains in service if at least one Session Manager administered in the cluster is reachable.
  • Trunk group remains in service, and all members administered in the trunk group can deliver traffic.
  • For example, a trunk group with 5000 members in the first scenario can service 2500 agents on Session Manager-1 and 2500 agents on Session Manager-2. If the connectivity between Communication Manager and Session Manager-1 goes down, the same trunk group with 5000 members can service 2500 agents on Session Manager-1 and 2500 agents on Session Manager-1 and 2500 agents on Session Manager-2 through the link between Communication Manager and Session Manager-2. Even if Session Manager-1 goes down and all agents move to Session Manager-2, the same 5000 members can reach all the 5000 agents.
The SIP trunk optimization feature are as follows:
  • Number of trunk members is 9,999 for SIP trunk groups.
  • Number of SIP agents is 10,000.
  • System-wide trunk members is 30,000.
  • Measured trunks is 30,000.
  • TLS connections for SIP is 56 from 32 to support 28 Session Managers because two links are required to support each Session Manager.
  • SIP Station form directly points to its Primary and Secondary Session Manager to support 28 Session Managers because two links are required to support each Session Manager. For more information about the capacities, see Avaya Aura® Communication Manager System Capacities Table.
    Note:
    When the policy-based assignment is enabled in System Manager, you can administer up to four Session Managers for a SIP station.
  • Look Ahead Routing feature is deprecated for SIP station calls if routed over clustered signaling group.
  • Route pattern can now specify a network region.