Twilio Inbound Suddenly stops working

Hmm - this is interesting - why would it be matching a peer that is only configured for Outbound? The Twilio-DID[1-4] trunks are configured for Outbound calls and have NO incoming peer settings.

Also - these have been in place since day 1 and never caused an issue, wonder if a module update caused some changes to how these peers are handled on inbound routes?

It seems that it is only checking trunks that are configured for Outgoing and none of my incoming trunks - any way to change this behavior?

for inbound

instead of debugging everything (sip set debug on) try an explicit:-

sip set debug ip ip.for.your.region

if there is no traffic there on an inbound call , call Twilio or check your routers

All of that traffic output above was specific to a singular inbound call.

I have identified that the incoming call is matching a trunk that has no incoming User Context Peer details.

This is per the Twilio Interconnection guide though. I set it up exactly as they recommend.

Yet you said that twilio sends inbound calls on “ip.for.your.region” I guess they lied, add inbound trunks or add inbound settings for all your outbound trunks to cover.

I get what you’re saying - I had thought to do that as well, but this seems to be a flaw with Asterisk, why would it check the source IP of an incoming SIP connection against trunks with only OUTGOING settings defined?

It doesn’t :wink:

generally all Twilio traffic will be on

54.172.60.0/23

so

tcpdump -nnvv net 54.172.60.0/23

might be interesting, you can capture all that stuff and wireshark it if you prefer guis

Here is some junk from tcpdump

23:04:00.668914 IP (tos 0x10, ttl 35, id 61624, offset 0, flags [DF], proto UDP (17), length 1465)
54.172.60.0.5060 > 10.251.14.186.5060: [udp sum ok] SIP, length: 1437
INVITE sip:[email protected] SIP/2.0
Record-Route: sip:54.172.60.0:5060;lr;ftag=03636896_6772d868_0b7fbbd3-eb17-4a75-9ec2-2cb4f7df9975
From: sip:[email protected];tag=03636896_6772d868_0b7fbbd3-eb17-4a75-9ec2-2cb4f7df9975
To: sip:[email protected];user=phone
CSeq: 31073 INVITE
Max-Forwards: 61
Accept: application/sdp,application/isup,application/dtmf,application/dtmf-relay,multipart/mixed
P-Asserted-Identity: sip:[email protected]:5060
Content-Disposition: session;handling=required
Diversion: sip:[email protected];reason=unconditional
Call-ID: [email protected]
Via: SIP/2.0/UDP 54.172.60.0:5060;branch=z9hG4bK8d2e.6d812a91.0
Via: SIP/2.0/UDP 172.18.5.96:5060;branch=z9hG4bK0b7fbbd3-eb17-4a75-9ec2-2cb4f7df9975_6772d868_1763044002874572
Contact: sip:[email protected]:5060;transport=udp
Allow: INVITE,ACK,CANCEL,BYE,UPDATE,OPTIONS
User-Agent: Twilio Gateway
X-Twilio-AccountSid: ACe8281c857a15388463f36c20ad518e2c
X-Twilio-ApiVersion: 2010-04-01
Content-Type: application/sdp
X-Twilio-CallSid: CAf1b93afe473254c52a40415c31081055
Content-Length: 250

    v=0
    o=- 1091482841 1091482841 IN IP4 54.172.60.115
    s=Twilio Media Gateway
    c=IN IP4 54.172.60.115
    t=0 0
    m=audio 10170 RTP/AVP 0 101
    a=rtpmap:0 PCMU/8000
    a=rtpmap:101 telephone-event/8000
    a=fmtp:101 0-15
    a=sendrecv
    a=maxptime:20
    a=ptime:20

23:04:00.669313 IP (tos 0x60, ttl 64, id 35445, offset 0, flags [none], proto UDP (17), length 760)
10.251.14.186.5060 > 54.172.60.0.5060: [bad udp cksum 65ce!] SIP, length: 732
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 54.172.60.0:5060;branch=z9hG4bK8d2e.6d812a91.0;received=54.172.60.0;rport=5060
Via: SIP/2.0/UDP 172.18.5.96:5060;branch=z9hG4bK0b7fbbd3-eb17-4a75-9ec2-2cb4f7df9975_6772d868_1763044002874572
From: sip:[email protected];tag=03636896_6772d868_0b7fbbd3-eb17-4a75-9ec2-2cb4f7df9975
To: sip:[email protected];user=phone;tag=as2f82089f
Call-ID: [email protected]
CSeq: 31073 INVITE
Server: FPBX-13.0.61.1(13.7.2)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm=“asterisk”, nonce="6d0dbf4f"
Content-Length: 0

