I have followed the guide for trunk setup provided by twilio and got Twilio working with Freepbx.
I see random call failures for incoming calls, and doing a tshark command shows they are 401 unauthorized errors. The issue resolves itself automatically after several minutes, and then ensues again.
It seems like FreePBX is rejecting servers from which twilio is send the sip call, and twilio must be cycling through different servers. Any input on how to resolve this?
If you are using the Firewall, make sure the Twilio IPs are Trusted. I also add these IPs to the IDS whitelist.
Good point, I added those shortly before posting this post. I still got called failed errors today.
What is the IDS whitelist?
IDS Whitelist is under Admin > Intrusion Detection > Whitelist
Add your signaling Twilio IPs there:
54.172.60.0
54.172.60.1
54.172.60.2
54.172.60.3
54.171.127.192
54.171.127.193
54.171.127.194
54.65.63.192
54.65.63.193
54.65.63.194
54.169.127.128
54.169.127.129
54.169.127.130
54.252.254.64
54.252.254.65
54.252.254.66
177.71.206.192
177.71.206.193
177.71.206.194
adolfoc thank you for the reply.
Unfortunately that did not resolve the problem. I have pasted below the output from tshark while monitor the network on an incoming call attempt which leads to a failed call:
115.374800 54.172.60.0 -> 192.168.1.110 SIP/SDP 1491 Request: INVITE sip:[email protected]:5061 | , with session description
115.375261 192.168.1.110 -> 54.172.60.0 SIP 779 Status: 401 Unauthorized |
115.393509 54.172.60.0 -> 192.168.1.110 SIP 476 Request: ACK sip:[email protected]:5061 |
115.399093 54.172.60.0 -> 192.168.1.110 SIP/SDP 1497 Request: INVITE sip:[email protected]:5061 | , with session description
115.399452 192.168.1.110 -> 54.172.60.0 SIP 781 Status: 401 Unauthorized |
115.417903 54.172.60.0 -> 192.168.1.110 SIP 476 Request: ACK sip:[email protected]:5061 |
115.437589 54.172.60.0 -> 192.168.1.110 SIP/SDP 1490 Request: INVITE sip:[email protected]:5061 | , with session description
115.437926 192.168.1.110 -> 54.172.60.0 SIP 778 Status: 401 Unauthorized |
115.456698 54.172.60.0 -> 192.168.1.110 SIP 475 Request: ACK sip:[email protected]:5061 |
115.461190 54.172.60.3 -> 192.168.1.110 SIP/SDP 1492 Request: INVITE sip:[email protected]:5061 | , with session description
115.461533 192.168.1.110 -> 54.172.60.3 SIP 779 Status: 401 Unauthorized |
115.480389 54.172.60.3 -> 192.168.1.110 SIP 475 Request: ACK sip:[email protected]:5061 |
115.485901 192.168.1.110 -> 192.168.1.2 SSH 1514 Encrypted response packet len=1460
It is very weird that even after turning off all firewalls it doesn’t resolve the issue. The only that works is if I edit the Inbound Route, and remove the + sign from the DID value, update the settings, then go back and edit and add the + again to the DID and apply settings, then that inbound did works.
Have you ever seen an issue like that before?
Search the forum, many have seen that problem, use the context
from-pstn-e164-us
for your inbound trunk
According to twilio’s article this is what they recommend for each of 4 incoming trunk
host=54.172.60.0
type=peer
context=from-trunk
of course the IP is different. What are your thoughts?
My thoughts are that if they are sending you
I would not agree with them, use from-pstn-e164-us because it IS actually in e164 format and that context will rationalize it all for you. Even when they don’t send an initial + .
I tried that and got the same error. Do I need to change how the DID is stated for the incoming trunk? it was using a +1XXXXXXXXXX. I tried removing the +, removing the one, and nothing worked. sip requests were still with +1.
I noticed something when calling repeatedly using the Twilio provided context:
Only calls from a certain Twilio IP are being accepted, i.e. 54.172.60.1
When I call in succession calls from other Twilio IPs are being rejected even though I have them added in the whitelist in the intrusion detection portion and firewall section (see attached for screenshot of firewall section).
I am testing this fail2ban and iptables turned off.
So here is what I found after messing around with different settings to improve incoming call acceptance:
I had to set the following to yes in asterisk sip settings to get asterisk to accept inbound sip connections from Twilio:
Allow Anonymous Inbound SIP calls : YES
Allow SIP Guests: Yes
With the above two enabled along with the following things are working:
Whitelist in firewall
Whitelist in intrustion detection
I am using 4 incoming peers as Twilio documentation suggests with context=from-trunk
Although I am not getting as many 401 unauthorized errors, they are still happening from time to time. Take a look here for example which occurred during successive call attempts where 1/5 calls ended up failing:
901.421335 54.172.60.3 -> 192.168.1.110 SIP/SDP 1509 Request: INVITE sip:[email protected]:5061 | , with session description
901.421769 192.168.1.110 -> 54.172.60.3 SIP 794 Status: 401 Unauthorized |
901.441049 54.172.60.3 -> 192.168.1.110 SIP 489 Request: ACK sip:[email protected]:5061 |
901.447272 54.172.60.0 -> 192.168.1.110 SIP/SDP 1507 Request: INVITE sip:[email protected]:5061 | , with session description
901.447628 192.168.1.110 -> 54.172.60.0 SIP 794 Status: 401 Unauthorized |
901.467255 54.172.60.0 -> 192.168.1.110 SIP 489 Request: ACK sip:[email protected]:5061 |
901.485037 54.172.60.3 -> 192.168.1.110 SIP/SDP 1509 Request: INVITE sip:[email protected]:5061 | , with session description
901.485374 192.168.1.110 -> 54.172.60.3 SIP 794 Status: 401 Unauthorized |
901.504875 54.172.60.3 -> 192.168.1.110 SIP 489 Request: ACK sip:[email protected]:5061 |
901.511044 54.172.60.0 -> 192.168.1.110 SIP/SDP 1505 Request: INVITE sip:[email protected]:5061 | , with session description
901.511376 192.168.1.110 -> 54.172.60.0 SIP 793 Status: 401 Unauthorized |
901.532303 54.172.60.0 -> 192.168.1.110 SIP 489 Request: ACK sip:[email protected]:5061 |
917.229373 54.172.60.2 -> 192.168.1.110 SIP/SDP 1504 Request: INVITE sip:[email protected]:5061 | , with session description
917.230453 192.168.1.110 -> 54.172.60.2 SIP 843 Status: 100 Trying |
917.246849 192.168.1.110 -> 54.172.60.2 SIP/SDP 1242 Status: 200 OK | , with session description
917.270089 54.172.60.2 -> 192.168.1.110 SIP 668 Request: ACK sip:[email protected]:5061 |
920.030590 192.168.1.161 -> 192.168.1.110 CLASSIC-STUN 64 Message: Binding Request
920.622538 192.168.1.110 -> 192.168.1.161 SIP 599 Request: OPTIONS sip:[email protected]:5061 |
920.680909 192.168.1.161 -> 192.168.1.110 SIP 500 Status: 200 OK |
922.464285 54.172.60.2 -> 192.168.1.110 SIP 695 Request: BYE sip:[email protected]:5061 |
Does it make my server vulnerable when I allow Allow Anonymous Inbound SIP calls and Allow Sip Guests?
What else could be causing 401 unauthorized errors?
I am about to give up on this and switch to Pilvo as this is turning out to be a pain. I like call logs available on Twilio.com which let me know if calls failed and who to call back.
Bump. Any suggestions please.
Fix/add to your inbound trunks, you might need several for twilio, one for each possible server, if you don’t allow anonymous (which is a good idea 
. )
I already have 4 trunks in place, one for each IP that twilio specifies. Despite having a trunk for that IP as peer, it is getting rejected. Sometimes one Twilio ip works and the other 3 fail. Then it’s another.
talk to twilio. . . . make sure they are listening on 5061.
I wish Twilio actually responded to support requests. Their support leaves a lot to be desired. Even porting a number has been a pain with them.
I did switch the SIP port to 5060 everywhere on my install and tested it again to rule out Twilio sending sip-tls on 5061 by default, but that didn’t make any difference. So I am stuck. If Twilio doesn’t respond to my support request I will most likely give up and switch.
I have an older installation of asterisk running with Twilio. I have 4 inbound trunks defined, one for each IP.
@cvsjmabbott I have exactly the same configuration for my 4 inbound trunks. This is how Twilio instructs users to set up Origination Trunks. But I am still having the issue mentioned in this thread.
On your inbound routes, do your DIDs have a + in front… like +18771234367 ?
