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 <jc...@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
ule...@gmail.com
CyCore Systems
--
_____________________________________________________________________
-- 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
