[Home]

Summary:ASTERISK-02481: reload and extensions reload forget subscriptions for presence (e.g. SNOM busy lamps)
Reporter:revk (revk)Labels:
Date Opened:2004-09-27 12:59:04Date Closed:2008-01-15 15:45:53.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:If you do a reload or extensions reload, busy lamp fields stop working. I suspect it is simply forgetting all of the subscriptions.

****** ADDITIONAL INFORMATION ******

Er, CVS head this morning, but shows 01/15/04 for some reason?!

After a reload, sip show subscriptons still shows subscriptions for a while, but then shows none a bit later. Resetting the SNOM seems to fix and sip show subscriptions shows them again and they work until the next reload. Looks like waiting a long time fixes - I assume SIP re-subscribes.

Not sure if this is core asterisk or SIP or what, please do re-categorise if I have it wrong!
Comments:By: Olle Johansson (oej) 2004-10-06 07:14:47

This is definitely SIP. We need to check the timers for a subscription - how do we handle expiration? How do we handle subscriptions at SIP reload?

Also, please try to trace a dialog where a SNOM subscribes, so we can check their request and our reply for expiration times.

Will the snome re-subscribe at expiration of a subscription?
By: revk (revk) 2004-10-08 12:00:38

It appears the SNOM does re-subscribe, but a reload causes a period of time when there is no subscription and hence the lights don't work. Do you have a SNOM? If not, I can send you one!
By: Olle Johansson (oej) 2004-10-11 12:48:14

I have a Snom 200, but please email me a config that I can start with for testing. Thank you for the offer!
By: twisted (twisted) 2004-10-27 16:41:18

Is this still an issue?  were we able to find out anything in testing?  Just an update if I may so request it...
By: Olle Johansson (oej) 2004-10-28 02:25:01

THank you for the reminder, this is on my "to-do" list :-)
By: Olle Johansson (oej) 2004-11-09 04:19:00.000-0600

I've been looking into this a bit. My guess is that the subscription is lost in core during "extensions reload". This command does not affect the sip channel at all. SIP subscriptions are handled as calls and expired at expiration time, where the client has to renew the subscription. The SIP subscription should stay during a "sip reload" - please check that to confirm if I am wildly or mildly wrong :-)
By: Brian West (bkw918) 2004-11-09 09:37:42.000-0600

well the best way is to store this info in the ast_db

ast_extension_state_add(p->context, p->exten, cb_extensionstate, p);

around that line in chan_sip.c the same way we store registration data in the astdb.

bkw

edited on: 11-09-04 12:07
By: Olle Johansson (oej) 2004-11-10 01:09:03.000-0600

bkw: The problem seems to be that the core forgets about our subscription at extensions reload and there's no way I can detect an "extensions reload" from chan_sip...
By: Olle Johansson (oej) 2004-11-16 12:09:06.000-0600

To solve this, we need someone familiar with the Asterisk core functionality. I can't figure out why the subscriptions disappear at "extensions reload"
By: Brian West (bkw918) 2004-11-16 14:45:04.000-0600

they disappear because they are not written to disk.. its like doing add extension from the cli.. those go away during reload....  If you add them to the database.. then pbx_config.c can be told to add them back when a reload is issued.

bkw
By: khb (khb) 2004-11-22 14:11:50.000-0600

No, it's very simple, they disappear because when the extensions get deleted by the reload, the extension state id's become stale until they get destroyed by the next schedule expiration. The phone then needs to and will resubscribe after all the implied timeout are exhausted.
I don't think you can just write the id's to disk and expect them to be valid later.
The best thing to do here probably is to expire all state id's immediately when reloading and set the phones expirations shorter (can't remember now if that's possible).  What could be written to disk are the phones' subscription info, and after reload the extension states should be rescheduled for new id's.  Hmm, perhaps that's actually what bkw meant also.

edited on: 11-22-04 14:26

edited on: 11-22-04 14:27
By: Olle Johansson (oej) 2004-12-12 15:53:17.000-0600

Yes, this is still an issue. /Housekeeping.
By: Brian West (bkw918) 2004-12-12 16:24:40.000-0600

