[asterisk-dev] [asterisk-users] [asterisk-app-dev] Proposed change to External Media API

Dan Jenkins dan at nimblea.pe
Fri Oct 18 08:11:39 CDT 2019


seems fair to me!

Looking forward to this George!

On Fri, Oct 18, 2019 at 1:57 PM George Joseph <gjoseph at digium.com> wrote:

> When we created the External Media addition to ARI we created an
> ExternalMedia object to be returned from the channels/externalMedia REST
> endpoint.  This object contained the channel object that was created plus
> local_address and local_port attributes (which are also in the Channel
> variables).  At the time, we thought that creating an ExternalMedia object
> would give us more flexibility in the future but as we created the sample
> speech to text application, we discovered that it doesn't work so well with
> ARI client libraries that a) don't have the ExternalMedia object defined
> and/or b) can't promote the embedded channel structure to a first-class
> Channel object.
>
> Example:
>
> A common pattern using the node-ari-client is to create a new Channel
> object, attach an event handler to it, then call originate on it like so...
>
> chan = ari.channels.Channel();
> chan.on('StasisStart', <add chan to bridge>);
> chan.originate(...);
>
> With the current ExternalMedia API:
>
> chan = ari.channels.Channel();
> chan.on('StasisStart', <add chan to bridge>);
> chan.externalMedia(...);
>
> This doesn't work however because the return from channels/externalMedia
> isn't a Channel.  It's an ExternalMedia object with an chlld object that
> looks like a Channel but has no Channel behavior attached to it.  The event
> handler added to chan will never get called and you can't attach handlers
> or perform any operations on ExternalMedia.channel because it's just a
> plain object, not an instance of Channel.
>
> Realistically, it doesn't make sense to force client library
> implementations to create special logic to promote the
> ExternalMedia.channel object into an instance of Channel and since External
> Media is a new capability anyway, it seems that the least painful solution
> is to remove the ExternalMedia object and have channels/externalMedia
> return a Channel object directly, just like channels/create and
> channels/originate.  As I described above, the only other attributes of
> ExternalMedia were the local address and port and they're already available
> in the Channel variables anyway.
>
> I would think that this change would make things easier for ARI developers
> but I wanted to make sure that you knew about it in advance and had a
> chance to comment.  There will be a Gerrit review up for this change later
> this morning.
>
> Also...  I mentioned the "sample speech to text application" above.  It's
> working and will be published next week.
>
> Comments?  Questions?
>
> --
> *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
>
> _______________________________________________
> asterisk-app-dev mailing list
> asterisk-app-dev at lists.digium.com
> http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> Check out the new Asterisk community forum at:
> https://community.asterisk.org/
>
> New to Asterisk? Start here:
>       https://wiki.asterisk.org/wiki/display/AST/Getting+Started
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20191018/0516ba5d/attachment.html>


More information about the asterisk-dev mailing list