23:04:00.748656 IP (tos 0x10, ttl 35, id 61635, offset 0, flags [DF], proto UDP (17), length 449)
54.172.60.0.5060 > 10.251.14.186.5060: [udp sum ok] SIP, length: 421
ACK sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 54.172.60.0:5060;branch=z9hG4bK8d2e.6d812a91.0
From: sip:[email protected];tag=03636896_6772d868_0b7fbbd3-eb17-4a75-9ec2-2cb4f7df9975
Call-ID: [email protected]
To: sip:[email protected];user=phone;tag=as2f82089f
CSeq: 31073 ACK
Max-Forwards: 70
User-Agent: Twilio Gateway
Content-Length: 0

23:04:00.755148 IP (tos 0x10, ttl 37, id 18706, offset 0, flags [DF], proto UDP (17), length 1469)
54.172.60.1.5060 > 10.251.14.186.5060: [udp sum ok] SIP, length: 1441
INVITE sip:[email protected] SIP/2.0
Record-Route: sip:54.172.60.1:5060;lr;ftag=45382281_6772d868_e26a8b64-f80d-4353-a614-2be7183c60a9
From: sip:[email protected];tag=45382281_6772d868_e26a8b64-f80d-4353-a614-2be7183c60a9
To: sip:[email protected];user=phone
CSeq: 31073 INVITE
Max-Forwards: 61
Accept: application/sdp,application/isup,application/dtmf,application/dtmf-relay,multipart/mixed
P-Asserted-Identity: sip:[email protected]:5060
Content-Disposition: session;handling=required
Diversion: sip:[email protected];reason=unconditional
Call-ID: [email protected]
Via: SIP/2.0/UDP 54.172.60.1:5060;branch=z9hG4bK82e1.48771c66.0
Via: SIP/2.0/UDP 172.18.14.147:5060;branch=z9hG4bKe26a8b64-f80d-4353-a614-2be7183c60a9_6772d868_1763057144876588
Contact: sip:[email protected]:5060;transport=udp
Allow: INVITE,ACK,CANCEL,BYE,UPDATE,OPTIONS
User-Agent: Twilio Gateway
X-Twilio-AccountSid: ACe8281c857a15388463f36c20ad518e2c
X-Twilio-ApiVersion: 2010-04-01
Content-Type: application/sdp
X-Twilio-CallSid: CAf1b93afe473254c52a40415c31081055
Content-Length: 250

    v=0
    o=- 1633755016 1633755016 IN IP4 54.172.60.116
    s=Twilio Media Gateway
    c=IN IP4 54.172.60.116
    t=0 0
    m=audio 14560 RTP/AVP 0 101
    a=rtpmap:0 PCMU/8000
    a=rtpmap:101 telephone-event/8000
    a=fmtp:101 0-15
    a=sendrecv
    a=maxptime:20
    a=ptime:20

23:04:00.755427 IP (tos 0x60, ttl 64, id 37247, offset 0, flags [none], proto UDP (17), length 762)
10.251.14.186.5060 > 54.172.60.1.5060: [bad udp cksum ba2c!] SIP, length: 734
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 54.172.60.1:5060;branch=z9hG4bK82e1.48771c66.0;received=54.172.60.1;rport=5060
Via: SIP/2.0/UDP 172.18.14.147:5060;branch=z9hG4bKe26a8b64-f80d-4353-a614-2be7183c60a9_6772d868_1763057144876588
From: sip:[email protected];tag=45382281_6772d868_e26a8b64-f80d-4353-a614-2be7183c60a9
To: sip:[email protected];user=phone;tag=as71a2822d
Call-ID: [email protected]
CSeq: 31073 INVITE
Server: FPBX-13.0.61.1(13.7.2)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm=“asterisk”, nonce="3d68b01b"
Content-Length: 0

23:04:00.827630 IP (tos 0x10, ttl 37, id 18709, offset 0, flags [DF], proto UDP (17), length 449)
54.172.60.1.5060 > 10.251.14.186.5060: [udp sum ok] SIP, length: 421
ACK sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 54.172.60.1:5060;branch=z9hG4bK82e1.48771c66.0
From: sip:[email protected];tag=45382281_6772d868_e26a8b64-f80d-4353-a614-2be7183c60a9
Call-ID: [email protected]
To: sip:[email protected];user=phone;tag=as71a2822d
CSeq: 31073 ACK
Max-Forwards: 70
User-Agent: Twilio Gateway
Content-Length: 0

