Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A default app should serve i18n audio via HTTP #570

Open
benlangfeld opened this issue Jun 19, 2015 · 7 comments
Open

A default app should serve i18n audio via HTTP #570

benlangfeld opened this issue Jun 19, 2015 · 7 comments
Milestone

Comments

@benlangfeld
Copy link
Member

No description provided.

@benlangfeld benlangfeld added this to the 3.0.0 milestone Jun 19, 2015
@bklang
Copy link
Member

bklang commented Jun 19, 2015

If we do this, we should add a note somewhere, perhaps under a Performance section, that this should be offloaded to either direct filesystem access or a separate process.

Also, how does this work with Asterisk?

@benlangfeld
Copy link
Member Author

The intention of this is for apps where FS/* do not share a filesystem with the app to work out of the box.

As yet Asterisk still does not play nicely with this idea, unlike every other IVR platform in existence :)

@nathansamson
Copy link

Hi, to be performant can we implement something like

  • Ahn comes with a (simple) webserver built in (rack based?)
  • The app comes with a set of audio files
  • as benlangfeld mentioned, the app might not be on the same host as the VoiP platform (asterisk, freeswitch, ...)
  • On startup ahn calculates the hash of the audio files in the "assets/audio" directory
  • when play_asset "myfile.mp3" it will send to VOIP: http://ahn-webserver/assets/myfile-hash.mp3
  • This will have a very long cache timeout,
  • next time this audio file is sent the VOIP platform will (hopefully) decide it still has the file in cache, and not even do a http request, but just load from disk.

Disadvantage

  • AHN needs to come with a webserver (or this can be offloaded to nginx/apache, but then the webserver config might be hard to setup, and if done wrong might not benefit)
  • The AHN service needs to open an addtional port/attack vector
  • We need to assume VOIP platform will come with decent caching system

Advantages

  • No setup needed for users to play asset files bundled with the application, and no shared disk with the platform.
    Think http://12factor.net/

I might have misunderstood the original idea, but I think this captures it?

Note: the other way should be somehow possible as well (recording an audio file, and then doing something with it on the AHN platform).

@bklang
Copy link
Member

bklang commented Jun 23, 2015

@nathansamson Great suggestions! And good news:

Ahn comes with a (simple) webserver built in (rack based?)

This is already done! See #569

The app comes with a set of audio files

This is also done. See #557, which includes English and Italian "Hello World" prompts

Regarding your caching questions, there is a document cache available in Virginia, which was the basis for our built-in HTTP server in Adhearsion. For now we've elected to leave the document cache out, but it will likely be resurrected as a separate plugin. Check the implementation and documentation.

However, the caching we've done so far has been for GRXML and SSML documents, since they can be expensive to generate. We've not done caching for audio files, since they are static and don't require computation time to create. Can you go into more detail about what you are trying to solve by hashing & caching them?

@nathansamson
Copy link

The main use case seems to be where the Freeswitch platform (or Asterisk, or ...) is on a different host than the Adhearsion platform.

Imagine now AHN serving audio files via a web server.

Call flow

  • AHN (App) -> FS: Play file http://xxxx
  • FS -> AHN (Web): HTTP: GET http://xxxx
  • AHN (Web) -> FS: Serving the file, if a longer tune could even be megabytes.

Doing this 10s of times per second is obviously too expense for the bandwitdh usage, and also latencies to setup TCP connections might kill the peformance of the app.

Hence why Freeswitch should cache the files locally. But if you give every file a unique (hashed) name, whenever the file changes (and AHN is restarted) Freeswitch would immediately download the new file.
You can just keep the same file name, and work with Cache timeouts, or even do a HEAD request (only looking if there is an updated file without downloaded the actual file if not needed), but that will lead to either stale caches, or worse performance as the TCP connection for the HTTP call still needs to be done. And yes, you can keep the TCP connection open, and HTTP2 will even be better, but still if you don't need to access the network, then don't.

Unless I am missing something
Note that this is just a shameloss copy&paste from Rails' assets pipeline component.

And now I write this, it would even be better if the app could contain mp3 files, and then when pipelining the files could be converted to more suitable audio formats before starting to serve them. But thats another report I would say

@emcgee
Copy link

emcgee commented Jun 23, 2015

Note that using mod_http_cache or mod_httapi already include built-in caching mechanisms on the FreeSWITCH layer for audio files. Unsure if Asterisk has something similar.

@benlangfeld
Copy link
Member Author

I think @nathansamson has got this dead on. Nathan, do you have any interest in contributing this feature for Adhearsion 3.0?

@benlangfeld benlangfeld modified the milestones: 3.0.0, 3.1.0 Jan 5, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants