Connecting a Twilio SIP Trunk to vCUBE

Overview

As we transition from a PRI and POTS telephony landscape to a SIP trunk based one, we are inevitably faced with new technology to configure and maintain. Today’s vCUBE (Cisco Unified Border Element) blog may look similar to the one Chad wrote a few years ago. However, this is geared more towards the virtual edition of CUBE. We’re going to be taking a look at how this appliance gets deployed to your Data Center. Make no mistake, this is not a hardware based CUBE replacement. Lots of features found in the hardware based CUBE are unsupported or simply non-existent in the virtual edition. Let’s dive in.

Prerequisites

Just a few items to note here: Cisco delivers vCUBE within the CSR1000v OVA file. In order to enable CUBE features, you must be running IOS XE 3.15S. Check out the download link to the CSR1000v here:

In addition to 3.15S, Cisco notes that as of April 14, 2017, ESXi 5.1 and 5.5 are the only supported hypervisors that will get love from TAC. In addition, Cisco also recommends disabling hyperthreading. See table below:


Features NOT Supported with vCUBE

vCUBE supports most of the features available in CUBE. Any feature that manages the media plane is not expected to work in the Cisco CSR 1000V router. The following features are not supported in vCUBE:

  • All DSP based features
    • Codec Transcoding, Transrating
    • DTMF interworking
    • Call Progress Analysis (CPA)
    • Noise Reduction (NR), Acoustic Shock Protection (ASP), and Audio Gain
  • Limited Voice Class Codec (VCC) support
    • Codec supported on peer leg will be included in offer. Other codecs will be filtered out.
  • IOS Gatekeeper
  • 323 Interworking
  • IOS based Hardware MTP

Now let’s walk through each step of configuration, starting with the VMware side of things:

VMWare Configuration

Deploy the OVF Template:

Configure VM specific settings:

Time to boot up:

After booting the vCUBE, I noticed on my instance that the IP address I configured in the setup process did nothing. The boot process itself was normal and everything else seemed to be configured except the IP address. For that, we get back to our roots and configure a static IP manually.

Okay, we have our vCUBE sized, built, deployed, and reachable across the network. Let’s move on to Twilio:

Twilio Configuration

First and foremost, you will need a Twilio account. If you do not have one, head over here and get signed up. After signing up, you will want to start trying some of the neat features Twilio has to offer. Let’s start with what they call an “Elastic SIP Trunk”.  Webster defines elastic as the the capability of ready change or easy expansion and contraction. Ultimately, Twilio has built a platform that allows for even the most skeptical of people to easily and quickly deploy redundant SIP trunks on a cost effective scale. SIP trunks can be easily moved around at a moments notice. From automatic failover to secure trunking via TLS, Twilio’s Elastic SIP trunk is by far the industry leader in both user serviceability as well as scalability. Now, let’s get one configured.

Create a new trunk, give it a name:

Well, that was easy:

Create a Termination URI:

Create an Access Control List and Credential List:

Apply ACL and Credential List to the Termination Point:

 

Add an Origination URI. This will be “sip:” appended in front of your public IP:

Verify it is enabled:

Purchase a number:

Apply the number you just purchased to the SIP trunk you just created. This configuration is done from within the phone number configuration itself:

 

vCUBE Configuration

While your config may differ slightly, you will see below that we have a few dial-peers. Dial-peer 300 matches anything +(10 digits) and sends it to 172.16.54.32 (CUCM). Presumably this will be inbound from Twilio across the SIP trunk. Our next dial-peer 600 is responsible for matching inbound calls to the vCUBE from CUCM and sending them to Twilio. Note: Twilio sends calls in E164 format. 

 

dial-peer voice 300 voip
 destination-pattern +T
 session protocol sipv2
 session target ipv4:172.16.54.32
 no voice-class sip session refresh
 dtmf-relay rtp-nte
 codec g711ulaw
 no vad
!
dial-peer voice 600 voip
 translation-profile outgoing twilio
 destination-pattern 91[2-9]..[2-9]......
 session protocol sipv2
 session target sip-server
 voice-class codec 1  
 no voice-class sip session refresh
 dtmf-relay rtp-nte sip-kpml sip-notify
 no vad
!
sip-ua 
 authentication username cloverhound password 7 XXXXXXXXXXXXXXX realm sip.twilio.com
 registrar dns:chound-dev.pstn.twilio.com expires 3600
 sip-server dns:chound-dev.pstn.twilio.com
!

Below is a sample of a successful inbound SIP INVITE coming from Twilio.

vcube#
*Jun 15 20:15:22.454: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:+17045047352@172.16.54.208 SIP/2.0
Record-Route: <sip:54.172.60.3:5060;lr;ftag=54944286_6772d868_8705b7fe-726c-4176-b2ed-dc6cdf0b0bfa>
From: <sip:+17048675309@chound-dev.pstn.twilio.com>;tag=54944286_6772d868_8705b7fe-726c-4176-b2ed-dc6cdf0b0bfa
To: <sip:+17045047352@172.16.54.208;user=phone>
CSeq: 31102 INVITE
Max-Forwards: 81
P-Asserted-Identity: <sip:+17048675309@4.55.2.35:5060>
Diversion: <sip:+17045047352@public-vip.us1.twilio.com>;reason=unconditional
Call-ID: dafe45325a0454d5af9497e244d4eecd@0.0.0.0
Via: SIP/2.0/UDP 54.172.60.3:5060;branch=z9hG4bKdfdb.ce4175c1.0
Via: SIP/2.0/UDP 172.18.19.170:5060;rport=5060;received=172.18.19.170;branch=z9hG4bK8705b7fe-726c-4176-b2ed-dc6cdf0b0bfa_6772d868_293-12712659941386300061
Contact: <sip:+17048675309@172.18.19.170:5060;transport=udp>
Allow: INVITE,ACK,CANCEL,BYE,OPTIONS
User-Agent: Twilio Gateway
X-Twilio-AccountSid: AC136e72e8ee77014e16ae0ccc71b87b1c
Content-Type: application/sdp
X-Twilio-CallSid: CAcc3937ee666c372adcdbf5af5de6a896
Content-Length: 250

v=0
o=- 1504769997 1504769997 IN IP4 54.172.60.135
s=Twilio Media Gateway
c=IN IP4 54.172.60.135
t=0 0
m=audio 19500 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=maxptime:20
a=ptime:20
a=sendrecv

 

Firewall Configuration (Cisco ASA)

As we see below, we have a 1:1 static NAT from our public IP to our IP assigned to a GigE interface on the vCUBE. This allows Twilio to reach the vCUBE if your vCUBE sits behind a firewall, which ours does. If you are assigned a public IP to your vCUBE, then 1:1 static NAT is not necessary. Below the NAT is an access list to allow inbound traffic to come into your vCUBE on the outside interface.

object network vCUBE
 host 172.16.54.208
 description :vCUBE
 nat (inside,outside) static 67.212.2.202
!
access-list outside line 1 extended permit tcp any4 host 172.16.54.208 eq sip
access-list outside line 2 extended permit udp any4 host 172.16.54.208 eq sip
!

And that’s it! Feel free to drop us a comment below if you have any questions.

Helpful Links

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-virtual-cube.html

https://www.twilio.com/docs/api/sip-trunking/sample-configuration#cisco

http://www.cisco.com/c/en/us/td/docs/security/asa/asa90/configuration/guide/asa_90_cli_config/nat_objects.html