On Sat, Dec 20, 2014 at 12:34 PM, Paul Belanger <paul.belanger@xxxxxxxxxxxxxx> wrote: > On Sat, Dec 20, 2014 at 1:03 PM, Leif Madsen <lmadsen@xxxxxxxxxxxxxxxxxx> wrote: >> On 20 December 2014 at 06:01, Ben Langfeld <ben@xxxxxxxxxxx> wrote: >>> >>> >>> Agreed entirely. Dial() is the same sort of monster that Voicemail and >>> such are. I think Paul is trying to get agreement on an ARI /dial resource >>> (please correct me if I've misunderstood, Paul!) but I think this is a >>> mistake. This would break with the purpose of ARI, which is for low-level >>> flexible control to implement these sort of application level features >>> outside of Asterisk. >>> >>> It would be nice to solve the problems around early media. Adhearsion has >>> had some discussion around these issues relating to the Rayo protocol >>> (https://github.com/adhearsion/adhearsion/issues/298) and implements >>> something similar to Dial() >>> (http://www.rubydoc.info/gems/adhearsion/Adhearsion/CallController/Dial:dial). >>> >>> What we have found is that these things are very often application >>> specific and it's difficult to create something simple yet generic at the >>> application level of abstraction; it is probably better to simplify or >>> augment the lower level primitives to compose these things more easily in an >>> ARI application. >>> >> >> >> Ben, actually what I think Paul is trying to propose is a document (think >> like an RFC) that describes the functionality, and then programming several >> applications in multiple languages that satisfy the functionality of that >> document. Think of it like a replacement for app_queue, but in this case, >> app_dial. In this case I think we're all in agreement it is going to be >> fairly simple, which is great because that shows the power of ARI. >> Essentially Paul is asking that we use this as a method to coordinate on >> documentation on how to build the dialplan replacement of app_dial in an ARI >> driven application. >> >> This would be another one of those Lego blocks that could be made available >> to people so that they could start to build something from the blocks. If >> the community is able to come together, write some basic documentation on >> how something should work, and then other people come in and satisfy that >> documentation with code that controls ARI, then that gives us many examples >> of ARI being used in capacities formerly satisfied by dialplan applications. >> >> I could be wrong, but that was my impression of this thread. I don't think >> he was proposing any sort of ARI resource. >> > Right, I wanted to get everybody thinking about, and even documenting > how a basic ARI app dial would look. Something that is basic enough > that people would be like, oh I could use said ruby / python / js > function to quickly use dial. > > For me, the reply that Josh did was spot on. That, to me, would be > the simplest way I'd see dial working with ARI. Now, Matt does it a > little different by playing the callee into the bridge first, then > playing audio into said bridge for ring. So, there we have 2 > differences already. Create bridge and join callers after answer or > Create bridge move callee first, join caller after answer. Well... kind of. The channels in the holding bridge are actually entertained with music on hold. The example on github is specifically for this page: https://wiki.asterisk.org/wiki/display/AST/ARI+and+Bridges%3A+Bridge+Operations The example in github is showing how you can move channels between bridges. As it turns out, it's also a basic Dial. > Which way do people prefer? > I think a basic Dial that emulates a very standard Dial operation, e.g., Dial(endpoints,timeout) Would be great. Since we have an ari-examples repo on github, a pull request against that repo might be a good starting point. If someone would like to write some documentation on the wiki, that'd be fantastic too! :-) -- Matthew Jordan Digium, Inc. | Engineering Manager 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org _______________________________________________ asterisk-app-dev mailing list asterisk-app-dev@xxxxxxxxxxxxxxxx http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
