[asterisk-dev] Subscription Persistence Issues

[Joshua Colp]

On Tue, Feb 7, 2017, at 03:16 PM, George Joseph 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.

I don't trust clients enough to expect that this behavior will work for
everything. If we can do the work ourselves in a way that guarantees it
works for all clients I usually opt for doing that.

-- 
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org