[asterisk-dev] ARI Extending Existing Feature: bridge control

[Nir Simionovich]

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 at 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.simionovich at 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 <mmichelson at 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20141218/2a6399eb/attachment-0001.html>