[Asterisk-Dev] Resource: RVM Server

[John Todd]

>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
>occurs, no message will be stranded longer than others.  I'm also
>going to use a monitor thread that will kill server connections if the
>number of connections is at the max and no data has been received
>for 300 seconds on a particular thread.
>
>I'm going to use SSL to encrypt the connection.  I'll also be using MIME
>headers to encode the message.  I've also already decided for a maximum
>of 5 concurrent server connections and 1 client connection per Asterisk
>server (for bandwidth reasons).  These numbers aren't set in stone.
>
>My reasons for making this post are twofold:  first, I don't want two
>competing solutions for the same problem, so I want everybody to know
>that I'm doing this.  Second, I haven't resolved all of the details,
>such as whether servers can define which clients may forward voicemail
>and how.  I'm considering using the voicemail.conf options field to add
>remote=1234 at 12.34.56.78 to specify the remote mailbox/server.
>
>Suggestions that this functionality is not needed will be routed to
>/dev/null (I don't really see a better way, and yes, I do need this
>functionality).  Other suggestions on additional features or behavior
>that you think should be changed are welcome.
>
>-Tilghman

Firstly: yeah, great, do it!  :-)

Secondly: I'll throw some bad ideas up against the wall and see if 
they have any merit.

Forgive my ignorance on the topic of MySQL - I have only limited 
exposure to it, and I find that many of the "new" features often 
outpace the documentation (like Asterisk. ;)

Would a method of storing voicemail messages in a database as BLOBs 
and then synchronizing the two databases be a better method?  In this 
way, you could store the voicemail in a variety of ways:

1) Each user would have a "master" server that housed their account, 
and any other servers would try to hand off the voicemail to the 
"master" server, and would re-queue and re-attempt if unable to reach 
the server or a "success" message is not received back.

2) Complete mirroring could be done such that each message is 
duplicated on each system, and when a user deletes the message on 
server A, then all the rest of the servers would receive notice to 
delete that message as well (I like this method, since it allows for 
redundancy)

Actions can be performed by a daemon on each database server that 
scans through the database every minute or so and takes action if a 
new message arrives/changes/disappears.  Instead of a daemon it may 
be the case if the MySQL stuff supports it that a stored 
procedures/trigger combination would do the same tasks - I don't know 
if that's "production" code yet.


Interactions with Asterisk would be done with a generalized 
abstraction layer, so that other databases could be installed in the 
back end (though procedures such as "mirroring" and "remote server 
deletion" would be different for each one, as stored procedures 
depending on how that particular DB handled it.)

Other notes:

Of course, your method may be much lighter weight than using a 
database, and have other benefits as well that are particular to your 
implementation.  However, there are other concepts being discussed 
already for how to handle messages as database objects as well as 
just the user data, and it would seem that some intermediate layer or 
description in voicemail.conf should be perhaps discussed and agreed 
upon to make the diverging methods of file transport less 
different-looking from a configuration standpoint.

http://bugs.digium.com/bug_view_page.php?bug_id=0000153

JT