Problems with TCP Signaling for Twilio

0
votes

We are having a UDP fragmentation issue with UDP packets on our firewall and tried to change the originating SIP requests for our trunk to TCP. I added ;transport=tcp our origination URI. However it doesn't appear to work. The connections are failing. We see no packets from Twilio on the firewall and the Twilio PCAP logs for the calls are showing that it is still using UDP instead of TCP. Does anyone know how to set this up properly?

According to the documentation: By default, Twilio sends originating SIP requests towards your communications infrastructure over UDP. This may be customized to be sent over TCP rather than UDP. Change this by using the transport parameter in the origination SIP URI. And the example that is given is: sip:[email protected];transport=tcp

1
twilio
I'd recommend reaching out to Twilio support if you are having this sort of problem. They should be able to help you easier than on StackOverflow, where questions are more about code that isn't working. Cheers! – philnash
Are you using SIP trunk or Twiml SIP ? The option you mention seems to be the way to go with SIP trunking – gogasca
We are using a SIP trunk. – Kelly Brown

1 Answers

2
votes

I believe I have resolved the issue with failed originating calls. It appears that quite a few customers (using Asterisk + FreePBX servers) were having the same exact issue whereby random (first or first few) inbound calls were being rejected with a 401 unauthorized error. Unfortunately, none of these customers’ were able to resolve the issue with the exception of one customer: http://community.freepbx.org/t/twilio-inbound-suddenly-stops-working/33216/37

The above customer noticed in the debug logs that the initial originating call actually was connecting to an outbound Twilio trunk instead of the inbound trunk; and failing (obviously) since no incoming settings were configured. When the customer removed all Twilio outbound trunks, he no longer received the originating call failed entries in the log within the Twilio console. He then proceeded to make an inbound and outbound single main Twilio trunk which took care of both incoming and outgoing calls without failed inbound calls.

Since the above resolution was far from ideal, I researched why Twilio’s originating calls would utilize an outbound trunk (initially). The answer was that FreePBX configured trunk settings alphabetically by trunk name and asterisk would read the configuration file from top to bottom. Moreover, if there were duplicate host IPs in the trunk configurations, asterisk (1.6 and later versions) would use the first trunk (from top to bottom) with the duplicate host IP.

So as per the FreePBX Interconnect guide you can download here, I have 4 inbound (US VA) trunks using IPs 54.172.60.0-3, 4 inbound (US OR) trunks using IPs 54.244.51.0-3, and 5 (1 master + 4 subaccount) outbound Twilio trunks using FQDN termination sip uri. A few of the outbound trunks were alphabetically ordered before the inbound trunks. I renamed all outbound trunks, starting with a ‘z’ so that FreePBX would put the outbound Twilio trunks at the end of the configuration file. That did the trick and resolved the inbound ‘failed’ calls.