Asterisk and Twilio's Elastic SIP Trunking (inbound troubleshooting)

1.5k views Asked by At

I've been at this for a few days and can't seem to route incoming calls through to user extensions. Outgoing calls and internal SIP extension dialing both work however, when placing a call to the number associated with a Twilio Elastic SIP trunk I have setup and configured for a domain, I get an "All circuits are busy" message from my carrier.

The system is a fresh install of FreePBX 12.0.68 running on Ubuntu 14.04 with internal SIP extention dialing and outbound calls on the trunk working. The Twilio trunk configuration for Asterisk was taken from here and here

type=peer
secret=xxxxxxxxxxxxxxxxxxx
username=xxxxxxxxxxxxxxx
host=xxxxxxxxx.pstn.twilio.com
dtmfmode=rfc2833
canreinvite=no
disallow=all
allow=ulaw
insecure=port,invite
fromuser=xxxxxxxxxxx
fromdomain=xxxxxxxxx.pstn.twilio.com
context=incoming

Here's the TCP/UDP traffic between Twilio and the server

Source          Destination     Protocal  Info
10x.xxx.xx.xxx  10x.xxx.xxx.xx  UDP       Source port: 5060  Destination port: 5060
54.172.60.2     10x.xxx.xxx.xx  SIP/SDP   Request: INVITE sip:[email protected] 
54.172.60.2     10x.xxx.xxx.xx  SIP/SDP   Request: INVITE sip:[email protected] 
54.172.60.2     10x.xxx.xxx.xx  SIP/SDP   Request: INVITE sip:[email protected] 
54.172.60.2     10x.xxx.xxx.xx  SIP/SDP   Request: INVITE sip:[email protected] 
54.172.60.2     10x.xxx.xxx.xx  SIP/SDP   Request: INVITE sip:[email protected] 
54.172.60.2     10x.xxx.xxx.xx  SIP/SDP   Request: INVITE sip:[email protected] 
54.172.60.2     10x.xxx.xxx.xx  SIP/SDP   Request: INVITE sip:[email protected] 
54.172.60.2     10x.xxx.xxx.xx  SIP/SDP   Request: INVITE sip:[email protected] 
54.172.60.3     10x.xxx.xxx.xx  SIP/SDP   Request: INVITE sip:[email protected] 
54.172.60.3     10x.xxx.xxx.xx  SIP/SDP   Request: INVITE sip:[email protected] 
54.172.60.3     10x.xxx.xxx.xx  SIP/SDP   Request: INVITE sip:[email protected] 
54.172.60.3     10x.xxx.xxx.xx  SIP/SDP   Request: INVITE sip:[email protected] 
54.172.60.3     10x.xxx.xxx.xx  SIP/SDP   Request: INVITE sip:[email protected] 
54.172.60.3     10x.xxx.xxx.xx  SIP/SDP   Request: INVITE sip:[email protected] 
54.172.60.3     10x.xxx.xxx.xx  SIP/SDP   Request: INVITE sip:[email protected] 
54.172.60.3     10x.xxx.xxx.xx  SIP/SDP   Request: INVITE sip:[email protected] 
54.172.60.0     10x.xxx.xxx.xx  SIP/SDP   Request: INVITE sip:[email protected] 
54.172.60.0     10x.xxx.xxx.xx  SIP/SDP   Request: INVITE sip:[email protected] 
54.172.60.0     10x.xxx.xxx.xx  SIP/SDP   Request: INVITE sip:[email protected] 
10x.xxx.xx.xxx  10x.xxx.xxx.xx  UDP       Source port: 5060  Destination port: 5060

And here's the INVITE UDP stream

INVITE sip:[email protected] SIP/2.0
Record-Route: <sip:54.172.60.0:5060;lr;ftag=11540065_6772d868_144031e0-db91-45e9-ae85-6de18ed14b19>
From: <sip:[email protected];pstn-params=808481808882;cpc=ordinary>;tag=11540065_6772d868_144031e0-db91-45e9-ae85-6de18ed14b19
To: <sip:[email protected];user=phone>
CSeq: 25149 INVITE
Max-Forwards: 132
Accept: application/sdp,application/isup,application/dtmf,application/dtmf-relay,multipart/mixed
Session-Expires: 1800
Min-SE: 90
Content-Disposition: session;handling=required
Diversion: sip:[email protected];reason=unconditional
Call-ID: [email protected]
Via: SIP/2.0/UDP 54.172.60.0:5060;branch=z9hG4bKdf6c.854803a7.0
Via: SIP/2.0/UDP 172.18.18.39:5060;branch=z9hG4bK144031e0-db91-45e9-ae85-6de18ed14b19_6772d868_287964010429808
Contact: <sip:[email protected]:5060;transport=udp>
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE
User-Agent: Twilio Gateway
X-Twilio-AccountSid: ACaa6e5a9a0d40b2b12751f33b612ebf6e
X-Twilio-ApiVersion: 2010-04-01
Content-Type: application/sdp
X-Twilio-CallSid: CAcc7d0e0603fea476fdaa1c94d9243104
Content-Length: 233

