The Twilio/FreePBX config guide tells you to configure everything with a PJSIP driver, but I’ve had so many issues with it that I decided to try to switch to the SIP driver.
I’m trying to setup secure trunking (TLS) and I have everything working except for inbound calls. I have 4 different trunks setup (each with a different IP for each Twilio server), but every time that I make an inbound call, it keep saying “Rejecting unknown SIP connection from 54.172.60.3” (IP address changes). So it is acting as if it’s not looking at the trunks for the IPs that I have configured.
The only way that I can get it to accept incoming calls is to configure “allow anonymous inbound” which I don’t want to do due to the obvious security concerns. Please let me know if you know of any ideas to get this working without enabling anonymous connections.
Here’s an example of one of the inbound trunk configs:
Chan_SIP can’t differentiate by blocks of addresses. That’s why Twilio wants you to use PJ-SIP.
Your other option is to set up a trunk for every host at Twilio (something ridiculous like 64 addresses).
After a couple minutes of reflection, you could get by with a custom inbound context - allow your anonymous connections, but route them through the custom context and have it check the source IP address and check it against the banks of addresses at Twilio and reject the rest.
I tried using PJSIP, but I couldn’t get inbound calls to work with TLS. Whenever I would call inbound I would just get a busy signal and nothing in the FreePBX logs at all. I would see packets hitting the PBX server via tcpdump, but nothing else. If I disabled TLS, it worked just fine. If you have any suggestions for how to get PJSIP working, please let me know.
As for Chan_SIP, I created a trunk for each of the 4 US1 IP addresses that Twilio says the inbound calls are coming from. According to another tutorial that I found (and other posts in this community), that was supposed to work.
How do you setup a custom inbound context to do what you mentioned?
This is the full log from a test call if this helps:
– Executing [+1410XXXXXXX@from-sip-external:1] NoOp(“SIP/test123.pstn.twilio.com-00000007”, “Received incoming SIP connection from unknown peer to +1410XXXXXXX”) in new stack
– Executing [+1410XXXXXXX@from-sip-external:2] Set(“SIP/test123.pstn.twilio.com-00000007”, “DID=+1410XXXXXXX”) in new stack
– Executing [+1410XXXXXXX@from-sip-external:3] Goto(“SIP/test123.pstn.twilio.com-00000007”, “s,1”) in new stack
– Goto (from-sip-external,s,1)
– Executing [s@from-sip-external:1] GotoIf(“SIP/test123.pstn.twilio.com-00000007”, “1?setlanguage:checkanon”) in new stack
– Goto (from-sip-external,s,2)
– Executing [s@from-sip-external:2] Set(“SIP/test123.pstn.twilio.com-00000007”, “CHANNEL(language)=en”) in new stack
– Executing [s@from-sip-external:3] GotoIf(“SIP/test123.pstn.twilio.com-00000007”, “1?noanonymous”) in new stack
– Goto (from-sip-external,s,5)
– Executing [s@from-sip-external:5] Set(“SIP/test123.pstn.twilio.com-00000007”, “TIMEOUT(absolute)=15”) in new stack
– Channel will hangup at 2018-09-24 17:21:01.944 UTC.
– Executing [s@from-sip-external:6] Log(“SIP/test123.pstn.twilio.com-00000007”, "WARNING,“Rejecting unknown SIP connection from 54.172.60.1"”) in new stack
[2018-09-24 17:20:46] WARNING[29557][C-00000007]: Ext. s:6 @ from-sip-external: “Rejecting unknown SIP connection from 54.172.60.1”
– Executing [s@from-sip-external:7] Answer(“SIP/test123.pstn.twilio.com-00000007”, “”) in new stack
– Executing [s@from-sip-external:8] Wait(“SIP/test123.pstn.twilio.com-00000007”, “2”) in new stack
– Executing [s@from-sip-external:9] Playback(“SIP/test123.pstn.twilio.com-00000007”, “ss-noservice”) in new stack
– <SIP/test123.pstn.twilio.com-00000007> Playing ‘ss-noservice.ulaw’ (language ‘en’)
– Executing [h@from-sip-external:1] Hangup(“SIP/test123.pstn.twilio.com-00000007”, “”) in new stack
== Spawn extension (from-sip-external, h, 1) exited non-zero on ‘SIP/test123.pstn.twilio.com-00000007’
The name of the server can return any number of return addresses, which Chan-SIP can’t handle.
As to writing a custom inbound context - that’s a lot more than a forum post can cover. Start by looking at some of the contexts in “extensions.conf” and see what they are doing. Search that file for “from-sip-external” and see what that context is doing. Chances are, you’re going to want to do something with the ‘s’ destination in a custom context that would ‘gate keep’ your anonymous connections.
Just guessing, Twilio was sending the calls to port 5060 and your PBX was listening for TLS on port 5061. If you still have the capture file, you can check that easily. If that’s the issue, in the Twilio portal, try putting :5061 after your IP address.
For chan_sip, instead of defining many trunks, you can add just two lines of custom code for each address from which Twilio can send calls. See https://www.callcentric.com/support/device/freepbx/13 step 23 for an example for another provider.
@cynjut - you’re saying that the name of the server can return multiple addresses, but I accounted for all of those addresses by having a trunk for each one and it still didn’t work.
@Stewart1 - unfortunately when I had the PJSIP trunk, the traffic was indeed coming over via port 5061 (confirmed via the tcpdump). For some reason, the PBX server just was not doing anything with the traffic and there was nothing that I could debug in the logs
I like the idea of step 23 that you sent along, but I’m a little unsure how to implement it. I removed all inbound trunks and tried editing the sip_custom_post.conf file as described on that web site, but I still cannot make an inbound call without enabling anonymous. Am I missing something?
The name test123.pstn.twilio.com can resolve to any number of addresses, and the log message says that the source of this call is from an IP-address-specific trunk that doesn’t exist in your server. There are lots of ways this can go wrong, including local cache errors, reverse DNS failures, /etc/hosts file entry mistakes, and simple DNS failure. We’ve seen lots of DNS failures today, so it’s on everyone’s mind.
We’ve been following a lot of people with Twilio problems over the past few weeks. There’s something going on there that’s outside our scope, but hopefully we can help you solve the problems and get you back online.
@cynjut Thank you. The odd thing though is if I disable TLS and switch back to port 5060, then the inbound trunks work properly (without anonymous enabled).