Max_contacts, remove_existing, and unavailable contacts

This is really an Asterisk issue, but because this first appeared in these forums recently I’m posting this here.

The default behavior in FreePBX is when max_contacts for a PJSIP endpoint is set greater than 1, remove_existing is set to no. This will ensure that the first endpoints to register to a particular endpoint will not be overwritten by subsequent registrations that exceed max_contacts.

I have run into a problem several times now, especially when my endpoints are behind SonicWALL routers, that the external port for the device will change aggressively, the device will reregister on that new port, and therefore max_contacts will be hit. The funny thing is that all of the existing contacts preventing the registration will not QUALIFY and are UNAVAILABLE. This seems incorrect to me; if a device is attempting to register, and there are no available contact slots, we should remove an unavailable contact to make room for the registration.

I have submitted a patch to Asterisk to change this behavior, but the developers disagree that this patch is needed or correct.

I’m posting this here so if anyone is interested in seeing that this patch is either merged or discarded should comment on the JIRA issue here:

[ASTERISK-29525] PJSIP remove_existing unavailable contacts - Digium/Asterisk JIRA

Your feedback will be appreciated.

Sorry, but I agree with the developers.

This situation is problematic regardless of pjsip behavior. If a registration will have a ‘new’ source port, that means that the previous NAT association has timed out or has otherwise been lost. So, an incoming call arriving just before that registration will fail. Sure, sometimes s**t happens and a call fails. But in your scenario, it’s happening repeatedly or at least frequently, resulting in an unreliable system. Also, if there is more than one endpoint behind the same NAT, calls will sometimes ring the wrong extension, because a registration will be assigned a source port previously used by a different extension.

Usually, setting a short registration expiry in the endpoint configuration, e.g. 120 seconds will correct this issue. If not, you need to find out what is going wrong and fix it. It is usually not difficult.

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