Before we begin, this is not a complete step by step guide meant for people who have never configured a Ribbon SWe before. However, this article includes videos and links to supporting resources to support this guide and / or further learnings around the subject.
This guide assumes that you understand Ribbon and SIP in general to a basic level and you are comfortable filling in the sub details.
Enghouse Contact Center Enterprise
Enghouse Contact Center Enterprise (CCE) is different to the more commonly known Enghouse Interactive Contact Center (EICC) that is used for Skype for Business deployments.
Instead of integrating with Skype for Business using trusted application endpoints, Enghouse CCE is a standalone contact center that contains its own software SBC based on Dialogic.
That Dialogic SBC will interface with the FreeSwitch PBX on the Enghouse CCE server and the subsequent underlying contact center application.
The Enghouse CCE application for Teams consists of a minimum of 2 Servers. Server 1 is the call processing server (CP) that contains the contact center application and call flow logic. Server 2 is the Enghouse Teams Connector (TC) server that is used as a conference server to connect the Teams based agent and the caller.
These 2 servers do not interconnect directly, meaning an SBC is responsible for the connection and call routing between these servers and also the PSTN and Teams leg of the call flow.
Call Flow Descriptions
There are several call legs that make up a single interaction between an Agent in Teams and a caller into the Enghouse CCE application.
Call from PSTN to CP server
The CCE application will expect inbound calls to its IVR system based on the DNIS number called by the caller. Therefore, all calls to the CCE numbers should be directly routed from the ITSP SIP trunk to the CCE CP server SIP trunk on the SBC.
The caller will then be placed into the appropriate queue system for treatment. Once the caller has reached first in the queue agent hunting begins.
At this moment, the caller is transferred from the CP Server to the Enghouse TC Server via the SBC using a routing number prefix that allows the SBC to route the call appropriately.
Call from CP to TC server
This call is initiated from the CP server and sent to the SBC for routing to the TC server when the agent is being hunted. The INVITE request will contain a routing prefix number and the agent’s DDI.
Example: sip:72*+441234567890
The routing prefixes can be any number that is not currently conflicting with other routing rulesets on the SBC. The CCE application will be configured with the supplied prefix.
Upon routing to the TC server, the TC server will create a conference and then REFER the PSTN caller to that conference, thus transferring the caller to the TC server and the conference.
Call from TC server to Teams
Simultaneously, the Enghouse TC server will place an outbound call to the agent number as passed to it from the CP call. This will be sent to the SBC in this format sip:72*+441234567890. The SBC can then safely strip the prefix and route that call over the Teams Direct Routing SIP trunk.
The Teams agent will receive the call to their Teams client and upon accept will be placed into the conference created on the TC server.
Agent ReQueuing
There will be times where the answering agent will have to send the caller back to the Enghouse CP server for re-queuing. This is usually when a caller has got through to the wrong team. The agent will dial a special re-queue number that will transfer the caller back into the IVR system and into the required queue workflow.
These requeue numbers can be any internal range that is not currently used elsewhere e.g. 62000 – 62099. The actual total amount of requeue numbers required will depend on your Enghouse CCE requirements.
The agent will dial these requeue numbers using the Teams client standard dial pad using blind call transfer. Therefore, Teams outbound routing will be required to route these numbers from Teams to the SBCs configured for CCE.
Once received by the SBC, these calls should be routed from Teams to the Enghouse TC server. The TC server will then place an outbound call INVITE to the CP server using the same requeue number and then transfer the caller back from the TC server to the CP server.
Agent Outbound Calling
For an agent to make an outbound call using Enghouse CCE they must first use the Touchpoint client to enter the called number into that. This client then sends a CTI to the TC server and instructs it to make the outbound call on behalf of the agent.
The TC server then creates a conference and invites the called number and the agent’s DDI into the conference.
In this configuration, if the Agent places an outbound call to a company employee’s phone number that is also in Teams, that call will be placed over the PSTN. You can keep these calls on net and configure the SBC to route these destinations back to Teams using the DR trunk. However, the SBC will need to know how to make that decision.
It can be done in one of 3 ways. Depending on the complexity of the pre-reqs you may choose one over all or none at all
- AD based routing. This is where the SBC interrogates AD to determine if the called number is internal. If true, route to Teams. This requires AD to be accurate for all phone numbers. Generally, unless you have AzureAD Premium P2 license for your users that allows attribute write back from AzureAD to AD, this option carries a lot of risk and management overhead to keep two directories manually in-sync.
- Range detection. If you know the DDI ranges you own, then you can configure the routing table to route based on the entire range(s). This may not work well if you have a split-range between Teams and another PBX or if you use Microsoft numbers with calling plans. With Microsoft numbers, you don’t always get contiguous blocks of numbers, so configuring the SBCs for individual numbers is not scaleable.
- Re-Route on Fail. This uses failover routing based on an error code received. Essentially configure the SBC to route all calls to Teams regardless of the number called. Teams will look up this number against your tenant. If a user is found with this number, the call is processed. If not, Teams will send a 404 User Not Found response and the SBC can re-route the call to the PSTN trunk instead. It’s not elegant, it produces a lot of false positives in monitoring, adds a few milliseconds to call setup and relies on Teams to send the appropriate response. But it can be a viable option if the other two are impossible to implement.
High Availability
The Enghouse CCE application can run in high availability mode. If this is configured, multiple pairs of CP and TC servers are deployed. High Availability can be deployed in one of two ways:
Same datacenter region connected to the same SBC
Different datacenter region connected to different SBCs
This topology gets quite complicated as the SBCs must be interconnected, and failover routing configured to re-route each leg of the call to the appropriate partner destination.
When configured in this topology, each call leg described in the call flow descriptions must be configured for re-routing on fail. Enghouse CCE will return either Q.850 Cause Codes 41 or 102 to signal a failure with its application service. The SBC should be configured to re-route if these are received.
An example of failover routing for an inbound call from the PSTN to the Enghouse CCE CP server would look like this
Deployment Checklist
Before you start configuring the Ribbon SBC for Enghouse CCE, make sure that you have decided on the dial plan you need to implement. This is especially important if you are deploying inter-region failover as making configuration changes can get very complicated.
| Inbound DDI numbers (DNIS) the CCE CP IVR application is expecting | |
| The Agent Routing Number prefix for each regional deployment e.g. 72* | |
| The Agent ReQueue Numbers that they will dial to place the caller back into the IVR e.g. 62000 – 62099. (One range per region) | |
| Number pattern for outbound dialling to internal users |
Configuring Ribbon SWE Lite in Azure
Deploying the Ribbon SWe lite in Azure is a fairly mundane task. However, you do have to consider your network architecture and security first. At a basic level, how are you connecting the SIP trunks between your ITSP and the SBC and the SBC to the Enghouse CCE application?
Are you deploying this in a single Azure subnet with a public IP attached to the private interface of the SBC? Or are you separating the public side from the private side with two subnets?
The latter, two-legged network topology is the most secure because you are not exposing the internal CCE servers to public risk by attaching them to the network that has public inbound access to the SBC. Instead, you are using Azure networking security and SBC securities by design and adding a layer of protection out of the box.
Whatever you decide, you will need to add at least one additional virtual network adapter to the SBC VM above and beyond the one deployed by the marketplace image. This is because the first networking adapter is designated the Admin Interface in the Ribbon SWe-lite SBC.
The Admin interface cannot be used as a SIP interface by design. If you try and use this, calls will fail.
This means you need to choose an Azure VM size that supports at least 2 network adapters. If you are deploying the two-legged network topology, you need 3 interfaces.
A word of caution on the VM sizes. Ribbon do not provide support for SWe-Lite’s deployed on non-recommended Azure VM instances.
I urge Ribbon to consider widening their supported Azure VM sizes.
The reason, the entry level for an SBC in this configuration (3 or 4 network adapters) is an F4s (4 vCPU, 8GB RAM). At 20 cents per hour regardless of whether you are running 10 sessions or 1,000 costs a minimum of $1,752 per year per SBC in just compute.
Whereas the cheapest VM size that supports 3 network adapters is the B2ms (2 vCPU, 8GB RAM) at a run cost of approx. 9.4cents per hour (or $788 per year). The B2ms with burstable CPU to 200% offers approx. capacity of 60 transcoded sessions.
Moving on, it is important that you add your networking adapters before you start configuring the SBC. It might not make too much difference if you are deploying just one SBC. However, when you have 4, 6, 10+ in the deployment, it is nice to have a consistent configuration across them all. This means nic assignment order.
I’ve seen it where Eth1 in Azure shows as logical interface 3 and Eth2 show as logical interface 2. This can get confusing, especially when setting up the NSGs and then working back into the application layer of the SBC.
As a general rule, Eth0 will be Admin, Eth 1 Interface 1, Eth2 Interface 2 etc. But getting these right before you’ve configured the SBC and most importantly, licensed it, you have the opportunity to blow away the VM and redeploy.
To deploy a SWE-Lite into Azure, please follow our good friend Luca Vitali’s step by step guide.
You can also watch a quick deployment demo below
Ribbon SWe Lite Application Configuration Fundamentals
If you are not familiar with how a Ribbon SWe-Lite functions, the admin user interface can feel a little overwhelming at first. But once you understand the building blocks, the UI is very easy and intuitive.
If you have got this far in your deployment, the chances are you know something about SIP and how SBCs work. If not, then you may find configuring and more importantly troubleshooting quite difficult.
SIP hasn’t changed much since it was created and learning the fundamentals of how it works is going to set you up well. For a fee of about £300 you can take an online course with an industry recognised SIP certification exam (SSCA) at The SIP School (https://www.thesipschool.com/courses/view). I have taken this course and exam myself and it is well worth the £300 just for the course material only.
More specifically for Ribbon SWe-Lite how it works guide, I find this better described as a video than pages of text and screenshots.
I am going to take you back 7 years now, when Ribbon was once called Sonus. Aside from the colour & name change, the UI and logic hasn’t changed visually that much.
Here is a video Iain Smith made walking you through the fundamentals of how the Sonus 1000 (Ribbon 1000 and SWe-Lite) works
Configuring Ribbon SWe-Lite for Microsoft Teams
Before jumping into the configuration for Enghouse CCE, first connect your SBC to Teams using Direct Routing.
You can follow Ribbon’s guide here: https://support.sonus.net/display/UXDOC90/Connect+SBC+SWe+Lite+to+Microsoft+Teams+Direct+Routing+Deployed+in+Azure
Be sure to check out the best practices and troubleshooting guide for more in depth knowledge https://support.sonus.net/display/UXDOC90/Best+Practice+-+Troubleshoot+Issues+with+Microsoft+Teams+Direct+Routing
For more information about Ribbon and Microsoft Teams this webinar is a good starter for 10
Configuring the Ribbon SWe-Lite for Enghouse CCE
This section assumes that you have made successful connections to Teams and your ITSP provider on the SBC.
CCE CP Signalling and Media Information
The Enghouse CCE CP server, by default listens on port 5060 UDP for signalling. The SBC should send SIP OPTIONS to the server and the CP server shall respond 200 OK to those. The CP server itself does not send SIP OPTIONS to the SBC by design.
The media codec used is G.711a or G.711u. Both are offered by standard in SDP. You can configure the SBC to only offer a or u based on the region you are deploying. By default, G.711a is used.
Media ports for the CP server will generally be within the range of 49152 – 49652 UDP. You should check with Enghouse engineer on the range required for your deployment.
CCE TC Signalling and Media Information
The Enghouse CCE TC server, requires two signalling ports. 5060 TCP and 5060 UDP. Only 5060 TCP should be enabled for SIP OPTIONS monitoring from the SBC. UDP should be unmonitored as the TC server will not respond to those on that protocol.
The media codec used is G.711a or G.711u. Both are offered by standard in SDP. You can configure the SBC to only offer a or u based on the region you are deploying. By default, G.711a is used.
Media ports for the TC server will generally be within the range of 49152 – 49652 UDP. You should check with Enghouse engineer on the range required for your deployment.
Failover Codes
If you are deploying failover then you will need to create a Cause Code Reroute Table to support that. In addition to the ones supplied by Enghouse, I recommend the following
- 3: No Route to Destination
- 18: No User Responding
- 34: No Circuit Available
- 38: Network Out of Order
- 41: Temporary Failure
- 79: Service or Option Not Implemented
- 102: Recovery timer on expiry
SIP Profiles
I always recommend that in any configuration you should create separate profiles and tables for each server group you are going to connect. Even if the settings are the same!
IMPORTANT TIP: The problem with using a single profile configuration e.g. SIP profile, Media, TLS, SDES etc. is that it does not give you the flexibility to tailor it for a particular server. You may run into issues after subsequent updates that you need to tweak a setting for one server, and find you break several others in the process. ALWAYS create separate ones! You’ll thank me for it.
Create separate SIP profiles for the Enghouse CCE CP and TC server. The settings in these profiles can remain as the default.
Media Profiles
Enghouse CCE applications do not use encrypted media by default. If you have requested encryption, you will also need to create an SDES profile. Create 2 Media profiles, one for the CP and the other for the TC server. Each one containing the required codec based on your region.
TIP: You may want to disable comfort noise because this can introduce unwanted interference when callers are in the IVR system. You should do this on the ITSP media profile as well.
SIP Server Tables
SIP server tables are the destination servers calls will be routed to. Add a SIP server table for the CP server and the TC server.
Remember, for the TC server, you need to add both TCP and UDP server destinations. Only TCP should be enabled for SIP OPTIONS monitoring.
Transformation Tables
Transformation tables are used to match incoming requests to a specified route within the call routing table attached to the receiving signalling group.
To support CCE call flows you are going to need at least the following tables
| Name | Description |
| From ITSP > CCE CP | Match incoming called numbers from the ITSP that should be routed to the CCE CP IVR system |
| From CCE CP > CCE TC | Match the agent routing number prefix used by the CP server to create the conference on the TC server and to dial the agent’s DDI |
| From CCE TC > Teams | Match the agent number (and other Teams agent outbound destinations) that should be routed to Teams |
| From CCE TC > CCE CP | Match the called number for the requeue numbers |
| From CCE TC > ITSP | Match called numbers that are not Teams or Contact Center routing numbers (agent outbound calls) |
| From Teams > CCE CP | Match the called number for the requeue numbers |
From ITSP > CCE CP
This will contain the called numbers that should be routed to the Enghouse CCE CP server. If this SBC is only used to CCE, then (.*) all can be used. The CCE CP server operates in E.164 format, so depending how your ITSP delivers you the called number, you might have to convert it to E.164.
From CCE CP > CCE TC
This will contain the agent routing number prefix and the agent’s DDI. You need to pass this called number to the TC server as the CP server sends it. The routing prefix is unique to each CCE CP application pair. So if you have more than one, you need additional routing prefixes.
This example shows the calling number that can be accepted is 71*+441234567890
From TC > Teams
The Teams connector server will need to dial out to Teams using at least 2 rules.
The first is the agent prefix / number which will be sent as prefix+agent number e.g. 71*+441234567890. To get to Teams, the SBC will need to strip the prefix, sending only the E164 formatted agent DDI to Teams.
The second will be if any customers of the contact center reside internally on Teams, then you need to be able to route internal ranges back to Teams as if they were external calls.
In the below example, 404 redirect is used to determine a PSTN outbound customer, so all calls are routed first to Teams.
From CCE TC > ITSP
The Enghouse TC server will also need to dial outbound to the PSTN, so a transformation rule is needed to match external calls. The TC server will send the number in E164 format.
In this example, the agent prefix is also added in the event that the Teams DR trunk is down, the agent can still be called via the PSTN (assuming their Teams DDI terminates on a different service to the ITSP connected to this SBC e.g. Calling Plans or other DR solution).
From Teams > CCE CP
This is needed for the agent requeue numbers. When an agent requeues a caller they transfer them back to the CP server using these special numbers. You will need to ensure that you have configured outbound routing on Teams to support these using DR voice policies and routes.
In this example, the CP server expects requeue numbers between 62000 and 62099
From CCE TC > CCE CP
The Enghouse TC server will also need to dial outbound back to the CP server on the same requeue numbers. In the below example it supports the range 62000 – 62499 because these SBCs have been deployed with failover capability. Be careful though, from the TC server the numbers are sent without the + and the CP server expects E164
From Failed SBC > CCE CP
This is needed if you are deploying failover where a call is received by another SBC, but that cannot route the call to its local CP server because the CP server is down. Instead that SBC can reroute the call to this SBC and it can then route to this local CP server.
As a typical rule, the first leg of the call is always received by the CP server. So, this rule should be a catch all transformation
From Failed SBC > CCE TC
This table is used when the CP server in another region is online, but the TC server is not. Therefore, the SBC can reroute calls from that region’s CP server to the local TC server in this SBC location. To do this, you define the agent prefix routing numbers for the other regions.
Failures outside CCE
What about failover from the PSTN trunk? – Generally, if the ITSP SIP trunk is offline in one region, the ITSP in most cases cannot re-terminate numbers in another region. Instead, you would have to place a carrier emergency call forward to CCE numbers in your other region.
What about failover from Teams Trunk? – Teams DR is very resilient and is built with a level of redundancy. If the fault is Teams side, then this will affect everyone in the world (where all 3 regional egresses are simultaneously down). If it is just one regional hub, then Teams will automatically failover itself. Therefore, you don’t need to failover Teams side calls between your own SBCs.
However, if the fault is the SBCs egress, then you may consider rerouting that to other SBCs in the same region first and then inter-region. You’d probably want to do this where your deployment is on-prem. When deployed in Azure, this is not necessary.
Conversely, outbound from Teams to the SBC can be controlled within Teams DR configuration with failover routing and load balancing.
Call Routing Tables
Call Routing tables is where all the magic happens. You will need to create a routing table for each receiving group. At a minimum, the following:
| Name | Description |
| From ITSP | Where should calls received from the PSTN be routed to? |
| From CCE CP | Where calls received from the CP server should be routed to? |
| From CCE TC | Where calls received from the TC server should be routed to? |
| From Teams | Where calls received from the Teams should be routed to? |
| From Failed SBC* | Where calls received from another SBC should be routed to? |
*optional if configuring failover.
Failover Routing Explained
Ribbon SBCs have a routing table per signalling group. This makes it really easy to configure logical routing decisions and rules. Each rule has a priority in the routing table.
If there are more than one routing rule that match a routing condition, then the rule that has the highest priority is chosen first (Priority: 1 being highest). This means that by combining the priority and the cause code reroute table created previously, you can control how calls get routed.
From ITSP
In this routing table you want to match the transformation table From ITSP > CCE CP to the signalling group of the CCE CP server.
If you are deploying failover, add the additional routes as seen above making sure that the priority is set accordingly.
Note: if the priority is set to the same value, then a random route is selected which may not be optimised.
Set the cause code reroutes value to the table created to initiate failover.
From CCE CP
This table controls what types of calls can get routed from the Enghouse CP server to the TC server. This will be the From CCE CP > CCE TC transformation table created previously.
Again, configure failover routing if required.
From CCE TC
The TC server will need to route out three destinations, the CP servers, Teams and the PSTN. Failover routing if configured, will need to be enabled for the CP route only. This is so the requeue numbers can be processed by a CP server from another region.
In addition, the table will also need a route to Teams and the PSTN using the appropriate transformation tables created.
From Teams
This table is used to route calls from Teams including non-contact center calls (if multi-use SBC). Again, if failover deployed, failover reroutes will need to be configured for the requeue numbers.
It is important in any table to make sure your most explicit routes are defined higher in the routing table as it gets processed top to bottom.
From Failed SBC
This table defines where to route calls received from another SBC due to a reroute. Due to the way this is configured, this is quite easy. The rule is if the called number contains any agent prefix, route to the TC server. If not, route it to the Enghouse CP server.
You do not configure failover routing on this table because you would end up in an infinite loop. If the local TC or CP server is down, the SBC will return a fail code to the sending SBC and that SBC would try another region itself.
Signalling Groups
Signalling Groups control the send and receive endpoints. A call is received by a signalling group which then processes its call routing table and when a route found sends the call to the servers listed in the destination signalling group’s SIP server table.
You will need a signalling group for each peer.
In terms of specific SG settings for the CP or TC server, there aren’t any beyond the normal changes you would make e.g. number of channels, SIP & media profile to use and the federated endpoints for each group.
This concludes the walkthrough explanation of how to configure a Ribbon Swe-lite for Enghouse CCE application. I hope you found it informative.
