[asterisk-dev] Subscription Persistence Issues

[Matthew Jordan]

On Tue, Feb 7, 2017 at 1:16 PM, George Joseph <gjoseph at digium.com> wrote:

> Greetings All,
>
> 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.
>
> 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.
>
> 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.
>
> Thoughts?
>
>
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?

-- 
Matthew Jordan
Digium, Inc. | CTO
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20170208/e376d349/attachment.html>