Re: [asterisk-dev] Module Deprecation, Default Not Building, and Removal
On Thu Oct 1, 2020 at 3:07 PM EDT, Joshua C. Colp wrote: > I think I personally hesitate to be so aggressive because long ago the > project was that way. We would push to remove things faster and such, > and the result was upset people and complaints. Years later I still had > people coming up to me at AstriCon talking about that stuff and how it screwed > them over. I think this is a key point which we, as developers and integrators can easily overlook. We're being pulled in two direction: one, we must always keep up-to-date in our implementations, and two, we must be able to work with what the customers are willing to use. Once things are deprecated, it is far easier to push the customer to do the right thing. Removal makes this easier. Thus, faster deprecation and removal is better for the integrator/developer/consultant. But we do not represent more than the barest fraction of the Asterisk user base. The greater portion is running production workloads with very low tolerance for either change or down-time, and are resultingly very conservative with their upgrades and loathe to spend great effort into managing those upgrades. If we accelerate deprecation, we may end up making the problem _worse_ (as it used to be), where users would simply not upgrade at all, because it was too difficult to do so. I agree that 4 years feels like an eternity to _me_, but to an operator working with very slim margins, it is not nearly so glacial. --- Seán C McCord ule...@gmail.com PGP/GPG: https://cycoresys.com/scm.asc -- _ -- 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
Re: [asterisk-dev] Module Deprecation, Default Not Building, and Removal
On Thu Oct 1, 2020 at 10:34 AM EDT, Joshua C. Colp wrote: > On Thu, Oct 1, 2020 at 11:32 AM Seán C McCord wrote: > > I, too, am in favour of this formalization. My only comment is that it > > seems to me that default-enabled being turned off would seem to come before > > deprecation. I can see the other side, though. > > > > I pondered that once, but I think to the user base it would be too much > of a drastic change. I think of it as a gradual nudging essentially. > Changing to deprecated and notes being informational for planning, default > enabled being an interrupt to actually do something. Of course there will > still > be individuals who don't see this stuff - but one can only do so much. I can understand that, but I also look at it from the packager's perspective: for the most generic appeal, I would generally want to enable everything which wasn't either experimental or deprecated. The default-enabled status would not be of interest. If packagers followed that way of thinking, you would, in fact, be _causing_ a more abrupt change. By switching this around, you would not impact lazy users who do not compile their own Asterisk at first, but would gain the attention (one hopes) of those who are ever so slightly more advanced. This bifurcates the impact to affect the more advanced users first, rather than the other way around. Seán C McCord ule...@gmail.com PGP/GPG: https://cycoresys.com/scm.asc -- _ -- 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
Re: [asterisk-dev] Module Deprecation, Default Not Building, and Removal
On Thu Oct 1, 2020 at 10:22 AM EDT, Jared Smith wrote: > On Thu, Oct 1, 2020 at 10:04 AM Joshua C. Colp > OK, thanks for the clarification. Consider me in favor of the process as > you outlined it, and also in favor of a more aggressive stance on > deprecation of modules that obviously aren't being heavily > used/maintained. I, too, am in favour of this formalization. My only comment is that it seems to me that default-enabled being turned off would seem to come before deprecation. I can see the other side, though. --- Seán C McCord ule...@gmail.com PGP/GPG: https://cycoresys.com/scm.asc -- _ -- 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
Re: [asterisk-dev] Audio to/from Asterisk
Sounds like good reasoning to me. On Wed, Aug 7, 2019, 11:23 Joshua C. Colp wrote: > On Wed, Aug 7, 2019, at 12:18 PM, Seán C. McCord wrote: > > I don't think checking channel events is too onerous, considering that > > IP-based connections would be able to fail, too. > > > > As far as the ARI API: I don't really care that much, but is there a > > reason to not simply use the existing channel tech/target syntax (e.g. > > ExternalMedia/media.host.example.com:6645)? > > Cramming options in the future in a dial string makes things rather > unfriendly (see chan_sip) - this is why I pushed for an explicit API to > create such a thing. It's also more approachable, and easier to document. > > -- > 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 -- _ -- 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
Re: [asterisk-dev] Audio to/from Asterisk
I don't think checking channel events is too onerous, considering that IP-based connections would be able to fail, too. As far as the ARI API: I don't really care that much, but is there a reason to not simply use the existing channel tech/target syntax (e.g. ExternalMedia/media.host.example.com:6645)? On Wed, Aug 7, 2019, 10:04 George Joseph wrote: > > > On Wed, Aug 7, 2019 at 7:28 AM Seán C. McCord wrote: > >> I would definitely prefer to have it be a "normal" channel, so that it >> interoperates with everything exactly as any other channel, especially as >> regarding bridges. I went back and forth a lot on this during the >> AudioSocket development. There are conveniences with having things >> automated/bundled, but flexibility is more important. >> > > The thinking now is to create an "externalMedia" sub-resource under > "channels" so "POST /channels/externalMedia" would give you a back a > channel you could do anything you want with. > > >> >> DNS is pretty important for me, since my deployments are generally all in >> an abstracted, dynamic environment (generally kubernetes), but I developed >> asteriskconfig to be able to reactively handle those kinds of changes and >> abstractions... so first pass no DNS? Sure. Ultimately, it's pretty >> important. >> > > Yeah OK. I'll might as well do it now then. The only downside is that > you'll have to look for events or do a GET on the channel to see if/when > it's connected. > > > >> >> >> On Wed, Aug 7, 2019 at 9:00 AM George Joseph wrote: >> >>> Thinking more about code organization and taxonomy... It might make >>> sense to make ExternalMedia a first-class object in it's own right. Rather >>> than calling "POST /channels//externalMedia" or "POST >>> /bridges//externalMedia" to create a new external media session, >>> you'd call "POST /externalMedias" and pass in the bridge or channel id you >>> want to act on. This prevents having to have external media code in both >>> the channels and bridges modules. >>> >>> Also thinking about DNS resolution. How important is it to be able to >>> specify a hostname for the external server, at least in the first release? >>> It complicates matters because the lookup has to be done asynchronously or >>> we risk locking ARI up if the lookup response time is slow. We'd have to >>> solve this later for TCP connection types anyway because the connection >>> handshake could also be be slow but I'm wondering if I can defer the async >>> processing for a bit. >>> >>> On Thu, Aug 1, 2019 at 6:52 AM George Joseph wrote: >>> >>>> So here's where we're at with adding this capability... >>>> >>>> Initial release: >>>> >>>>- Two new ARI endpoints, one on channel and one on bridge: >>>> - /channels//externalMedia >>>> - /bridges//externalMedia >>>>- You can specify: >>>> - host: : >>>> - encapsulation: rtp (with others added later) >>>> - transport: udp (with tcp, ws, tls, http, etc added later) >>>> - connection_type: client (with server added later) >>>> - format: >>>> - direction: both (with in, out supported later) >>>> - mixed: true (at some later date, we may allow each channel in >>>> a bridge or each direction on a channel to be placed in a separate >>>> audio >>>> channel) >>>> >>>> We'll use chan_rtp (rtp, udp, client) as the initial underlying >>>> provider but we'll create a mechanism to easily add other providers. Also >>>> in the initial release, calling externalMedia on a channel that's already >>>> in a bridge will fail. In this case, you should call externalMedia on the >>>> bridge. We'll revisit this after we get some real-world feedback. We may >>>> be able to use the snoop functionality to isolate a single channel in a >>>> bridge for instance. >>>> >>>> For later releases: >>>> What are your priorities for payload encapsulation and transport? >>>> >>>> >>>> >>>> >>>> On Mon, Jul 29, 2019 at 9:43 AM George Joseph >>>> wrote: >>>> >>>>> >>>>> >>>>> On Mon, Jul 22, 2019 at 3:05 AM Jean Aun
Re: [asterisk-dev] Audio to/from Asterisk
;>>> even AGI (all the different ways) - I need that same process to handle the >>>> media I'm sending and receiving to/from asterisk and so if I already have >>>> that process up and then Asterisk calls out to a generic URI then that >>>> media will never make it back to the original nodejs process. >>>> >>>> I think its of upmost importance that I be able to ask asterisk for a >>>> host:port pair and then be able to connect to that port from my external >>>> application. >>>> >>>> What do people think? I thought we'd talked about this mechanism at >>>> devcon? >>>> >>>> Dan >>>> >>>> On Sat, Jul 20, 2019 at 2:39 PM Dan Jenkins wrote: >>>> >>>>> Just going to chime in and say I don't see a one way audio solution >>>>> as enough and I'd worry that doing that would lead to "oh but only so many >>>>> people need to chuck audio in". This has been discussed at at least 3 >>>>> devcons now. >>>>> >>>>> On Thu, Jul 18, 2019 at 2:09 PM Seán C. McCord >>>>> wrote: >>>>> >>>>>> I certainly don't mind if a better-designed system comes along and >>>>>> obviates my AudioSocket implementation. I built it because I needed it. >>>>>> However, bidirectional audio flow is critical for me (speech synthesis, >>>>>> external interfacing, real-time processed audio, processed injections, >>>>>> etc). While I would actually prefer a system which was a bit beefier >>>>>> than >>>>>> my own (simple protocol aside, there's a good deal of range between my >>>>>> protocol and MRCP), my meagre C skills (and patience) don't allow me to >>>>>> venture forth into those difficult waters. >>>>>> >>>>>> I do like the separate connection (unlike Wazo's) and the support of >>>>>> TLS (unlike mine)... and yours is certainly (even without looking) more >>>>>> performant. Mine also probably needs a multi-threaded, >>>>>> dedicated-receiver >>>>>> approach like most of the other channels which handle socket-received >>>>>> media, rather than the simple non-blocking I/O with null frame insertion. >>>>>> No perfect solution yet. >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Jul 18, 2019 at 8:01 AM George Joseph >>>>>> wrote: >>>>>> >>>>>>> Hey Guys, >>>>>>> >>>>>>> I was on vacation when this thread happened but I'm also working on >>>>>>> this now. The implementation uses the existing ARI channel and bridge >>>>>>> recording endpoints ands add the ability to specify a URI in the form of >>>>>>> (udp|tcp|tls)://hostname:port to stream the media. This makes use of >>>>>>> the >>>>>>> existing chan_bridge_media driver and only requires a scheme handler >>>>>>> similar to Seán's res_audiosocket. This implementation is more >>>>>>> targeted >>>>>>> to real-time speech recognition/transcription/captioning and is >>>>>>> therefore >>>>>>> one way (outbound). A future enhancement is planned that would send >>>>>>> each >>>>>>> channel in a bridge as a separate audio channel in a multi-channel >>>>>>> container. >>>>>>> >>>>>>> I'm not suggesting that this should replace Seán's audiosocket stuff >>>>>>> but I did want to let you know what was in the pipeline. >>>>>>> >>>>>>> george >>>>>>> >>>>>>> On Fri, Jul 5, 2019 at 7:38 AM Seán C. McCord >>>>>>> wrote: >>>>>>> >>>>>>>> Solutions such as Jack are non-network oriented and severely >>>>>>>> limited in scalability. There are, of course, many other options, but >>>>>>>> the >>>>>>>> closest are chan_rtp and chan_nbs. RTP is a good option except for the >>>>>>>> difficulty for non-telephony people to intera
Re: [asterisk-dev] Audio to/from Asterisk
Sorry, typing on the phone while wasting away on the tarmac. https://github.com/CyCoreSystems/asterisk-k8s-demo On Thu, Aug 1, 2019, 14:52 Mohit Dhiman wrote: > Hey Sean, I would really like to try your Implementation of Google ASR but > the link (Https://GitHub.com/CyCoreSystems/asterisk-k8d-demo > <https://github.com/CyCoreSystems/asterisk-k8d-demo>) you just provided > isn't working. > > On Fri, 2 Aug 2019 at 00:19, Seán C. McCord wrote: > >> Just as a mention, though it uses my AudioSocket rather than what George >> is talking about, I do have a complete example of bidirectional >> communication with Google TTS and speech-to-text. >> >> Https://GitHub.com/CyCoreSystems/asterisk-k8d-demo >> >> >> On Thu, Aug 1, 2019, 14:44 Mohit Dhiman wrote: >> >>> This is getting really interesting now because just a few days ago I >>> started exploring about how can I get a continuous media stream (without >>> blocking the channel in the Dialplan) out of Asterisk and feed it to the >>> Google ASR engine. >>> I hope this feature comes out soon as it will be a massive help towards >>> my project. >>> >>> Thanks >>> Mohit Dhiman >>> >>> >>> On Thu, 1 Aug 2019 at 23:48, George Joseph wrote: >>> >>>> >>>> >>>> On Thu, Aug 1, 2019 at 12:10 PM George Joseph >>>> wrote: >>>> >>>>> >>>>> >>>>> On Thu, Aug 1, 2019 at 9:56 AM marek wrote: >>>>> >>>>>> is there someone who can write/share small HOWTO test it with >>>>>> https://cloud.google.com/speech-to-text/ ? >>>>>> >>>>> You won't be able to use the new capability directly with Google or >>>>> any other public speech to text service provider as they all have >>>>> different >>>>> access mechanisms and protocol constraints. We also wouldn't know what to >>>>> do with the returned transcription. Instead, you'd write an ARI >>>>> application using the technology of your own choosing to act as the proxy >>>>> between Asterisk and your chosen service provider. Most of the service >>>>> providers have api toolkits to help with that. What you then do with the >>>>> returned transcription is up to you. >>>>> >>>> >>>> Actually, I just talked to the boss (Matt Fredrickson) and we agreed >>>> that we could provide a bare-bones example ARI app to talk to Google. >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> Dne 01/08/2019 v 16:54 George Joseph napsal(a): >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Aug 1, 2019 at 7:36 AM Joshua C. Colp >>>>>> wrote: >>>>>> >>>>>>> On Thu, Aug 1, 2019, at 10:28 AM, George Joseph wrote: >>>>>>> > So here's where we're at with adding this capability... >>>>>>> > >>>>>>> > Initial release: >>>>>>> > * Two new ARI endpoints, one on channel and one on bridge: >>>>>>> >* /channels//externalMedia >>>>>>> >* /bridges//externalMedia >>>>>>> >>>>>>> What do these return? How do you stop external media at a future >>>>>>> time? >>>>>>> >>>>>> >>>>>> They'd return an ExternalMedia object which would contain an ID along >>>>>> with other pertinent data that can be gleaned from the underlying >>>>>> provider. For chan_rtp, it could be the local IP address and local port. >>>>>> To stop the streaming, you'd make a DELETE request on the ExternalMedia >>>>>> resource. >>>>>> >>>>>> This is similar to how we do Playback and Record today. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> -- >>>>>>> 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 >>>>>>> &g
Re: [asterisk-dev] Audio to/from Asterisk
Just as a mention, though it uses my AudioSocket rather than what George is talking about, I do have a complete example of bidirectional communication with Google TTS and speech-to-text. Https://GitHub.com/CyCoreSystems/asterisk-k8d-demo On Thu, Aug 1, 2019, 14:44 Mohit Dhiman wrote: > This is getting really interesting now because just a few days ago I > started exploring about how can I get a continuous media stream (without > blocking the channel in the Dialplan) out of Asterisk and feed it to the > Google ASR engine. > I hope this feature comes out soon as it will be a massive help towards my > project. > > Thanks > Mohit Dhiman > > > On Thu, 1 Aug 2019 at 23:48, George Joseph wrote: > >> >> >> On Thu, Aug 1, 2019 at 12:10 PM George Joseph wrote: >> >>> >>> >>> On Thu, Aug 1, 2019 at 9:56 AM marek wrote: >>> is there someone who can write/share small HOWTO test it with https://cloud.google.com/speech-to-text/ ? >>> You won't be able to use the new capability directly with Google or any >>> other public speech to text service provider as they all have different >>> access mechanisms and protocol constraints. We also wouldn't know what to >>> do with the returned transcription. Instead, you'd write an ARI >>> application using the technology of your own choosing to act as the proxy >>> between Asterisk and your chosen service provider. Most of the service >>> providers have api toolkits to help with that. What you then do with the >>> returned transcription is up to you. >>> >> >> Actually, I just talked to the boss (Matt Fredrickson) and we agreed that >> we could provide a bare-bones example ARI app to talk to Google. >> >> >> >>> >>> >>> >>> >>> >>> Dne 01/08/2019 v 16:54 George Joseph napsal(a): On Thu, Aug 1, 2019 at 7:36 AM Joshua C. Colp wrote: > On Thu, Aug 1, 2019, at 10:28 AM, George Joseph wrote: > > So here's where we're at with adding this capability... > > > > Initial release: > > * Two new ARI endpoints, one on channel and one on bridge: > >* /channels//externalMedia > >* /bridges//externalMedia > > What do these return? How do you stop external media at a future time? > They'd return an ExternalMedia object which would contain an ID along with other pertinent data that can be gleaned from the underlying provider. For chan_rtp, it could be the local IP address and local port. To stop the streaming, you'd make a DELETE request on the ExternalMedia resource. This is similar to how we do Playback and Record today. > > -- > 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 -- *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 -- _ -- 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 >>> >>> >>> >>> -- >>> *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 >>> >>> >> >> -- >> *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 >> >> -- >> _ >> -- 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 > > -- > _ > -- 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 -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev
Re: [asterisk-dev] Audio to/from Asterisk
While I know there are people who try to maximize the number of concurrent calls, that's really not an issue for me. I dimension these systems to about 200 calls per Asterisk box. Even if that were 1000, port exhaustion just isn't a concern. On Thu, Jul 25, 2019 at 12:54 PM George Joseph wrote: > First, I think bidirectionality is a given now. Still thinking about the > in vs out thing. > > Does anyone have concerns about port exhaustion on an Asterisk instance > where we're streaming a large number of calls? Basically, you're adding a > port for every call being streamed. I've been considering an "RTP > Muxing" approach where a single module would open a connection to the > audio server and ALL media would flow to/from it over that single > connection with metadata to distinguish channel/bridge, etc. > > > On Wed, Jul 24, 2019 at 10:30 AM Seán C. McCord wrote: > >> 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 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 >>> >>> -- >>> __
Re: [asterisk-dev] Audio to/from Asterisk
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 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
Re: [asterisk-dev] Audio to/from Asterisk
This sounds like a case where Wazo's solution (though it presently is only single-direction) might be the best for you, since it piggy-backs the audio data on the same websocket as ARI. For me, that's worse than useless, since I multiplex the ARI amongst a wide range of processing nodes, but if you want to minimize additional routing and orchestration, you can't beat just simply using the same websocket that your control channel is on. That's about as coupled as it gets. On Wed, Jul 24, 2019 at 11:51 AM Dan Jenkins wrote: > So even in its most basic form - lets take a Node process thats made a > websocket connection to Asterisk for ARI purposes... within the event loop > for that ARI session, I cant easily handle the audio going out to asterisk > within the same "thread" (I use that term loosely) because when the > connection comes into Node (say im listening as a audio providing server on > port X ready),,, those two things within the same node process are within > two separate events within the same process - as soon as you start sharing > state outside of that ARI "thread" thats dealing with that one session we > get into dangerous territory. I'd much rather have a websocket out to > Asterisk, have an event come in via websocket to say heres a new session > and we create an ARI "thread" within that process. When I need to make a > session with bidirectional audio in/out of asterisk to my process I should > be able to ask the ARI for where to connect to in order to send/receive > that media, make that connection with a uuid and then instruct ARI to > bridge the original channel and the new one. > > Simple ARI apps shouldnt need messaging between apps to handle > instructions and media. The same process and event loop should be able to > handle both. > > Theres a lot of personal preference in all of that I do grant you. But I > do believe that I shouldnt have to make specific node processes available > to external resources but asterisk already is (to a degree). I see both > sides of the coin - im basically saying i want to build it this way and > youre saying, but i dont want to have asterisk open to external > applications so who wins? In an ideal world you should be able to do > both because Asterisk needs to be a flexible media engine! > > On Wed, Jul 24, 2019 at 6:33 PM Seán C. McCord wrote: > >> AudioSocket was initially designed precisely to be able to slot into the >> role of MRCP, for a client who was more interested in designing their own >> system (and paying for its development) than paying the license fees for >> UniMRCP. George's solution should also fit that need. I have since used >> AudioSocket for a number of other operations, but that was its original >> impetus. >> >> The channel interface for AudioSocket really should solve the ARI use >> case (the app interface is simpler for AMI and AGI). >> >> As to the port-in rather than port-out mechanism... I'm sure there are >> definitely use cases for it, but in any sufficiently large system, you're >> going to have to do routing one way or the other: to Asterisk or from >> Asterisk. Ultimately, you are going to have multiple instances of all >> components, so the directionality of the socket connection doesn't seem to >> me to be a large factor. That is to say, adding an inbound port to >> Asterisk to initiate the two-way socket doesn't seem to be particularly >> more useful than outgoing. Am I missing something, Dan, about your >> scenarios? I didn't really design AudioSocket with inbound connections in >> mind at all. >> >> >> On Wed, Jul 24, 2019 at 10:03 AM George Joseph >> wrote: >> >>> >>> >>> On Wed, Jul 24, 2019 at 7:11 AM Dan Cropp wrote: >>> >>>> Out of curiosity, would this be an alternative to unimrcp’s asterisk >>>> support for MRCP (TTS/ASR)? >>>> >>> >>> Well it wasn't intended to implement MRCP but yes, it's intended to >>> provide the same very-high-level functionality controlled via ARI. >>> >>> >>> >>>> >>>> >>>> >>>> >>>> *From:* asterisk-dev *On >>>> Behalf Of *Luca Pradovera >>>> *Sent:* Monday, July 22, 2019 3:12 AM >>>> *To:* Asterisk Developers Mailing List >>>> *Subject:* Re: [asterisk-dev] Audio to/from Asterisk >>>> >>>> >>>> >>>> Hello, >>>> >>>> I remember this being talked about, and it's essentially tied to the >>>> mechanism that would al
Re: [asterisk-dev] Audio to/from Asterisk
AudioSocket was initially designed precisely to be able to slot into the role of MRCP, for a client who was more interested in designing their own system (and paying for its development) than paying the license fees for UniMRCP. George's solution should also fit that need. I have since used AudioSocket for a number of other operations, but that was its original impetus. The channel interface for AudioSocket really should solve the ARI use case (the app interface is simpler for AMI and AGI). As to the port-in rather than port-out mechanism... I'm sure there are definitely use cases for it, but in any sufficiently large system, you're going to have to do routing one way or the other: to Asterisk or from Asterisk. Ultimately, you are going to have multiple instances of all components, so the directionality of the socket connection doesn't seem to me to be a large factor. That is to say, adding an inbound port to Asterisk to initiate the two-way socket doesn't seem to be particularly more useful than outgoing. Am I missing something, Dan, about your scenarios? I didn't really design AudioSocket with inbound connections in mind at all. On Wed, Jul 24, 2019 at 10:03 AM George Joseph wrote: > > > On Wed, Jul 24, 2019 at 7:11 AM Dan Cropp wrote: > >> Out of curiosity, would this be an alternative to unimrcp’s asterisk >> support for MRCP (TTS/ASR)? >> > > Well it wasn't intended to implement MRCP but yes, it's intended to > provide the same very-high-level functionality controlled via ARI. > > > >> >> >> >> >> *From:* asterisk-dev *On Behalf >> Of *Luca Pradovera >> *Sent:* Monday, July 22, 2019 3:12 AM >> *To:* Asterisk Developers Mailing List >> *Subject:* Re: [asterisk-dev] Audio to/from Asterisk >> >> >> >> Hello, >> >> I remember this being talked about, and it's essentially tied to the >> mechanism that would allow streaming ASR/TTS services to be used. >> >> +1 on this feature! >> >> >> >> On Mon, Jul 22, 2019 at 10:01 AM Dan Jenkins wrote: >> >> Also coming back to this with some real-life case issues I'm currently >> facing and why I can't use audiosocket :( >> >> >> >> I need to be able to ask the ARI/AGI/AMI for an IP/port combo and for an >> external app to then connect into asterisk rather than asterisk connecting >> to a URI elsewhere. Lets say I already have a nodejs (or any other >> language) process taking care of controlling that call via ARI or even AGI >> (all the different ways) - I need that same process to handle the media I'm >> sending and receiving to/from asterisk and so if I already have that >> process up and then Asterisk calls out to a generic URI then that media >> will never make it back to the original nodejs process. >> >> >> >> I think its of upmost importance that I be able to ask asterisk for a >> host:port pair and then be able to connect to that port from my external >> application. >> >> >> >> What do people think? I thought we'd talked about this mechanism at >> devcon? >> >> >> >> Dan >> >> >> >> On Sat, Jul 20, 2019 at 2:39 PM Dan Jenkins wrote: >> >> Just going to chime in and say I don't see a one way audio solution as >> enough and I'd worry that doing that would lead to "oh but only so many >> people need to chuck audio in". This has been discussed at at least 3 >> devcons now. >> >> >> >> On Thu, Jul 18, 2019 at 2:09 PM Seán C. McCord wrote: >> >> I certainly don't mind if a better-designed system comes along and >> obviates my AudioSocket implementation. I built it because I needed it. >> However, bidirectional audio flow is critical for me (speech synthesis, >> external interfacing, real-time processed audio, processed injections, >> etc). While I would actually prefer a system which was a bit beefier than >> my own (simple protocol aside, there's a good deal of range between my >> protocol and MRCP), my meagre C skills (and patience) don't allow me to >> venture forth into those difficult waters. >> >> >> >> I do like the separate connection (unlike Wazo's) and the support of TLS >> (unlike mine)... and yours is certainly (even without looking) more >> performant. Mine also probably needs a multi-threaded, dedicated-receiver >> approach like most of the other channels which handle socket-received >> media, rather than the simple non-blocking I/O with null frame insertion. >> No perfect solution yet. >>
Re: [asterisk-dev] Audio to/from Asterisk
I certainly don't mind if a better-designed system comes along and obviates my AudioSocket implementation. I built it because I needed it. However, bidirectional audio flow is critical for me (speech synthesis, external interfacing, real-time processed audio, processed injections, etc). While I would actually prefer a system which was a bit beefier than my own (simple protocol aside, there's a good deal of range between my protocol and MRCP), my meagre C skills (and patience) don't allow me to venture forth into those difficult waters. I do like the separate connection (unlike Wazo's) and the support of TLS (unlike mine)... and yours is certainly (even without looking) more performant. Mine also probably needs a multi-threaded, dedicated-receiver approach like most of the other channels which handle socket-received media, rather than the simple non-blocking I/O with null frame insertion. No perfect solution yet. On Thu, Jul 18, 2019 at 8:01 AM George Joseph wrote: > Hey Guys, > > I was on vacation when this thread happened but I'm also working on this > now. The implementation uses the existing ARI channel and bridge recording > endpoints ands add the ability to specify a URI in the form of > (udp|tcp|tls)://hostname:port to stream the media. This makes use of the > existing chan_bridge_media driver and only requires a scheme handler > similar to Seán's res_audiosocket. This implementation is more targeted > to real-time speech recognition/transcription/captioning and is therefore > one way (outbound). A future enhancement is planned that would send each > channel in a bridge as a separate audio channel in a multi-channel > container. > > I'm not suggesting that this should replace Seán's audiosocket stuff but I > did want to let you know what was in the pipeline. > > george > > On Fri, Jul 5, 2019 at 7:38 AM Seán C. McCord wrote: > >> Solutions such as Jack are non-network oriented and severely limited in >> scalability. There are, of course, many other options, but the closest are >> chan_rtp and chan_nbs. RTP is a good option except for the difficulty for >> non-telephony people to interact with it. NBS is deprecated, undocumented, >> and unsupported by any locatable resources. >> >> While the original app interface from last year required dialplan, the >> channel interface does not. It is a plain channel which can be used by ARI >> directly. >> >> >> On Fri, Jul 5, 2019, 15:28 Sylvain Boily wrote: >> >>> Hello Seán, >>> >>> On 2019-07-05 4:45 a.m., Seán C. McCord wrote: >>> >>> A brief update: >>> >>> I have adapted my app_audiosocket from last year to become >>> chan_audiosocket, a full bidirectional audio channel interface for Asterisk >>> to any AudioSocket service (which itself is a dead-simple implementation). >>> I'll be demoing it in my talk next week at CommCon, for anyone who might be >>> interested. I'm going to try to have it ready to push to gerrit for review >>> this weekend. >>> >>> >>> I'll be there. >>> >>> >>> For now, you can see it in the 'channel' branch of >>> github.com/CyCoreSystems/audiosocket. >>> >>> >>> This is very different from what we did. You need dialplan to use it. In >>> our case we don't need any dialplan to use it, it's more ARI approach. >>> >>> Sylvain >>> >> -- >> _ >> -- 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 > > > > -- > *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 > > -- 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
Re: [asterisk-dev] Audio to/from Asterisk
Solutions such as Jack are non-network oriented and severely limited in scalability. There are, of course, many other options, but the closest are chan_rtp and chan_nbs. RTP is a good option except for the difficulty for non-telephony people to interact with it. NBS is deprecated, undocumented, and unsupported by any locatable resources. While the original app interface from last year required dialplan, the channel interface does not. It is a plain channel which can be used by ARI directly. On Fri, Jul 5, 2019, 15:28 Sylvain Boily wrote: > Hello Seán, > > On 2019-07-05 4:45 a.m., Seán C. McCord wrote: > > A brief update: > > I have adapted my app_audiosocket from last year to become > chan_audiosocket, a full bidirectional audio channel interface for Asterisk > to any AudioSocket service (which itself is a dead-simple implementation). > I'll be demoing it in my talk next week at CommCon, for anyone who might be > interested. I'm going to try to have it ready to push to gerrit for review > this weekend. > > > I'll be there. > > > For now, you can see it in the 'channel' branch of > github.com/CyCoreSystems/audiosocket. > > > This is very different from what we did. You need dialplan to use it. In > our case we don't need any dialplan to use it, it's more ARI approach. > > Sylvain > -- _ -- 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
Re: [asterisk-dev] Audio to/from Asterisk
A brief update: I have adapted my app_audiosocket from last year to become chan_audiosocket, a full bidirectional audio channel interface for Asterisk to any AudioSocket service (which itself is a dead-simple implementation). I'll be demoing it in my talk next week at CommCon, for anyone who might be interested. I'm going to try to have it ready to push to gerrit for review this weekend. For now, you can see it in the 'channel' branch of github.com/CyCoreSystems/audiosocket. On Fri, May 17, 2019 at 2:22 AM Sylvain Boily wrote: > > > On 2019-05-16 10:36 p.m., Matt Fredrickson wrote: > >> I talked with Matthew at the Kamailio World 2019 about this module and > >> he said to me George will start to work on this feature. Do you have > >> feedback or comment about this module? > > Hey Sylvain, > > > > Sorry, sounds like we had a bit of a misunderstanding. George did > > some research on prospective architectures around this functionality, > > but we have not committed to or engaged upon any work on it at this > > time. I did mention that George might have some new perspective on > > any submitted implementation or continued discussion due to some of > > the information he gained during his research though :-) > > > > Best wishes, and sorry about any confusion in our conversation. > > > Oh :), no worry, you know my english is clearly not the best héhé. > But this subject is open for everyone want to discuss about this nice > feature. > > Sylvain > > -- > _ > -- 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
Re: [asterisk-dev] Looking for developer for a custom dahdi/asterisk module
I'm happy to look over it and give you an estimate, off-list. Perhaps there will be others here who will also volunteer. https://cycoresys.com he...@cycoresys.com On Wed, Mar 27, 2019 at 1:31 PM Alvaro Bosch wrote: > Thanks Sean, we do have a large number of systems deployed (several > thousands of lines) so it's more cost effective than other solutions. > We're developing the specifications through reverse engineering it, > since there's almost no documentation, being an internal protocol from > the early 80's not standarized. Nevertheless it's quite straight > forward. > > El mié., 27 mar. 2019 a las 14:16, Seán C. McCord () > escribió: > > > > If you have the spec, and depending on your specific requirements, I can > probably get it done. However, it seems unlikely to be cost-effective > unless you have a large number of deployed systems to which this adaptation > will be applied. > > > > > > On Wed, Mar 27, 2019 at 12:04 PM Alvaro Bosch > wrote: > >> > >> Hi guys, > >> I've been addressed the challenge to connect asterisk to a legacy NEC > >> public system from the 80's that uses a custom protocol running over > >> X.25/LAPB on timeslot 16 of an E1. The rest of the channels are like > >> B-chans. > >> > >> I wonder if anyone can do it so I can hire the development services > >> for such task. > >> > >> Kind regards. > >> > >> -- > >> _ > >> -- 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 > > -- > _ > -- 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
Re: [asterisk-dev] Looking for developer for a custom dahdi/asterisk module
If you have the spec, and depending on your specific requirements, I can probably get it done. However, it seems unlikely to be cost-effective unless you have a large number of deployed systems to which this adaptation will be applied. On Wed, Mar 27, 2019 at 12:04 PM Alvaro Bosch wrote: > Hi guys, > I've been addressed the challenge to connect asterisk to a legacy NEC > public system from the 80's that uses a custom protocol running over > X.25/LAPB on timeslot 16 of an E1. The rest of the channels are like > B-chans. > > I wonder if anyone can do it so I can hire the development services > for such task. > > Kind regards. > > -- > _ > -- 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
Re: [asterisk-dev] ARI, Stasis, and Dialplan
Nice! Thanks, looking at it now. On Fri, Jan 25, 2019 at 10:22 AM Ben Ford wrote: > Hey all, > > Just a quick update - this functionality is now up for review on Gerrit, > and can be found here <https://gerrit.asterisk.org/#/c/asterisk/+/10882/>. > > More eyes on it would be helpful! > > On Thu, Dec 20, 2018 at 1:40 PM Seán C. McCord wrote: > >> As Josh says, all calls would go to the app; the (completely >> non-user-facing and non-user-editable) context would be roughly >> equivalent to having fallthrough enabled and extension 's' going to >> the Stasis App. You should not be able to assign an existing real >> context to an ARI app. That would lead to confusion, which is one of >> the reasons why I like the idea of having deterministic context names. >> >> As to the channel-in-bridge on ARI app transfer, I would fully expect >> that channel to stay in whatever bridge it may be. Bridges are >> logical link points between ARI apps anyway, and they can be >> manipulated by multiple ARI apps at any given time anyway (this >> assertion is from memory... it is possible I am mistaken here). Now, >> as to whether the ARI app should automatically gain a subscription to >> member bridges, that's a good question. I would lean toward not doing >> so, but I do not have a strong argument beyond simplicity. >> >> >> On Thu, Dec 20, 2018 at 1:25 PM Joshua C. Colp wrote: >> > >> > On Thu, Dec 20, 2018, at 2:14 PM, Corey Farrell wrote: >> > > How will the ARI/dialplan integration handle specific extensions? For >> > > example if I have a stasis app which registers itself to dialplan as >> > > 'somecontext', how does this integration decide which extensions are >> > > handled by the app? Does that app get calls for all extensions or only >> > > specific extensions? Do we create a new type of ARI app which would >> > > respond to PBX switch callbacks where all calls go to the stasis >> router >> > > app which then accepts or rejects calls based on the ARI apps own >> > > extension list? For example if we have a context: >> > > >> > > [from-outside] >> > > exten => 7002052000,1,Stasis(myapp) >> > > exten => 7002052001,1,Stasis(myapp) >> > > How do you envision replicating having these two extensions handled >> but >> > > all other extensions being invalid? >> > >> > The context would send all calls to that application (except for the h >> extension). That application would then be able to move that channel to >> another application according to its own routing logic if it wanted. >> > >> > -- >> > 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 > > > > -- > *Benjamin Ford* > Digium - A Sangoma Company | Software Engineer > 445 Jan Davis Drive NW - Huntsville, AL 35806 - US > <https://maps.google.com/?q=445+Jan+Davis+Drive+NW+-+Huntsville,+AL+35806+-+US&entry=gmail&source=g> > Check us out at: https://digium.com · https://sangoma.com > > > -- > _ > -- 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
Re: [asterisk-dev] ARI, Stasis, and Dialplan
As Josh says, all calls would go to the app; the (completely non-user-facing and non-user-editable) context would be roughly equivalent to having fallthrough enabled and extension 's' going to the Stasis App. You should not be able to assign an existing real context to an ARI app. That would lead to confusion, which is one of the reasons why I like the idea of having deterministic context names. As to the channel-in-bridge on ARI app transfer, I would fully expect that channel to stay in whatever bridge it may be. Bridges are logical link points between ARI apps anyway, and they can be manipulated by multiple ARI apps at any given time anyway (this assertion is from memory... it is possible I am mistaken here). Now, as to whether the ARI app should automatically gain a subscription to member bridges, that's a good question. I would lean toward not doing so, but I do not have a strong argument beyond simplicity. On Thu, Dec 20, 2018 at 1:25 PM Joshua C. Colp wrote: > > On Thu, Dec 20, 2018, at 2:14 PM, Corey Farrell wrote: > > How will the ARI/dialplan integration handle specific extensions? For > > example if I have a stasis app which registers itself to dialplan as > > 'somecontext', how does this integration decide which extensions are > > handled by the app? Does that app get calls for all extensions or only > > specific extensions? Do we create a new type of ARI app which would > > respond to PBX switch callbacks where all calls go to the stasis router > > app which then accepts or rejects calls based on the ARI apps own > > extension list? For example if we have a context: > > > > [from-outside] > > exten => 7002052000,1,Stasis(myapp) > > exten => 7002052001,1,Stasis(myapp) > > How do you envision replicating having these two extensions handled but > > all other extensions being invalid? > > The context would send all calls to that application (except for the h > extension). That application would then be able to move that channel to > another application according to its own routing logic if it wanted. > > -- > 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
Re: [asterisk-dev] ARI, Stasis, and Dialplan
Sorry if I was unclear. Yes, I would love to extend the "Continue" function to add App and AppArgs as an option to use instead of Context/Extension/Priority. "Originate" and "Create" both allow these already. Adding these to "Continue" would be very helpful. On Thu, Dec 13, 2018 at 2:45 PM Ben Ford wrote: > To elaborate on this further, would it be fine the way it is currently, > where you specify a context and extension, or is there any interest in > being able to alternatively specify an application and arguments to pass to > it? > > On Thu, Dec 13, 2018 at 12:37 PM Seán C. McCord wrote: > >> Absolutely. I really forgot about that, because I've just molded my >> design approach to maintain a single ARI application per node, but that >> extension to Continue (similar to Originate's App/AppArgs properties), >> would be enormously helpful. >> >> >> On Thu, Dec 13, 2018 at 11:47 AM Ben Ford wrote: >> >>> I think having a context that's created when the application starts >>> sounds like a solid approach. >>> >>> Another thing to consider is how to move from one application to the >>> next. Any thoughts on the use of /continue to tackle this? Is this >>> something you'd like to be able to make use of in your applications? >>> >>> On Wed, Dec 12, 2018 at 11:42 PM Anil Gupta >>> wrote: >>> >>>> +1 to the context idea >>>> >>>> Something like *context = stasis:app_name* would be nice. I presume >>>> this could be achieved by adding the functionality to the PBX module and >>>> most (if not all) channel drivers would work without modification. >>>> >>>> Thanks, >>>> Anil >>>> >>>> On Thu, Dec 13, 2018 at 2:16 AM Dan Jenkins wrote: >>>> >>>>> Oh I do remember the context idea - which seemed like a good idea at >>>>> the time because of not having to change much internally >>>>> >>>>> On Wed, Dec 12, 2018 at 7:07 PM Seán C. McCord >>>>> wrote: >>>>> >>>>>> Correction: when I said the "latter," I should have said the "third" >>>>>> option. The last option does not really work well, since _channels_ >>>>>> map to _contexts_, not CELs. >>>>>> On Wed, Dec 12, 2018 at 1:52 PM Seán C. McCord >>>>>> wrote: >>>>>> > >>>>>> > Neither of my previous emails appear to be showing up third >>>>>> time's >>>>>> > the charm? >>>>>> > >>>>>> > We had briefly discussed the idea of creating virtual >>>>>> context/dialplan >>>>>> > to handle this. The idea would be that a context and dialplan would >>>>>> > be internally and automatically generated which would direct calls >>>>>> > sent to that context directly to ARI. Since the impetus for this >>>>>> > feature was operational simplicity, not any kind of optimization of >>>>>> > Asterisk itself, the idea of a virtual dialplan should work well and >>>>>> > would seem to not cause much disruption or require much >>>>>> code-wrangling >>>>>> > elsewhere. >>>>>> > >>>>>> > I see a few ways that this might be implemented (at the user level): >>>>>> > - Upon connecting an ARI application, the additional URL parameter >>>>>> > "context" may be passed, which would create the virtual context and >>>>>> > pass all calls to that context to the ARI app. >>>>>> > - Add an ARI REST API call which creates a virtual context/dialplan >>>>>> > including, optionally, ARI parameters to be included with that call. >>>>>> > - Define an automatic naming scheme for virtual dialplans >>>>>> associated >>>>>> > with ARI applications and have them generated automatically when an >>>>>> > ARI application connects. For instance, the ARI application named >>>>>> > 'HOWDY' may have an automatically-generated context named >>>>>> > 'ari_autocontext_HOWDY'. >>>>>> > - Define a single context (say, 'ari_auto') whose _extensions_ map >>>>>> to >>>>>> >
Re: [asterisk-dev] ARI, Stasis, and Dialplan
Absolutely. I really forgot about that, because I've just molded my design approach to maintain a single ARI application per node, but that extension to Continue (similar to Originate's App/AppArgs properties), would be enormously helpful. On Thu, Dec 13, 2018 at 11:47 AM Ben Ford wrote: > I think having a context that's created when the application starts sounds > like a solid approach. > > Another thing to consider is how to move from one application to the next. > Any thoughts on the use of /continue to tackle this? Is this something > you'd like to be able to make use of in your applications? > > On Wed, Dec 12, 2018 at 11:42 PM Anil Gupta wrote: > >> +1 to the context idea >> >> Something like *context = stasis:app_name* would be nice. I presume this >> could be achieved by adding the functionality to the PBX module and most >> (if not all) channel drivers would work without modification. >> >> Thanks, >> Anil >> >> On Thu, Dec 13, 2018 at 2:16 AM Dan Jenkins wrote: >> >>> Oh I do remember the context idea - which seemed like a good idea at >>> the time because of not having to change much internally >>> >>> On Wed, Dec 12, 2018 at 7:07 PM Seán C. McCord wrote: >>> >>>> Correction: when I said the "latter," I should have said the "third" >>>> option. The last option does not really work well, since _channels_ >>>> map to _contexts_, not CELs. >>>> On Wed, Dec 12, 2018 at 1:52 PM Seán C. McCord >>>> wrote: >>>> > >>>> > Neither of my previous emails appear to be showing up third time's >>>> > the charm? >>>> > >>>> > We had briefly discussed the idea of creating virtual context/dialplan >>>> > to handle this. The idea would be that a context and dialplan would >>>> > be internally and automatically generated which would direct calls >>>> > sent to that context directly to ARI. Since the impetus for this >>>> > feature was operational simplicity, not any kind of optimization of >>>> > Asterisk itself, the idea of a virtual dialplan should work well and >>>> > would seem to not cause much disruption or require much code-wrangling >>>> > elsewhere. >>>> > >>>> > I see a few ways that this might be implemented (at the user level): >>>> > - Upon connecting an ARI application, the additional URL parameter >>>> > "context" may be passed, which would create the virtual context and >>>> > pass all calls to that context to the ARI app. >>>> > - Add an ARI REST API call which creates a virtual context/dialplan >>>> > including, optionally, ARI parameters to be included with that call. >>>> > - Define an automatic naming scheme for virtual dialplans associated >>>> > with ARI applications and have them generated automatically when an >>>> > ARI application connects. For instance, the ARI application named >>>> > 'HOWDY' may have an automatically-generated context named >>>> > 'ari_autocontext_HOWDY'. >>>> > - Define a single context (say, 'ari_auto') whose _extensions_ map to >>>> > the names of ARI applications. >>>> > >>>> > I am partial to the latter, since it seems to be the simplest, but the >>>> > second has merit, too, since it allows any number of associations and >>>> > additional execution parameters to be set. >>>> > >>>> > On Wed, Dec 12, 2018 at 11:22 AM Ben Ford wrote: >>>> > > >>>> > > Hey all, >>>> > > >>>> > > >>>> > > We’re looking into AstriCon feedback and one of the things we want >>>> to touch on is ARI -- specifically, the ability to not have to create an >>>> extensions.conf in order to dial into Stasis. Before we start working on >>>> this, we’d like some direction from the community on what people would be >>>> looking for. From a user perspective, how would you expect something like >>>> this to work? Where would you look for information on how to do this, or >>>> where it would be configured? Any feedback is welcome! >>>> > > >>>> > > >>>> > > Ben >>>> > > >>>> > > >>>> > > -- >>>> &g
Re: [asterisk-dev] ARI, Stasis, and Dialplan
Correction: when I said the "latter," I should have said the "third" option. The last option does not really work well, since _channels_ map to _contexts_, not CELs. On Wed, Dec 12, 2018 at 1:52 PM Seán C. McCord wrote: > > Neither of my previous emails appear to be showing up third time's > the charm? > > We had briefly discussed the idea of creating virtual context/dialplan > to handle this. The idea would be that a context and dialplan would > be internally and automatically generated which would direct calls > sent to that context directly to ARI. Since the impetus for this > feature was operational simplicity, not any kind of optimization of > Asterisk itself, the idea of a virtual dialplan should work well and > would seem to not cause much disruption or require much code-wrangling > elsewhere. > > I see a few ways that this might be implemented (at the user level): > - Upon connecting an ARI application, the additional URL parameter > "context" may be passed, which would create the virtual context and > pass all calls to that context to the ARI app. > - Add an ARI REST API call which creates a virtual context/dialplan > including, optionally, ARI parameters to be included with that call. > - Define an automatic naming scheme for virtual dialplans associated > with ARI applications and have them generated automatically when an > ARI application connects. For instance, the ARI application named > 'HOWDY' may have an automatically-generated context named > 'ari_autocontext_HOWDY'. > - Define a single context (say, 'ari_auto') whose _extensions_ map to > the names of ARI applications. > > I am partial to the latter, since it seems to be the simplest, but the > second has merit, too, since it allows any number of associations and > additional execution parameters to be set. > > On Wed, Dec 12, 2018 at 11:22 AM Ben Ford wrote: > > > > Hey all, > > > > > > We’re looking into AstriCon feedback and one of the things we want to touch > > on is ARI -- specifically, the ability to not have to create an > > extensions.conf in order to dial into Stasis. Before we start working on > > this, we’d like some direction from the community on what people would be > > looking for. From a user perspective, how would you expect something like > > this to work? Where would you look for information on how to do this, or > > where it would be configured? Any feedback is welcome! > > > > > > Ben > > > > > > -- > > Benjamin Ford > > Digium - A Sangoma Company | Software Engineer > > 445 Jan Davis Drive NW - Huntsville, AL 35806 - US > > Check us out at: https://digium.com · https://sangoma.com > > > > > > -- > > _________ > > -- 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 -- 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
Re: [asterisk-dev] ARI, Stasis, and Dialplan
Neither of my previous emails appear to be showing up third time's the charm? We had briefly discussed the idea of creating virtual context/dialplan to handle this. The idea would be that a context and dialplan would be internally and automatically generated which would direct calls sent to that context directly to ARI. Since the impetus for this feature was operational simplicity, not any kind of optimization of Asterisk itself, the idea of a virtual dialplan should work well and would seem to not cause much disruption or require much code-wrangling elsewhere. I see a few ways that this might be implemented (at the user level): - Upon connecting an ARI application, the additional URL parameter "context" may be passed, which would create the virtual context and pass all calls to that context to the ARI app. - Add an ARI REST API call which creates a virtual context/dialplan including, optionally, ARI parameters to be included with that call. - Define an automatic naming scheme for virtual dialplans associated with ARI applications and have them generated automatically when an ARI application connects. For instance, the ARI application named 'HOWDY' may have an automatically-generated context named 'ari_autocontext_HOWDY'. - Define a single context (say, 'ari_auto') whose _extensions_ map to the names of ARI applications. I am partial to the latter, since it seems to be the simplest, but the second has merit, too, since it allows any number of associations and additional execution parameters to be set. On Wed, Dec 12, 2018 at 11:22 AM Ben Ford wrote: > > Hey all, > > > We’re looking into AstriCon feedback and one of the things we want to touch > on is ARI -- specifically, the ability to not have to create an > extensions.conf in order to dial into Stasis. Before we start working on > this, we’d like some direction from the community on what people would be > looking for. From a user perspective, how would you expect something like > this to work? Where would you look for information on how to do this, or > where it would be configured? Any feedback is welcome! > > > Ben > > > -- > Benjamin Ford > Digium - A Sangoma Company | Software Engineer > 445 Jan Davis Drive NW - Huntsville, AL 35806 - US > Check us out at: https://digium.com · https://sangoma.com > > > -- > _ > -- 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
Re: [asterisk-dev] FW: Question about permit/deny in pjsip endpoints
I would suspect some syntax problem. Can you post the actual relevant config file bits rather than a paraphrase? On Mon, Oct 29, 2018 at 10:42 AM Floimair Florian wrote: > No one with any idea about this? > > > > > > - > > > > UPDATE: > > Additionally, I see this message in the logs: > > > > ["2018-10-25 07:52:40.6837"] WARNING[123176]: named_acl.c:333 > ast_named_acl_find: ACL 'deny/permit' does not exist. The ACL will be > marked as undefined and will automatically fail if applied. > > > > > > > > > > Hello all! > > > > I wanted to try limiting incoming SIP packets to the IP of my Kamailio > loadbalancer. > > Since I’m using a database backend I tried to achieve this using the > permit and deny attributes in ps_endpoints table. > > So I set permit=”192.168.1.10/32” and deny to “0.0.0.0/0”, and while this > seems to work in general, I get lots of the following WARNINGS in the logs: > > > > ["2018-10-25 07:41:34.7761"] WARNING[116934]: acl.c:740 ast_apply_acl: SIP > ACL: Rejecting '192.168.1.10' due to use of an invalid ACL 'deny/permit'. > > > > What is the problem with this configuration? > > Of course I could alternatively define a named ACL and assign it using > acl=name instead, but then what’s the point of the permit and deny options > after all? > > > > BR, Florian > -- > _ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > Astricon is coming up October 9-11! Signup is available at: > https://www.asterisk.org/community/astricon-user-conference > > asterisk-dev mailing list > To UNSUBSCRIBE or update options visit: >http://lists.digium.com/mailman/listinfo/asterisk-dev -- Seán C McCord CyCore Systems, Inc +1 888 240 0308 PGP/GPG: http://cycoresys.com/scm.asc -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Astricon is coming up October 9-11! Signup is available at: https://www.asterisk.org/community/astricon-user-conference asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Audio to/from Asterisk
Agreeing with Dan, and as I mentioned in the DevCon, app_audiosocket is the _wrong_ solution; it was simply an expedient solution. A channel interface seems to me to be the best approach, especially for interop with ARI. Maybe something as simple as chan_websocket would be sufficient (building on audiosocket, if there isn't already a better way). Websocket, being bidirectional and connection-oriented, falls well within the general needs which audiosocket was designed for. It's a bit more work to serve a websocket than a plain old TCP socket, but not _that_ much more. One of the flexibility features that the current app_audiosocket maintains is a run-time-selectable endpoint, which would be contrary to the existing channel drivers' designs. However, since this would always be an internally-initiated connection (not for receiving connections from the outside), I don't see this as the security risk that it may otherwise be. It could be argued, of course, that you could just use the existing WebRTC for this. The problem is that it is needlessly complicated and requires much adaptation to just simply pipe audio in and out for arbitrary (non-voIP) use. For the stuff I'm interested in, I _just_ want the bidirectional audio stream, a tag/label, and nothing else. The simpler the Asterisk-side interface, the better. On Tue, Oct 16, 2018 at 10:53 AM Dan Jenkins wrote: > Thanks for the reminder Matt. > > The minutes from devcon can be found here if anyone is interested - > https://wiki.asterisk.org/wiki/display/AST/astridevcon+2018+minutes > > At devcon we talked about the growing need to be able to read audio from a > channel and be able to pump audio back into a channel too from third party > applications. Historically we'd use app_jack or file descriptors in AGI etc > etc, but none of this really works very well for how a lot of us now build > applications - using ARI we build applications which run outside of > Asterisk's host OS and we don't have access to files/file descriptors etc > etc so we now want to be able to get access to this audio data via other > means (as well as not using Dialplan applications) > > Sean mentioned he'd made something that did a lot of what we wanted in his > "audiosocket" application - however its only a dialplan application which > isnt much use when it comes to apps built with ARI. > > We proposed a combination of a few ideas and this is where we should > probably have a discussion. My first idea was to be able to stream a > channel's audio via a http endpoint in the ARI which is great for taking > audio and piping it off to another provider to do speech recognition for > example but its no good for sending generated audio back into a channel > - at which point the conversation about audiosocket was brought up - other > than it being a tiny bit harder to get set up and get started, this is a > much better all round solution. I'd love to be able to pass into the ARI, > send audio to this IP at this port number, or doing a GET request to get > the IP and port for our app to go and connect to. > > All of us at devcon would love to hear more about what other real world > scenarios and what would really work for everyone. But for me, I'd plus 1 > either of those ARI slutions where I either tell asterisk where to send the > audio on a tcp socket, or i get told via the ARI where to connect to. > > Dan > > On Tue, Oct 16, 2018 at 2:16 PM Matt Fredrickson > wrote: > >> On Tue, Oct 9, 2018 at 12:09 PM Seán C. McCord wrote: >> > >> > Because several people raised the issue at DevCon, I figured it may be >> worth mentioning this: app_audiosocket. I haven't submitted it mainly due >> to the thought that no one else would fine it interesting. There exist >> other, similar ways to get audio out: app_jack, app_unimrcp, etc. I built >> this because of some special needs, and it is very convenient due to its >> extremely light weight. >> > >> > Regardless, should anyone be interested, here it is: >> > >> > https://github.com/CyCoreSystems/audiosocket >> > >> > The idea is to create a TCP socket to somewhere, pass some extremely >> simple metadata (a UUID), and broker audio between the channel and the >> socket. It is as simple as possible. >> >> For those who aren't aware, getting this pushed out to the -dev list >> was an AstriDevCon 2018 takeaway action item with regards to interop >> with web-based speech recognition APIs. I'd love to see more >> discussion and work on this topic, as I think that there stands much >> to be improved in Asterisk to better interoperate with some of the >> major speech recog
[asterisk-dev] Audio to/from Asterisk
Because several people raised the issue at DevCon, I figured it may be worth mentioning this: app_audiosocket. I haven't submitted it mainly due to the thought that no one else would fine it interesting. There exist other, similar ways to get audio out: app_jack, app_unimrcp, etc. I built this because of some special needs, and it is very convenient due to its extremely light weight. Regardless, should anyone be interested, here it is: https://github.com/CyCoreSystems/audiosocket The idea is to create a TCP socket to somewhere, pass some extremely simple metadata (a UUID), and broker audio between the channel and the socket. It is as simple as possible. -- Seán C McCord CyCore Systems, Inc +1 888 240 0308 PGP/GPG: http://cycoresys.com/scm.asc -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Astricon is coming up October 9-11! Signup is available at: https://www.asterisk.org/community/astricon-user-conference asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] ARI events order
As to the events should have a deterministic order or not, I cannot speak, but this is definitely normal behaviour. On Wed, Sep 5, 2018 at 12:22 PM Jean Aunis wrote: > Hello, > > It looks like the ARI events ordering during channel destruction is not > deterministic. I noticed this for ChannelLeftBridge and ChannelDestroyed > events : given a channel is in a bridge and is hanged up, sometimes > ChannelLeftBridge is raised before ChannelDestroyed, sometimes it's the > contrary. Test conditions are exactly the same in both cases. > > Is this non-deterministic behaviour normal, or should it be considered as > a bug ? > > To my mind, ChannelDestroyed should always be the very last event raised > for a given channel. From a developper point of view, it would give a clear > indication that the resources associated to the channel can be freed. > > Regards > -- > > > Jean AUNIS > > Ingénieur R&D > R&D engineer > > Tel : +33 1 30 85 90 22 <+33%201%2030%2085%2090%2022> > Standard: +33 1 30 85 55 55 >Rue de Broglie >22300 LANNION >FRANCE >www.prescom.fr <http://www.prescom.fr/> > > > *"Les informations contenues dans ce courrier sont données à titre > purement informatif et ne peuvent être considérées comme contractuelles > entre les récipiendaires, la société PRESCOM." **"The content of this > e-mail is purely for information and may not be considered as contractual > between the recipients, PRESCOM company."* > -- > _ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > Astricon is coming up October 9-11! Signup is available at: > https://www.asterisk.org/community/astricon-user-conference > > asterisk-dev mailing list > To UNSUBSCRIBE or update options visit: >http://lists.digium.com/mailman/listinfo/asterisk-dev -- Seán C McCord CyCore Systems, Inc +1 888 240 0308 PGP/GPG: http://cycoresys.com/scm.asc -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Astricon is coming up October 9-11! Signup is available at: https://www.asterisk.org/community/astricon-user-conference asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] One sip stack to rule them all....
I obviously failed to sufficiently emphasize the point. Whether you like it or not, whether you think pjsip is ready or not, whether it is better or not, chan_sip is effectively at a dead end.Unless some miraculously talented and motivated person emerges to maintain chan_sip (which is somewhat less likely than my dead grandmother taking up x86 assembly), there is no future for it. The discussion is not about that. There is no discussion about that. This is not about chan_sip vs chan_pjsip. It is pointless to wax about the perceived solidity of chan_sip. It is not solid. It is not maintainable. It is already years behind. People have managed to patch it into a simulacrum of stability under certain use cases (though I will admit that those use cases are wide and, in a self-fulfilling manner, perhaps do represent the majority of present use cases of active users of chan_sip), but this will not and has not continued. Factual deprecation itself is not even under discussion. chan_sip _is_ deprecated, whether that is officially acknowledged or not. Rather, this discussion is about making sure lurkers who are still using chan_sip but have not reported specific problems or feature gaps have their say, are aware that chan_sip is NOT the recommended stack, and understand that chan_sip will (again, whether anyone likes it or not) progressively worsen as time progresses. On Sun, Oct 8, 2017 at 3:33 PM Bryant Zimmerman wrote: > I would agree with this. We have tried to deploy pjsip several times over > the last year with limited success. > We have had nothing but issues with database real-time deployments. Tables > not working from one 13.x release to another. > Table builders sorcery failing out. > > Issues when there are multiple transports on varying networks were udp is > not routed correctly through the asterisk servers. No matter the settings. > > Connectivity issues with varying success by carrier. > > Unexplained audio quality issues that don't occur on the same spec running > chan_sip > > We want to move to pjsip but the functionality and stability have only > proven out for limited applications. > > > Bryant > > -- > *From*: "Daniel Journo" > *Sent*: Sunday, October 8, 2017 3:12 PM > *To*: "Asterisk Developers Mailing List" > *Subject*: Re: [asterisk-dev] One sip stack to rule them all > > > > What is _also_ needed, however, is more use of PJSIP and reports of > specific problems, and specific deficits of PJSIP so that the fear can be > eased before, at some point many years from now, chan_sip just doesn't work > any more. > > There are a number of specific issues on issue tracker which still need > addressing before more people will take it on properly. Some issues > probably require a semi-major rethink and probably won’t be dealt with for > months. > Making chan_sip depreciated would leave Asterisk with no production grade > sip stack that is officially being maintained. > -- > _ > -- 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 CyCore Systems, Inc +1 888 240 0308 PGP/GPG: http://cycoresys.com/scm.asc -- _ -- 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
Re: [asterisk-dev] One sip stack to rule them all....
As James mentioned at the top, chan_sip is already de facto deprecated. The discussion (at devcon) was centered around making it _officially_ deprecated. For clarity, deprecation is NOT the same thing as removal. (It is also not depreciation, the reduction in value of something.) Deprecation is the declaration that something is not approved. Using chan_sip has not been recommended for a long time. It _is_ important to officially deprecate chan_sip because it is really isn't being maintained as it would otherwise need to be. There is no reasonable way _to_ maintain it. Users should _know_ of that status, and that status is highly unlikely to change. What is _also_ needed, however, is more use of PJSIP and reports of specific problems, and specific deficits of PJSIP so that the fear can be eased before, at some point many years from now, chan_sip just doesn't work any more. On Sun, Oct 8, 2017 at 12:56 PM Troy Bowman wrote: > I sincerely hope they don't deprecate it. The pjsip code might seem fine > in development and test environments, but I am still afraid of using it in > production. I see too many issues with it regularly on this list. I can't > gamble stability versus my job security. > > From my perspective, chan_sip doesn't get bugfixes because it doesn't seem > to need them. It just works. I have had zero issues with it for several > years. > > > On Sun, Oct 8, 2017 at 8:55 AM, James Finstrom > wrote: > >> One does not simply depricate a sip stack. >> >> Ok so at devcon there was a discussion of depricating chan_sip. This may >> sound a lot worse than it actually is. Chan_sip has been essentially >> untouched in 4ish years. It does not receive bug fixes. It is just sort of >> a barge floating in the ocean. >> >> So one of the things that is needed to finally put Chan sip to bed is >> feature parody. Someone brought up CCSS. >> >> What features do you feel you would lose going from chan_sip to pjsip. >> >> Are there any bugs in pjsip that keep you from migrating? >> >> -- >> _ >> -- 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 >> > > -- > _ > -- 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 CyCore Systems, Inc +1 888 240 0308 PGP/GPG: http://cycoresys.com/scm.asc -- _ -- 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
Re: [asterisk-dev] Asterisk 15 Beta Released
I just wanted to know if it was an out-of-hand distaste or some more fundamental complication. Not enough timeshare is a perfectly acceptable reason. It's not like I have a whole bunch of free time to do release engineering, after all, either! Thanks On Wed, Aug 23, 2017 at 9:59 AM Matt Fredrickson wrote: > On Fri, Aug 18, 2017 at 8:03 AM, Seán C. McCord wrote: > > Matt, > > > > would you care to expound on your reasons against 14.6 -> LTS? I don't > > have all the data, so I certainly don't discount the possibility that > there > > are compelling "reasons," but those that you gave, such as they are, are > too > > vague to form an argument against. > > Hey Sean, > > I think that Sidney hit the nail on the head. Trying to go through > that kind of change right now would be challenging, a lot of it due to > preparations in getting 15 tested, released, and out there, Astricon > preparations, and more importantly, AstriDevCon preparations and other > things of that nature that are happening right now. You'd never > believe how much time it takes to make all of that come together > (never mind all of the day to day demands). > > It's a non insignificant amount of work from just a project policy > perspective to make a change like you and Dan are proposing. I'm not > completely opposed to the proposal, but my fallback preference is to > just keep current policy and wait until 16 is released to cut a new > LTS. Or at the very least discuss this more after 15 is released. > > Matthew Fredrickson > > > > > > > On Fri, Aug 18, 2017 at 5:07 AM Dan Jenkins > wrote: > >> > >> > >> > >> On Thu, Aug 17, 2017 at 11:11 PM, Matt Fredrickson > >> wrote: > >>> > >>> On Tue, Aug 15, 2017 at 1:15 PM, Dan Jenkins > >>> wrote: > >>> > > >>> > > >>> > On Wed, Aug 2, 2017 at 10:57 PM, Matt Fredrickson < > cres...@digium.com> > >>> > wrote: > >>> >> > >>> >> It is with great pleasure I wish to inform you of the first beta > >>> >> release of the new Asterisk 15 branch. It's a very exciting time to > be > >>> >> a user of Asterisk! Asterisk 15 is arguably the biggest release of > >>> >> Asterisk that has happened in the last 10 or so years. There has > been > >>> >> a lot of work done in the Asterisk core to better support newer > >>> >> multi-stream video and WebRTC related technologies. For those who > are > >>> >> interested, much of this will be covered in blog posts at > >>> >> http://blogs.asterisk.org/ over the next month or two. > >>> >> > >>> >> Typically, when a new major branch of Asterisk is created (13, 14, > >>> >> 15...), there are a few months of testing on the new branch that > >>> >> occurs prior to release in order to find regressions and other > issues > >>> >> that may cause a first official release from the branch to be dead > on > >>> >> arrival for a significant number of users. With today's release of > >>> >> 15.0.0-beta1, this process has begun. Please feel free to start > >>> >> testing this version of Asterisk in as many adverse environments as > >>> >> possible. Any bugs should be reported on the Asterisk issue tracker > at > >>> >> https://issues.asterisk.org/ > >>> >> > >>> >> As a side note, due to many of the core changes in the 15 branch > that > >>> >> have been made since Asterisk 14 was released, it has been decided > >>> >> that Asterisk 15 will not be an LTS release. For those of you who > are > >>> >> not familiar with the differences between LTS versus standard > >>> >> releases, you can find more information here [1]. > >>> >> > >>> >> Thanks to all the many Asterisk community members for providing so > >>> >> much help and support to make Asterisk the great open source project > >>> >> that it is. > >>> >> > >>> >> P.S. Binary codecs and other modules distributed by Digium are not > >>> >> immediately available for 15.0.0-beta1, but should be shortly. > >>> >> > >>> >> Best wishes to all, and happy testing! > >>> >> > >>> >> [1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Version
Re: [asterisk-dev] Asterisk 15 Beta Released
eason that it was decided to break convention and to not >> make 15 an LTS is that there were some fairly considerable core >> changes to Asterisk necessary to make the multi-stream work come >> together to build an MVP video SFU out of Asterisk, which was our >> goal. Bearing that in mind, we did not feel comfortable building an >> LTS release fresh off of those considerable core changes. >> >> We also anticipate a number of other considerable changes going into >> the 15 branch as people start to play with the new SFU support. Since >> our proof of concept client is so bare bones (doesn't use Asterisk ARI >> APIs yet) we expect there to be many of ARI API enrichments that are >> likely to happen as people start to play with the new SFU support in >> app_confbridge. There are also potentially more fundamental changes >> that could break clients if some of our initial behavioral assumptions >> are incorrect, such as how app_confbridge reuses negotiated streams on >> peerconnections or how new streams are negotiated and in what order. >> >> I know this places great difficulty on those who are using 14 features >> counting on 15 being an LTS, but to be honest, I don't think that you >> would want to use those features in a 15 LTS if you were concerned >> about potential stability changes. While we earnestly hope that 15 >> will continue 13 and 14's trend of being some of most solid stable >> releases that have been cut, in an abundance of caution we decided to >> break convention and make it non-LTS. >> >> > I'd like to propose that we make 14.6 (or later) the LTS in a similar >> > fashion to how other communities are now promoting versions to LTS mid >> cycle >> > (https://github.com/nodejs/LTS). That way you get to release all the >> > exciting things that are in 15 but as a community we get LTS support on >> > everything thats now in 14 - as we know, some businesses will not move >> to a >> > non LTS and I think it would be a real shame to not get particular >> > organisations moved over to using some of the great things that have >> been >> > added in 14. >> > >> > What are everyone's thoughts? >> >> So from a project policy perspective, and due to the many other >> burdens we have right now, I don't feel comfortable making this change >> at this time. I'm not saying it's never going to happen, just that I >> can't imagine going forward with everything else going on right now. >> >> From a compromise position perspective, if your customers really would >> like to get on an LTS with particular features that they're enjoying >> in 14 (such as newer ARI changes, etc), there is a potential pathway >> forward that might allow this sooner rather than later. As long as >> the changes they want are not of the nature to destabilize the >> codebase (such as the DNS changes and a few others) or breaking API >> changes, they can find a software developer to backport them into the >> 13 branch. Obviously, this requires submitting tests for features >> that didn't have tests originally submitted. But this would allow the >> customer to have some of the new feature functionality of 14 in the 13 >> branch. >> >> I know that isn't exactly what you were asking, but perhaps it might >> be another possibility for those who really want to remain on an LTS. >> >> Sorry to be the bearer of bad news on this :-( >> >> -- >> Matthew Fredrickson >> Digium, Inc. | Engineering Manager >> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA >> >> -- >> _ >> -- 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 >> > > > So a compromise is having clients pay a developer to try and get those > changes into 13? I don't really see that as a compromise personally. When > those features were written, why weren't they written with tests and > backported into 13? Because its more difficult and time consuming. > > Its all semantics at the end of the day - whether you release 14 as 15 and > then have 15 be a LTS and then release what is 15 beta to be 16 - its all > just numbers. I don't want you to change your general policy on LTS version > numbers specifically - I just want an LTS as described in the same wiki > document you linked to - releasing 14.6 as an LTS is the way to do that. > > I don't really understand how as an open source project you can have a > public policy and then change that policy _just_ when people are expecting > that policy to come into force - if 6 months ago you had said "15 has a > load of changes in it and we want to break our LTS policy" then I'm sure > people would have thought and planned a bit more - but at this time we're > just over a month until Astricon where typically, the new version of > Asterisk is released, where we were expecting an LTS. This really leaves a > bitter taste in the mouth. > -- > _ > -- 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 CyCore Systems, Inc +1 888 240 0308 PGP/GPG: http://cycoresys.com/scm.asc -- _ -- 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
Re: [asterisk-dev] Asterisk 15 Beta Released
support on > everything thats now in 14 - as we know, some businesses will not move to a > non LTS and I think it would be a real shame to not get particular > organisations moved over to using some of the great things that have been > added in 14. > > > > What are everyone's thoughts? > > > > > -- > _ > -- 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 CyCore Systems, Inc +1 888 240 0308 PGP/GPG: http://cycoresys.com/scm.asc -- _ -- 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