v=0
o=- 412164138 412164138 IN IP4 54.172.60.23
s=SIP Media Capabilities
c=IN IP4 54.172.60.23
t=0 0
m=audio 11590 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=ptime:20
INVITE sip:[email protected] SIP/2.0
Record-Route: <sip:54.172.60.0:5060;lr;ftag=11540065_6772d868_144031e0-db91-45e9-ae85-6de18ed14b19>
From: <sip:[email protected];pstn-params=808481808882;cpc=ordinary>;tag=11540065_6772d868_144031e0-db91-45e9-ae85-6de18ed14b19
To: <sip:[email protected];user=phone>
CSeq: 25149 INVITE
Max-Forwards: 132
Accept: application/sdp,application/isup,application/dtmf,application/dtmf-relay,multipart/mixed
Session-Expires: 1800
Min-SE: 90
Content-Disposition: session;handling=required
Diversion: sip:[email protected];reason=unconditional
Call-ID: [email protected]
Via: SIP/2.0/UDP 54.172.60.0:5060;branch=z9hG4bKdf6c.854803a7.0
Via: SIP/2.0/UDP 172.18.18.39:5060;branch=z9hG4bK144031e0-db91-45e9-ae85-6de18ed14b19_6772d868_287964010429808
Contact: <sip:[email protected]:5060;transport=udp>
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE
User-Agent: Twilio Gateway
X-Twilio-AccountSid: ACaa6e5a9a0d40b2b12751f33b612ebf6e
X-Twilio-ApiVersion: 2010-04-01
Content-Type: application/sdp
X-Twilio-CallSid: CAcc7d0e0603fea476fdaa1c94d9243104
Content-Length: 233

v=0
o=- 412164138 412164138 IN IP4 54.172.60.23
s=SIP Media Capabilities
c=IN IP4 54.172.60.23
t=0 0
m=audio 11590 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=ptime:20
INVITE sip:[email protected] SIP/2.0
Record-Route: <sip:54.172.60.0:5060;lr;ftag=11540065_6772d868_144031e0-db91-45e9-ae85-6de18ed14b19>
From: <sip:[email protected];pstn-params=808481808882;cpc=ordinary>;tag=11540065_6772d868_144031e0-db91-45e9-ae85-6de18ed14b19
To: <sip:[email protected];user=phone>
CSeq: 25149 INVITE
Max-Forwards: 132
Accept: application/sdp,application/isup,application/dtmf,application/dtmf-relay,multipart/mixed
Session-Expires: 1800
Min-SE: 90
Content-Disposition: session;handling=required
Diversion: sip:[email protected];reason=unconditional
Call-ID: [email protected]
Via: SIP/2.0/UDP 54.172.60.0:5060;branch=z9hG4bKdf6c.854803a7.0
Via: SIP/2.0/UDP 172.18.18.39:5060;branch=z9hG4bK144031e0-db91-45e9-ae85-6de18ed14b19_6772d868_287964010429808
Contact: <sip:[email protected]:5060;transport=udp>
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE
User-Agent: Twilio Gateway
X-Twilio-AccountSid: ACaa6e5a9a0d40b2b12751f33b612ebf6e
X-Twilio-ApiVersion: 2010-04-01
Content-Type: application/sdp
X-Twilio-CallSid: CAcc7d0e0603fea476fdaa1c94d9243104
Content-Length: 233

v=0
o=- 412164138 412164138 IN IP4 54.172.60.23
s=SIP Media Capabilities
c=IN IP4 54.172.60.23
t=0 0
m=audio 11590 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=ptime:20

I also have an incoming route configured within the FreePBX interface with the DID Number set to my Twilio number and Destination set directly to a user's SIP extension with a corresponding client running and ready to receive calls. I've used both netstat and tcpdump which to me it looks like an INVITE request is sent from Twilio and FreePBX just isn't routing it properly?

1

There are 1 answers

0
Fernando Rodriguez On

I read you had a NAT issue--I still wanted to post this for people who also come across this with the similar issue.

I have gotten my Twilio Elastic SIP trunk properly functioning from several of my PBX systems as well as our ViciDIAL open-source dialer configurations for some of our clients. I had one heck of a time with something that seemed identical to what OP describes.

Granted, I have only tested the inbound on a PBX--I tried several different permutations of my config until I nailed down exactly what was messing with using Twilio as opposed to any other SIP provider in the world.

First off, the only thing I have for asterisk settings:

[twilio]
host=xxxxxxx.pstn.twilio.com
type=friend
dtmfmode=rfc4733
canreinivite=no
insecure=port,invite

[twilio1]
type=friend
insecure=port,invite
host=54.172.60.0
dtmfmode=rfc4733
canreinivite=no

[twilio2]
type=friend
insecure=port,invite
host=54.172.60.1
dtmfmode=rfc4733
canreinivite=no

...and so on for each of the Twilio IP's you will be using for inbound, since you never know which of the nearby geo ip's it will utilize. (I would notice asterisk log show calls round robin through the IP's which depend on your geographic region).

You can see an example here in my asterisk log, where I've only replace my twilio phone number with (twilio_phone) for privacy: http://pastebin.com/rXz7cY39

The one other major difference:

Inbound routes (DID's) had to be declared with the leading + sign, which is not typical in my experience

So, with twilio you have to include every possible IP as a trunk and also include the + before numbers both when dialing out and creating your inbound routes

Hope this is a help to anyone struggling to implement!