In the last post, we talked about Microsoft’s Business Voice offer and why it’s not always a practical solution. Today we get a bit more in-depth on the Direct Routing components and what’s required for external Teams telephony and the associated SBCs.
Direct Routing and Session Border Controllers
Direct Routing is Microsoft’s way of saying, external SIP connectivity. It allows admins of Teams to create interconnectivity with the outside VoIP and PSTN world without using Microsoft’s calling plans. From the Microsoft website…
Direct Routing lets you connect a supported Session Border Controller (SBC) to Microsoft Phone System to enable voice calling features. You can view information about SBCs and online voice routes; add, edit, or delete an SBC; add, edit, and specify priority of online voice routes; and manage online PSTN usage records.
So, here we know that in order for us to connect our own VOIP phone system, I needed an SBC in the middle. Here’s a quick reminder of what an SBC does in a VoIP network…
SBCs, or Session Border Controllers, are network elements that help protect VoIP networks from malicious attacks. They also serve as a point of NAT traversal and media transcoding, to aid in the connection of VoIP endpoints.
Well, it’s not the end of the world. My favorite CPaaS has plenty of SBCs in-network so that shouldn’t be an issue. Not so fast. This particular SBC needs to be set up with some specific configuration including TLS + SIP Options, specific Contact Headers & audio codecs, and few more fiddly bits. Time to dust off my SIP tools and get started. Let’s start by seeing what happens when we try and point Direct Routing to my CPaaS SBCs…
Nope, no go. Now what’s this about the domain not being setup? O365 admin says my DNS configuration is fine, so what gives?
After spending some time with Microsoft Support, the fellow I was speaking to said he copied my setup and his config wasn’t working until he enabled Exchange and Outlook MX records in his DNS. Hmm, that didn’t sound right. I didn’t want to point all my MX records to Outlook for this test, I only want Voice and Teams chat to work. Then I noticed there is a “Skype For Business / Voice” only option when verifying your domain.
I added the DNS records and it gave me the all green as you can see above, but it still wasn’t allowing me to add the SBC.
Tech Tip: I had to actually assign a user to that domain before it would recognize that domain as being active. After doing that I was able to add my SBC domain.
Down the SBC rabbit hole
The SBC in my chosen CPaaS was not directing calls to the proper Microsoft SIP signaling servers, looks like I will definitely need an SBC in between my CPaaS and Microsoft’s SIP servers.
I had no choice, if I was going to get this working I would have to use one of the certified Teams SBCs, or build my own. The certified SBCs were relatively expensive and required licensing based on per channel usage or per minute metering if you used one of their cloud images eg. Azure, Amazon. That would not fly for my friend’s business, he is very cost-conscious, not unlike most business owners.
Down the rabbit hole we go, I bit the bullet and began building up a server. The first objective was getting outbound calls to the PSTN/outside world from Teams users. From past experience, it’s always easier to start with outbound calling first, when you get that working move on to inbound. The reason being is that NAT firewalls and SIP don’t mix well, especially if they are blocking certain traffic. Sending traffic out of a NAT was always easier than getting past the firewall inbound.
I set to work on building my SBC also known as a B2BUA (Back to back user Agent). This is not brain surgery but it does take some VoIP network know-how and a good understanding of Linux.
My first stop was Kamailio.org. A great open-source SIP server project that is used in countless commercial deployments. I found some recent articles on their mail-list talking about how to setup up Kamailio with Teams, which was a great start. Before we can proceed we must address the elephant in the room, TLS.
More on that in the next “Microsoft Teams Phone System, Direct Routing, and SBCs, a journey. (pt.3)”, to be published next week!
I hope you found this article interesting.
If you have any questions or comments or want your own SBC for Direct Routing, get in touch via firstname.lastname@example.org or give us a call 1.877.897.1952