[asterisk-bugs] [Asterisk 0017153]: chan_sip sends to peer mwi notify for wrong mailbox

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=17153 
====================================================================== 
Reported By:                Jamuel
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   17153
Category:                   Channels/chan_sip/Subscriptions
Reproducibility:            random
Severity:                   minor
Priority:                   normal
Status:                     feedback
Asterisk Version:           1.6.1.18 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-04-08 15:29 CDT
Last Modified:              2010-04-13 00:45 CDT
====================================================================== 
Summary:                    chan_sip sends to peer mwi notify  for wrong mailbox
Description: 
A SIP peer can be sent the wrong message count for an MWI subscription. 

In 1.6.1 we're seeing an issue where a peer is receiving the message count
for another peer's mailbox:

Example:
Peer A has messages 10/8 (as verfied by counting messages in filesystem
and confirmed by voicemail show users)
Peer B as messages 0/0 (as verfied by counting no messages in filesystem
and confirmed by voicemail show users)

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

Mailbox polling is turned on in app_voicemail so you were to then 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 mailbox poll interval, Peer B's message count is correctly reflected
(1/0) in the subsequent NOTIFY (as well as voicemail show users in the
cli). 

Next if you delete this message, * correctly sends a NOTIFY reflecting
(0/0) to Peer B. 

But then eventually after some time has elapsed (not sure if its
time-based or some other event triggering yet) Peer B starts getting Peer
A's message count again.

In all cases CLI "voicemail show users" shows Peer B's message count
correctly (0/0).  This leads me to guess that there is an issue with the
MWI caching that chan_sip implement (get_cached_mwi).
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0016660 [patch] [regression] [patch] chan_sip d...
====================================================================== 

---------------------------------------------------------------------- 
 (0120313) Jamuel (reporter) - 2010-04-13 00:45
 https://issues.asterisk.org/view.php?id=17153#c120313 
---------------------------------------------------------------------- 
Patch from 0016660 had no effect.  Still see chan_sip intermittently
sending MWI NOTIFY's with message counts from wrong mailbox.

I've created a script that can parse a pcap of the related SIP NOTIFY
messages. The script then logs when NOTIFY's are sent with the wrong
message count as compared to actual messages counted on the file system by
the script for the same mailbox.

This is the regex and bpf ngrep filter that will capture all NOTIFY's for
message-summary:

ngrep -l -q -t -W byline "Voice-Message: [0-9]+" port 5060 > mwi.txt 2>&1
&

I've then gone and patched chan_sip's sip_send_mwi_to_peer method to no
longer invoke get_cached_mwi, ignore returning immediately on the
cache_only = 1 parameter, and instead to always use ast_app_inboxcount:

Basically comment out the compound if/else if block starting with:
 if(!get_cached_mwi 
 ...
 } else { /* Fall back to manually checking the mailbox */

and just leaving:

struct ast_str *mailbox_str = ast_str_alloca(512);
peer_mailboxes_to_str(&mailbox_str, peer);
ast_app_inboxcount(mailbox_str->str, &newmsgs, &oldmsgs);

So that chan_sip always invokes ast_app_inboxcount and never relies upon
caching or the EVENT system.

I'll will run in this mode for a day or so and see if my issue goes away
and report back.  On a busy machine this issue presents itself at least
every hour.  My impression if this does put the issue into bypass then that
ought to at least implicate the get_cached_mwi method. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-04-13 00:45 Jamuel         Note Added: 0120313                          
======================================================================