27 Mar Installing Ribbon (Sonus) SBC in Azure
Ribbon alongside Audiocodes and Anynode are all vendors certified for direct routing who have appliances in the Azure marketplace that can be utilised for providing PSTN/telephony connectivity via your chosen Internet Telephony Service Provider. Deploying virtual SBC’s into a Public Cloud allows for a significant amount of flexibility and provides many advantages for customers pursuing a “Cloud first” deployment model. Ribbon announced at Enterprise Connect 2019 that their SWe Lite model which is based on the Sonus 1000 (1K) will be generally available in Azure and AWS.
This post will cover the configuration steps for installing a working Ribbon virtual SBC in Azure with Teams PSTN connectivity. This post assumes you have the following already:-
- An account with Sipgate. Sipgate are an ITSP who provide ‘free’ UK DIDs for inbound PSTN calling. Your account needs to be in credit to place outbound calls to the PSTN. https://www.sipgatebasic.co.uk/
- An Azure tenant. You can sign up for a trial here https://azure.microsoft.com/en-gb/free/
- A Microsoft 365 tenant with a Microsoft Teams user that’s licensed for Phone System. You can sign up for a trial here.
Note:- The Ribbon SBC is limited to a 30 day trial.
Part I – Installation
From the Azure marketplace type Ribbon and press enter.
On the next screen click “Create”.
Select your subscription. Create a new Resource Group or use an existing RG. I created a new RG called “Ribbon”. Give the new Virtual Machine a unique name. Ensure you select the region that’s closest to your M365 tenant. My M365 tenant is in Western Europe so i selected the Azure Western Europe region. This allows for the Teams service to be as close as possible geographically to my SBC.
As the SBC is only being used for lab purposes i choose “Standard SDD” for the hard disk.
Either create a new Virtual Network and Subnet or use an existing one. Note the Virtual Machine is automatically configured with its own Network Security Group. This NSG will need some additional rules added at a later stage.
Unless required turn off “Boot diagnostics”. Then select “Review + Create”.
Note:- Turning on Boot Diagnostics can be useful if you need to login via the CLI/Serial Console of the Virtual Machine.
Browse to the newly created Vnet.
Ribbon expects the management and voice interfaces to be on seperate networks. Add a new address space in the CIDR notation format per the screenshot below.
Under subnet add the new subnet.
Browse to Network Interfaces
Give the new interface a name and select the correct Vnet aling with the new subnet just created. The private IP can be left as Dynamic. Select the NSG created during the initial setup of the Virtual Machine, then select the correct Resource Group.
Browse to Public IP Address.
Add a new Public IP address
Select the newly created Public IP address and associate it with the previously created network interface.
Browse to virtual machines and select the SBC.
Stop the VM and then attach the newly created network interface.
Browse to networking and create two new rules to allow ports 5061 for signalling/call control and media 16384-19384 inbound to the SBC.
Now enter the Public IP address of the SBC into your web browser. You’ll then be taken through the “Initial Ribbon SBC SWe Lite Setup”. Fill out the details below and select “ok”.
Note:- Configuring the Syslog is optional but its useful to configure for troubleshooting.
Part II – SBC Configuration
Browse to the Public IP address of the SBC or the FQDN/DNS name if you’ve configured one and login with the username and password created earlier.
The voice interface created earlier will be used for signalling and media traffic. This needs to be configured before we can run the “Easy Config Wizard”. The interface can be left on DHCP as the IP address is assigned by Azure, but the “Media Next Hop IP” needs to be added. This is the default gateway for the network subnet. In this case 10.0.1.1. Under “Settings” browse to the container below.
Next we need to add two static routes so the voice interface knows where to route network traffic destined for Teams or Sipgate. Change the gateway to the correct IP address. The first network is the Azure subnet and the second is Sipgate.
The “Easy Config Wizard” can be used to do the bulk of the neccesary configuration. Browse to Tasks > SBC Easy Setup > Easy Config Wizard and enter the following in the parameters per the screen shots below.
Click finish and then ok on the next screen to acknowledge the information prompt.
As the SBC sits behind a NAT firewall the NAT Public IP for the Voice Interface (Ethernet 1) must be added under the Static NAT – Outbound configuration below. Ensure this is done on both trunks.
Media Bypass is not supported by Ribbon at this time of writing, but it will be supported in a later release. So to prevent any media establishment issues “ICE lite” support needs to be turned off on the Microsoft Teams SIP trunk.
Teams requires a certificate as it utilizes SIP/TLS for connectivity to the Microsoft Teams Phone System SIP Proxy. You will need to upload your certificate chain including the root and all intermediates. In addition the Root CA used by Microsoft Teams must also be uploaded. This can be found here https://cacert.omniroot.com/bc2025.pem. Ensure you use a supported Certificate Authority otherwise Teams SIP trunk connectivity will fail. Supported CA’s for Teams can be found here.
A new CSR for the SBC must be generated. This certificate will need to contain the FQDN of the SBC. The FQDN must be an existing domain that’s already registered in Microsoft 365. The default domain onmicrosoft.com is not supported. In addtion a DNS A record for this FQDN must be resolvable from the internet. This A record will point to the public IP address of the Voice Interface.
Assign the certificate to the SBC by importing it under the “SBC Edge certificate” container.
In order to register the Sipgate trunks your Sipgate user credentials are required. These must be entered into the “Remote Authorization Table” and the “Contact Registrant Table”. Browse to SIP > Remote Authorization Table click the + radio button and enter a new Remote Authorisation Table.
Enter your Sipgate user name as the “Authentication ID”.
Browse to SIP > Contact Registrant Table and create a table. In the new table add an entry for your Sipgate user account using the settings in the screen shot below. The “Address of Record URI” field should begin with “sip:” followed by your user account. The contact username also needs to be this same username but without the “sip:” prefix.
Click on “Registration Status” and you should see the Sipgate trunk registered sucessfully.
To confirm the trunks registration in Sipgate login to https://www.sipgatebasic.co.uk/ and you should see the SBC User Agent under “Registered Devices”.
With both trunks configured and working under the “Signalling Group” container you should see the “Service Status” for both trunks as up.
You should see incoming/outgoing SIP options pings on the Microsoft Teams trunk. Likewise you should also see incoming/outgoing 200OK responses.
In order to make a call from Microsoft Teams via the Sipgate trunk Sipgate expects the sipgate user account ID to be in the from field of the SIP header so Sipgate can verify which account the call is coming from. If the user account ID is not present in the from field it will reject the call. Therefore the Teams extension or DID assigned to the user must be replaced with the Sipgate user account which can be accomplished using a transformation rule. The “Calling Address/Number” in the “Output field needs to contain your Sipgate user account ID – normally in a 7 digit format.
Create two new transformation tables one from Sipgate to Teams and Teams to Sipgate.
Likewise in order for your Sipgate DID to route to your Teams extension a transformation rule must be created to forward inbound PSTN calls to your Teams users extension or DID.
You should now be able to make a succesful call from the Microsoft Teams client and see the call under the Real Time Monitor.
If you click on the channel with the active call (In this case channel 10) you’ll see addtional details about the call.
Part III – Troubleshooting
Ribbon provide the LX Syslogger for troubleshooting. This is a very useful tool for understanding what’s happening on the ‘wire’ when troubleshooting SIP connectivity issues. LX requires a valid login in order to download the tool which can be downloaded from here.
Create a new “Remote Log” and point this at the IP address of the PC that the LX is installed on. In my case i pointed the LX at the Public IP address of my Windows 10 Laptop and then opened 514 inbound on my home firewall to my private IP address.
Add the following “Log Profiles” ensuring they point to the newly created “Remote Log Server”.
From the LX ensure the “Listening IP” address, “Transport” protocol and “Port” are all correct. The SBC will then write to the syslog.