[asterisk-app-dev] Who uses the ari/sounds resource?

[George Joseph]

On Mon, Jan 21, 2019 at 2:45 PM sduthil at wazo.io <sduthil at wazo.io> wrote:

> On 2019-01-21 10:42 a.m., George Joseph wrote:
> > and what do you use it for?
>
> I assume that you're talking about the /sounds resource available in ARI
> [1].
>
> At Wazo [2], we use the /sounds resource to list the sound files that
> are register in Asterisk.
>
> It allows us to implement a REST API that gives an overview of what
> sound files are available and in what languages.
>
> This REST API is then used to display the list of sound files in a web
> page, or to select a sound file in an application, e.g. when creating an
> IVR and selecting a sound file to play. The REST API is also used to
> list the available languages for sound files.
>
> We have used the /sounds resource when we could, but we still had to
> access the file system directly at some point in order to offer more
> features in our REST API, like uploading custom sounds, streaming the
> sound files or accessing recording files.
>
> [1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+16+Sounds+REST+API
> [2] http://wazo.community/
>
> --
> Sébastien Duthil
> Wazo developer
>

Thanks Sébastien.

What kind of response time are you getting when you retrieve the full list?

The reason I'm asking is that when Asterisk starts, we pre-populate an
internal cache (media_index) with all the sounds which, depending on which
languages and formats are installed, could easily be 20,000 files.  In some
instances, users are creating symlinks inside the sounds language
directories to other places (like voicemail) which now will also get
indexed.  In one case, we had a customer with an effective list of over
800,000 sound files.  This takes quite a bit of memory.  What we're trying
to determine is the value of the cache considering that we're only caching
directory entries (not contents) which the filesystem has already got
cached.  In tests of the ari/sounds resource, 95% of the response time is
constructing the JSON response, even when not using the cache.  I.E.  The
cache made no appreciable difference in the response time.









-- 
*George Joseph*
Digium - A Sangoma Company | Software Developer | Software Engineering
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
direct/fax: +1 256 428 6012
Check us out at: https://digium.com · https://sangoma.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-app-dev/attachments/20190122/5ed72e6d/attachment.html>