Twilio SIP Trunking with CUBE

[JOHN PARDUHN]

I am working on my lab setup with CUCM 11.5, a 2811 router running IOS 12.4, and a Twilio SIP trunk. I can route a call to the trunk from an IP phone without an issue, but the call won't set up. I get the following dump from the Twilio debugger (redacted):

ParametersShow Raw

From	<sip:6305551212@domain_sip.pstn.twilio.com;user=phone>;tag=11296D5C-10CC
To	<sip:+14154758378@domain_sip.pstn.twilio.com;user=phone>
SipSrcIp	1.2.3.4
SipSrcTransport	udp
SipCallId	6CBE739-EA5A11E6-99CBC1B4-E343E364@192.168.0.2
UserAgent	Cisco-SIPGateway/IOS-12.x

Message TextShow Raw

Msg	The body of the request was empty, which is not allowed in this context.
ErrorCode	32103
LogLevel	WARN

I'm curious if anyone has worked on this setup and what your experience was. I'd really like to have this proof-of-concept working for my own knowledge. Thanks in advance!

[nathanjgrace]

Hi John, can you please provide the output of 'debug ccsip messages' from your 2811 during that call as well as your config?  Thank you.

[JOHN PARDUHN]

Here you go, Nathan. Thanks for your eyes on this.

John

[nathanjgrace]

Thanks.  The first error we see is the 407 Proxy Authentication Required coming from Twilio.  After that, we see the 400 Empty Body and finally your CUCM gives a 500.

Can you check your config in case there is any sip-ua authentication you might need to establish per Twilio?

I'd also like to see your full running config in case there are any quick oversights.  Thanks!

[JOHN PARDUHN]

Thanks for looking. There is an authentication with the UA, and I have that in my configuration:

sip-ua
authentication username jparduhn password 7 075B7214405A4A2E4E4035015D realm sip.twilio.com
registrar dns:foxchasesip.pstn.twilio.com expires 3600
sip-server dns:foxchasesip.pstn.twilio.com

I initially had an issue with the authentication being incorrect because of a username issue, and the Twilio debugger helped me make that determination. Now I just see a series of empty body errors. Do you see anything wrong with the configuration above? Full configuration is attached. Your feedback is extremely welcome.

[JOHN PARDUHN]

Nathan:

Is it possible there's an issue with the realm portion of the authentication parameter?

John

[nathanjgrace]

Possibly, but it looks good based on the configuration guide at https://www.twilio.com/docs/api/sip-trunking/sample-configuration#cisco.  Also in this guide, we see that Twilio lists a number of IP addresses to add to your trusted list.  In your config, it looks like you don't have a list and also don't have the authentication disabled.

I think you have two options- you can either add the code below to allow communications to Twilio and your CUCM

 voice service voip 
 ip address trusted list
  ipv4:172.31.101.181
  ipv4 54.172.60.0/23
  ipv4 54.171.127.192/26
  ipv4 54.65.63.192/26
  ipv4 54.169.127.128/26
  ipv4 54.252.254.64/26
  ipv4 177.71.206.192/26

or (less secure) remove the trusted authentication completely

voice service voip
 no ip address trusted authenticate

Let me know how this works!  For more info on the trusted list, check http://www.cisco.com/c/en/us/support/docs/voice/call-routing-dial-plans/112083-tollfraud-ios.html.

Thanks.

-Nathan

[JOHN PARDUHN]

IOS 12.4 would not allow these commands, so I'm reverting to 15.1 to try again, Nathan. I had them there originally before downgrading the code, but was missing the trust list entry back to CUCM.

I'll keep you posted.

[nathanjgrace]

Hi John, looking forward to hear if this was resolved.  Thanks!

[JOHN PARDUHN]

No luck, Nathan. I have the same problem with the allow list. I thought I wrote you back to let you know, but apparently was just thinking about doing so and never got around to it. Silly me! I shelved it for the weekend and figured I'd get back to it today. It's really weird, and part of me thinks it's something related to Twilio. I see the call hit their debugger every time, and I've verified the credentials as well as tested with the ACL enabled/disabled. It's a real head-scratcher. I'm thinking of going to an alternate provider to see if I have the same issue. Any thoughts? Thanks for following up with me!

John

[nathanjgrace]

I've worked with may carriers over the years, but not Twilio.  I would give them a fair chance to troubleshoot and also open a TAC case before switching.

I can suggest a few carriers I've had success with- please email me privately at nathanjgrace@gmail.com and I'll give some suggestions if you wish to go this route.  Thanks!

-Nathan

[JOHN PARDUHN]

Good morning, Nathan! I made progress yesterday with inbound calls routing to my phone, although I have to state that neither Twilio or Cisco Support have been especially helpful in helping me achieve that result. The Twilio guy told me things I already knew, and my TAC engineer never even wrote me back after requesting 2811 SIP debugs. I've essentially relied on my good friend Google to help me figure out the problem. The first issue was my dial peer configuration. I didn't have them set up in an orderly fashion in the first crack at this. Once I separated the CUCM peers from the Twilio ones, my life got a little easier because I could see the logic. I still kept getting the empty body message on the Twilio debugger, but the Twilio engineer said something about my origination URI that got me thinking. He mentioned the private IP that I had assigned to the DMZ interface on my CUBE. No matter what SIP profile header manipulation I did, that IP kept showing up the the Twilio debug. I realized that the 1:1 NAT configuration I have configured on my Meraki MX64 is probably the culprit. I read around and found that others have experienced this as well. I'm going to move the CUBE outside the firewall later today when I can get a longer cable to extend to the ISP router. I should be able to assign the public IP to the WAN-facing port on the 2811 and just connect up to the ISP, much like what I've had to do with statically assigning public IP to the external WAN interface on the MX64. I'll let you know what happens from there. Have a good day!

[JOHN PARDUHN]

EUREKA! I figured it out! This after having issues assigning a public IP address to my 2811 on one Ethernet interface and having a private one on the other. I reverted back to my old 1:1 NAT configuration and just kept playing around trying to find an answer.

So under the 'voice service voip' command, I put the command 'address-hiding', and the calls outbound route now. According to a SIP CUBE lab guide I found on the web:

“address-hiding” allows you to hide your internal signaling and media peer addresses from your service provider. All SIP methods/messages will terminate on CUBE and re-originate with CUBE’s own IP addressing.

Attached is my updated configuration.

[Theofilos Tzachristas]

Thank you Nathan,

I had the same problem. After adding the Call Manager IP to the trusted list, I was able to make outbound calls.

voice service voip
 ip address trusted list
  ipv4 <CUCM>

Also Twilio doesn't accept SIP delayed offer. In the INVITE message SDP should be included which can be done when you force Early Offer

Twilio-CUBE(config)#voice service voip
Twilio-CUBE(conf-voi-serv)#sip
Twilio-CUBE(conf-serv-sip)#early-offer forced

Theo