Summary: | ASTERISK-20855: 'sip reload' does not properly flush MWI outbound subscriptions defined in sip.conf | ||
Reporter: | Kristopher Lalletti (kris2k) | Labels: | |
Date Opened: | 2013-01-02 22:38:13.000-0600 | Date Closed: | |
Priority: | Minor | Regression? | |
Status: | Open/New | Components: | Channels/chan_sip/Subscriptions |
Versions: | 11.1.0 11.1.1 13.18.4 | Frequency of Occurrence | Constant |
Related Issues: | |||
Environment: | Centos 6.3 / 2.6.32-279.19.1.el6.i686 #1 SMP Wed Dec 19 04:30:58 UTC 2012 i686 i686 i386 GNU/Linux | Attachments: | ( 0) full.scenario-1 ( 1) full.scenario-2 ( 2) full.scenario-3 ( 3) full.scenario-4 |
Description: | Using the following MWI registration pattern in sip.conf
mwi => 120:passwordA:120@192.168.1.2/120 mwi => 121:passwordB:121@192.168.1.2/121 mwi => 122:passwordC:122@192.168.1.2/122 Then referred by my sip "friends" with the mailbox argument: mailbox=120@SIP_Remote, etc.. 1. Upon asterisk startup "sip show mwi" will list valid MWI registrations for 120,121,122 2. Following a "sip reload" "sip show mwi" will list valid MWI registrations for 120,121,122,120,121,122 3. Following another "sip reload" (even tried with module reload chan_sip.so) "sip show mwi" will list valid MWI registrations for 120,121,122,120,121,122,120,121,122 This suggest that the reload routine, is not destroying existing MWI subscriptions, and at every reload, new MWI subscriptions are added. I thought this may have just been a question of expiration of the older subscriptions, but after waiting significantly beyond the subscription refresh interval, the redundant MWI registrations still persisted. This is causing the target PBX to complain about bad auth for certain MWI subscriptions. Performing a "module unload chan_sip.so" then "module load chan_sip.so" puts the MWI subscriptions back into normal operation. | ||
Comments: | By: Rusty Newton (rnewton) 2013-01-04 13:26:40.075-0600 This looks straightforward to reproduce. Can you easily provide an Asterisk log with VERBOSE and DEBUG (at least level 5 for both) logging during the reload? It would be helpful for a developer to compare with their own if they get different results with attempting reproduction. By: Kristopher Lalletti (kris2k) 2013-01-08 10:12:24.850-0600 I've managed to succesfully isolate the misbehaviour; The issue is not at a SIP protocol level, but indeed at a configuration parsing level. I freshly compiled Asterisk 11.1.2 using stock sip.conf from the distribution to properly validate, and here are my observations. Scenario-1: Using an #include in sip.conf/[general] section File: sip.conf --- ; Located just below MWI/Registry comments #include sip.d/regs.conf File: sip.d/regs.conf--- mwi => 120:passwordA:120@192.168.1.2/120 --- RESULT: this will yield in a continuous appending on MWI subscriptions, at every sip.reload Scenario-2: Using the mwi declaration in sip.conf/[general] section File: sip.conf --- ; Located just below MWI/Registry comments mwi => 120:passwordA:120@192.168.1.2/120 --- RESULT: no appending of MWI subscriptions at every sip reload Scenario-3: Same as scenario-1, but this time, include put at end-of file ([authentication] section) File: sip.conf --- ; Located at EOF #include sip.d/regs.conf --- File: sip.d/regs.conf --- mwi => 120:passwordA:120@192.168.1.2/120 --- RESULT: no active MWI subscriptions listed in sip show mwi, even after sip reload. Scenario-4: This was an unintentional scenario when documenting this BUG; basically, a combination of Scenario-2 + 3 File: sip.conf --- ; Located just below MWI/Registry comments mwi => 120:passwordA:120@192.168.1.2/120 ; Located at EOF #include sip.d/regs.conf --- File: sip.d/regs.conf --- mwi => 120:passwordA:120@192.168.1.2/120 --- RESULT: Initial MWI subscription at load was OK, then sip reload revealed MWI subscription appendage. This is an interesting behaviour, since we had initially demonstrated in scenario-3 at the EOF inclusion resulted in no effect, and now its influencing the declaration in scenario-2 which exhibited no issues upon sip reload. See included logs for scenario, 1, 2, 3, 4. By: Kristopher Lalletti (kris2k) 2013-01-08 10:14:15.822-0600 Trace+Debug logs for each scenario observed in today's update. By: Kristopher Lalletti (kris2k) 2013-01-08 10:17:51.432-0600 Provided logs + isolated observation of the issue. By: Nate Carlson (natecarlson) 2013-08-27 15:37:14.103-0500 I'm seeing the same thing on Asterisk 1.8.23.0 (ie, "me too".) |