> On 22 Dec 2016, at 18:13, George Joseph <[email protected]> wrote:
>
>
>
> On Thu, Dec 22, 2016 at 9:22 AM, Olle E. Johansson <[email protected]
> <mailto:[email protected]>> wrote:
>
>> On 22 Dec 2016, at 17:14, Matthew Jordan <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>
>>
>> On Thu, Dec 22, 2016 at 9:32 AM, George Joseph <[email protected]
>> <mailto:[email protected]>> 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.
>
> Without knowing the details of the PJSIP channel this conversation seems all
> upside down to me.
> Subscriptions provide their own contact for the NOTIFY and have no
> relationship to the REGISTER message.
>
> There's no protocol level relationship but there is a functional
> relationship. If a phone with 15 BLF subscriptions goes missing and we can
> correlate the expired registration contact with the subscription contact,
> should we bother sending NOTIFYs that we know will timeout and need to be
> retried?
>
It all depends on how you determine that a device “goes missing” but the cool
thing with subscriptions is that a server can
terminate the subscription early by sending a notify. If the phone considers
itself alive and kicking, it will send a re-subscribe
to fight your decision. I would say that the correlation should be
“sip-instance”, the UUID of the device, to be good enough
to do this.
I think this happens in chan_sip if an extension disappears at dialplan reload
and we have active subscriptions for it
- we terminate the subscription from the server side. Kevin and I worked on
that part a long time ago.
/O
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
