[Asterisk-Dev] Resource: RVM Server

[Steven Critchfield]

On Tue, 2003-09-16 at 16:33, Tilghman Lesher wrote:
> I'm currently developing a new resource for Asterisk, which I am calling
> RVM (remote voice mail).  It will consist of three components, a server
> for receiving, a queue, and a client for sending.  The problem that I'm
> attempting to solve is that we have 3 Asterisk servers, in
> geographically diverse locations.  The links between these servers are
> not particularly reliable, as we are using Internet routing between them
> (as opposed to a dedicated pipe).
> 
> We need to be able to transfer messages received on one server to a
> voicemail box located on another server.  No, NFS will not work, as
> the links are not reliable.  No, rsync won't work either, as voicemail
> messages must be consecutively numbered.  Yeah, we could write
> a complex set of scripts around rsync, but by the time we do that, we
> could have just written the functionality below.  And finally, no, we
> can't put all of our voicemail on one server (Try explaining to a
> salesman why, when his connection is down, his clients can't record
> and he can't listen to voicemail).
> 
> An RVM server will listen on a particular TCP port and accept
> connections.  Once it receives a connection, the voicemail message
> will be transferred, along with the corresponding msgXXXX.txt attribute
> file.  The filenames will be assigned by the remote host, once the files
> are received.  Once the client confirms the server has fully received
> the message, the client will delete that voicemail from the local
> machine.  Queues will be used to make sure that if a backlog ever

Maybe I'm missing something very important. But if your sales staff is
local to the original voicemail, why would you want it to go off site?
You state how you want to listen to it locally, but you also want to be
able to delete it locally when the remote verifies it has it's copy. I'm
wondering if the last part was actually part of your queue design, not
the voicemail changes.

As a way of guessing ahead, if you are doing this for archival, maybe
you should set up a email/imap solution that allows the delivery of the
voicemail. This would allow you to manage storage, plus add a well known
queue mechanism and transport to the project without reinventing the
wheel.  

To help out better it would be a good idea to  describe the problem you
are trying to solve (storage/management/archival/disaster
recovery/distribution) instead of details on how you want to solve the
problem. 
-- 
Steven Critchfield <critch at basesys.com>