Lifestyle, Main Menu - Mobile App, microsoft teams, News, privacy, Snapsonic, WebRTC

Microsoft Teams Phone System, Direct Routing, and SBCs, a journey. (pt.4/4)

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.

Setting your outbound routes

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…

Inbound routes

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).

Be sure to Run PS as Administrator

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 “” -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 or give us a call 1.877.897.1952

Main Menu - Mobile App, microsoft teams, privacy, Snapsonic

Microsoft Teams Phone System, Direct Routing, and SBCs, a journey. (pt.3)

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 “*” 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. 




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 or give us a call at 1.877.897.1952 (also textable).

WebRTC Ships in MacOS and iOS 11


Looks like VP8 is not there after all, bummer. More political jostling afoot, which sucks for the development community.

This is a big deal, to have Apple / Safari onboard is really the final major obstacle in the adoption of this awesome standard.

More info (thanks Marc Abrams !!)…
Based on the beta for macOS High Sierra – that was made available yesterday……­
– Test samples: (It passed most of the tests)
– Video codec support is VP8 and H.264 (I have not seen a test that shows H.265 or HEVC but I know it’s there)
– Audio codec support is Opus, ISAC16, G.722 and PCMU
– Basic datachannel support is there but none of the tests seem to work


AWESOME!!! This took a bit longer that many of us were expecting, but hey better late than never!

Screen Shot 2017-06-06 at 4.45.16 PM

PulverHWC – How We Communicate

Next week I will be joining friends old and new at PulverHWC to rediscover – How We Communicate.

Here is an email from Jeff Pulver inviting all of you to join us in Los Gatos for what is sure to be a landmark occasion.

Hope to see you there!


The Keys to the Communications Universe

Next week I return to doing the one thing that I love best – bringing together brilliant, interesting people.

Leaders, visionaries, dreamers and market makers from the worldwide communications industry have accepted my invitation to take part in the Pulver HWC Summit, May 18 – 19 at Testarossa Winery in Los Gatos, CA. I am grateful for both the people who are speaking and the tech legends who have signed up to join us for an intimate conversation. I believe understanding the message behind “How We Communicate” (“HWC”) is the next great area of growth in the communications space. Trillions of dollars of opportunity will be created and there are relationships to be forged, deals to be made, and knowledge to be shared.

There are a limited number of tickets still for sale. To join the conversation and to register, please click here. I would appreciate it if you could share this email with your friends and family involved in the communications industry.

Thank you!

Warm hugs, Jeff

Do you really want a dual MTI video codec for WebRTC?

H.264 AVC for WebRTC VP8 - Webm

Update: There is now some healthy conversation in the IETF WG around what “compliant” and “compatible” actually mean. More on this as it unfolds.

We are now in the final throes of a consensus call in the IETF around which video codec should be made mandatory for those building WebRTC apps, services et al, who wish to be considered “WebRTC Compliant”. The codec contenders are VP8 and H.264, in many forms and combinations.

This latest consensus call is for both codecs to be mandated for all WebRTC endpoints, or “dual MTI codec”. I am sure I will catch hell from someone on language but that is the essence of it. As one might expect, there are some that are in favor and some that are against a dual MTI video codec. Those in favor seem motivated to accept this based on the promise of interoperability that might follow and other reasons. As one might expect, we are all quite eager to put this debate to bed so we could get on with other work.

This is not a decision that should be made lightly. Let’s consider the implications. Imposing a dual MTI suggests that every developer that wishes to produce a WebRTC compliant app must implement both codecs.

Coming from a co-founder of an RTC toolkit vendor I can tell you that this does not sit very well with me, nor others in the WebRTC WG. One glance at the thread comments should provide some insight.

I find it difficult to agree to mandate a dual MTI codec knowing that there are a great many developers who will not want or will be in a position to implement both codecs. Yes, many WebRTC SDK vendors will support both. Even if both codecs and their transports are provided as part or could be easily added to the application at compile time it doesn’t mean that every developer will want to implement or ship both codecs.

Bottom line is, according this consensus, if developers do not implement/ship both codecs they are not considered WebRTC compliant. To me, this seems like a rather unreasonable expectation. Developers should be able to choose which codec they ship, and not be forced to do 2x the work to become compliant.

I would love to hear from other developers on this. Do you plan on implementing both VP8 and H.264 in your apps?

1 2 3 10 11
Privacy Settings
We use cookies to enhance your experience while using our website. If you are using our Services via a browser you can restrict, block or remove cookies through your web browser settings. We also use content and scripts from third parties that may use tracking technologies. You can selectively provide your consent below to allow such third party embeds. For complete information about the cookies we use, data we collect and how we process them, please check our Privacy Policy
Consent to display content from Youtube
Consent to display content from Vimeo
Google Maps
Consent to display content from Google
Consent to display content from Spotify
Sound Cloud
Consent to display content from Sound