khb I know exactly how to fix this.. and why it happens.. now if someone can send me a phone that I can use to fix this I would be more than willing to fix it.

bkw
By: Olle Johansson (oej) 2004-12-19 07:40:57.000-0600

After discussing with Markster: This is a design error in the core, that should be fixed in the core, but can also be handled with some ugly coding in chan_sip...
By: alric (alric) 2004-12-31 10:09:06.000-0600

Any activity here or has any attempt been made at the core code?  Will get in touch with oej about this today.
By: Mark Spencer (markster) 2005-01-09 03:46:06.000-0600

The two options are either

(a) move specific extension subscriptions so that they are part of the global subscription list and not part of the context (better, faster, more work)

(b) make chan_sip register for all extensions and then apply each (slower, less work)
By: twisted (twisted) 2005-01-28 19:56:10.000-0600

So, now that there have been options given as to how to fix this, where does this stand?
By: Clod Patry (junky) 2005-02-27 22:26:47.000-0600

Long time since no activity in here?

oej, are you working on that bug or can we close that bug?
By: Olle Johansson (oej) 2005-02-28 00:40:07.000-0600

No, I wasn't working on this but since I've spent a lot of time with subscriptions and event handling lately (see other bugs) I've become more aware of the problems here. I'll see if I understand Marks earlier response better now :-)
By: Olle Johansson (oej) 2005-03-16 13:24:13.000-0600

--- reminder, this is still a bug to be fixed ---
By: Olle Johansson (oej) 2005-03-19 15:50:24.000-0600

kpfleming is rewriting the event handler, which will propably solve this issue. Stay on hold :-)
By: Olle Johansson (oej) 2005-07-18 09:03:10

Can someone check if Kevin's changes to the devicestate notification subsystem has fixed this?
By: xrobau (xrobau) 2005-07-31 03:30:37

'extensions reload' does _not_ destroy the subscriptions. However, a 'reload' does:
[...]
14 active SIP subscriptionss
gw*CLI> reload
gw*CLI> sip show subscriptions
Peer             User        Call ID                Extension       Last state
0 active SIP subscriptionss
gw*CLI>
By: Olle Johansson (oej) 2005-07-31 04:26:42

xrobau: I think you misunderstand the issue. Yes, a SIP reload or a reload removes active subscriptions from memory. An "extensions reload" keeps the SIP subscriptions intact, but the internal devicestate subscriptions are gone so there's no alerts any more.
By: xrobau (xrobau) 2005-07-31 05:42:34

Wups. Sorry. I must have mis-read. I just tested it and yes, while the subscriptions are still visible, they are not actually being sent. So, to answer your question "Can someone check if Kevin's changes to the devicestate notification subsystem has fixed this?", the answer is no, it has not been fixed.
By: Olle Johansson (oej) 2005-07-31 05:59:16

Thank you very much for testing! Ok, we need to figure this out before 1.2. Thinking caps on!
By: Michael Jerris (mikej) 2005-08-24 01:50:14

does ASTERISK-3564 have any affect on this issue?
By: Olle Johansson (oej) 2005-08-25 14:40:51

This is a huge problem. I wonder if we can fix this before 1.2? Maybe a quick-and-dirty patch.
By: Olle Johansson (oej) 2005-08-25 14:41:36

No, 3644 does not fix this issue, but needs this to be fixed to work properly after a reload of the dial plan.
By: Kevin P. Fleming (kpfleming) 2005-08-27 19:53:57

Believe it or not, this is now fixed in CVS HEAD :-)
By: Digium Subversion (svnbot) 2008-01-15 15:45:53.000-0600

Repository: asterisk
Revision: 6431

U   trunk/channels/chan_sip.c
U   trunk/include/asterisk/pbx.h
U   trunk/pbx.c

------------------------------------------------------------------------
r6431 | kpfleming | 2008-01-15 15:45:52 -0600 (Tue, 15 Jan 2008) | 2 lines

preserve hint watchers and laststate across 'extensions reload' (issue ASTERISK-2481)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=6431