[Home]

Summary:ASTERISK-09074: Sharing ODBC voicemail amongst several Asterisk servers
Reporter:Andrew Smith (eurodrew555)Labels:
Date Opened:2007-03-22 06:45:51Date Closed:2007-03-22 08:51:48
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Applications/app_voicemail
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:We have the following Asterisk network design.

  OpenSER Proxy
     |      |
Asterisk   Asterisk

We have two Asterisk servers sitting behind an OpenSER proxy.
We are using ODBC voicemail on both servers.

The problem we are having is it appears that app_voicemail.c only counts the number of voicemessages when Asterisk first starts up, and our clustered Asterisk solution eventually goes out of sync with the number of voicemessages.

Asterisk also on occassion will stop storing voicemails in the database, and writes them to the local /var/spool/asterisk/voicemail/... directory.

I would like to request that app_voicemail.c be modified to count the number of messages every time the mailbox is accessed (for instance when a user calls in to check their messages).

There also needs to be a solution for inserting voicemails that are written locally (for example when a dropped network connection restablishes). This may be difficult - how do we keep the message numbering in the correct order?

I've only looked quickly but it appears that Asterisk counts the number at startup, and then keeps an internal count, rather than checking the database again for changes.

The problem is with our design both servers are sharing the same database - it  slowly starts to go out of sync.

For example:

Both servers start up.
Mailbox 2821 has 0 messages.
Leave a message directly on Asterisk 1.
Check voicemail on Asterisk 1 and it reports 1 new message.
Check voicemail on Asterisk 2 and it reports no new messages.

I then dial in and leave a message directly on Asterisk 2.
Asterisk 2 then reports 1 new message.
Asterisk 1 reports 1 new message.

Our solution for the moment is to simply get around this with our dialplans - when a user wants to check a mailbox we call voicemailmain on Asterisk 1, then voicemailmain on Asterisk 2. We play a message first stating that we are checking server 1, then checking server 2.. so the users know to hold on. Once they get used to it there's no problem but it would be nicer if a clustered solution (imagine 10 or 20 Asterisk servers behind the proxy, it would not be possible to say "checking server 1", "checking server 2", "checking server 3".... 4,5,6,7,8....

Most of the network designs I have seen usually do have a dedicated voicemail server, but if ODBC voicemail could be modified in this way Asterisk would have a fully redundant clustered voicemail solution... which I think would be incredibly powerful.




****** ADDITIONAL INFORMATION ******

Fedora Core 6 - 2.6.19-1.2911.6.5.fc6 2007 i686

openser 1.1.1-notls

Asterisk Realtime
ODBC Voicemail

Our users do not record their own VM prompts. This would be an issue with a clustered design but we are mainly concerned with just leaving and picking up voicemail (at the moment).

We mainly use Asterisk for our call centre, and VM prompts are recorded and then resynced across all servers.

Comments:By: Andrew Smith (eurodrew555) 2007-03-22 06:58:26

Does anyone know if IMAP storage in Asterisk 1.4 will work with multiple Asterisk servers all sharing the same storage without the above issues?

By: Serge Vecher (serge-v) 2007-03-22 08:51:47

as per bug guidelines, feature requests are not accepted via the bug-tracker without a patch implementing it. The changes you are talking about are not likely trivial, so I suggest to post a bounty on the wiki (voip-info.org). Feel free to reopen the issue if you have a disclaimed patch implementing this feature ready.

Also, occasional writing of vm into /var/spool folder sounds like a bug, so if you can narrow down what's causing it or at least can capture a good console log of this happening with verbosity and debug set to 4, please feel free to open a new issue for that.

Thanks