looks like you need an inbound trunk for that. (54.172.60.1)

That’s the problem - I already do :slightly_smiling:
host=54.172.60.1
insecure=port,invite
type=peer
context=from-trunk

I have an inbound trunk for .0, .1, .2 and .3

Sorry out of ideas, call Twilio

But as you can see from the other logs further up… it’s taking the IP and matching it to my outbound trunks, here is a sample from one of those outgoing peer details that it is matching to :frowning:

username=redacted
type=peer
secret=redacted
host=1pp-did4.pstn.us1.twilio.com
dtmfmode=rfc2833
disallow=all
context=incoming
canreinvite=no
allow=ulaw

do you have a context called incoming?, generally use from-trunk.

I’m not sure, got that from another article about setting up FreePBX with Twilio.

But my incoming trunks are defined with from-trunk

host=54.172.60.1
insecure=port,invite
type=peer
context=from-trunk

You can have trunks that are just incoming or just outgoing or you can set them up to swing both ways, inbound settings need to point the calls to an existing context, not just something arbitrary,. Did you you read the wiki yet. If the trunks are arguing about contexts or hosts, you need to rationalize to only one of anything.

Yes - I am familiar.

I just did a test and disabled by 4 outgoing trunks and now everything works. Except now I have no outgoing routes for my 4 users.

But at least I know for certain it’s those routes that messing everything up… Now to figure out why…

(all in the wiki) . . .

The funny thing causing confusion here is that there is really no such thing as an outgoing-only trunk in Asterisk. FreePBX breaks it down as “outgoing” and “incoming” but it is a bit misleading.

What has happened is that you have effectively defined two SIP trunks (“peers”) with the same host= information. One you have configured by DNS name and the other by IP address, and they are equivalent. When you configure trunks in FreePBX and then click Apply Changes, the SIP Peers are written out to config files and this is what Asterisk actually cares about.

In the config files the peers appear in a certain order. When a call comes in, lacking any other matching information, Asterisk works its way down from top to bottom in its list of peers to find one that matches the host/IP. It uses the first one it finds.

In your case, it found your “outgoing” trunk, and your outgoing trunk did not have insecure=port,invite set, so Asterisk sent a 401 challenge.

I believe the solution here is to review all your “outgoing” Twilio trunks. If they are all the same hosts/IPs as the ones you set up for incoming, do this:

  • Remove your incoming trunks
  • Add insecure=port,invite to the outgoing Twilio trunks, allowing them to receive calls from Twilio
  • properly set the context, or remove the context= line altogether and let FreePBX set the default

Use type=peer for this kind of setup.

1 Like

I know that this can’t possibly be it, but one of my customers suffered from a problem just like this. Tech support looked at there records and everything was configured correctly.

It wasn’t until the customer talked to the billing department did the actual cause become clear.

Just saying it could be something far simpler than a misconfiguration over night, especially since it was over night…

Thank you for this brilliant reply, had I stumbled across something like this, I would have solved my issues a lot sooner!

What I ended up doing is removing my “outgoing” trunks and just left my single/main trunk (Twilio allows any outbound CID, so no need for these additional trunks).

However, after reading your post about the order in which they are written to the file, it would make sense, the whole overnight thing, since I made a trunk config change and it must have changed the order, because the change I made was nothing that should have broken anything.

Thanks again and I really appreciate all the help from you guys!

The actual fix is to rename the inbound and/or outbound trunks so that the inbound trunks appear before the outbound in the sip_additional.conf. FreePBX configures the trunks in the the sip_additional.conf file in alphabetical order while asterisk reads the file from top to bottom. Moreover, with and after Asterisk 1.6, asterisk takes the first trunk having duplicate host IPs (from top to bottom). So if the trunk with the sip termination uri (outbound trunk) matches one of the host IPs in the inbound Twilio trunk and the outbound is listed before the inbound trunk in the sip file, originating calls will fail trying to initially connect to the outbound trunk.

I’ve already submitted the bug report to Twilio so they may fix from their end or at least update the FreePBX interconnection guide.

1 Like