[asterisk-bugs] [JIRA] (ASTERISK-29525) PJSIP remove_existing unavailable contacts

[Joe (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-29525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=255662#comment-255662 ] 

Joe commented on ASTERISK-29525:
--------------------------------

We're not removing the unavailable contacts wholesale just because they're unavailable.

There is another device attempting to register and there's an unavailable contact holding the spot needed for the new registration.  So we're blocking a known good device because it hit max_contacts, just so that we can hold on to an unavailable device that "might" come back online?

The most common cause of this is a device behind NAT that changed port or external IP address.  remove_existing should not be needed for this common use case.  If the unavailable device comes back, max_contacts is set too low anyway, and it'll have to wait until the current contacts expire and they'll keep fighting with each other until max_contacts is increased.

> PJSIP remove_existing unavailable contacts
> ------------------------------------------
>
>                 Key: ASTERISK-29525
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29525
>             Project: Asterisk
>          Issue Type: Improvement
>      Security Level: None
>          Components: pjproject/pjsip
>    Affects Versions: 16.19.0, 18.5.0
>            Reporter: Joe
>
> The current behavior of remove_existing is:
> 1. If enabled, the contact that will expire soonest will be removed
> 2. If disabled, no contacts will be removed.
> This doesn't take into account contacts that have gone offline and are now unavailable.  There doesn't seem to be any use case for maintaining unavailable contacts.  Perhaps, a more intelligent process would work like this instead:
> 1. If enabled, first remove unavailable contacts, and if there aren't any, remove expiring soonest
> 2. If disabled, remove only unavailable contacts.
> If changing the behavior of 'no' is unwanted, then add a 3rd option of:
> remove_existing=unavailable
> to create the behavior of 2 above.



--
This message was sent by Atlassian JIRA
(v6.2#6252)