Twilio Inbound Suddenly stops working

Aside from the insecure param, I set it up exactly as their guide shows, as you can see here: screencast DOT com/t/cvVBZNObmcU

Another debugging tool that will be useful to you is the SIP debug output.

Go to the asterisk console and turn up verbose and SIP debug:

pbx*CLI> core set verbose 9 pbx*CLI> sip set debug on

then test your inbound call and review the logged information. Don’t forget to turn the debugger back off or you will have large log files.

pbx*CLI> sip set debug off

That was very helpful, thank you - hopefully some of this makes sense to you:

<— SIP read from UDP:54.172.60.0:5060 —>
INVITE sip:[email protected] SIP/2.0
Record-Route: sip:54.172.60.0:5060;lr;ftag=07806895_6772d868_880c190f-6d95-4e0b-9a2f-4bdd30c0dcbd
From: sip:[email protected];tag=07806895_6772d868_880c190f-6d95-4e0b-9a2f-4bdd30c0dcbd
To: sip:[email protected];user=phone
CSeq: 10671 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=z9hG4bK1885.27995573.0
Via: SIP/2.0/UDP 172.18.12.238:5060;branch=z9hG4bK880c190f-6d95-4e0b-9a2f-4bdd30c0dcbd_6772d868_1759432507970079
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: CA882c85f5006eb8a853241caa42972b2e
Content-Length: 248

v=0
o=- 297680592 297680592 IN IP4 54.172.60.107
s=Twilio Media Gateway
c=IN IP4 54.172.60.107
t=0 0
m=audio 14180 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
<------------->
— (21 headers 12 lines) —
Sending to 54.172.60.0:5060 (NAT)
Sending to 54.172.60.0:5060 (NAT)
Using INVITE request as basis request - [email protected]
Found peer ‘Twilio-DID2’ for ‘+18584494633’ from 54.172.60.0:5060

<— Reliably Transmitting (NAT) to 54.172.60.0:5060 —>
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 54.172.60.0:5060;branch=z9hG4bK1885.27995573.0;received=54.172.60.0;rport=5060
Via: SIP/2.0/UDP 172.18.12.238:5060;branch=z9hG4bK880c190f-6d95-4e0b-9a2f-4bdd30c0dcbd_6772d868_1759432507970079
From: sip:[email protected];tag=07806895_6772d868_880c190f-6d95-4e0b-9a2f-4bdd30c0dcbd
To: sip:[email protected];user=phone;tag=as6eb0a430
Call-ID: [email protected]
CSeq: 10671 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="07943769"
Content-Length: 0

<------------>
Scheduling destruction of SIP dialog ‘[email protected]’ in 32000 ms (Method: INVITE)

<— SIP read from UDP:54.172.60.0:5060 —>
ACK sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 54.172.60.0:5060;branch=z9hG4bK1885.27995573.0
From: sip:[email protected];tag=07806895_6772d868_880c190f-6d95-4e0b-9a2f-4bdd30c0dcbd
Call-ID: [email protected]
To: sip:[email protected];user=phone;tag=as6eb0a430
CSeq: 10671 ACK
Max-Forwards: 70
User-Agent: Twilio Gateway
Content-Length: 0

<------------->
— (9 headers 0 lines) —

<— SIP read from UDP:54.172.60.1:5060 —>
INVITE sip:[email protected] SIP/2.0
Record-Route: sip:54.172.60.1:5060;lr;ftag=77775662_6772d868_e34c4dde-a6a9-4e25-a605-52ef420ef0ba
From: sip:[email protected];tag=77775662_6772d868_e34c4dde-a6a9-4e25-a605-52ef420ef0ba
To: sip:[email protected];user=phone
CSeq: 10671 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=z9hG4bK871f.b22a5ea1.0
Via: SIP/2.0/UDP 172.18.20.158:5060;branch=z9hG4bKe34c4dde-a6a9-4e25-a605-52ef420ef0ba_6772d868_1759423577477287
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: CA882c85f5006eb8a853241caa42972b2e
Content-Length: 250

