[asterisk-dev] Audio to/from Asterisk

[Seán C. McCord]

I certainly like the foundation on which George's solution is based the
best.  It's just not useful to me particularly _until_ it is bidrectional.
There is something to be said about the accessibility of websocket as a
transport layer, as per Dan's suggestion.  It's more complicated than a
pure TCP socket (mainly impeded coding-wise on the Asterisk/C side), which
is why I didn't go that route with AudioSockets.  I'm still fairly
ambivalent as to the directionality of the connection initiation, but as
such, the direction doesn't matter to me.

So it _sounds_ like the ideal solution would be a George's solution which
added:
  - bidirectional audio
  - websocket transport option
  - arbitrary connection directionality

For _my_ case, the only one which really matters is the first.  I don't
imagine the second would be a big stretch to do.

However, the last seems to me to be a bit more complicated.  It would
require overcoming a number of hurdles which outbound conveniently bypasses:
  - communicating the allocated port (and IP address?) to the ARI (another
event, I'd assume)
  - determining the IP address (no small feat)
    - configured value? (messy)
    - media signaling address from a PJSIP transport? (not very flexible)
    - STUN-style discovery? (not designed for this)
    - ICE-style discovery?  (complicated, and even more needing of
coordination)
  - tear-down of listener
    - time-wise
    - after connection (what if nother ever connects?)
    - by command only
  - security
    - DoS vulnerability

Technically, you could say that interface binding is a problem with
outbound, too, of course.  It's just more commonly ignorable.

As you say, though, Rome was not actually built in a day (unless you play
Imperator: Rome, anyway).  George's foundation is clearly better.
AudioSockets merely works _now_.



On Wed, Jul 24, 2019 at 12:11 PM Joshua C. Colp <jcolp at digium.com> wrote:

> On Wed, Jul 24, 2019, at 1:06 PM, Dan Jenkins wrote:
> > oh I dont think it should ever live on the same websocket as the ARI
> > because of that very reason. But I mean if it could do ARI websocket,
> > inbound and outbound tcp connections thats as flexible as you'll ever
> > get and _anyone_ could build modern applications via any means.
> > starting development using ARI websocket and then potentially moving to
> > inbound/outbound whenever you need to scale further using an ARI proxy
> > for example...
> >
> > I just dont want this feature to come out and then be un-usable for X
> > number of applications. Surely Asterisk needs to be the most flexible
> > it can be?
>
> Rome wasn't built in a day. I think building a solid foundation that the
> various methods (inbound / outbound) can then be built on top of is good.
> Launching with one direction initially to get things flushed out, and then
> later adding other options is perfectly reasonable in my opinion - and can
> be done since we allow features to be added to release branches.
>
> --
> Joshua C. Colp
> Digium - A Sangoma Company | Senior Software Developer
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - US
> Check us out at: www.digium.com & www.asterisk.org
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev



-- 
Seán C. McCord
ulexus at gmail.com
CyCore Systems
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20190724/9ade38df/attachment.html>