Our setup has been problematic on outbound dialing and inbound folks occasionally complains of “garbled” calls that can be cleared up by having caller call right back. Granted, the second issue may be QoS related… though switch and FW are provisioned with QoS for SIP and RTP packets.
If you have a successful integration. Would you be willing to share your inbound/outbound trunk settings and what driver you are using (chan_sip/pjsip).
Below is what we are currently using… however, for some unknown reason the outbound trunk will become “UNREACHABLE” seemingly randomly. And then just like it fell out, it will come back. We are not having this issue with our “non secure” (UDP) Twilio outbound trunks. This is happening on 2 different FreePBX setups behind 2 different firewalls (Meraki MX65 and SonicWall SOHO)
Information:
FreePBX version 13 (10.13.66-20)
FPBX-13.0.191.11(13.15.0)
Using chan_sip over port 5061
eSXi 6.0u3 Environment on Dell R710 host
"Inbound" Trunk 1 (There are 8 of these.. 1 for each Twilio IP)
host=54.172.60.0
type=peer
context=from-trunk
transport=tls
encryption=yes
"Outbound" Trunk
username=*removed*
type=peer
transport=tls
secret=*removed*
qualify=yes
host=*removed*.pstn.us2.twilio.com
encryption=yes
dtmfmode=rfc2833
disallow=all
directmedia=no
allow=ulaw
From the Twilio website regarding secure sip trunkung.
Asterisk ships by default with chan_sip driver and works well with Twilio. However, if you have some reason to run PJSIP driver with Asterisk, please note the following:
Asterisk 13.8 cert2 defaults to PJSIP 2.5 and it does not work with Twilio for TLS/SRTP purposes. Non-encrypted calls do work
Asterisk 13.8 cert2 can also use the latest PJSIP driver, which at this time is 2.5.5. Twilio works well with it despite the following message appearing in your log:
PJSIP 2.5.5 outputs the following error but the call is still shown to work.
Sep 27 13:03:56] ERROR[10886]: pjproject:0 : tlsc0x7f217c03 RFC 5922 (section 7.2) does not allow TLS wildcard certificates. Advise your SIP provider, please!
Thank you all for taking the time to respond and help to a potential solution. I am truly grateful
Based on this portion of their guide, I opted to just use chan_sip on all servers.
Is it possible it’s related to something else? I have 1 server that gets almost no use and never seems to exhibit this behavior… although it may just be people are not making calls on it.
However I’ve been monitoring the output of “sip show peers” on this server and each time I check, the “outbound” Twilio route is always “OK”. On the other 2 servers it will become “UNREACHABLE”.
The only real difference between the servers is FreePBX version. 10.13.66-19 on the low use sever. 10.13.66-20 on the other 2.
The answer is yes. And I just assumed the folks at Twilio were aware of the underlying software in FreePBX when they wrote the tutorial as well. Which made me a little concerned since Asterisk was supported and in the same chart (with other asterisk based IP-PBX software) FreePBX was not. It was just a weird listing as technically FreePBX should be listed in relation to asterisk but it wasn’t.
I was using Twilio for testing purposes and I saw the same thing. It would just randomly not work for inbound or outbound calls and then 10 minutes later it would work normally again without changing anything. Whenever it would randomly drop calls it also wouldn’t let me download the logs so I could never see why they weren’t working. It was very unreliable, but I was just using it for testing so it still worked for my needs.
For anybody that comes across this post and is looking for a solution, here is what we found.
This issue was only related to TLS outbound trunk connections for CHAN_SIP.
The issue didn’t always occur on Vanilla installs… but did sometimes
The issue definitely occurred after upgrading the core of FreePBX (distro upgrade)
It turns out this was actually related to the Phone Servers being virtualized. We are running them on VM Ware eSXi 6.0u3 on Dell PowerEdge R710 servers. It has something to do with the network card and how it is passing data. We are currently using the VMXNET3 Virutal Cards. It’s possible that switching to the tried and true E100 would have also fixed this issue or even doing direct SRV-IOV Pass through… however we do not think we will need to.
The VM Ware tools needed installed/reinstalled after upgrading the Phone Server to the newest stable distro version. Once we did this, we have had rock solid connections. We were tipped off by a comment in this article from Renrick McDonald (http://www.asteriskguru.com/tutorials/peer_is_now_unreachable.html) that indicated similar issues when using VirtualBox but not when using Hardware install.
We followed this post to install the VM Ware tools on FreePBX
Also we found that after making all of the updates, the system received a new MAC Address. We followed this article to change the Eth1 back to Eth0 which had all of our static info on it. Alternatively we could have just change the VM to static the old MAC Address and this would have also fixed the issue.