[asterisk-dev] Subscription behavior when an incoming registration goes away?
Matthew Jordan
mjordan at digium.com
Thu Dec 22 10:14:42 CST 2016
On Thu, Dec 22, 2016 at 9:32 AM, George Joseph <gjoseph at digium.com> wrote:
> When an incoming registration goes away, either because it expires or it
> was explicitly expired, what should we do with subscriptions the contact
> may have? Right now we do nothing which means that activity for those
> subscriptions will trigger NOTIFYs which will time out and retry until
> timer_b expires. Only then will they be deleted.
>
> Should we:
>
> - Leave the behavior as is?
> - Automatically remove the subscriptions for a contact that has been
> deleted?
> - Create a global option to control auto deletion?
> - Create an aor option to control auto deletion?
>
> Opinions?
>
>
If an AoR only has dynamic contacts, and those dynamic contacts are no
longer valid (or the AoR no longer has any contacts), then at the very
least I would think we wouldn't want to send the NOTIFY requests until the
AoR has valid contacts. There's certainly no reason to use memory/CPU
cycles on something that will never succeed.
You may or may not want to actually remove the underlying subscription. I
could see a scenario in which a phone's REGISTER request goes "missing",
and so the registration drops - maybe for just a short period of time. When
the new REGISTER request does succeed, the phone may or may not send a new
SUBSCRIBE request (which may have a very different timer). If we
auto-deleted the underlying subscription, we could have a situation where
the phone is re-registered but no longer receives state updates.
I'll grant the above scenario is pretty unlikely, but it is plausible.
Matt
--
Matthew Jordan
Digium, Inc. | CTO
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20161222/a38b1de0/attachment.html>
More information about the asterisk-dev
mailing list