> On Jan. 7, 2015, 8:52 a.m., Mark Michelson wrote: > > The option flag you've introduced is unnecessary. There is an > > ast_shutting_down() function that you can call to determine if Asterisk is > > shutting down. > > > > I've been thinking about this a bit more since yesterday, and I think the > > behaviour you're introducing isn't always going to be wanted on a shutdown. > > It may be that this instance of Asterisk is being shut down permanently in > > order to migrate to a new server, or something similar. In such a case, > > keeping the subscriptions open during shutdown doesn't really make sense. > > But if the system is going down temporarily, say for a brief maintenance, > > on a shutdown it might make sense to persist the open subscriptions. I > > think making this behaviour optional on shutdown is a good idea. > > > > During a restart, I imagine that this introduced behavior will always be > > wanted, though. The problem is, there's no way to tell if the current > > shutdown operation is part of a restart. This may be an area where > > introducing a new option flag is warranted, to tell if Asterisk is being > > restarted. This way, you can always persist the subscriptions during a > > restart.
Funny, I saw ast_shutting_down in channel.c but ignored it because I thought it was channel specific. I'm open to other suggestions but you absolutely can't send a NOTIFY/terminated to a subscriber and expect to pick up where you left off. They'll respond with a 481. Also, testing for restart vs shutdown isn't viable as you may perform an asterisk shutdown to reboot or solve an issue. I think it's up to the subscribers to handle the cases of a permanent shutdown. Presumably they're going to have to be reconfigured anyway to pick up a new server. - George ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4318/#review14104 ----------------------------------------------------------- On Jan. 7, 2015, 8:24 a.m., George Joseph wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/4318/ > ----------------------------------------------------------- > > (Updated Jan. 7, 2015, 8:24 a.m.) > > > Review request for Asterisk Developers and Mark Michelson. > > > Repository: Asterisk > > > Description > ------- > > If you do a 'core (shutdown|restart) graceful' persistent subscriptions won't > survive. If you do a 'core (shutdown|restart) now' or asterisk terminates > for some reason, they do. Here's why... > > When asterisk shuts down gracefully, it sends a 'NOTIFY/terminated' to > subscribers for each subscription. This not only tells the subscribers that > the dialog/state machine is done, it also frees the last reference to the > subscription tree which causes the persistent subscription to get deleted > from astdb. When asterisk restarts, nothing's left. Just preventing the > delete from astdb doesn't work because we already told the subscriber to > terminate the dialog so we can't restart it even if it was still in astdb. > Everything works OK if asterisk terminates unexpectedly because we never send > the 'terminated' message so on restart, the subscription is still in astdb > and the subscriber is none the wiser. > > This patch suppresses the sending of 'NOTIFY/terminated' on shutdown for > persistent connections. To do this, I've had to add a new > AST_OPT_FLAG_SHUTTING DOWN to options so we know that a shut down is in > progress. > > > Diffs > ----- > > branches/13/res/res_pjsip_pubsub.c 430293 > branches/13/main/asterisk.c 430293 > branches/13/include/asterisk/options.h 430293 > > Diff: https://reviewboard.asterisk.org/r/4318/diff/ > > > Testing > ------- > > Lots of before and after Wireshark testing with Digium, Grandstream, Unidata > and soft phones. Now when asterisk comes back up, it sends NOTIFY/active > messages with updated expires to persistent subscribers which all return OK > and further notifies are processed correctly. > > > Thanks, > > George Joseph > >
-- _____________________________________________________________________ -- 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