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.
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.
Kamailio Dispatcher Module
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.
- AP — Active Probing — Destination is responding to option pings & looks to be up.
- IP — Inactive Probing — Destination is not responding to pings and might be unreachable. This could also mean the destination isn’t liking what you’re sending it and therefore is not responding. In many cases this is due to the improper configuration of TLS on your server.
- DX — Destination is disabled (administratively down)
- AX — Coming up, but has not yet satisfied the minimums to be considered up (ds_inactive_threshold)
- TX — Looks like or is, down. Has stopped responding to pings but has not yet satisfied downstate failed ping count (ds_probing_threshold)
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).
