[asterisk-dev] CSTA - Worth looking at again?

[Nir Simionovich]

Actually, +3

Although I'm not in direct familiarity with CSTA, I've got a couple of
customers using it.
These are mainly Contact/Call center oriented companies, that had developed
management
systems based on CSTA.

I'm currently envolved in a project where I'm incharged with verifying that
another contractor's
implementation will handle the load, but basically, it's an Asterisk
application that that performs
an AGI/AMI bridge to CSTA - fairly interesting from the performance point of
view.

Nir

On Thu, Oct 16, 2008 at 7:03 PM, Brian Degenhardt <bmd at digium.com> wrote:

> John Todd wrote:
> > [This has come up a few times over the last 4 years on this list and
> > others, but it has never before had enough people look at it who
> > understood perhaps what the benefits were, so I drag it out again
> > here for your amusement...]
> >
> >
> > Would a CSTA interface (or in a variant, uaCSTA) be a useful API
> > layer for Asterisk?  Would some of the PineMango goals be workable
> > with a CSTA method as the "language" portion of the communication?
> > Or would it merely be a monolithic module that would talk to the API
> > components as a discrete consumer/producer of messages to the various
> > components?  I'm largely ignorant of the details of where the API
> > discussion would layer into what something like CSTA could offer -
> > feel free to say that these two concepts are non-intersecting and
> > I'll drop it.
> >
> >
> > Regardless of CSTA's role in a potential "next-generation" fruit-like
> > API project, it still bears examination as a potential interface for
> > other Enterprise-ish platforms.  Microsoft's OCS/LCS Platform uses a
> > variant of uaCSTA over SIP, as does Avaya, Cisco, Mitel, and
> > others(?- need a list).  Of course, I'm not so interested in those
> > legacy PBX platforms, but the tools that third-party companies are
> > producing to bolt onto them are what sound like has some value.
> > Creating a CSTA interface to Asterisk would allow quick grafting of
> > "industry standard" tools onto an inexpensive and flexible OSS
> > back-end.
> >
> > Comments?
> >
> >
> > Base page:
> >
> http://www.ecma-international.org/activities/Communications/TG11/cstaIII.htm
> >
> >
> > Here's an introduction (194kb):
> >
> http://www.ecma-international.org/activities/Communications/TG11/CSTAoverview.pdf
> >
> >
> > This seems to be some of the documentation (4mb, 767 pages!):
> >   http://www.ecma-international.org/publications/standards/Ecma-269.htm
> >
> > CPAN module for CSTA (incomplete - Phase I only - need Phase III)
> >   http://search.cpan.org/~leifj/Net-CSTA-0.04/lib/Net/CSTA.pm<http://search.cpan.org/%7Eleifj/Net-CSTA-0.04/lib/Net/CSTA.pm>
>
> Again referring to Nir's diagram:
>
> http://www.simionovich.com/wp-content/uploads/2008/10/image2_diagram1.jpg
>
> I definitely think that CSTA is worth looking at, either in the
> tan/olive layer or as a shim layer in orange that translates the subset
> of res_api that's applicable to CSTA.
>
> Also, I think that CSTA is very helpful to get an idea of what a good
> telephony API looks like.  We should borrow heavily from it when
> designing res_api.
>
> However, CSTA alone will probably not satisfy all our needs.  There's a
> lot of things you might want to do that CSTA doesn't address such as
> peer/account creation/modification, registration status/hooks, music on
> hold, queue announcements,  detailed queue status and other
> Asterisk-specific features not addressed by the CSTA spec.
>
> cheers
> -bmd
>
> _______________________________________________
> --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/20081017/18c34555/attachment.htm