[Home]

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-0600Date Closed:
Priority:MinorRegression?
Status:Open/NewComponents: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/LinuxAttachments:( 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".)