Asterisk not responding to PJSIP packets

A sudden issue on a working system:

PJSIP endpoints register momentarily, then drop off as Unreachable. SNGREP shows all inbound packets to Asterisk flowing correctly, but Asterisk not sending and responses to those packets. All REGISTER, NOTIFY, OPTIONS just fall on deaf ears. However, outbound REGISTER packets from Asterisk to trunk providers complete successfully, so Asterisk can communicate out.

A test device in my office seems not to encounter this problem, only the customer’s site. But the internet is up and fast, and I was actually on-site for a different issue when the problem started. No new router, switch, config changes, etc…

Weird, what could it be?

Suspect that iptables is blocking your external sites.

iptables -L -n 

Do you see your network in there?

This smacks of firewall, since SNGREP can see what’s happening on the ethernet port (since it’s in promiscuous mode) and the program can’t (because the firewall is behind promiscuous mode). To double check, look at the /var/log/asterisk/full log and see if you see anything in there about incoming traffic from that site.

I should have said, I disabled fail2ban, the firewall module, and flushed iptables with iptables -F

Either way, please post the ‘issue’ of `iptables -L -n’

-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N fail2ban-BadBots
-N fail2ban-FTP
-N fail2ban-PBX-GUI
-N fail2ban-SIP
-N fail2ban-SSH
-N fail2ban-apache-auth
-N fail2ban-recidive
-A INPUT -j fail2ban-recidive
-A INPUT -p tcp -m multiport --dports 80,443 -j fail2ban-BadBots
-A INPUT -p tcp -m tcp --dport 21 -j fail2ban-FTP
-A INPUT -p tcp -j fail2ban-apache-auth
-A INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSH
-A INPUT -j fail2ban-PBX-GUI
-A INPUT -j fail2ban-SIP
-A fail2ban-BadBots -j RETURN
-A fail2ban-FTP -j RETURN
-A fail2ban-PBX-GUI -j RETURN
-A fail2ban-SIP -j RETURN
-A fail2ban-SSH -j RETURN
-A fail2ban-apache-auth -j RETURN
-A fail2ban-recidive -j RETURN

Then you haven’t successfully fully stopped fail2ban

fail2ban-client stop

try over

I restarted… But there’s clearly nothing in the jail.
Everything is off now:
-P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT

As an interesting addendum, I’m seeing Asterisk sending a huge amount of OPTIONS packets to the correct IP at a whole bunch of random ports.

pjsip show contacts has 2 unavailable contacts, it seems Asterisk still thinks there are endpoints behind those ports?!

Not really, asterisk has been told that to expect that ‘contact’ to reappear because you have it programmed, when and if it does it should reply to the OPTION it will send to the ‘last known’ address , if you don’t expect them to reappear, delete them. If you do, get the network/firewalls/routing/NAT fixed and make sure they are plugged in and all will be good again after they re-register

I deltreed the registrar/contact from console and this is still happening:

OPTIONS    [email protected]          [email protected]         11    1.2.3.4:5060     5.6.7.8:56477
OPTIONS    [email protected]          [email protected]         11    1.2.3.4:5060     5.6.7.8:56633
OPTIONS    [email protected]          [email protected]         11    1.2.3.4:5060     5.6.7.8:49377
OPTIONS    [email protected]          [email protected]         11    1.2.3.4:5060     5.6.7.8:55632
OPTIONS    [email protected]          [email protected]         11    1.2.3.4:5060     5.6.7.8:34257
OPTIONS    [email protected]          [email protected]         11    1.2.3.4:5060     5.6.7.8:41561
OPTIONS    [email protected]          [email protected]         11    1.2.3.4:5060     5.6.7.8:17946
OPTIONS    [email protected]          [email protected]         11    1.2.3.4:5060     5.6.7.8:15072
OPTIONS    [email protected]          [email protected]         11    1.2.3.4:5060     5.6.7.8:53975
OPTIONS    [email protected]          [email protected]         11    1.2.3.4:5060     5.6.7.8:21309
OPTIONS    [email protected]          [email protected]         11    1.2.3.4:5060     5.6.7.8:41561
OPTIONS    [email protected]          [email protected]         11    1.2.3.4:5060     5.6.7.8:46380
OPTIONS    [email protected]          [email protected]         11    1.2.3.4:5060     5.6.7.8:37843
OPTIONS    [email protected]          [email protected]         11    1.2.3.4:5060     5.6.7.8:53975
OPTIONS    [email protected]          [email protected]         11    1.2.3.4:5060     5.6.7.8:14113
OPTIONS    [email protected]          [email protected]         11    1.2.3.4:5060     5.6.7.8:16609

But the current contacts are:

Contact:  101/sip:[email protected]:37843;x-ast-orig 14a2e99e56 Unavail         nan
Contact:  101/sip:[email protected]:21309;x-ast-orig 340a89e649 Unavail         nan
Contact:  101/sip:[email protected]:53975;x-ast-orig bd7d8c4190 Unavail         nan

Sorry but there is nothing here to connect anything to anything else. all we know is 101 is not available

The phones are behind NAT. Lets use 101 as example (I pasted 102 by mistake).

The 3 devices registered and Asterisk accepted the registration. But then look at the ports asterisk is sending to - 3 of them are correct but the other 4 are not. There are stale entries that may be causing Asterisk to think the devices have timed out.

Just wait for the devices to re-register until then 'how will anything know"

Still waiting, same issue, about 4 hours since beginning of outage.
Doesn’t seem like waiting removes the rogue entries. I’m not sure anyway if that’s the source of my problem.

If they are not registering after 4 hours you have a problem , there is no point waiting for them much past the re-register timeout (usually 120 seconds) you probably have an underlying network/routing problem, but with sngrep you can drill down and possibly identify the culprit by any IP rewrites.

They reregister, then drop to Unreachable… probably because outbound Options are not coming back.
I’m beginning to suspect something like SIP ALG, but like I said it was working and suddenly stopped.

I’ll post back if I figure this out.

No, nothing to do with OPTIONS not coming back, just the Network . . .

Reset router on internal network = no good
Replace router in internal network = fixed

Lesson learned today: Sometimes bad equipment doesn’t completely fail, it just does weird stuff.

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.