v=0
o=- 1121804728 1121804728 IN IP4 54.172.60.108
s=Twilio Media Gateway
c=IN IP4 54.172.60.108
t=0 0
m=audio 10850 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
<------------->
— (21 headers 12 lines) —
Sending to 54.172.60.1:5060 (NAT)
Sending to 54.172.60.1:5060 (NAT)
Using INVITE request as basis request - [email protected]
Found peer ‘Twilio-DID1’ for ‘+18584494633’ from 54.172.60.1:5060

<— Reliably Transmitting (NAT) to 54.172.60.1:5060 —>
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 54.172.60.1:5060;branch=z9hG4bK871f.b22a5ea1.0;received=54.172.60.1;rport=5060
Via: SIP/2.0/UDP 172.18.20.158:5060;branch=z9hG4bKe34c4dde-a6a9-4e25-a605-52ef420ef0ba_6772d868_1759423577477287
From: sip:[email protected];tag=77775662_6772d868_e34c4dde-a6a9-4e25-a605-52ef420ef0ba
To: sip:[email protected];user=phone;tag=as20f1440a
Call-ID: [email protected]
CSeq: 10671 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="4370b110"
Content-Length: 0

<------------>
Scheduling destruction of SIP dialog ‘[email protected]’ in 32000 ms (Method: INVITE)

<— SIP read from UDP:54.172.60.1:5060 —>
ACK sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 54.172.60.1:5060;branch=z9hG4bK871f.b22a5ea1.0
From: sip:[email protected];tag=77775662_6772d868_e34c4dde-a6a9-4e25-a605-52ef420ef0ba
Call-ID: [email protected]
To: sip:[email protected];user=phone;tag=as20f1440a
CSeq: 10671 ACK
Max-Forwards: 70
User-Agent: Twilio Gateway
Content-Length: 0

<------------->
— (9 headers 0 lines) —

<— SIP read from UDP:54.172.60.2:5060 —>
INVITE sip:[email protected] SIP/2.0
Record-Route: sip:54.172.60.2:5060;lr;ftag=05624185_6772d868_9abbe9d4-bd8b-417c-bd0b-377dee05d5a3
From: sip:[email protected];tag=05624185_6772d868_9abbe9d4-bd8b-417c-bd0b-377dee05d5a3
To: sip:[email protected];user=phone
CSeq: 10671 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.2:5060;branch=z9hG4bK92e4.5716d602.0
Via: SIP/2.0/UDP 172.18.3.254:5060;branch=z9hG4bK9abbe9d4-bd8b-417c-bd0b-377dee05d5a3_6772d868_1759444306188282
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: CA882c85f5006eb8a853241caa42972b2e
Content-Length: 248

v=0
o=- 1440637182 1440637182 IN IP4 54.172.60.72
s=Twilio Media Gateway
c=IN IP4 54.172.60.72
t=0 0
m=audio 19360 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
<------------->
— (21 headers 12 lines) —
Sending to 54.172.60.2:5060 (NAT)
Sending to 54.172.60.2:5060 (NAT)
Using INVITE request as basis request - [email protected]
Found peer ‘Twilio-DID4’ for ‘+18584494633’ from 54.172.60.2:5060

<— Reliably Transmitting (NAT) to 54.172.60.2:5060 —>
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 54.172.60.2:5060;branch=z9hG4bK92e4.5716d602.0;received=54.172.60.2;rport=5060
Via: SIP/2.0/UDP 172.18.3.254:5060;branch=z9hG4bK9abbe9d4-bd8b-417c-bd0b-377dee05d5a3_6772d868_1759444306188282
From: sip:[email protected];tag=05624185_6772d868_9abbe9d4-bd8b-417c-bd0b-377dee05d5a3
To: sip:[email protected];user=phone;tag=as53e00658
Call-ID: [email protected]
CSeq: 10671 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="77e6bf23"
Content-Length: 0

<------------>
Scheduling destruction of SIP dialog ‘[email protected]’ in 32000 ms (Method: INVITE)

<— SIP read from UDP:54.172.60.2:5060 —>
ACK sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 54.172.60.2:5060;branch=z9hG4bK92e4.5716d602.0
From: sip:[email protected];tag=05624185_6772d868_9abbe9d4-bd8b-417c-bd0b-377dee05d5a3
Call-ID: [email protected]
To: sip:[email protected];user=phone;tag=as53e00658
CSeq: 10671 ACK
Max-Forwards: 70
User-Agent: Twilio Gateway
Content-Length: 0

<------------->

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