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

Thu Dec 18 02:00:34 CST 2014

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 at 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.simionovich at 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 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/4c80d6b1/attachment.html>