[Asterisk-Dev] Resource: RVM Server

Tue Sep 16 23:34:44 MST 2003

Just a note on JT's MySQL concept.

MySQL has database replication built in.  So basically, each client queue
would be assigned the same master MySQL server for storing messages.  Each
Slave Database would be used to play the messages that have been stored.
When you need to delete one, you ask the master server to delete it, and
database replication in MySQL handles taking care of that on the slave.
(MySQL's master/slave relationships basically keep track of Database
transactions and push out queries that have been posted to the master that
the slave hasn't processed yet).

This of course makes you much more reliable on MySQL's ability to keep the
databases in sync.  (Deleting a record from the slave and then deleting it
from the master will break the sync, as the Master will ask the slave to
delete a record that does not exist).  I'm also unsure as to how stable the
database replication has become.  I used it in a production environment and
found that every 4-6 months, one of the slaves would get out of sync.  This
was of course over 2 years ago, and MySQL has seen many many revisions since
then.

Anyway, it would allow for a much simpler design for RVM and still give you
what you're looking for.  You should be able to do something like, mark a
record as deleted on the slave (using a "deleted" column) and then queue a
delete query to be sent to the master.  (So you don't keep telling the
client that the record exists since the database sync hasn't caught up yet).
Just some thoughts to add to JTs.

--Chris

----- Original Message -----
From: "John Todd" <jtodd at loligo.com>
To: <asterisk-dev at lists.digium.com>
Sent: Wednesday, September 17, 2003 1:41 AM
Subject: Re: [Asterisk-Dev] Resource: RVM Server

> >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
> _______________________________________________
> Asterisk-Dev mailing list
> Asterisk-Dev at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-dev
>