<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 7, 2017 at 1:16 PM, George Joseph <span dir="ltr"><<a href="mailto:gjoseph@digium.com" target="_blank">gjoseph@digium.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Greetings All,<div><br></div><div>I've been working on the (many) issues with recreating inbound subscriptions after an asterisk restart.  I have an approach that works but has a drawback:  We can recreate the subscription on startup from the data we persist and can even send a NOTIFY to each subscriber BUT with the current version of pjproject, we can't actually set the expiration timer.  I have a pjproject patch ready that allows us to set tie timer but the drawback is that this approach will only work with bundled pjproject or a patched version of your own.</div><div><br></div><div>There's an alternative though...   When asterisk restarts, instead of sending 'active' NOTIFYs to each subscriber, we could send 'terminate,probation' instead.  The RFCs say that a "client SHOULD retry at some later time".  While this approach will work with any version of pjproject there are issues here as well.  The first issue is the word 'SHOULD'.  There's no guarantee that the client will actually resubscribe.  The second issue is the extra SUBSCRIBE/OK/NOTIFY/OK exchange between asterisk and the client at startup.  We can tell the client to retry not before a random interval similar to how we stagger sending OPTIONS messages at startup but it's still an extra 4 packets per subscription.</div><div><br></div><div>Neither approach is harder or easier than the other to implement.  It's just a matter of backwards compatibility vs extra traffic and the 'SHOULD' uncertainty.</div><div><br></div><div>Thoughts?</div><span class="HOEnZb"><font color="#888888"><div><br></div></font></span></div></blockquote><div><br></div><div>If you go with the first approach, do the changes to pjproject to fix the expiration timer issues cause any API changes? Or is it merely fixing a bug in pjproject?</div></div><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Matthew Jordan<br>Digium, Inc. | CTO<br>445 Jan Davis Drive NW - Huntsville, AL 35806 - USA<br>Check us out at: <a href="http://digium.com" target="_blank">http://digium.com</a> & <a href="http://asterisk.org" target="_blank">http://asterisk.org</a></div>
</div></div>