[asterisk-dev] Subscription Persistence Issues

[George Joseph]

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?


-- 
George Joseph
Digium, Inc. | Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20170207/03c19fa0/attachment.html>