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
Getting the hang of Microsoft Teams can be a bit different from other collaborative applications. With that in mind, we have kicked off a new series of short tutorial videos called “Get to know Microsoft Teams”.
These short videos have been designed to provide new Microsoft Teams users with answers to some of the more popular questions we get from our customers.
In this episode we cover Guest Messaging, and more specifically how to create Guests in your Team so that you can send/receive messages with external Teams users and see their presence status.
If you found this video helpful, please share and let us know by leaving a comment.
In the last post we did some preliminary investigation on Direct Routing and what part the SBC plays in Direct Routing. Today we will take a deeper dive into TLS and SIP Options.
In order for this connection to work, Microsoft expects TLS+SIP Options to signal their servers that your SBC is alive and vice-versa. For the purposes of this demonstration you can think of TLS as SSL for VoIP. I would need to install certificates per domain that were going to be signaling to Microsoft and then I would need to leverage the dispatcher module in Kamailio to send the SIP Options to the Microsoft SIP servers.
Installing TLS correctly would take some forethought. Working through the Microsoft multi-tenant scenario, was a bit of a beast. In order to serve multiple tenants (thinking ahead a bit here) with the same domain and certs we would need a wildcard certificate. The problem is, double wildcard certificates are not supported, for various security reasons. So, we would have to set up a workflow that used a “*.sbcgroup.mydomain.com” type of structure. We are going to use let’s encrypt certs for the test, just to see if this works. Initially I just created a cert for a single domain. Once that was up, I would return to the multi-tenant requirements. For now, running a single customer on one Digital Ocean droplet was not a huge concern, we can optimize as a next phase.
Tech Tip: Adding a certificate to a debian linux VM is widely documented, that said, using let’s encrypt’s certbot module makes it dead easy.
Once I had the machine up and resolving on a secure socket, we needed to ensure that the dispatcher in Kamailio was sending out the SIP Options. First we need to ensure the dispatcher module was loaded add then add entries to the dispatcher list. Nick has a great article on getting started with Kamailio dispatcher, so check that out if you want to learn more about it.
Once we had our Microsoft SIP Server records in Dispatcher, we could reload Kamailio and see what’s what!
sbc:~# kamcmd dispatcher.list | egrep “URI|FLAGS” allows us to see state Flags which means our system is Actively Probing and our config is correct.
URI: sip:sip3.pstnhub.microsoft.com:5061;transport=tls
FLAGS: AP
URI: sip:sip2.pstnhub.microsoft.com:5061;transport=tls
FLAGS: AP
URI: sip:sip.pstnhub.microsoft.com:5061;transport=tls
FLAGS: AP
If you are seeing IP or another FLAG, your configuration is likely incorrect. See below for the flag states.
Now let’s take a look at the SBC in our Teams configuration…
Hey that looks positive! Much better than the inactive state that is was in before. It would be nice if Microsoft were to rate these as a percentage of usage versus efficiency.
Next week in our final post in this series, “Microsoft Teams Phone System, Direct Routing, and SBCs, a journey (pt.4)” – we will try some outbound calls and set up our systems for inbound calls.
We hope you found this article interesting, please leave a comment or text the number below and tell us what you think!
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 at 1.877.897.1952 (also textable).
Product leadership and strategic consulting services.
© 2023 Plenty Of Hats Inc. All rights reserved.
Recent Comments