[Asterisk-Dev] Resource: RVM Server
Ben Miller
bgmiller at nframe.com
Tue Sep 16 20:23:05 MST 2003
This sounds like an admirable goal. Take a look at some of the "storage
api" discussion that is in the bugnotes of
http://bugs.digium.com/bug_view_page.php?bug_id=0000153. The idea
behind a storage API is to allow a database or some other repository to
hold the data. To transfer/forward a vmail from one server to another
should be as simple as the controlling voicemail API retrieving the
message from one mailbox on one server and pushing it to another mailbox
on another server. The storage API should handle the details of
inserting it into the data store. The actual data store could be an
IMAP mail server or a SQL database, and the transport and client/server
protocol is already developed for you. (if not stunnel is an excellent
tool for encrypting any protocol).
Just my two cents from another person trying to conceptualize the same
thing.
Ben
-----Original Message-----
From: asterisk-dev-admin at lists.digium.com
[mailto:asterisk-dev-admin at lists.digium.com] On Behalf Of Tilghman
Lesher
Sent: Tuesday, September 16, 2003 4:33 PM
To: asterisk-dev at lists.digium.com
Subject: [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
_______________________________________________
Asterisk-Dev mailing list
Asterisk-Dev at lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-dev
More information about the asterisk-dev
mailing list