| Summary: | ASTERISK-12196: realtime support and qualify (sip_poke_all_peers) after restart | ||
| Reporter: | deti (deti) | Labels: | |
| Date Opened: | 2008-06-14 11:04:14 | Date Closed: | 2011-06-07 14:08:18 |
| Priority: | Minor | Regression? | No |
| Status: | Closed/Complete | Components: | Channels/chan_sip/General |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ||
| Description: | When realtime support for chan_sip is enabled (sipusers,sippeers) and qualify is set to yes after a restart all sippeers remain in state UNKNOWN until they are restarted too. This behavior is completely different from Asterisk 1.2 and leaves the qualify function unusable. SIP accounts defined in sip.conf are properly scheduled for sip_poke_peer. ****** STEPS TO REPRODUCE ****** - Enable realtime support for sipusers and sippeers - Set qualify to yes for all sip peers - Let some SIP devices register - issue "restart now" via asterisk console - see all formerly registered peers in state UNKNOWN | ||
| Comments: | By: Joshua C. Colp (jcolp) 2008-06-16 07:16:18 I assume you are using realtime caching? By: deti (deti) 2008-06-16 07:56:24 Yes, these are my realtime settings in sip.conf: rtcachefriends=yes rtupdate=yes rtautoclear=no ignoreregexpire=yes rtsavesysname=yes By: Tilghman Lesher (tilghman) 2008-06-27 16:34:50 I'm not sure how this is different from 1.2. Realtime peers are never loaded from the database until they are requested by a registration. Perhaps when you were running with 1.2, you had your SIP phone registration timeout set much lower? By: Vadim Sherbakov (vinsik) 2008-07-01 01:40:50 I have noticed the same problem in 1.4.21 version. 1.4.20.1 worked nicely. Im going to dig a little deeper and report here. By: Olle Johansson (oej) 2008-07-01 02:29:37 We don't store the qualify state at restart and thus must re-initialize everything. Qualify support for realtime objects is really something that the design doesn't support, much like the 1.4 MWI system. To support restarts properly, I think we need a major redesign. It will cause severe issues in situations where we have multiple servers with the same realtime database, in that case we need to store which server that had the active registration and activate it in the proper server at restart - which will cause issues with failover scenarios... Ouch. By: Tilghman Lesher (tilghman) 2008-07-25 17:07:48 Working as designed. | ||