Your organization is using Microsoft 365 for office productivity and Microsoft Teams for your video collaboration. Your phone system/PBX is hosted outside of Teams by a third party. In an effort to reduce the number of vendors and the cost in your network you have been charged with moving your phone system to Teams.
Note: We won’t be covering the Microsoft Calling Plans in this post as there is plenty of information out there on that offering.
We recently wrote a series on building a Microsoft Teams Direct Routing SBC from open source, so we won’t go into too much more detail on that here. Suffice it to say, you need to know your way around Linux and be comfortable with advanced Kamailio configuration in order for this to be a viable option.
This is by far the most popular option chosen by IT administrators when building out Direct Routing for Microsoft Teams. Most administrators are fine configuring + administrating their own SBC. There are several options to choose from:
The full list is here.
Of all the options listed here, this is the most recent entrant for Direct Routing configuration. Very few SIP trunk providers provide or have enabled compatibility with Microsoft Teams, but that will surely change. Today there are a few Microsoft Teams SIP Providers that allow you to buy numbers from their carrier pool and associated those numbers with your 365 tenant users and use all the Phone Systems features available in Microsoft Teams.
For options DIY and Certified SBC, you will also need to find your own SIP Trunk supplier. A SIP Trunk, if you are not familiar, is just another way of saying, VoIP phone service for your phone system. It’s not difficult to find a supplier, in fact it can be a bit overwhelming as there are so many suppliers out there. A simple google search will yield an alarming number of choices. That said, not all SIP Trunk providers are built the same, some are better than others. Many have a free-trial so you can get a feel for the quality and capabilities before going whole hog. It may also be a good idea to join a few of the online forums and ask questions to a larger audience, the Microsoft Teams reddit community is also a good place to start.
Do you have questions? We are usually lurking in chat, found below, feel free to ask any questions you might have!
Last week we spent some time reviewing the TLS and SIP Options requirements for Microsoft Direct Routing, this week it’s payday! Time to make some final adjustments and place some calls.
For my setup, I wanted to route the outbound calls to my CPaaS, where I could do many other things besides just Origination or Termination. After some experimenting, we had our route configured and we could try some calls.
Calls were now flowing from my Teams client to my SBC and onto my CPaaS / external PSTN phone numbers. Much to my jubilation, the quality was pretty good, check it out for yourself…
Now the harder part, routing calls into Teams. For this part, I had to route to the Microsoft SIP resources + assign external numbers from my CPaaS to the Teams active users. This is where things get “interesting”.
As it turns out, the only way you can assign an external number to a user in Teams (today at least) is to run commands from a Power Shell connected to the Teams instance. Since I am a Mac user, that meant spinning up a VirtualBox, installing Windows on a VM, installing PowerShell and SFB modules. (Microsoft, please tell me there is a C# or Graph API coming for this).
Then we need to run the command to connect to the SFB resources…
It will create some remoting modules…
Once authenticated you will end up back at the prompt, where you can enter the commands to add your phone numbers.
That command looks something like this…
Set-CsUser -Identity “user@domain.name” -OnPremLineURI tel:1234567890 -EnterpriseVoiceEnabled $true -HostedVoiceMail $true
Tech tip: Here is a link to all the Skype module commands.
If it works, it will return you back to the PS prompt. A quick look inside Teams and we will see that the number has been associated with the user as an On-premises number.
Here we see the Teams user with the assigned number inside the Team client interface…
Now, we have to route the inbound number from the CPaaS to the SBC and then onto Teams. In my case, I registered my SBC to a CPaaS SIP endpoint and used that connection to send inbound calls from my number to the SBC endpoint. The SBC then forwards the calls to the Teams SIP servers and decides where to send the media. Even though all my endpoints were in the Vancouver area, the media sometimes connected in East USA, which seems weird, maybe their Western hubs were overloaded, not sure.
Et Voila! Once everything was set up, calls inbound started working. Celebrate your small victories, as my dad always said. Here is a screenshot of me answering a call from an external number to my Teams phone number.
I added a bit of redundancy (few more servers) monitoring + failover logic and rolled it out for my buddy’s business.
He’s elated. Not only is the price right, but he now has a great deal more flexibility in how he uses the systems. He added some SIP desk phones to the mix, which now ring simultaneously when someone calls a Teams number.
I also added some SMS capabilities, TTS (Text To Speech), Call Recording and Call Whisper to his setup.
The next post will be on using external telephony resources with some of the Microsoft Phone System features like; Auto-Attendant, Call Queues, Transfer, etc.
I hope you found this article interesting. We have had good interest in the offering thus far and now are now thinking of building a complete all-in-one solution that would do all of this through an intuitive interface eg. connect external phone systems, carriers/aggregators/cpaas, buy/manage numbers, choose carriers, set up domains, add TLS certs, et al. Let us know if you think that would be something you would be interested in.
If you have any questions or comments or want your own SBC for Direct Routing, get in touch via erik@snapsonic.com or give us a call 1.877.897.1952
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 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.
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 erik@snapsonic.com or give us a call 1.877.897.1952
If you are frustrated by how difficult it is to associate external phone numbers and SIP services (Session Initiation Protocol, the defacto signaling protocol for VoIP) to Teams users, this may be of interest to you. In this article, I will break down my journey from initial research of Microsoft’s inbuilt calling features to the implementation of an external Direct Routing solution using primarily open-source resources. If you are a Microsoft Teams direct routing and SBC (Session Border Controller) aficionado, you might decide to skip this one.
We understand that Microsoft Teams is intrinsically connected to Azure AD (Active Directory) and Microsoft 365, and therefore requires licensing and some training to manage. It can be a complicated beast. That being said, adding phone numbers and calling would seem to be something that Microsoft would have enabled by default? I mean, why would anyone want their customers to jump through hoops to get a phone number for their Teams account? A loaded question to be sure, let’s unpack it.
Recently I have been helping some of my friends, colleagues, and even my son’s teachers get more familiar with Microsoft Teams. I am quite impressed with how far this product has come in recent years. The old Skype For Business app was never my thing, it just felt clunky, but this new Teams app, it’s pretty good!
The one question I am hearing a lot is, “How can I get a phone number from my existing phone system into Teams?”. It’s been a while since I have looked at this but I was hoping Microsoft had a simple way of enabling basic calling from an external SIP source. I then had a flashback going back several years, I remembered that the process for adding SIP trunks to Skype for Business was arcane and wrought with utter frustration. I was hoping that had improved. Spoiler alert: it has improved, but not by a large margin, especially if you are moving from one Microsoft platform (eg. Skye for Business On-line, Or SfB On-premises) to Teams.
After a bit of research, and familiarizing myself with Azure AD, 365, licensing mechanisms (and Power Shell) and Teams, a few things became clear;
1) Managing policies & licensing is done via Azure Active Directory, the 365 admin center, Power Shell, and Teams Admin.
2) Teams user management is done primarily in Teams admin
3) Calling plans in Teams are fine but not what I would describe as competitively priced.
4) Enabling external phone services is not trivial.
To expand on that last point, things get much more complicated when you are migrating from existing Lync, Exchange, or Skype for Business Online or on-premises deployments. Microsoft has plenty of information on the topic on their website, so I won’t get into the nitty-gritty details but suffice it to say, you really need a certified Microsoft shop to help you with this.
To enable calling using Microsoft’s own phone services, we needed the Business Voice License and a Calling Plan license for each user. These are extra costs per subscriber over and above the other 365 fees your organization would need. Then, you can add numbers via the Teams admin console, but ensure you have the correct licensing and policies in 365 admin or you will not see anything. As you can see, there were none available… in the entire United States…
Most shops that are deploying Teams calling have an in-house admin that will know their way around the licensing. For this demo I am using a trial version of Microsoft Office 365 — Enterprise 5/E5, (you can get a trial here) so I can feel the pain from ground zero.
After a bit more digging, I found out I had not attributed the proper license, of course. Once I had the configuration in proper order, I then saw locations and numbers. I added some numbers to the account and then provisioned them to the users. After a few calls, I was satisfied it was working as per expectations. The admin could pick some number, associate them with users and the number would propagate to the end-user.
A friend of mine was keen on using Teams to make calls, as his team was using it daily for internal communications. What he wasn’t keen on was paying roughly $22/user (USD)+ extra monthly 365 licensing costs per user. Which is what spurred on this whole journey. Now that I knew what was possible and what it costed, I shifted gears to research any potential support for SIP trunking in Teams, something Microsoft calls Direct Routing.
More on “Microsoft Teams Phone System, Direct Routing, and SBCs, a journey” in Part 2, to be published next Monday!
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 erik@snapsonic.com or give us a call 1.877.897.1952
Communication software and development services.
© Copyright 2021 Snapsonic. All rights reserved.
Recent Comments