Extensions go unreachable, then reachable

FreePBX Endpoints
1

Have about 400 extensions behind a SonicWall; we have no control over the SonicWall. For 3 months everything was fine. Starting 2 weeks ago, extensions will randomly go unreachable, then again reachable:

[2024-02-13 20:43:27] VERBOSE[1684] res_pjsip/pjsip_options.c: Contact 4413/sip:[email protected]:58675;transport=TCP;x-ast-orig-host=192.168.20.15:5082 is now Reachable. RTT: 37.338 msec
[2024-02-13 20:42:30] VERBOSE[15226] res_pjsip/pjsip_options.c: Contact 4413/sip:[email protected]:58675;transport=TCP;x-ast-orig-host=192.168.20.15:5082 is now Unreachable. RTT: 0.000 msec
[2024-02-13 20:38:27] VERBOSE[18955] res_pjsip/pjsip_options.c: Contact 4413/sip:[email protected]:58675;transport=TCP;x-ast-orig-host=192.168.20.15:5082 is now Reachable. RTT: 38.635 msec
[2024-02-13 20:37:30] VERBOSE[15226] res_pjsip/pjsip_options.c: Contact 4413/sip:[email protected]:58675;transport=TCP;x-ast-orig-host=192.168.20.15:5082 is now Unreachable. RTT: 0.000 msec
[2024-02-13 20:35:27] VERBOSE[1684] res_pjsip/pjsip_options.c: Contact 4413/sip:[email protected]:58675;transport=TCP;x-ast-orig-host=192.168.20.15:5082 is now Reachable. RTT: 38.803 msec
[2024-02-13 20:34:30] VERBOSE[1872] res_pjsip/pjsip_options.c: Contact 4413/sip:[email protected]:58675;transport=TCP;x-ast-orig-host=192.168.20.15:5082 is now Unreachable. RTT: 0.000 msec

50 Yealink phones and 350 extensions across multiple Grandstream ATA’s. Complaints are from both Yealink and Grandstream users.

SIP is PJSIP over TCP. Server is FreePBX v16 hosted in AWS. Asterisk is ver 18.9.

I have been told that today the network admin changed the UDP timeout on the SonicWall from 30 to 90 secs, but we are still getting the same issue. Customer is certain our phone server is to blame.

Not sure where to look for answers.

We have many clients and locations, and only this client, this location has issues. I believe it to be the SonicWall blocking traffic.

What is my best course of action?

2

You’re using TCP, what does the UDP timeout have to do with anything for this? Have you done a basic PCAP capture to see how the OPTIONS leaving the PBX are getting proper responses from the endpoint? Unreachable means Asterisk tried to qualify/keep-alive the endpoint and didn’t get a response at all or within the expected reply timeout.

3

I thought that NAT KeepAlive messages were UDP.

4

Nope they go over the signalling transport you have opted to use. So you’re using TCP, just like INVITEs, NOTIFY’s or any other SIP message it will be sent over TCP. The only thing that is purely UDP is the media/SDP.

5

Here is a PCAP trace from a 401 Unauthorized event. Is my FreePBX server at 34.216.999.239 issuing the 401 or is the Sonicwall at 72.9.39.34 issuing the 401

It seems to me the originator of the 401 Unauthorized is the culprit??

NOTIFY sip:34.216.99.239:5777 SIP/2.0
Via: SIP/2.0/TCP 192.168.20.152:5084;branch=z9hG4bK1804170060;rport;alias
From: sip:[email protected]:5777;tag=1261306564
To: sip:34.216.99.239:5777
Call-ID: [email protected]
CSeq: 213130 NOTIFY
Contact: sip:[email protected]:5084;transport=tcp
Max-Forwards: 70
User-Agent: Grandstream GXW4248 V1.2A 1.0.7.7
Supported: replaces, path, timer, eventlist
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE
Content-Length: 0

SIP/2.0 401 Unauthorized
Via: SIP/2.0/TCP 192.168.20.152:5084;rport=22829;received=72.9.39.34;branch=z9hG4bK1804170060;alias
Call-ID: [email protected]
From: sip:[email protected];tag=1261306564
To: sip:34.216.99.239;tag=z9hG4bK1804170060
CSeq: 213130 NOTIFY
WWW-Authenticate: Digest realm=“asterisk”,nonce=“1707918368/fddf25435ef11e23ce17df23661d49dc”,opaque=“07b9b4a94ee87216”,algorithm=md5,qop=“auth”
Server: FPBX-16.0.40.7(18.9)
Content-Length: 0

NOTIFY sip:34.216.99.239:5777 SIP/2.0
Via: SIP/2.0/TCP 192.168.20.152:5084;branch=z9hG4bK1990839523;rport;alias
From: sip:[email protected]:5777;tag=1261306564
To: sip:34.216.99.239:5777
Call-ID: [email protected]
CSeq: 213131 NOTIFY
Contact: sip:[email protected]:5084;transport=tcp
Authorization: Digest username=“2106”, realm=“asterisk”, nonce=“1707918368/fddf25435ef11e23ce17df23661d49dc”, uri=“sip:34.216.99.239:5777”, response=“b54bd033df531a884ba37b5b37beb84c”, algorithm=md5, cnonce=“15425897”, opaque=“07b9b4a94ee87216”, qop=auth, nc=00000001
Max-Forwards: 70
User-Agent: Grandstream GXW4248 V1.2A 1.0.7.7
Supported: replaces, path, timer, eventlist
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE
Content-Length: 0

SIP/2.0 501 Not Implemented
Via: SIP/2.0/TCP 192.168.20.152:5084;rport=22829;received=72.9.39.34;branch=z9hG4bK1990839523;alias
Call-ID: [email protected]
From: sip:[email protected];tag=1261306564
To: sip:34.216.99.239;tag=z9hG4bK1990839523
CSeq: 213131 NOTIFY
Server: FPBX-16.0.40.7(18.9)
Content-Length: 0

6

Asterisk doesn’t accept NOTIFYs for a keepalive. Update the Grandstream configs to send keepalives as an OPTIONS message.

However, I was referring as Asterisk sending to the Grandstream. You’re showing Grandstream to Asterisk. The endpoint going unreachable in Asterisk is because Asterisk sent an OPTIONS based keepalive to the Grandstream and it either A) didn’t get a response or B) didn’t get a response before timeout.

7

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