Sorry, previous sample was wrong, here is a more accurate sample: T 178.62.127.227:44972 -> 178.62.127.227:8088 [AP] POST /ari/channels/participant HTTP/1.1. Authorization: Basic dGVzdDp0ZXN0. Host: 178.62.127.227:8088. Content-Length: 31. Accept: application/json. Content-Type: application/json. . {"endpoint":"Local\/1000@demo"}
T 178.62.127.227:8088 -> 178.62.127.227:44972 [AP] HTTP/1.1 400 Bad Request. Server: Asterisk/SVN-trunk-r429683M. Date: Thu, 18 Dec 2014 07:59:34 GMT. Cache-Control: no-cache, no-store. Content-type: application/json. Content-Length: 61. . T 178.62.127.227:8088 -> 178.62.127.227:44972 [AP] { "message": "Application or extension must be specified" } On Thu, Dec 18, 2014 at 9:48 AM, Nir Simionovich <nir.simionov...@gmail.com> wrote: > > One more thing - per your recommendations, I'm trying to re-implement > app_dial using ARI. > > Now, if I read you all right, the process should be: > > 1. Get a call into Asterisk from an external phone > 2. Create a new bridge > 3. Put the call into the newly created bridge > 4. Originate a new call > 5. Put the new call into the existing bridge > > So, 1,2,3 work just fine - then you get to 4. According to the docs, I can > originate a channel with only the endpoint defined. > However, that doesn't seem to work: > > T 178.62.127.227:44938 -> 178.62.127.227:8088 [AP] > POST /ari/channels HTTP/1.1. > Authorization: Basic dGVzdDp0ZXN0. > Host: 178.62.127.227:8088. > Content-Length: 85. > Accept: application/json. > Content-Type: application/json. > . > {"endpoint":"Local\/1000@demo > ","channelId":"participant","variables":{"var1":"var1"}} > > T 178.62.127.227:8088 -> 178.62.127.227:44938 [AP] > HTTP/1.1 400 Bad Request. > Server: Asterisk/SVN-trunk-r429683M. > Date: Thu, 18 Dec 2014 07:41:59 GMT. > Cache-Control: no-cache, no-store. > Content-type: application/json. > Content-Length: 61. > . > > > T 178.62.127.227:8088 -> 178.62.127.227:44938 [AP] > { > "message": "Application or extension must be specified" > } > > Am I missing something here? or is this a bug? > > > > On Thu, Dec 18, 2014 at 8:59 AM, Nir Simionovich < > nir.simionov...@gmail.com> wrote: >> >> I see your point now - that makes more sense. It was fairly clear to me >> that ast_bridge_config is somewhat of a legacy data structure, >> but I was assuming that in some respect it was used in ARI as well. What >> your actually saying is that ARI bypasses all of the legacy >> stuff and interacts directly with the bridge core, and that's why it >> doesn't support that data structure. So technically, accessing bridge >> configuration for a Legacy (Dial, Queue, FollowMe) is a fairly complex >> task, as they don't see the same information space. >> >> This now raises a slightly off-topic discussion - wouldn't it beneficial >> to provide some form of ARI access to some of the legacy stuff >> as well? On one hand, we don't really want to do that - as we're trying >> to push people into proper usage of ARI and Asterisk, however, >> my heart goes out to the legacy stuff, that if we don't cater to, will >> become a caveat. >> >> I will explain. About 6 years I've built a large scale Asterisk based >> dialer for a customer. When I say large scale, I meant humongous >> in 2008 terms - 2500 concurrent calls. Now, that dialer relied heavily on >> AMI (of course) and AGI. It was originally built on Asterisk 1.6. >> Recently, the customer came back to me, asking me to upgrade their system >> to Asterisk 11, specifically for security reasons. I then >> looked at the code, realizing that the customer had wrote some stuff >> using MeetMe and some of the deprecated app_queue stuff. >> I indicated to them that their legacy code should be migrated as well. >> Customer looked at it, realized that apart from upgrading Asterisk, >> they will have about 6 months worth of coding to migrate their stuff to >> the new constructs - the entire project caved. We just upgraded >> to latest version of the 1.6 branch, and the customer is now evaluating >> 1.8 - in other words, not supporting the legacy stuff in some >> respect will at some point bite us in the ass. >> >> I realize this is very much a leadership question, not a technical nor >> operational. >> >> New question: Do we want to enable legacy features inside ARI? >> >> Nir >> >> On Thu, Dec 18, 2014 at 1:26 AM, Mark Michelson <mmichel...@digium.com> >> wrote: >> >>> On 12/17/2014 05:01 PM, Nir Simionovich wrote: >>> >>> <snip> >>> >>> Let's try to stick to the tech for now and answer the first two >>> questions: >>> >>> 1. Is there a way to obtain the information in ast_bridge_config for >>> each of the iterated bridges? >>> >>> >>> ast_bridge_config is not used at all for Stasis bridges. >>> ast_bridge_config describes bridge features that basic bridges use based on >>> Dial(), Queue(), and FollowMe() features. For instance, when Dial is called >>> with the 't' and 'T' options, the ast_bridge_config indicates that the >>> caller and callee can perform DTMF transfers based on features.conf >>> settings. >>> >>> For Stasis bridges, the idea of using ast_bridge_config does not make >>> sense for several reasons >>> >>> 1) Stasis applications are intended to be fully in control of everything >>> that happens in the bridge. There should be nothing that the participants >>> should be able to do independently of the Stasis application to change the >>> bridge. >>> 2) ast_bridge_config relies heavily on the concept that a bridge >>> contains exactly two participants. For basic bridges, this assumption >>> holds. Stasis bridges can have any number of participants, though, so this >>> structure doesn't work well. >>> >>> 2. Is there a way to manipulate the configuration of the bridge, >>> via modifying the associated bridge configuration in real time? >>> >>> >>> The configuration of a Stasis bridge is defined by the Stasis >>> application that creates and manipulates the bridge. It is up to the Stasis >>> application to determine properties of the bridge and manipulate the bridge >>> based on those properties. Whether you can manipulate this in real time is >>> based on the programming language and runtime model of the ARI library you >>> use. >>> >>> >>> Nir >>> >>> >>> >>> -- >>> _____________________________________________________________________ >>> -- 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