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 -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
