[asterisk-dev] Subscription behavior when an incoming registration goes away?

[Richard Mudgett]

On Thu, Dec 22, 2016 at 10:14 AM, Matthew Jordan <mjordan at digium.com> wrote:

>
>
> 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.
>

I was originally thinking to dump the subscriptions.  But Matt's reasoning
makes plain that we
should only just skip sending the NOTIFY's when we have no AOR available.

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20161222/77c610fb/attachment.html>