[asterisk-users] Retrieving/Streaming audio/video files from DBusing over AGI

[Danny Nicholas]

  _____  

From: asterisk-users-bounces at lists.digium.com
[mailto:asterisk-users-bounces at lists.digium.com] On Behalf Of A E [Gmail]
Sent: Monday, May 02, 2011 2:44 PM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] Retrieving/Streaming audio/video files from
DBusing over AGI

 

On Mon, May 2, 2011 at 3:23 PM, Danny Nicholas <danny at debsinc.com> wrote:

  _____  

From: asterisk-users-bounces at lists.digium.com
[mailto:asterisk-users-bounces at lists.digium.com] On Behalf Of A E [Gmail]
Sent: Monday, May 02, 2011 1:23 PM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] Retrieving/Streaming audio/video files from
DBusing over AGI

 

 

Just realised that this can better be described another way:

 

What we're essentially trying to do is be able to do any one of these

 

a) stream an audio/video file stored in the DB via AGI into the current
channel so that it plays on the phone

 

OR 

 

b) Do something like what Realtime Voicemail does, where it gets the file
from the DB, saves as a temp file in the user mailbox directory and then
plays it to the caller but this needs to happen through AGI, something along
the lines of readsql (a la func_odbc) inside of AGI

 

OR 

 

c) Anything else that's better than a) and b) above that someone can
suggest. 

 

P.S> I do know about the AGI AddOn of PUT SOUNDFILE and GET SOUNDFILE which
seems to be the only solution we can think of right now, other than of
course having the DB machine exporting the SAN volume as an NFS share for
the Asterisk server to mount, but that sounds like it'll be bad for
performance?

 

Thanks again

 

 

No takers? :(

[Danny Nicholas] 

In your original scenario you were opening yourself to probable latency
issues - I would personally pursue something along the line of option B
where I put the DB data into a temp file and ran a daemon to clear the temp
files hourly or daily as needed.  If the delivery worked well across most
LAN's/WAN's, some gung-ho developer would have hosed another part of
Asterisk trying to get that "bell and whistle" into the trunk.

 

Thanks Danny. I'm not so sure, that latency will be that much of an issue
being on the same physical GbE switch as the DB server without any other
traffic on it but sure, I know that a long time ago when I implemented
Realtime Voicemail, it worked pretty good, so I'll be happy with b). I guess
we do need to use that AGI AddOn of PUT SOUNDFILE after all. 

 

Would be good if more people can throw a few ideas around to see if there's
a smarter way to do it. Another idea we had was to dumb these files (since
they'll be very small in duration and thus in size) into a directory, run a
web-server and have AGI retrieve them using curl and just use "Background"
to play it. Thoughts?

[Danny Nicholas] 

IMO, adding curl to the mix is just going to introduce another possible
point of failure.  If they are that small, why not do a daemonized delivery
system?

 

By daemonized delivery system, I'm assuming you mean have some background
process running to transport these files from the DB to the asterisk server
and play them?

 

There are two issues with that

a) Sounds like too much I/O esp. with small files getting written and
deleted. 

 

b) What if there are several asterisk servers and the call can come into any
of the servers. Do we invoke the daemon at will, run a SQL query, extract it
from the DB, and transfer it to the asterisk server which initiated the
request and then play it? Sounds like it might add a bit more latency than
streaming it right inside the connection opened by AGI itself, although we
could not store these files in the DB and just have them sit on a dedicated
SAN volume and whenver a request comes in, we send it to the requesting
asterisk server. 

 

That's all of course if I understood you correctly.

[Danny Nicholas] 

For my .02, I would run the daemon on the central server and just push out
changed files - should be insignificant latency/overhead.  If you wanted to
run daemons, on every client, you could do that, but why?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20110502/b31b98ff/attachment.htm>