[asterisk-bugs] [Asterisk 0016660]: [patch] [regression] [patch] chan_sip does not check other mailboxes on AST_EVENT_MWI

Asterisk Bug Tracker noreply at bugs.digium.com
Thu Apr 1 16:46:44 CDT 2010


A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=16660 
====================================================================== 
Reported By:                rain
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   16660
Category:                   Channels/chan_sip/Subscriptions
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     acknowledged
Asterisk Version:           1.6.2.1 
JIRA:                       SWP-767 
Regression:                 Yes 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-01-20 13:51 CST
Last Modified:              2010-04-01 16:46 CDT
====================================================================== 
Summary:                    [patch] [regression] [patch] chan_sip does not check
other mailboxes on AST_EVENT_MWI
Description: 
When chan_sip receives an AST_EVENT_MWI, the callback will always believe
the message counters in the event
(AST_EVENT_IE_NEWMSGS/AST_EVENT_IE_OLDMSGS); however, if the peer receiving
the event has voicemail messages in a different mailbox that it is ALSO
subscribed to, these counters will be wrong (since the callback makes no
attempt to check other mailboxes if event is not NULL.)

The easiest solution to this problem seems to be ignoring the IEs in the
AST_EVENT_MWI event and going right to get_cached_mwi, which appears to
check for MWI events on all subscribed inboxes.  The attached patch does
this, but this caused some of my phones to incorrectly show messages
waiting when I restarted Asterisk.  From some debug logging I added locally
to get_cached_mwi, it seems that ast_event_get_cached() can return an MWI
event with incorrect data in the NEWMSGS/OLDMSGS IEs while app_voicemail is
loading (e.g. 1 new, 0 old), although a cache query for the same
mailbox at context will (accurately) return 0/7 a moment later.  (I'm trying
to debug that.)

Disclaimer on file.
====================================================================== 

---------------------------------------------------------------------- 
 (0120079) Jamuel (reporter) - 2010-04-01 16:46
 https://issues.asterisk.org/view.php?id=16660#c120079 
---------------------------------------------------------------------- 
Rain: have you seen cases (before your patch) where a peer can be sent the
wrong message count?  In 1.6.1.12 I'm seeing an issue where a peer is
receiving the message count for another peer's mailbox:

Peer A has messages 10/8
Peer B as messages 0/0

on SUBSCRIBE by Peer B to Peer B's mailbox, * returns Peer A's message
count in the NOTIFY to Peer B.

I have polling turned on in app_voicemail so if I then were to go and add
a message to Peer B's INBOX via the linux filesystem (e.g. touch
/var/spool/asterisk/voicemail/default/PEERB/INBOX/msg0000.txt) then after
the poll interval, Peer B's message count is correctly reflected (1/0).
Then if I delete this message again, * correctly sends a NOTIFY reflecting
(0/0) to Peer B.  But then after some time has elapsed (not sure of how
long just yet) Peer B starts getting Peer A's message count again.

Any thoughts would be appreciated. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-04-01 16:46 Jamuel         Note Added: 0120079                          
======================================================================




More information about the asterisk-bugs mailing list