<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 22 Dec 2016, at 18:13, George Joseph <<a href="mailto:gjoseph@digium.com" class="">gjoseph@digium.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Dec 22, 2016 at 9:22 AM, Olle E. Johansson <span dir="ltr" class=""><<a href="mailto:oej@edvina.net" target="_blank" class="">oej@edvina.net</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><span class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 22 Dec 2016, at 17:14, Matthew Jordan <<a href="mailto:mjordan@digium.com" target="_blank" class="">mjordan@digium.com</a>> wrote:</div><br class="m_503867797432212479Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Dec 22, 2016 at 9:32 AM, George Joseph <span dir="ltr" class=""><<a href="mailto:gjoseph@digium.com" target="_blank" class="">gjoseph@digium.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">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.<div class=""><br class=""></div><div class="">Should we:</div><div class=""><ul class=""><li class="">Leave the behavior as is?</li><li class="">Automatically remove the subscriptions for a contact that has been deleted?</li><li class="">Create a global option to control auto deletion?</li><li class="">Create an aor option to control auto deletion?</li></ul><div class="">Opinions?</div><span class="m_503867797432212479HOEnZb"><font color="#888888" class=""><div class=""><br class=""></div></font></span></div></div></blockquote><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">I'll grant the above scenario is pretty unlikely, but it is plausible.</div></div></div></div></div></blockquote><br class=""></div></span><div class="">Without knowing the details of the PJSIP channel this conversation seems all upside down to me.</div><div class="">Subscriptions provide their own contact for the NOTIFY and have no relationship to the REGISTER message.</div></div></blockquote><div class=""><br class=""></div><div class="">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?</div><div class=""> </div></div></div></div></div></blockquote>It all depends on how you determine that a device “goes missing” but the cool thing with subscriptions is that a server can</div><div>terminate the subscription early by sending a notify. If the phone considers itself alive and kicking, it will send a re-subscribe</div><div>to fight your decision. I would say that the correlation should be “sip-instance”, the UUID of the device, to be good enough</div><div>to do this.</div><div><br class=""></div><div>I think this happens in chan_sip if an extension disappears at dialplan reload and we have active subscriptions for it</div><div>- we terminate the subscription from the server side. Kevin and I worked on that part a long time ago.</div><div><br class=""></div><div>/O</div></body></html>