Twilio Inbound Suddenly stops working

Had everything set up and working and suddenly over night, inbound calls are not working.

In the Asterisk CLI, if I show channels, I see tons of channels created when I call in, when I view the history for one channel, I can see it’s giving a 401 unauthorized on the INVITE. This seems like it shouldn’t be doing that though and hasn’t been a problem previously.

Any ideas? I’m sort of a newb at all this so any troubleshooting advice is appreciated.

Thanks!

I would honestly contact twillio and say you are getting back a 401. They may be able to tell you why they are sending that.

Thanks, I have done this but their support response is slow unless we shell out $500/mo!!

I figured this was our server saying 401 unauthorized, but it’s theirs?

Hi!

How are you auhentifying to their server, with a registration string or by IP?

If by IP, could your IP have been changed overnight?

If it costs so much to actually have service from them maybe it’s time to switch to another provider?

(or providers, I am using 4…)

Good luck and have a nice day!

Nick

Authentication with Twilio is very simple for Inbound, you just register your IP with the SIP trunk and setup 4 inbound trunks with: host=ip.for.your.region type=peer and context=from-trunk

This has been working - so that is what is so strange.

I thought maybe my Asterisk was corrupt, so I did asterisk-version-switch and it went through the process of updating to the latest minor version, the problem still exists though.

Have you checked if your IP is still the one you think it is?

Unless you are running your own mail or web services your IP could have been changed overnight by your ISP and you would not know because everything would seem to be fine (except for the PBX of course).

Good luck and have a nice day!

Nick

If the only authentication is the IP address, then your settings also need to include insecure=port,invite

Perhaps this is the 401 you are seeing–your Asterisk server is challenging the incoming call for additional authentication.

Tried this, no difference,

This is what I see when I show history on one of the channels

  • SIP Call
  1. Rx INVITE / 24596 INVITE / sip:[email protected]
  2. AuthChal Auth challenge sent for - nc 0
  3. TxRespRel SIP/2.0 / 24596 INVITE - 401 Unauthorized
  4. SchedDestroy 32000 ms
  5. Rx ACK / 24596 ACK / sip:[email protected]

Is this the host= value in one of the trunks you set up?

thats my server’s ip address

The Asterisk log would be a more straightforward way of seeing what is happening. With sufficient verbosity it will tell you where the call is coming from and what peer it matches to if any.

Using the Asterisk Logfile Settings in the UI, I tried setting verbose to “On” and it didn’t stick, I then tried a setting of 1 and it didn’t log much, I tried a setting of 20 and it logged more, but still nothing about the calls…

What am I missing here?

I added security logging however and now I see hundreds of these when I try to place a call

SecurityEvent=“ChallengeSent”,EventTV=“2016-02-09T19:30:38.990-0600”,Severity=“Informational”,Service=“SIP”,EventVersion=“1”,AccountID="sip:[email protected]",SessionID=“0x3295998”,LocalAddress=“IPV4/UDP/54.176.53.224/5060”,RemoteAddress=“IPV4/UDP/54.172.60.3/5060”,Challenge=“667b2e04”
[2016-02-09 19:30:39] SECURITY[2069]
res_security_log.c:
SecurityEvent=“ChallengeSent”,EventTV=“2016-02-09T19:30:39.083-0600”,Severity=“Informational”,Service=“SIP”,EventVersion=“1”,AccountID="sip:[email protected]",SessionID=“0x30daa78”,LocalAddress=“IPV4/UDP/54.176.53.224/5060”,RemoteAddress=“IPV4/UDP/54.172.60.2/5060”,Challenge=“2d048402”
[2016-02-09 19:30:39] SECURITY[2069]
res_security_log.c:
SecurityEvent=“ChallengeSent”,EventTV=“2016-02-09T19:30:39.164-0600”,Severity=“Informational”,Service=“SIP”,EventVersion=“1”,AccountID="sip:[email protected]",SessionID=“0x30dbf78”,LocalAddress=“IPV4/UDP/54.176.53.224/5060”,RemoteAddress=“IPV4/UDP/54.172.60.0/5060”,Challenge=“0e04daae”
[2016-02-09 19:30:39] SECURITY[2069]
res_security_log.c:
SecurityEvent=“ChallengeSent”,EventTV=“2016-02-09T19:30:39.801-0600”,Severity=“Informational”,Service=“SIP”,EventVersion=“1”,AccountID="sip:[email protected]",SessionID=“0x320afe8”,LocalAddress=“IPV4/UDP/54.176.53.224/5060”,RemoteAddress=“IPV4/UDP/54.172.60.3/5060”,Challenge=“1d2878bb”
[2016-02-09 19:30:39] SECURITY[2069]
res_security_log.c:
SecurityEvent=“ChallengeSent”,EventTV=“2016-02-09T19:30:39.884-0600”,Severity=“Informational”,Service=“SIP”,EventVersion=“1”,AccountID="sip:[email protected]",SessionID=“0x320c4e8”,LocalAddress=“IPV4/UDP/54.176.53.224/5060”,RemoteAddress=“IPV4/UDP/54.172.60.0/5060”,Challenge=“21ca39fd”
[2016-02-09 19:30:39] SECURITY[2069]
res_security_log.c:
SecurityEvent=“ChallengeSent”,EventTV=“2016-02-09T19:30:39.976-0600”,Severity=“Informational”,Service=“SIP”,EventVersion=“1”,AccountID="sip:[email protected]",SessionID=“0x30bbb58”,LocalAddress=“IPV4/UDP/54.176.53.224/5060”,RemoteAddress=“IPV4/UDP/54.172.60.2/5060”,Challenge=“62c17f87”
[2016-02-09 19:30:40] SECURITY[2069]
res_security_log.c:
SecurityEvent=“ChallengeSent”,EventTV=“2016-02-09T19:30:40.055-0600”,Severity=“Informational”,Service=“SIP”,EventVersion=“1”,AccountID="sip:[email protected]",SessionID=“0x30bd058”,LocalAddress=“IPV4/UDP/54.176.53.224/5060”,RemoteAddress=“IPV4/UDP/54.172.60.2/5060”,Challenge=“7e5fb319”

It looks like Twilio’s proxies are trying to connect to you from various addresses, trying to get through.

Do you have trunks defined (including with insecure=port,invite) for each of:

host=54.172.60.2
host=54.172.60.0
host=54.172.60.3

Yes - I followed their interconnection guide for FreePBX and it has worked for nearly 2 weeks, then randomly stopped working seemingly overnight.

www DOT twilio.com/resources/images/docs/UsingFreePBXwithTwilioElasticSIPTrunking-06152015.pdf

I have a separate trunk for 54.172.60.0, .1, .2 and .3

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