> 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:

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:

Reply via email to