PJSIP Qualify fails where SIP Qualify works

(Greg Snover) #1

Trying to use PJSIP as Chan-SIP is going away - but I have a customer with 15 remote extensions behind a SonicWALL firewall on Comcast - If I set them with PJSIP extensions, about 6 of them eventually go to unreachable and stay that way - if I set them to SIP Extensions, they work perfectly - they stay registered, reachable and functional.

I have the SIP qualify set to 30 Seconds.

(Andrew) #2

Do you have SonicWall rules specific to your SIP port? You will have to update those to include the port bind to PJSIP as well

(Greg Snover) #3

Of course - both ports are open and forwarded - It’s not a firewall thing, I just don’t think the PJSIP qualifies frequently enough. And I can’t see where to adjust that.

(Joshua C. Colp) #4

In Asterisk land it is referred to as the “qualify_frequency”. I don’t know where that is in FreePBX or what it is called. Otherwise you’d need to show a log.

(Andrew) #5

It’s in the GUI for PJSIP extensions, field is called Qualify Frequency. Otherwise, /etc/asterisk/pjsip.aor.conf stores that setting per extension.


The default UDP timeout for SonicWall is 30 seconds, way too short. Set this to 300 seconds; see
Also see
Set the registration expiry in the phones to 120, so registrations alone will keep the NAT association alive, even without qualify. Also, if for some reason the NAT association is lost, it will be reestablished in no more than two minutes.

If the SonicWall doesn’t have a public IP address on its WAN interface (the Comcast modem is configured as a gateway), put the modem in bridge mode.

(Greg Snover) #7

It most certainly is - Sorry I missed that - I will experiment!


What do you mean by that? If there are 15 phones on the same public IP address, then the SoncWall will assign 15 different source ports. Forwarding any of these should not be required (and in general is not useful), because incoming calls should appear as ‘replies’ to the REGISTER requests and be automatically routed to the proper phone.

(Greg Snover) #9

Didn’t open any ports at the remote site - I meant that the two ports for PJSIP and SIP were open on the Firewall that the PBX is behind (Also a SonicWALL) - Phones registering to it from the remote site force a connection to the PBX and the qualify keeps it open (or is supposed to…)


That is not robust; a momentary internet outage, Asterisk restart, etc. would cause the connection to be closed.

With the default 30 second UDP timeout on SonicWALL and 30 second qualify interval, slight timing variations will lose the connection. And you should allow for occasional loss anyhow, by using a short registration interval to ensure that any outage is brief.

(Luke C) #11

Had the same problem with a SonicWall with remote endpoints, after switching to Chan-Sip, still had problems with NAT. Finally threw the SonicWall in the trash, I then recouped some sanity after moving to a Firebox at the remote location.

(Andrew) #12

Normally with SonicWall I create a LAN > WAN rule with an address group containing all the phones (IP range, MAC addresses, whatever’s clever) as the source and the external phone server as the destination. That way you can set UDP timeout specifically for the phones, BWM, etc.