Twilio Trunk not getting calls from a specific phone number

[ChadRT]

Debian Buster 10
Asterisk 16.2.1~dfsg-1+deb10u2
Twilio Trunk Provider

Hello Everyone,
Anyone who works with Twilio knows that when you build a trunk you build all the settings in that trunk with Elastic SIP Trunking. Then you add phone numbers and each number gets its settings from the trunk profile. Twilio is not being helpful with this whatsoever. All day support emails back and forth and they just dont get it. So I am here in the community asking for a bit of advise (other than dumping Twilio).

I have 1 phone number in my trunk that works perfect 100% of the time. I have a second number that was ported in and said port is status “COMPLETE” with that being said the second number will not work unless it is from another Twilio trunk. ex: Location1–>Asterisk–>Twilio Trunk–>PSTN then back again PSTN–>Twilio Trunk–Asterisk–>Location2 (THIS EXAMPLE WORKS!)

Twilio claims unable to communicate with my SIP infrastructure. However if they are both on the same trunk how is it one number can communicate and the other cannot?

;SANITIZED
[incoming]

;LOCATION TEMP - REMOVE AFTER PORT CONFIRMED - LOOSING CARRIER FORWARDED HERE
exten => +13601111111,1,SipAddHeader(Alert-Info: <Bellcore-dr2>)
        same => n,dial(SIP/7302&SIP/7303&SIP/7308&SIP/7305,20,i)
        same => n,Dial(SIP/CORPOFFICE_VOIP/4570) ;WORKING LOCATION
        same => n,Hangup()

;LOCATION PERMANENT
exten => +13602222222,1,SipAddHeader(Alert-Info: <Bellcore-dr2>)
        same => n,dial(SIP/7302&SIP/7303&SIP/7308&SIP/7305,25,i)
        same => n,Dial(SIP/CORPOFFICE_VOIP/4570) ;WORKING LOCATION
        same => n,Hangup()

This is my trunk setup:

        [twilio-trunk](!)
                type=peer
                context=incoming
                canreinivite=no
                insecure=port,invite
                dtmfmode=rfc2833

        [twilio0](twilio-trunk)
                host=MyPrivateURI.pstn.umatilla.twilio.com ;Our Termination URI
                defaultuser=MyAwesomeUsername
                remotesecret=MySuperSecretPassword


;       [twilio1](twilio-trunk)
;               host=54.172.60.2

;       [twilio2](twilio-trunk)
;               host=54.172.60.0

;       [twilio3](twilio-trunk)
;               host=54.172.60.1

;       [twilio4](twilio-trunk)
;               host=54.172.60.3

;       [twilio5](twilio-trunk)
;               host=54.172.51.0

;       [twilio6](twilio-trunk)
;               host=54.172.51.1

;       [twilio7](twilio-trunk)
;               host=54.172.51.2

;       [twilio8](twilio-trunk)
;               host=dynamic ;THIS DOESNT SEEM TO WORK CAN SOMEONE CONFIRM?

        [twilio9](twilio-trunk)
                host=54.244.51.0
        [twilio10](twilio-trunk)
                host=54.244.51.1

        [twilio11](twilio-trunk)
                host=54.244.51.2

        [twilio12](twilio-trunk)
                host=54.244.51.3

Several of the Twilio lines are commented out but they are for regions that we do not have piped into the Asterisk box. I would be willing to just allow everything as in my little test example above and just use the firewall to manage the inbound traffic.

[justishar]

You need to run traces to see what is actually being sent and received between Twilio and your Asterisk server. Twilio should be able to provide traces from their end and you can run tshark to take traces on your end. The tshark trace taken from the Asterisk server would be the most useful one. Once you have the trace, you can look at the call flow and see where it is breaking down. It’s not really clear from your post what the problem is, but it sounds like the most likely scenarios are that 1) Twilio is misconfigured and is not sending anything down your trunk when the number is called, or 2) Twilio is sending the call to you and you’re not handling it properly. In any case, figuring out what exactly is wrong with the call flow is the first step before digging into any Asterisk configs.

[ChadRT]

OK so I ran the trace and I can see the inbound request coming from the working number…

89 14.841511744  54.244.51.0 → 172.31.22.1  SIP/SDP 1301 Request: INVITE sip:+13601111111@172.31.22.1 |
   90 14.842010845  172.31.22.1 → 54.244.51.0  SIP 791 Status: 100 Trying |

However when I dial the number that does NOT work I get nothing from the Twilio network. Just as suspected I dont believe that Twilio is even attempting to reach my network.

I wonder if they are sending the call from a different set of IP’s? How would I allow that trunk to just accept a call from anywhere and not just the IP’s listed. This way I can have the firewall handle all the security and leave the Asterisk box out of the equation completely. By the way I have the firewall allowing every listed IP that Twilio has published so I do not believe that it is a fw issue.

[david551]

You would enable allowguest in the general section.

Note, at the best of times, trunk is not a well defined term in SIP; it appears nowhere in the main specification document, but once you enable allowguest, you cannot really describe the incoming calls as coming from a trunk at all; they are just from the “cloud”.

[justishar]

All signs are pointing to a Twilio configuration issue, though it could be a firewall issue too. Go to them with these traces and ask why they are not sending the call to your IP when the number is dialed. If they say that they can’t communicate with your infrastructure, ask them to clearly define what they mean by that in technical terms.

You can also run a packet capture on your firewall while generating calls in order to rule that out as the cause of the problem.

Lastly, if you save your tshark trace as a file, you can open it in Wireshark and get a lot more detail on what is in the packets.

[justishar]

One more thing – you mentioned trying to get Asterisk to accept a call from anywhere, but your problem is different. You just verified with your packet capture that the call is never getting to your Asterisk server in the first place. You need to get the call to the Asterisk server first before Asterisk can even decide whether to accept it or not.