Re: [asterisk-dev] ARI Extending Existing Feature: bridge control
This would be a very useful feature to have available in dialplan. To be able vary the length of a call, during the call. I just emailed the dev list with the thought of adding this feature to confbridge with the following type of commands: same = n,Set(CONFBRIDGE(bridge,max_time)= or same = n,Set(CONFBRIDGE(bridge,max_datetime)= or same = n,Set(CONFBRIDGE(bridge,start_datetime)= same = n,Set(CONFBRIDGE(bridge,stop_datetime)= with the following to add some notifications same = n,Set(CONFBRIDGE(bridge,hangup_warning)= same = n,Set(CONFBRIDGE(bridge,hangup_message)= The idea was that if you have some call credit it will reduce by the variable number of callers which will join the same bridge. Using same = n,Set(TIMEOUT(absolute)= only sets the time out for an individual call and not the bridge. Perhaps something that could be used for all call types would be a better approach rather than modifying individual apps. Regards From: Nir Simionovich Sent: Wednesday, December 17, 2014 8:16 PM To: Asterisk Developers Mailing List Subject: [asterisk-dev] ARI Extending Existing Feature: bridge control Hi All, After shipping out my first patch to ARI, I became hungry :-) So, now I've set up a slightly higher goal, adding a much required feature for ARI. I'll describe the problem first, then I have some questions. The Asterisk dial application enables us to limit the duration of the call and play a warning sound. Once this had been set, as far as I know, you can't modify these values externally. When the feature was originally introduced, over 10 years ago, the goal was simple: enable a calling card system to limit the call according to a credit line. As time went by, people realized that this feature is useful, however limited. In today's mobile application era, when a VoIP phone can actually purchase credit while on the actual call, we need a way to control this from an external source. Now, I've started digging into the code, and I've managed to understand that following (feel free to bash me if I'm wrong): 1. The time limits are maintained at the bridge structure, not at the channel - using the ast_bridge_config data structure 2. The ARI bridges GET method only retrieves a list of bridges and their associated channels, not their configurations So, assuming that I'm reading the ast_ari_bridges_list function from resouce_bridges.c correctly, we retrieve a snapshot of all active bridges via the snapshots variable (if you can call it that). The output is built by iterating through it. Now, my questions: 1. Is there a way to obtain the information in ast_bridge_config for each of the iterated bridges, then output it via the JSON response? 2. Is there a way to manipulate the configuration of the bridge, via modifying the associated bridge configuration? The floor is now open :-) Nir S -- _ -- 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] ARI Extending Existing Feature: bridge control
On Sun, Dec 21, 2014 at 6:01 AM, Jonathan White uvac...@googlemail.com wrote: This would be a very useful feature to have available in dialplan. To be able vary the length of a call, during the call. So, this isn't really the topic of conversation in this thread. Most of this thread concerns itself with discussing additions/modifications to ARI and its manipulation of bridges. I just emailed the dev list with the thought of adding this feature to confbridge with the following type of commands: same = n,Set(CONFBRIDGE(bridge,max_time)= or same = n,Set(CONFBRIDGE(bridge,max_datetime)= or same = n,Set(CONFBRIDGE(bridge,start_datetime)= same = n,Set(CONFBRIDGE(bridge,stop_datetime)= with the following to add some notifications same = n,Set(CONFBRIDGE(bridge,hangup_warning)= same = n,Set(CONFBRIDGE(bridge,hangup_message)= The idea was that if you have some call credit it will reduce by the variable number of callers which will join the same bridge. Keep in mind that the CONFBRIDGE function modifies the ConfBridge application, not all bridges in Asterisk. Adding capabilities to the ConfBridge dialplan application won't really affect the topic this thread is discussing. The CONFBRIDGE function should *not* be re-purposed for things outside the ConfBridge application. If someone wanted to write a generic dialplan function that modified properties of a bridge, that would be a better solution than using CONFBRIDGE. That being said, the dialplan is extremely channel focussed. That is both a strength (it is relatively simple and straight forward) and a weakness (doing things outside of manipulating a single channel can become convoluted). I'm not sure that adding these kinds of capabilities to the dialplan is the best way forward. That being said, Asterisk is open source. If someone wants to write a generic bridge function that modifies bridges in Asterisk, that would be an interesting patch. Using same = n,Set(TIMEOUT(absolute)= only sets the time out for an individual call and not the bridge. Perhaps something that could be used for all call types would be a better approach rather than modifying individual apps. -- 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 -- _ -- 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 Extending Existing Feature: bridge control
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
Re: [asterisk-dev] ARI Extending Existing Feature: bridge control
Hi, On 2014-12-18 01:01, Nir Simionovich wrote: 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? 2. Is there a way to manipulate the configuration of the bridge, via modifying the associated bridge configuration in real time? Nir You may take a look at my old RTCC patch for Dial() [1]: In the last version [2] I have ended with adding the bridge_config and both channels to a data store, which is accessed from a scheduled callback and modifies the call limit. Once you have the data store attached to the channel it is easy to access it from a hook or another thread/app [1] https://issues.asterisk.org/jira/browse/ASTERISK-6175 [2] https://issues.asterisk.org/jira/secure/attachment/40666/rtcc_trunk_327742.diff -- _ -- 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 Extending Existing Feature: bridge control
In deed, that is interesting - but truly stirs away from ARI - not something that I'm trying to do. On Thu, Dec 18, 2014 at 1:00 PM, Kaloyan Kovachev kkovac...@varna.net wrote: Hi, On 2014-12-18 01:01, Nir Simionovich wrote: 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? 2. Is there a way to manipulate the configuration of the bridge, via modifying the associated bridge configuration in real time? Nir You may take a look at my old RTCC patch for Dial() [1]: In the last version [2] I have ended with adding the bridge_config and both channels to a data store, which is accessed from a scheduled callback and modifies the call limit. Once you have the data store attached to the channel it is easy to access it from a hook or another thread/app [1] https://issues.asterisk.org/jira/browse/ASTERISK-6175 [2] https://issues.asterisk.org/jira/secure/attachment/40666/ rtcc_trunk_327742.diff -- _ -- 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] ARI Extending Existing Feature: bridge control
Ahh... On Thu, Dec 18, 2014 at 1:32 PM, Kaloyan Kovachev kkovac...@varna.net wrote: I meant that for accessing bridge configuration for a Legacy (Dial, Queue, FollowMe) from your other email On 2014-12-18 13:26, Nir Simionovich wrote: In deed, that is interesting - but truly stirs away from ARI - not something that I'm trying to do. On Thu, Dec 18, 2014 at 1:00 PM, Kaloyan Kovachev kkovac...@varna.netwrote: Hi, On 2014-12-18 01:01, Nir Simionovich wrote: 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? 2. Is there a way to manipulate the configuration of the bridge, via modifying the associated bridge configuration in real time? Nir You may take a look at my old RTCC patch for Dial() [1]: In the last version [2] I have ended with adding the bridge_config and both channels to a data store, which is accessed from a scheduled callback and modifies the call limit. Once you have the data store attached to the channel it is easy to access it from a hook or another thread/app [1] https://issues.asterisk.org/jira/browse/ASTERISK-6175 [1] [2] https://issues.asterisk.org/jira/secure/attachment/40666/ rtcc_trunk_327742.diff [2] -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com [3] -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev [4] Links: -- [1] https://issues.asterisk.org/jira/browse/ASTERISK-6175 [2] https://issues.asterisk.org/jira/secure/attachment/40666/ rtcc_trunk_327742.diff [3] http://www.api-digital.com [4] 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 mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] ARI Extending Existing Feature: bridge control
On Thu, Dec 18, 2014 at 1: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? New answer: I don't believe so. I think this issue / question is the hardest thing to understand about ARI. There really isn't any sort of link to existing Asterisk application or features; not yet any ways. Somebody has to build it again a top of ARI. When I first dreamed of using ARI I was looking at it from a configuration management tool mindset. Oh, I could create a new peer in chan_sip over HTTP or let me reconfigure features.conf using ARI. However, as I started playing with it more I found that was not what it did. And, changing it to do something like that doesn't feel like the right approach. Now, that being said. Creating some sort of interface to control sorcery objects, now that would be cool. Having sorcery connect to redis and change key / values directly in redis for sip peers would be hotness. However, I'm not sure I would want to have Asterisk serve up that interface directly. Feels more like an external application would serve up the REST interface into redis, allowing the user to change key/pairs. I also believe, until there are some standard ARI libraries / application (for example app_dial replacement). It will feel like a large task to build anything in ARI, because some of the core application basically need to be written from scratch. And I think this is the main reason people are slow to move to ARI or fearful from dropping the dialplan. Because doing: exten = s,1,NoOp() same = n,Dial(SIP/f...@example.org) is a lot easier then origination a channel over ARI, creating bridges and playing any tones needed using ARI. Easier might not be the right work, more steps required is. -- Paul Belanger | PolyBeacon, Inc. Jabber: paul.belan...@polybeacon.com | IRC: pabelanger (Freenode) Github: https://github.com/pabelanger | Twitter: https://twitter.com/pabelanger -- _ -- 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 Extending Existing Feature: bridge control
On Thu, Dec 18, 2014 at 2: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?
You need to also pass the app parameter in this case. So Asterisk
knows where to send events.
--
Paul Belanger | PolyBeacon, Inc.
Jabber: paul.belan...@polybeacon.com | IRC: pabelanger (Freenode)
Github: https://github.com/pabelanger | Twitter: https://twitter.com/pabelanger
--
_
-- 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 Extending Existing Feature: bridge control
On 18 December 2014 at 11:07, Paul Belanger paul.belan...@polybeacon.com wrote: On Thu, Dec 18, 2014 at 1:59 AM, Nir Simionovich nir.simionov...@gmail.com wrote: New question: Do we want to enable legacy features inside ARI? New answer: I don't believe so. I think this issue / question is the hardest thing to understand about ARI. There really isn't any sort of link to existing Asterisk application or features; not yet any ways. Somebody has to build it again a top of ARI. When I first dreamed of using ARI I was looking at it from a configuration management tool mindset. Oh, I could create a new peer in chan_sip over HTTP or let me reconfigure features.conf using ARI. However, as I started playing with it more I found that was not what it did. And, changing it to do something like that doesn't feel like the right approach. Now, that being said. Creating some sort of interface to control sorcery objects, now that would be cool. Having sorcery connect to redis and change key / values directly in redis for sip peers would be hotness. However, I'm not sure I would want to have Asterisk serve up that interface directly. Feels more like an external application would serve up the REST interface into redis, allowing the user to change key/pairs. I also believe, until there are some standard ARI libraries / application (for example app_dial replacement). It will feel like a large task to build anything in ARI, because some of the core application basically need to be written from scratch. And I think this is the main reason people are slow to move to ARI or fearful from dropping the dialplan. Because doing: exten = s,1,NoOp() same = n,Dial(SIP/f...@example.org) is a lot easier then origination a channel over ARI, creating bridges and playing any tones needed using ARI. Easier might not be the right work, more steps required is. I also agree that we do not want to start making ARI start talking to legacy applications. As discussed at AstriDevCon, the push is really to start making Asterisk a media communications platform. The way to do that is to move away from the dialplan centric driven applications and to move to a decentralized model of applications and business logic being separated from Asterisk, and essentially making Asterisk much dumber in terms of the actual business logic and routing logic, and making it a lean mean media communications machine. The way forward sometimes is to stop looking back. Currently both AMI and AGI are still happily co-existant in Asterisk, and should be considered the defacto interface to traditional methods of writing Asterisk business logic (dialplan, etc). When flipping to ARI, it is a different mind set that does take some time to get around. Much like Paul I had my own preconceived notions about what ARI was and was initially disappointed it didn't match what I thought it should have been. However over the last few months of watching what Paul has been doing along with some small side POC stuff to better understand what ARI is intended for, it definitely has become a lot clearer. At the most basic levels, ARI to me is a bridge control interface that allows you to hook channels together while not worrying about transcoding, media characteristics etc. You have two or more channels that may or may not speak the same language, and your external applications stick them together, and Asterisk acts as the universal translator for those channels. By writing all your business logic and controls outside of Asterisk, it makes the API much simpler to interoperate with, and allows great scaling possibilities. Admittedly I'm still a bit naive on a lot of the ARI front, but one thing my gut tells me, is it is a new interface, and should not be confused as a replacement to the legacy (term used loosely) methods of building Asterisk systems. This is one of those situations that I feel avoiding legacy and backwards compatibility with the traditional methods is going to really open up a better realm of possibilities with ARI. If someone truly just needs an HTTP based interface for controlling dialplan and such, I feel a translation application (library) should just be written for AMI and AGI that permits that and has that goal. Overloading what ARI is supposed to be doing is a step backwards in my opinion. -- Leif The Dialplan Is Dead Madsen -- _ -- 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 Extending Existing Feature: bridge control
Now, this is why I love Open Source - opinions, thoughts and most importantly, acceptance. I can totally see where the general idea is going here, and that is what we all agreed during AstriDevCon this year. On Thu, Dec 18, 2014 at 6:31 PM, Leif Madsen lmad...@thinkingphones.com wrote: On 18 December 2014 at 11:07, Paul Belanger paul.belan...@polybeacon.com wrote: On Thu, Dec 18, 2014 at 1:59 AM, Nir Simionovich nir.simionov...@gmail.com wrote: New question: Do we want to enable legacy features inside ARI? New answer: I don't believe so. I think this issue / question is the hardest thing to understand about ARI. There really isn't any sort of link to existing Asterisk application or features; not yet any ways. Somebody has to build it again a top of ARI. When I first dreamed of using ARI I was looking at it from a configuration management tool mindset. Oh, I could create a new peer in chan_sip over HTTP or let me reconfigure features.conf using ARI. However, as I started playing with it more I found that was not what it did. And, changing it to do something like that doesn't feel like the right approach. Now, that being said. Creating some sort of interface to control sorcery objects, now that would be cool. Having sorcery connect to redis and change key / values directly in redis for sip peers would be hotness. However, I'm not sure I would want to have Asterisk serve up that interface directly. Feels more like an external application would serve up the REST interface into redis, allowing the user to change key/pairs. I also believe, until there are some standard ARI libraries / application (for example app_dial replacement). It will feel like a large task to build anything in ARI, because some of the core application basically need to be written from scratch. And I think this is the main reason people are slow to move to ARI or fearful from dropping the dialplan. Because doing: exten = s,1,NoOp() same = n,Dial(SIP/f...@example.org) is a lot easier then origination a channel over ARI, creating bridges and playing any tones needed using ARI. Easier might not be the right work, more steps required is. I also agree that we do not want to start making ARI start talking to legacy applications. As discussed at AstriDevCon, the push is really to start making Asterisk a media communications platform. The way to do that is to move away from the dialplan centric driven applications and to move to a decentralized model of applications and business logic being separated from Asterisk, and essentially making Asterisk much dumber in terms of the actual business logic and routing logic, and making it a lean mean media communications machine. The way forward sometimes is to stop looking back. Currently both AMI and AGI are still happily co-existant in Asterisk, and should be considered the defacto interface to traditional methods of writing Asterisk business logic (dialplan, etc). When flipping to ARI, it is a different mind set that does take some time to get around. Much like Paul I had my own preconceived notions about what ARI was and was initially disappointed it didn't match what I thought it should have been. However over the last few months of watching what Paul has been doing along with some small side POC stuff to better understand what ARI is intended for, it definitely has become a lot clearer. At the most basic levels, ARI to me is a bridge control interface that allows you to hook channels together while not worrying about transcoding, media characteristics etc. You have two or more channels that may or may not speak the same language, and your external applications stick them together, and Asterisk acts as the universal translator for those channels. By writing all your business logic and controls outside of Asterisk, it makes the API much simpler to interoperate with, and allows great scaling possibilities. Admittedly I'm still a bit naive on a lot of the ARI front, but one thing my gut tells me, is it is a new interface, and should not be confused as a replacement to the legacy (term used loosely) methods of building Asterisk systems. This is one of those situations that I feel avoiding legacy and backwards compatibility with the traditional methods is going to really open up a better realm of possibilities with ARI. If someone truly just needs an HTTP based interface for controlling dialplan and such, I feel a translation application (library) should just be written for AMI and AGI that permits that and has that goal. Overloading what ARI is supposed to be doing is a step backwards in my opinion. -- Leif The Dialplan Is Dead Madsen -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit:
Re: [asterisk-dev] ARI Extending Existing Feature: bridge control
On Thu, Dec 18, 2014 at 10:31 AM, Leif Madsen lmad...@thinkingphones.com wrote: On 18 December 2014 at 11:07, Paul Belanger paul.belan...@polybeacon.com wrote: On Thu, Dec 18, 2014 at 1:59 AM, Nir Simionovich nir.simionov...@gmail.com wrote: New question: Do we want to enable legacy features inside ARI? New answer: I don't believe so. I think this issue / question is the hardest thing to understand about ARI. There really isn't any sort of link to existing Asterisk application or features; not yet any ways. Somebody has to build it again a top of ARI. When I first dreamed of using ARI I was looking at it from a configuration management tool mindset. Oh, I could create a new peer in chan_sip over HTTP or let me reconfigure features.conf using ARI. However, as I started playing with it more I found that was not what it did. And, changing it to do something like that doesn't feel like the right approach. Now, that being said. Creating some sort of interface to control sorcery objects, now that would be cool. Having sorcery connect to redis and change key / values directly in redis for sip peers would be hotness. However, I'm not sure I would want to have Asterisk serve up that interface directly. Feels more like an external application would serve up the REST interface into redis, allowing the user to change key/pairs. I also believe, until there are some standard ARI libraries / application (for example app_dial replacement). It will feel like a large task to build anything in ARI, because some of the core application basically need to be written from scratch. And I think this is the main reason people are slow to move to ARI or fearful from dropping the dialplan. Because doing: exten = s,1,NoOp() same = n,Dial(SIP/f...@example.org) is a lot easier then origination a channel over ARI, creating bridges and playing any tones needed using ARI. Easier might not be the right work, more steps required is. I also agree that we do not want to start making ARI start talking to legacy applications. As discussed at AstriDevCon, the push is really to start making Asterisk a media communications platform. The way to do that is to move away from the dialplan centric driven applications and to move to a decentralized model of applications and business logic being separated from Asterisk, and essentially making Asterisk much dumber in terms of the actual business logic and routing logic, and making it a lean mean media communications machine. The way forward sometimes is to stop looking back. Currently both AMI and AGI are still happily co-existant in Asterisk, and should be considered the defacto interface to traditional methods of writing Asterisk business logic (dialplan, etc). When flipping to ARI, it is a different mind set that does take some time to get around. Much like Paul I had my own preconceived notions about what ARI was and was initially disappointed it didn't match what I thought it should have been. However over the last few months of watching what Paul has been doing along with some small side POC stuff to better understand what ARI is intended for, it definitely has become a lot clearer. At the most basic levels, ARI to me is a bridge control interface that allows you to hook channels together while not worrying about transcoding, media characteristics etc. You have two or more channels that may or may not speak the same language, and your external applications stick them together, and Asterisk acts as the universal translator for those channels. By writing all your business logic and controls outside of Asterisk, it makes the API much simpler to interoperate with, and allows great scaling possibilities. Admittedly I'm still a bit naive on a lot of the ARI front, but one thing my gut tells me, is it is a new interface, and should not be confused as a replacement to the legacy (term used loosely) methods of building Asterisk systems. This is one of those situations that I feel avoiding legacy and backwards compatibility with the traditional methods is going to really open up a better realm of possibilities with ARI. If someone truly just needs an HTTP based interface for controlling dialplan and such, I feel a translation application (library) should just be written for AMI and AGI that permits that and has that goal. Overloading what ARI is supposed to be doing is a step backwards in my opinion. Exposing Asterisk features (and that term encompasses 'features.conf' features as well as other things) in the short run would add more features to the API, but in the long run will result in severely limiting the ARI API - and making it really difficult to build ARI applications. I think everyone is on this page from this thread, but for the sake of posterity, I'll go into some of where this would fall apart if we tried to put 'features' into ARI. Integral to ARI is the concept of control. When a channel is in
Re: [asterisk-dev] ARI Extending Existing Feature: bridge control
Matt, I think your entire email should be put on the wiki, maybe not in its current format, but the contents are imperative for the future. This is actually the first ever detailed explanation I've ever read as to why ARI shouldn't do all sorts of things - which from an external (none core developer) point of view - would seem reasonable. On Thu, Dec 18, 2014 at 8:38 PM, Matthew Jordan mjor...@digium.com wrote: On Thu, Dec 18, 2014 at 10:31 AM, Leif Madsen lmad...@thinkingphones.com wrote: On 18 December 2014 at 11:07, Paul Belanger paul.belan...@polybeacon.com wrote: On Thu, Dec 18, 2014 at 1:59 AM, Nir Simionovich nir.simionov...@gmail.com wrote: New question: Do we want to enable legacy features inside ARI? New answer: I don't believe so. I think this issue / question is the hardest thing to understand about ARI. There really isn't any sort of link to existing Asterisk application or features; not yet any ways. Somebody has to build it again a top of ARI. When I first dreamed of using ARI I was looking at it from a configuration management tool mindset. Oh, I could create a new peer in chan_sip over HTTP or let me reconfigure features.conf using ARI. However, as I started playing with it more I found that was not what it did. And, changing it to do something like that doesn't feel like the right approach. Now, that being said. Creating some sort of interface to control sorcery objects, now that would be cool. Having sorcery connect to redis and change key / values directly in redis for sip peers would be hotness. However, I'm not sure I would want to have Asterisk serve up that interface directly. Feels more like an external application would serve up the REST interface into redis, allowing the user to change key/pairs. I also believe, until there are some standard ARI libraries / application (for example app_dial replacement). It will feel like a large task to build anything in ARI, because some of the core application basically need to be written from scratch. And I think this is the main reason people are slow to move to ARI or fearful from dropping the dialplan. Because doing: exten = s,1,NoOp() same = n,Dial(SIP/f...@example.org) is a lot easier then origination a channel over ARI, creating bridges and playing any tones needed using ARI. Easier might not be the right work, more steps required is. I also agree that we do not want to start making ARI start talking to legacy applications. As discussed at AstriDevCon, the push is really to start making Asterisk a media communications platform. The way to do that is to move away from the dialplan centric driven applications and to move to a decentralized model of applications and business logic being separated from Asterisk, and essentially making Asterisk much dumber in terms of the actual business logic and routing logic, and making it a lean mean media communications machine. The way forward sometimes is to stop looking back. Currently both AMI and AGI are still happily co-existant in Asterisk, and should be considered the defacto interface to traditional methods of writing Asterisk business logic (dialplan, etc). When flipping to ARI, it is a different mind set that does take some time to get around. Much like Paul I had my own preconceived notions about what ARI was and was initially disappointed it didn't match what I thought it should have been. However over the last few months of watching what Paul has been doing along with some small side POC stuff to better understand what ARI is intended for, it definitely has become a lot clearer. At the most basic levels, ARI to me is a bridge control interface that allows you to hook channels together while not worrying about transcoding, media characteristics etc. You have two or more channels that may or may not speak the same language, and your external applications stick them together, and Asterisk acts as the universal translator for those channels. By writing all your business logic and controls outside of Asterisk, it makes the API much simpler to interoperate with, and allows great scaling possibilities. Admittedly I'm still a bit naive on a lot of the ARI front, but one thing my gut tells me, is it is a new interface, and should not be confused as a replacement to the legacy (term used loosely) methods of building Asterisk systems. This is one of those situations that I feel avoiding legacy and backwards compatibility with the traditional methods is going to really open up a better realm of possibilities with ARI. If someone truly just needs an HTTP based interface for controlling dialplan and such, I feel a translation application (library) should just be written for AMI and AGI that permits that and has that goal. Overloading what ARI is supposed to be doing is a step backwards in my
Re: [asterisk-dev] ARI Extending Existing Feature: bridge control
On Wed, Dec 17, 2014 at 3:16 PM, Nir Simionovich nir.simionov...@gmail.com wrote: Hi All, After shipping out my first patch to ARI, I became hungry :-) So, now I've set up a slightly higher goal, adding a much required feature for ARI. I'll describe the problem first, then I have some questions. The Asterisk dial application enables us to limit the duration of the call and play a warning sound. Once this had been set, as far as I know, you can't modify these values externally. When the feature was originally introduced, over 10 years ago, the goal was simple: enable a calling card system to limit the call according to a credit line. As time went by, people realized that this feature is useful, however limited. In today's mobile application era, when a VoIP phone can actually purchase credit while on the actual call, we need a way to control this from an external source. Now, I've started digging into the code, and I've managed to understand that following (feel free to bash me if I'm wrong): 1. The time limits are maintained at the bridge structure, not at the channel - using the ast_bridge_config data structure 2. The ARI bridges GET method only retrieves a list of bridges and their associated channels, not their configurations So, assuming that I'm reading the ast_ari_bridges_list function from resouce_bridges.c correctly, we retrieve a snapshot of all active bridges via the snapshots variable (if you can call it that). The output is built by iterating through it. Now, my questions: 1. Is there a way to obtain the information in ast_bridge_config for each of the iterated bridges, then output it via the JSON response? 2. Is there a way to manipulate the configuration of the bridge, via modifying the associated bridge configuration? The floor is now open :-) I am a little confused what you are asking. You want to add some sort of lifetime support to bridge within asterisk, using ARI? -- Paul Belanger | PolyBeacon, Inc. Jabber: paul.belan...@polybeacon.com | IRC: pabelanger (Freenode) Github: https://github.com/pabelanger | Twitter: https://twitter.com/pabelanger -- _ -- 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 Extending Existing Feature: bridge control
Well, In simple words yes. To be more specific, I'd like to do something like this: 1. Have a simple dialplan that will dialout using the L parameter in Dial application 2. Have ARI bridge list function retrieve not only the list of active bridges, but also their allocated duration timers - if assigned 3. Provide a means via ARI to manipulate the duration timers Nir On Wed, Dec 17, 2014 at 10:37 PM, Paul Belanger paul.belan...@polybeacon.com wrote: On Wed, Dec 17, 2014 at 3:16 PM, Nir Simionovich nir.simionov...@gmail.com wrote: Hi All, After shipping out my first patch to ARI, I became hungry :-) So, now I've set up a slightly higher goal, adding a much required feature for ARI. I'll describe the problem first, then I have some questions. The Asterisk dial application enables us to limit the duration of the call and play a warning sound. Once this had been set, as far as I know, you can't modify these values externally. When the feature was originally introduced, over 10 years ago, the goal was simple: enable a calling card system to limit the call according to a credit line. As time went by, people realized that this feature is useful, however limited. In today's mobile application era, when a VoIP phone can actually purchase credit while on the actual call, we need a way to control this from an external source. Now, I've started digging into the code, and I've managed to understand that following (feel free to bash me if I'm wrong): 1. The time limits are maintained at the bridge structure, not at the channel - using the ast_bridge_config data structure 2. The ARI bridges GET method only retrieves a list of bridges and their associated channels, not their configurations So, assuming that I'm reading the ast_ari_bridges_list function from resouce_bridges.c correctly, we retrieve a snapshot of all active bridges via the snapshots variable (if you can call it that). The output is built by iterating through it. Now, my questions: 1. Is there a way to obtain the information in ast_bridge_config for each of the iterated bridges, then output it via the JSON response? 2. Is there a way to manipulate the configuration of the bridge, via modifying the associated bridge configuration? The floor is now open :-) I am a little confused what you are asking. You want to add some sort of lifetime support to bridge within asterisk, using ARI? -- Paul Belanger | PolyBeacon, Inc. Jabber: paul.belan...@polybeacon.com | IRC: pabelanger (Freenode) Github: https://github.com/pabelanger | Twitter: https://twitter.com/pabelanger -- _ -- 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] ARI Extending Existing Feature: bridge control
On Wed, Dec 17, 2014 at 3:46 PM, Nir Simionovich nir.simionov...@gmail.com wrote: Well, In simple words yes. To be more specific, I'd like to do something like this: 1. Have a simple dialplan that will dialout using the L parameter in Dial application 2. Have ARI bridge list function retrieve not only the list of active bridges, but also their allocated duration timers - if assigned 3. Provide a means via ARI to manipulate the duration timers Correct me if I am wrong, but I don't think this will work. Any bridge or channel from your dialplan would not be controlled by stasis. And since it is not in stasis, ARI cannot modify it. I think the general idea was to build a new app_dial atop of ARI, then your application would provide that functionality to control the L parameter. -- Paul Belanger | PolyBeacon, Inc. Jabber: paul.belan...@polybeacon.com | IRC: pabelanger (Freenode) Github: https://github.com/pabelanger | Twitter: https://twitter.com/pabelanger -- _ -- 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 Extending Existing Feature: bridge control
I agree with Paul 100%. Given my experience with ARI over the last year and how easy it is to create these apps I would think you could avoid the dialplan completely and easily create a routine to do exactly what you want. 1. You would know when the call started and was connected. 2. You can easily play a sound, any sound, to either end of the connection or to both. 3. You can disconnect the call when you want. 4. I'm not sure given your requirements but you could even allow the caller (or callee) to put funds in their account to allow for more time. ARI is the way to go! IMHO. Phil M On Wed, Dec 17, 2014 at 3:58 PM, Paul Belanger paul.belan...@polybeacon.com wrote: On Wed, Dec 17, 2014 at 3:46 PM, Nir Simionovich nir.simionov...@gmail.com wrote: Well, In simple words yes. To be more specific, I'd like to do something like this: 1. Have a simple dialplan that will dialout using the L parameter in Dial application 2. Have ARI bridge list function retrieve not only the list of active bridges, but also their allocated duration timers - if assigned 3. Provide a means via ARI to manipulate the duration timers Correct me if I am wrong, but I don't think this will work. Any bridge or channel from your dialplan would not be controlled by stasis. And since it is not in stasis, ARI cannot modify it. I think the general idea was to build a new app_dial atop of ARI, then your application would provide that functionality to control the L parameter. -- Paul Belanger | PolyBeacon, Inc. Jabber: paul.belan...@polybeacon.com | IRC: pabelanger (Freenode) Github: https://github.com/pabelanger | Twitter: https://twitter.com/pabelanger -- _ -- 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] ARI Extending Existing Feature: bridge control
Ok, I'll start with this - I agree with the both of you, ARI is the right way to go. However, when I look at ARI, I see somewhat of a Hybrid. When I say hybrid I mean, a tool that enables me to do stuff, both inside and outside of the Stasis construct. Example, ARI provides a channels API, enabling you to originate a call. If ARI was only about stasis, why did we enable the classic application/extension, we could have easily just said: oh, originate the call and dump it into a Stasis app - but that didn't happen. Instead, you put the call into a dialplan or an application, which in turn, will call the Stasis app (if truly required). My point is this, if the ability exists and can be added, why not? It doesn't break anything that's already in there, it adds much needed functionality and it makes ARI richer in comparison to its predecessor AMI, which people still have a hard time figuring out why they should move to ARI. This kind of feature can be a tipping point. My 2c on the matter. On Wed, Dec 17, 2014 at 11:04 PM, Phil Mickelson p...@cbasoftware.com wrote: I agree with Paul 100%. Given my experience with ARI over the last year and how easy it is to create these apps I would think you could avoid the dialplan completely and easily create a routine to do exactly what you want. 1. You would know when the call started and was connected. 2. You can easily play a sound, any sound, to either end of the connection or to both. 3. You can disconnect the call when you want. 4. I'm not sure given your requirements but you could even allow the caller (or callee) to put funds in their account to allow for more time. ARI is the way to go! IMHO. Phil M On Wed, Dec 17, 2014 at 3:58 PM, Paul Belanger paul.belan...@polybeacon.com wrote: On Wed, Dec 17, 2014 at 3:46 PM, Nir Simionovich nir.simionov...@gmail.com wrote: Well, In simple words yes. To be more specific, I'd like to do something like this: 1. Have a simple dialplan that will dialout using the L parameter in Dial application 2. Have ARI bridge list function retrieve not only the list of active bridges, but also their allocated duration timers - if assigned 3. Provide a means via ARI to manipulate the duration timers Correct me if I am wrong, but I don't think this will work. Any bridge or channel from your dialplan would not be controlled by stasis. And since it is not in stasis, ARI cannot modify it. I think the general idea was to build a new app_dial atop of ARI, then your application would provide that functionality to control the L parameter. -- Paul Belanger | PolyBeacon, Inc. Jabber: paul.belan...@polybeacon.com | IRC: pabelanger (Freenode) Github: https://github.com/pabelanger | Twitter: https://twitter.com/pabelanger -- _ -- 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 mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] ARI Extending Existing Feature: bridge control
Nir, I agree with you about wondering why does the call go through the dialplan. Perhaps someone could answer that? Or, perhaps give us some idea if this will change? In my case, the connection to the dialplan is literally three lines. The minimum required. I never return. Phil M On Wed, Dec 17, 2014 at 4:12 PM, Nir Simionovich nir.simionov...@gmail.com wrote: Ok, I'll start with this - I agree with the both of you, ARI is the right way to go. However, when I look at ARI, I see somewhat of a Hybrid. When I say hybrid I mean, a tool that enables me to do stuff, both inside and outside of the Stasis construct. Example, ARI provides a channels API, enabling you to originate a call. If ARI was only about stasis, why did we enable the classic application/extension, we could have easily just said: oh, originate the call and dump it into a Stasis app - but that didn't happen. Instead, you put the call into a dialplan or an application, which in turn, will call the Stasis app (if truly required). My point is this, if the ability exists and can be added, why not? It doesn't break anything that's already in there, it adds much needed functionality and it makes ARI richer in comparison to its predecessor AMI, which people still have a hard time figuring out why they should move to ARI. This kind of feature can be a tipping point. My 2c on the matter. On Wed, Dec 17, 2014 at 11:04 PM, Phil Mickelson p...@cbasoftware.com wrote: I agree with Paul 100%. Given my experience with ARI over the last year and how easy it is to create these apps I would think you could avoid the dialplan completely and easily create a routine to do exactly what you want. 1. You would know when the call started and was connected. 2. You can easily play a sound, any sound, to either end of the connection or to both. 3. You can disconnect the call when you want. 4. I'm not sure given your requirements but you could even allow the caller (or callee) to put funds in their account to allow for more time. ARI is the way to go! IMHO. Phil M On Wed, Dec 17, 2014 at 3:58 PM, Paul Belanger paul.belan...@polybeacon.com wrote: On Wed, Dec 17, 2014 at 3:46 PM, Nir Simionovich nir.simionov...@gmail.com wrote: Well, In simple words yes. To be more specific, I'd like to do something like this: 1. Have a simple dialplan that will dialout using the L parameter in Dial application 2. Have ARI bridge list function retrieve not only the list of active bridges, but also their allocated duration timers - if assigned 3. Provide a means via ARI to manipulate the duration timers Correct me if I am wrong, but I don't think this will work. Any bridge or channel from your dialplan would not be controlled by stasis. And since it is not in stasis, ARI cannot modify it. I think the general idea was to build a new app_dial atop of ARI, then your application would provide that functionality to control the L parameter. -- Paul Belanger | PolyBeacon, Inc. Jabber: paul.belan...@polybeacon.com | IRC: pabelanger (Freenode) Github: https://github.com/pabelanger | Twitter: https://twitter.com/pabelanger -- _ -- 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 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] ARI Extending Existing Feature: bridge control
Phil, It is one thing to say: I'm interested in advancement, it is completely a different thing to say: I don't give a damn about backward compatibility. Asterisk is a huge community around the world, shifting the community from one methodology of thought to another takes time. During that time of transition, we must think about the fact that some (if not many) will still stick to the old ways. For example, it took over 3 years to deprecate app_meetme - do you honestly believe it will take the same time to deprecate app_dial? I suspect that the answer will be - app_dial will always be there. We may not like it, but still, it is the simplest way of getting a call out of Asterisk. Like it or not, the dialplan will still be here, even 5 years or 10 years from now - it's the most basic form. In the mean time, we must provide functionality and robustness - if we don't, we'll become irrelevant. On Wed, Dec 17, 2014 at 11:16 PM, Phil Mickelson p...@cbasoftware.com wrote: Nir, I agree with you about wondering why does the call go through the dialplan. Perhaps someone could answer that? Or, perhaps give us some idea if this will change? In my case, the connection to the dialplan is literally three lines. The minimum required. I never return. Phil M On Wed, Dec 17, 2014 at 4:12 PM, Nir Simionovich nir.simionov...@gmail.com wrote: Ok, I'll start with this - I agree with the both of you, ARI is the right way to go. However, when I look at ARI, I see somewhat of a Hybrid. When I say hybrid I mean, a tool that enables me to do stuff, both inside and outside of the Stasis construct. Example, ARI provides a channels API, enabling you to originate a call. If ARI was only about stasis, why did we enable the classic application/extension, we could have easily just said: oh, originate the call and dump it into a Stasis app - but that didn't happen. Instead, you put the call into a dialplan or an application, which in turn, will call the Stasis app (if truly required). My point is this, if the ability exists and can be added, why not? It doesn't break anything that's already in there, it adds much needed functionality and it makes ARI richer in comparison to its predecessor AMI, which people still have a hard time figuring out why they should move to ARI. This kind of feature can be a tipping point. My 2c on the matter. On Wed, Dec 17, 2014 at 11:04 PM, Phil Mickelson p...@cbasoftware.com wrote: I agree with Paul 100%. Given my experience with ARI over the last year and how easy it is to create these apps I would think you could avoid the dialplan completely and easily create a routine to do exactly what you want. 1. You would know when the call started and was connected. 2. You can easily play a sound, any sound, to either end of the connection or to both. 3. You can disconnect the call when you want. 4. I'm not sure given your requirements but you could even allow the caller (or callee) to put funds in their account to allow for more time. ARI is the way to go! IMHO. Phil M On Wed, Dec 17, 2014 at 3:58 PM, Paul Belanger paul.belan...@polybeacon.com wrote: On Wed, Dec 17, 2014 at 3:46 PM, Nir Simionovich nir.simionov...@gmail.com wrote: Well, In simple words yes. To be more specific, I'd like to do something like this: 1. Have a simple dialplan that will dialout using the L parameter in Dial application 2. Have ARI bridge list function retrieve not only the list of active bridges, but also their allocated duration timers - if assigned 3. Provide a means via ARI to manipulate the duration timers Correct me if I am wrong, but I don't think this will work. Any bridge or channel from your dialplan would not be controlled by stasis. And since it is not in stasis, ARI cannot modify it. I think the general idea was to build a new app_dial atop of ARI, then your application would provide that functionality to control the L parameter. -- Paul Belanger | PolyBeacon, Inc. Jabber: paul.belan...@polybeacon.com | IRC: pabelanger (Freenode) Github: https://github.com/pabelanger | Twitter: https://twitter.com/pabelanger -- _ -- 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 mailing list To UNSUBSCRIBE or update options visit:
Re: [asterisk-dev] ARI Extending Existing Feature: bridge control
Regarding Stasis origination: like AMI/CLI/Dialplan origination, Stasis origination comes in two flavors. 1) Originate to an application. Unlike with AMI/CLI/Dialplan origination to an application, this will always originate to a Stasis application. So in a way, this flavor of origination does what Nir expects. 2) Originate to a dialplan location. This functions pretty much exactly like AMI/CLI/Dialplan origination to an extension/context/priority. The difference here is that your Stasis application gains a subscription to the channel that is created, so you have the ability to be notified of activities that this channel performs. My guess is that this is intended more for deployments that have upgraded Asterisk to use ARI for specific applications, but that already have some semblance of dialplan/AGI that they want to incorporate. In general, I would expect that someone implementing an ARI application from scratch would never use this flavor of origination. Now on to Nir's suggestion regarding bridge lifetimes: I'm not a fan of adding this to ARI. To me ARI should expose primitive operations only, and it's up to library/framework/application writers to build it into something more. For instance, you'll notice that we have no DTMF-triggered features available in ARI bridges. This is because we expose the ability for ARI applications to capture DTMF themselves and translate that into their own feature instead. Similarly, with regards to bridge lifetimes, any programming language you could ever use to write an ARI application will have timing libraries available for you to manage the lifetime of a bridge. The thing that's neat with a REST interface that exposes primitives is that it promotes an ecosystem where people can write libraries on top of ARI that perform more complex operations. For instance, it would be totally possible for someone to write a bridge management library that exposed a more complex API where bridges could have a lifetime, could play media to participants at given intervals, could have the lifetime changed (and play media to the participants letting them know that the lifetime changed), and could maybe even allow the bridge to be re-created after expiration if a participant takes a certain action (like providing more money to a service). Someone else could fork that bridge management library and add their own features on top of it. Instead of having ARI expose the one true way to manage the lifetime of bridges, people have a choice between different implementations written by others or they can write their own (either from scratch or by forking someone else's library) to fit their needs. On 12/17/2014 03:16 PM, Phil Mickelson wrote: Nir, I agree with you about wondering why does the call go through the dialplan. Perhaps someone could answer that? Or, perhaps give us some idea if this will change? In my case, the connection to the dialplan is literally three lines. The minimum required. I never return. Phil M On Wed, Dec 17, 2014 at 4:12 PM, Nir Simionovich nir.simionov...@gmail.com mailto:nir.simionov...@gmail.com wrote: Ok, I'll start with this - I agree with the both of you, ARI is the right way to go. However, when I look at ARI, I see somewhat of a Hybrid. When I say hybrid I mean, a tool that enables me to do stuff, both inside and outside of the Stasis construct. Example, ARI provides a channels API, enabling you to originate a call. If ARI was only about stasis, why did we enable the classic application/extension, we could have easily just said: oh, originate the call and dump it into a Stasis app - but that didn't happen. Instead, you put the call into a dialplan or an application, which in turn, will call the Stasis app (if truly required). My point is this, if the ability exists and can be added, why not? It doesn't break anything that's already in there, it adds much needed functionality and it makes ARI richer in comparison to its predecessor AMI, which people still have a hard time figuring out why they should move to ARI. This kind of feature can be a tipping point. My 2c on the matter. On Wed, Dec 17, 2014 at 11:04 PM, Phil Mickelson p...@cbasoftware.com mailto:p...@cbasoftware.com wrote: I agree with Paul 100%. Given my experience with ARI over the last year and how easy it is to create these apps I would think you could avoid the dialplan completely and easily create a routine to do exactly what you want. 1. You would know when the call started and was connected. 2. You can easily play a sound, any sound, to either end of the connection or to both. 3. You can disconnect the call when you want. 4. I'm not sure given your requirements but you could even allow the caller (or callee) to put funds in their account to allow for
Re: [asterisk-dev] ARI Extending Existing Feature: bridge control
Nir, I don't disagree with you at all. All I'd like is another way. The current methods don't have to disappear. It's not either or. However, there's also no reason not to explore new methods, is there? Phil M On Wed, Dec 17, 2014 at 5:29 PM, Nir Simionovich nir.simionov...@gmail.com wrote: Phil, It is one thing to say: I'm interested in advancement, it is completely a different thing to say: I don't give a damn about backward compatibility. Asterisk is a huge community around the world, shifting the community from one methodology of thought to another takes time. During that time of transition, we must think about the fact that some (if not many) will still stick to the old ways. For example, it took over 3 years to deprecate app_meetme - do you honestly believe it will take the same time to deprecate app_dial? I suspect that the answer will be - app_dial will always be there. We may not like it, but still, it is the simplest way of getting a call out of Asterisk. Like it or not, the dialplan will still be here, even 5 years or 10 years from now - it's the most basic form. In the mean time, we must provide functionality and robustness - if we don't, we'll become irrelevant. On Wed, Dec 17, 2014 at 11:16 PM, Phil Mickelson p...@cbasoftware.com wrote: Nir, I agree with you about wondering why does the call go through the dialplan. Perhaps someone could answer that? Or, perhaps give us some idea if this will change? In my case, the connection to the dialplan is literally three lines. The minimum required. I never return. Phil M On Wed, Dec 17, 2014 at 4:12 PM, Nir Simionovich nir.simionov...@gmail.com wrote: Ok, I'll start with this - I agree with the both of you, ARI is the right way to go. However, when I look at ARI, I see somewhat of a Hybrid. When I say hybrid I mean, a tool that enables me to do stuff, both inside and outside of the Stasis construct. Example, ARI provides a channels API, enabling you to originate a call. If ARI was only about stasis, why did we enable the classic application/extension, we could have easily just said: oh, originate the call and dump it into a Stasis app - but that didn't happen. Instead, you put the call into a dialplan or an application, which in turn, will call the Stasis app (if truly required). My point is this, if the ability exists and can be added, why not? It doesn't break anything that's already in there, it adds much needed functionality and it makes ARI richer in comparison to its predecessor AMI, which people still have a hard time figuring out why they should move to ARI. This kind of feature can be a tipping point. My 2c on the matter. On Wed, Dec 17, 2014 at 11:04 PM, Phil Mickelson p...@cbasoftware.com wrote: I agree with Paul 100%. Given my experience with ARI over the last year and how easy it is to create these apps I would think you could avoid the dialplan completely and easily create a routine to do exactly what you want. 1. You would know when the call started and was connected. 2. You can easily play a sound, any sound, to either end of the connection or to both. 3. You can disconnect the call when you want. 4. I'm not sure given your requirements but you could even allow the caller (or callee) to put funds in their account to allow for more time. ARI is the way to go! IMHO. Phil M On Wed, Dec 17, 2014 at 3:58 PM, Paul Belanger paul.belan...@polybeacon.com wrote: On Wed, Dec 17, 2014 at 3:46 PM, Nir Simionovich nir.simionov...@gmail.com wrote: Well, In simple words yes. To be more specific, I'd like to do something like this: 1. Have a simple dialplan that will dialout using the L parameter in Dial application 2. Have ARI bridge list function retrieve not only the list of active bridges, but also their allocated duration timers - if assigned 3. Provide a means via ARI to manipulate the duration timers Correct me if I am wrong, but I don't think this will work. Any bridge or channel from your dialplan would not be controlled by stasis. And since it is not in stasis, ARI cannot modify it. I think the general idea was to build a new app_dial atop of ARI, then your application would provide that functionality to control the L parameter. -- Paul Belanger | PolyBeacon, Inc. Jabber: paul.belan...@polybeacon.com | IRC: pabelanger (Freenode) Github: https://github.com/pabelanger | Twitter: https://twitter.com/pabelanger -- _ -- 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:
Re: [asterisk-dev] ARI Extending Existing Feature: bridge control
While I agree with the both of you - I still don't see a reason why not to do it. I'll tell you how I see it - I'm looking at this kind of feature from a cost/performance/benefit ratio. Does this kind of feature enable a new benefit that didn't exist previously - yes. Does it impact the overall performance of Asterisk - probably not. Is it a low hanging fruit to develop? - I can't answer that yet Would it take a longer time to develop a bridge manager externally, or develop the feature? - I can't answer that yet Currently, I'm trying to evaluate the task - from a technical/operational/financial reasoning. If Tech/Ops make sense, but Finance doesn't - it ain't worth doing. Let's try and discuss for a minute what it would actually take in order to do this, instead of debating if we should or shouldn't. Yes, maybe you'll say - in order to do this, you'll need to do 1, 2, 3, 4 - and maybe I'll: cool, I'll have a go at it, and maybe it will go in, and maybe it will not - but that's open source. Open Source means, we work collaboratively, we explore things and keep our minds open to ideas and suggestions. When Leonid and I created PHPARI about 4 months ago, we created it out of a need for a proper wrapper that will fit nicely into our projects. I'm currently aware of 10 different people using it in production - and some of them already contributed code and structural changes to it. One of the things people asked us for an OAuth based ARI proxy, because they like using tokens. Does ARI truly need something like that - not really. Does ARI need better security - for sure. Will we shot down the idea down? not at this point. We first examine what it will take to do it, technically, then financially - then we decide. Damn, this is turning into another theological discussion - not really to be part of this list. 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? 2. Is there a way to manipulate the configuration of the bridge, via modifying the associated bridge configuration in real time? Nir On Thu, Dec 18, 2014 at 12:33 AM, Phil Mickelson p...@cbasoftware.com wrote: Nir, I don't disagree with you at all. All I'd like is another way. The current methods don't have to disappear. It's not either or. However, there's also no reason not to explore new methods, is there? Phil M On Wed, Dec 17, 2014 at 5:29 PM, Nir Simionovich nir.simionov...@gmail.com wrote: Phil, It is one thing to say: I'm interested in advancement, it is completely a different thing to say: I don't give a damn about backward compatibility. Asterisk is a huge community around the world, shifting the community from one methodology of thought to another takes time. During that time of transition, we must think about the fact that some (if not many) will still stick to the old ways. For example, it took over 3 years to deprecate app_meetme - do you honestly believe it will take the same time to deprecate app_dial? I suspect that the answer will be - app_dial will always be there. We may not like it, but still, it is the simplest way of getting a call out of Asterisk. Like it or not, the dialplan will still be here, even 5 years or 10 years from now - it's the most basic form. In the mean time, we must provide functionality and robustness - if we don't, we'll become irrelevant. On Wed, Dec 17, 2014 at 11:16 PM, Phil Mickelson p...@cbasoftware.com wrote: Nir, I agree with you about wondering why does the call go through the dialplan. Perhaps someone could answer that? Or, perhaps give us some idea if this will change? In my case, the connection to the dialplan is literally three lines. The minimum required. I never return. Phil M On Wed, Dec 17, 2014 at 4:12 PM, Nir Simionovich nir.simionov...@gmail.com wrote: Ok, I'll start with this - I agree with the both of you, ARI is the right way to go. However, when I look at ARI, I see somewhat of a Hybrid. When I say hybrid I mean, a tool that enables me to do stuff, both inside and outside of the Stasis construct. Example, ARI provides a channels API, enabling you to originate a call. If ARI was only about stasis, why did we enable the classic application/extension, we could have easily just said: oh, originate the call and dump it into a Stasis app - but that didn't happen. Instead, you put the call into a dialplan or an application, which in turn, will call the Stasis app (if truly required). My point is this, if the ability exists and can be added, why not? It doesn't break anything that's already in there, it adds much needed functionality and it makes ARI richer in comparison to its predecessor AMI, which people still have a hard time figuring out why they should move to ARI. This kind of feature can be a tipping point. My 2c on the matter. On Wed, Dec 17, 2014 at 11:04 PM,
Re: [asterisk-dev] ARI Extending Existing Feature: bridge control
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
Re: [asterisk-dev] ARI Extending Existing Feature: bridge control
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
Re: [asterisk-dev] ARI Extending Existing Feature: bridge control
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
