Yes .
I wrote a patch for asterisk called remove_unavailable that will solve this problem more elegantly than remove_existing, if you are using the newer versions of asterisk (I think 16.21 and 18.5).
IMHO it should be the FreePBX default setting to have remove_unavailable enabled. The use case for having unavailable contacts persisting to the point that they block new registrations is very limited, and out of scope for most FreePBX users.
Has this patch been accepted?
This link is the patch for 16
This link is the patch for 18.
Merged and accepted into 16, 18, 19 and master. Check the changelog for the actual release that this showed up. I think for 16 is was 16.22, and for 18 is was 18.8 (correcting what I said before)
Iām running 18.11.0
So replace remove_existing in your instructions above with remove_unavailable.
Done.
Whatās a good way to test this?
This test will depend on how your NAT router does port address translation. But it works most of the time.
So you have a desk phone and a soft phone.
Plug in the desk phone, wait for it to register. Change the desk phoneās internal IP address and reboot. The NAT router will assign a different port for this session, and it will now appear as a second registration. The original registration will appear as unavailable (this can all be verified in the Asterisk Info tab). Keep doing this up to the setting of max contacts. With the setting remove_unavailable disabled, at some point your phone will stop registering because you hit the limit. With the setting enabled, the unavailable contacts will get bumped off for the new registration.
You need to wait long enough for the qualify to fail on it.
@Vietyank are you sure this wouldnāt be resolved if you just set GS Wave to unregister before new registration (the configuration I suggested)?
The issue seems to be that your location changes frequently and so your softphone fills up the registration table with a bunch of stale contacts. Why have Asterisk deal with this behavior rather than have the phone clean up after itself?
Itās funny how I see it the opposite way. Asterisk should be cleaning up stale contacts to favor new registrations from valid ones. Itās not the phoneās job to clean up asteriskās mess.
Besides, Iām not sure your way would work. The unregister will come from a different source address that asterisk cannot tie to the stale contact.
1 Like
This isnāt Asteriskās mess. A phone using random SIP ports on its requests from behind NAT is an issue with the phone not Asterisk. So yeah, Asterisk is cleaning up the mess of a poorly configured device. Sorry but a phone sending a new REGISTER every minute with randomized contact information is problematic on any platform, not just Asterisk. A single device can take up all the contacts allowed like this.
Additionally, it takes time for a contact to go from Available ā Unreachable ā Unavailable. There are at least 7 attempts to make an endpoint Available when it reaches an Unreachable state. That can take a minute or so during which time old contacts can expire and clear out.
I mean, I canāt view this feature as nothing more than a fix to clean up a bad phone and/or network configuration that isnāt an Asterisk problem.
That works for the softphone but there.is no such setting for the Yealink that I can find
Why would you need this setting for the Yealink? Doesnt it sit on your desk and maintain the same IP address for long stretches of time?
Well some firewalls, like pfsense, have port randomizers. That doesnt help either.
Actually it does. Good point.
Thatās not usually why this is happening.
Your two comments contradict and point out exactly what Iām trying to say. A device that gets a different address from DHCP will be given a different outbound port due to PAT. And some devices (yes SonicWALL) will close UDP sessions randomly and use a new port. With the default expiration of 3600 this has caused me much grief until remove_unavailable completely made this problem go away.
A single qualify fail is enough to trigger being bumped off with a new registration. Remember, we are rejecting a KNOWN GOOD endpoint in favor of one that is probably offline. If in fact this assumption is wrong, (i.e. both contacts are valid) and weāve exceeded max_contacts, then weāre screwed anyway, so why do we prefer endpoint 1 over endpoint 2?
The old contacts donāt expire until the registration does. It just gets stuck Unavailable. Thatās the asinine default behavior of PJSIPā¦ Reject good registrations so we donāt lose the useless unavailable contact.
Your softphone setting works. So does the Asterisk directive. I donāt suppose thereās anything wrong with using both
No, they actually donāt. IP devices have port randomizers that cause issues, even when they donāt or it is off, the firewall can do it and cause issues.
You really need to work on your DHCP server and/or network. If your devices are being assigned new IPs when requesting a DHCP lease (refresh or not) then youāve got other issues that you need to take care of.
Well, gonna be honest here, āKNOWN GOODā is subjective in this case. What makes it āKNOWN GOODā? How are you validating that? Proper details in the SIP headers? Proper User Agent? All that is actually known is a new REGISTER has been sent and that is that. For all you know it could be a rogue device connecting and doing bad things.
This is starting to sound like you had some bad experiences with poor clients and networks which made you believe this setting was more beneficial than it will turn out to be.