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

A E [Gmail] all.eforums at gmail.com
Mon May 2 14:43:46 CDT 2011


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20110502/b3f63f11/attachment-0001.htm>


More information about the asterisk-users mailing list