[Bayonne-desktop] Re: [Evolution-hackers] Re: [Bayonne-devel]Re: GNOME "Telephony Application Programming Services" Proposed

[David Sugar]

This is an interesting question.  Many proprietary PBX systems do have cti 
interfaces (that are unfortunately also often proprietary).  The manner w32 
solves this problem is to have a two stack library (known as TAPI), so that a 
vendor can create a proprietary plugin to an already proprietary library 
interface.  This isolates the vendor's code from both the os and user's code, 
but does so by having a two level api (one user visible, one vendor visible) 
and by redirecting all calls to the lower level plugin.  This is a very 
fragile approach, is inefficient since actual api calls have to be redirected 
through several layers, and means any change in the "wrapper" library 
requires an entirely new plugin has to be created (none are backward 
compatible, which is why there are many broken TAPI drivers from many PBX 
vendors litering the cti realm as they only worked with what are now no 
longer supported releases of TAPI).

In the case of gtaps, as a concept, I suppose anything that happens to 
implement the same defined library interface calls which applications link 
with at runtime could implement the specification.  A runtime linkable 
library could in this sense even be proprietary, although I would not 
recommend that.  However, gtaps would be concerned with implementing model 
(l)gpl'd libraries for existing free/oss telephony servers like Bayonne, 
Yate, Asterisk, and to provide an interface spec for those trying to write 
the same for other things, like say your Nortal switch, although reverse 
engineering, rather than a vendor supplied source secret library, would be 
the desirable way to do this.  At least that is the essense of the idea and 
the project; a library interface specification, and one (or more) reference 
implementation(s) for existing free/oss telephony platforms.  A few simple 
tools that exercise the library (such as a screen pop applet, a dialer 
thingie, etc) will be what makes the project complete.

On Monday 09 February 2004 05:53 am, Adam Williams wrote:
> Why are these messages stamped as year 2003?
>
> > GNU Bayonne already does some of these same things as well and has done
> > so for a number of years now in varied commercial, carrier class, and
> > governmental settings.  It is also an integral part of the GNU system,
> > and does some things that are distinctly different from Asterisk. 
> > However, TAPS has nothing to do directly with being such a system.  TAPS
> > is also not a softphone client.   Rather, TAPS is intended purely to
> > standardize how we integrate such things like GNU Bayonne, Astreisk, or
> > other common office telephony servers and systems, with common desktop
> > applications (such as address books, contact management  systems, etc). 
> > In that sense it services some of the same role as JTAPI, although in a
> > manner far more directly usable in GNOME (through a C callable library),
> > and both far simpler and more consistent with free software  development
> > than JTAPI (or fully proprietary systems such as Microsoft TAPI)
> > currently do this.
> >
> > > > > GNOME TAPS will offer a C callable library to easily integrate
> > > > > telephony functions into existing GNOME applications.  It will use
> > > > > a common TCP based backend protocol to communicate directly with
> > > > > office telephone equipment and services, and ideally for use with
> > > > > free software based telephone systems such as GNU Bayonne.  It will
> > > > > include an applet to pop-up and support handling of incoming calls.
> > > > >  It will include a gnome control-center plugin for setting of
> > > > > telephony options.
>
> This would be fabulous.  Is there any chance this will support
> commerical PBX's (for CTIish applications) anytime in the forseeable
> future.  I have 13 Nortel BCM VOIP phonesystems and have been looking
> for a way to integrate these with OpenGroupware in a
> click-contact-to-call fashion - as can be done from a Win32 system.