> On 22 Dec 2016, at 17:14, Matthew Jordan <mjor...@digium.com> wrote: > > > > On Thu, Dec 22, 2016 at 9:32 AM, George Joseph <gjos...@digium.com > <mailto:gjos...@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.
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. Unless you are discussing a Subscription for registration status - but even so your discussion is not parseable in my eyes ;-) Sorry for the intrusion /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
