If you’ve never heard of Twilio before, you’d be surprised to learn that they are the largest backend for services around automated calling services, text messaging (and verification), and are pioneering Software Defined Telephony by use of APIs to route and handle texts/calls/faxes. Is your Uber driver calling you now? That’s Twilio… Got a text from Netflix for a password reset? Yup, that’s Twilio… PagerDuty sending you a SMS alert? You guessed it!

There are MANY things you can build with Twilio, but you can also use its simple services to set up PSTN origination/termination with your Skype for Business infrastructure. Why?

• Fast and easy provisioning of trunks and numbers. No contracts, and you pay for what you use. Buy a number and it’s ready to use in less than a minute!
• Crazy scalable. If large companies rely on Twilio for their backend integrations, why wouldn’t you?
• Support for SIPS and SRTP, which means encrypted, secure calls over that internet trunk
• Record calls and pull them from the Twilio portal or over API. Need recording for certain Response Groups? Done.
• Failover mechanisms that can use preference/weight to balance call targets, or set up a script that can at least give callers a notice that your phones are down, or route them somewhere else, automatically
• Use add-ons to do fancy things like transcribe calls with speaker recognition, translate calls then play them using text-to-speech, or even cleanse call recordings of sensitive PCI data. Yes. I know. It’s crazy.
• Entire platform is built on top of AWS and globally scaled, so you know it’s good…

In this post I’ll guide you on setting up a trunk over the internet between a SfB infrastructure and Twilio’s Elastic SIP Trunking service, and you can start using it as a failover, aggregate, or maybe a conferencing bridge number so you’re not limited by your PRIs.

First, Sign up for Twilio

Obvious step here, you have to go here and sign up for an account.

Load it with some of your cash, which you can source from a Credit Card or over PayPal. You could use Twilio’s free test features, but if you want to call real numbers you need to have some money loaded there.

Create and configure a Twilio Elastic SIP Trunk

Now that you have an account with some moolah, it’s time to make that SIP trunk. Go on Elastic SIP Trunking (if you don’t see it, hit the “…” button) then Create new SIP Trunk

Give it a friendly name.

Then go on Termination and enter a Termination SIP URI. You’ll use this when creating the PSTN Gateway in Skype or Lync (or your favorite SBC). Don’t worry about call recording or encryption yet, you can play with that stuff later.

Then under Authentication, create an ACL and add the IP addresses of your mediation boxes. If you’re NATted outbound then use that, but in order to receive calls you’ll need to have inbound NAT or a public IP assigned.

Now save your Trunk by hitting Save at the bottom.

Next we will configure origination, so we can receive PSTN calls over the SIP trunk.

Configure an Origination URI, and set it in the format shown. ;transport=tcp will force Twilio’s edge to use TCP instead of the default UDP transport, still over 5060. If you want a different port, just use sip:IPADDR:PORT;transport=tcp. This is very similar if not exactly to how Flowroute’s inbound routes work. If you’ve got multiple servers, you can play with priorities and weights… but that’s out-of-scope for now.

Next, you can assign numbers for your DID’s.  If you don’t, you can still make outbound calls and mask caller ID as anything you want, but for receiving calls you need a PSTN number…

You can probably figure out the rest, but the basics are done. Let’s move to SfB now.

Configure Lync / Skype for Business Trunk

Remember that Termination SIP URI? We need it now. So we start by creating a new PSTN Gateway in the topology and using it as the FQDN.

Then we use 5060 as ports and TCP as the protocol. If we were using TLS, we can change that to 5061.

Publish the topology and then start using your new root trunk in your voice routes for outbound calls. That’s pretty much it! (assuming you’ve got the networking done right, either NAT or Public with dual-home).

To secure your edge you can use Twilio’s public IP list to make sure you’re not getting unauthorized SIP requests. You can get that here: https://www.twilio.com/console/sip-trunking/your-network

Test and smile

Since we’re not encrypting SIP traffic, and it’s flowing over 5060, we can fire up Wireshark and start looking at dialogs. Even with no calls flowing, we should be seeing OPTIONS requests roughly every 60 seconds sourcing from the Skype servers that have the trunk attached.

Making an inbound call we see the INVITE sourcing from Twilio.

And making an outbound call we see the call outgoing:

Also, Twilio has built-in pcaps that you can use to troubleshoot the remote-end of the trunk. Think of this as having Wireshark running on Twilio’s edge. VERY COOL!

Important note for NAT and non-SIP-aware edge

If you’re using a Mediation server, either dedicated or collocated, and use RFC1918 private IPs on your inside network, you have to do NAT to translate a public address to the inside IP and get calls flowing.

The issue this introduces is it’s not a supported configuration with Skype because the Contact header (and many others) will have the server’s internal IP, when it really should have the external, public IP. That’s why when doing Direct SIP with certified providers, you need to use the Edge server with a Public IP.

Some providers like IntelePeer will happily mangle SIP headers to make sure they have your external IP in there, and everything is well. In my case, using a NAT address kills some functionality, specifically:

• Some calls tend to hang up after 30 seconds
• Calls can’t be put on hold for longer than 30 seconds
• When hanging up the call on the far end, the out-of-dialog BYE message coming from Twilio goes to the contact IP, so you never get it… and the call hangs up after 30 seconds anyway

Using a Session Border Controller to trunk to Twilio is one answer. Using a SIP-aware firewall or edge device is another, but most can’t do SIP over TCP, and definitely not SIP over TLS… so what then?

There’s a bit of a hack, and it involves setting the EnableSessionTimer to $True, RTCPActiveCalls to $False and RTCPCallsOnHold to $False, like so:

Not ideal, but gets the job done. The SessionTimer will check every 30 seconds for an active RTP session, regardless of whether RTCP “control” packets were received or not. This is why calls hang up after 30 seconds, because of no RTCP from Twilio since it goes to the Contact IP.

This hack is probably best if done as a MUST, and no other solutions are viable. My recommendation would be to use use Public IP with proper edge security (limiting to Twilio’s service addresses) or using an SBC or B2BUA.

Hope you enjoyed this post!!! Please leave a comment!!!