No subject

discussed about in asterisk-users, about wanting to drive the AGI flow
based on AMI events, as you said, this requires to take care of sync
issues. With Async AGI approach, the channel will sit there waiting
for AGI commands that will arrive either by AMI or the CLI ( the CLI
AGI execution is useful for handy testing ). Each time an AGI command
is executed an AMI event is generated with the response of the
command, besides you have all the events the application executed
could have generated as feedback ( Like Dial and Link events ).

As stated in the bug tracker, I think that in theory, with some
creative use of manager actions  "Redirect" and "Bridge", with Async
AGI you can write  functionality like attended transfer, queues,
parking lots etc, using any language you want, including of course,
PERL, Python and PHP for quick development.

If you need the patch back-ported to 1.4 or 1.2, let me know. I
already have 1.4 back-port and could create a 1.2 port, which could
require a bit more effort since I think 1.2 does not have channel
datastores.

- Mois=E9s Silva

On Dec 10, 2007 1:27 PM, Jim Capp <jcapp at anteil.com> wrote:
> Moises,
>
>     This patch looks cool!  It looks like you will have to monitor all
> the events and then watch for the ones you are specifically interested
> in, in order to continue with step-by-step processing of the dynamic
> application?
>
> Jim
>
>
> Moises Silva wrote:
> > Also, with this patch I just added: http://bugs.digium.com/view.php?id=
=3D11282
> >
> > You can do AGI thru AMI, having a single interface :)
> >
> > On Dec 10, 2007 11:20 AM, Steven Critchfield <critch at basesys.com> wrote=
:
> >
> >> On Mon, 2007-12-10 at 17:40 +0100, David Roden wrote:
> >>
> >>> On Monday 10 December 2007 17:16:56 Jim Capp wrote:
> >>>
> >>>
> >>>> Please check out the "asterisk-java" project:
> >>>>
> >>> I am already using that. :)
> >>>
> >>> While it does indeed keep the low-level stuff away from me I still ha=
ve to
> >>> worry about synchronization issues between the two APIs in use. I wro=
te my
> >>> own layer above asterisk-java so that at least these two APIs are hid=
den from
> >>> my application but--as I said--I'd prefer if there was The One Asteri=
sk API I
> >>> could use instead. :)
> >>>
> >>> Would it be hard to include AMI commands like "ReadDTMF" that trigger
> >>> DTMFReadEvents or DTMFReadResponses as soon as the user pressed a key=
?
> >>>
> >> So here is an interesting thought for those who want to essentially
> >> rewrite core functionality, You have the source and can rewite the cor=
e.
> >>
> >> I'll quickly appologise for what looks like a flaming start to the
> >> message, it is meant to be taken with no attitude and as just a flat
> >> statement of fact.
> >>
> >> If you want access to the core call handling like AGI, why not create
> >> your app down in the core of asterisk. Then you also end up with acces=
s
> >> to all those events that are exposed up to AMI as well.
> >>
> >> This one single API you wish to access is really in the core of
> >> asterisk.
> >> --
> >> Steven Critchfield <critch at basesys.com>
> >>
> >>
> >>
> >> _______________________________________________
> >> --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
>



--=20
"Within C++, there is a much smaller and cleaner language struggling
to get out."