[OGo-Developer] Re: CTI In General [Was: Re: [OGo-Users] OGo &Asterisk]

[Sebastian Reitenbach]

developer@opengroupware.org wrote: 
> > > <aside>Lucky for me the protocol is largely based on IMAP and uses a
> > > bunch of X- commands to invoke PBXish operations - messaging as in
> > > checking for new messages is straight IMAP.</aside>
> > So for just e.g. name it NortelDialer.cti this should be easy
> 
> Yep.
> 
> > be put aside. From my point of view, the CTI bundle api is just 
sufficient, 
> > so no need to change there sth. besides adding new Dialer bundles.
> 
> I agree, but the bundle only provides the functionality for the dialer.
for sure, the additional stuff I wrote for Asterisk is a different question.

> 
> > I started the whole thing quite some time ago, my objective-c/webobjects 
> > skills where at a low level at the beginning. So there is very likely 
code
> > in the actual AsteriskUI that will hurt your eyes. 
> 
> Understood, I have the same issue in zOGI.  The code I wrote first is
> horrible to the code I wrote later.  Just the nature of the beast.
> 
> > For joint work, I think it would be great to have it in SVN, below Misc, 
> > with some write permissions for me there, and anybody else who wants to 
work 
> > on the PBXUI.
> 
> Agree.
> 
> > I think integrating the whole CDR stuff into the PBXUI first, keeping it 
as 
> > a separate bundle, makes sense.
> > Does the Nortel PBX also record these details to a database? 
> 
> Sort of.  I think in most cases, regardless of PBX kind,  there is going
> to be some routine to slurp CDR data from the PBX into OGo.
> 
> > or do you have to query it via the protocol you mentioned?
> 
> CDR on the BCM is accessed through a wretched little protocol,  but I
> don't see that as part of "OGo's problem".  OGo should just use the CDR
> data it finds in its database and now worry about how it got there.
yeah, not really the problem of ogo.

> 
> > However, I take a look at all that stuff I implemented already, and will 
> > propose a list of high level methods for the wrapper class for further 
> > discussion. Or should such a stuff be implemented as a @protocol ?
> 
> Seems like it to me.  But that is an implementation detail, either way
> will work.
> 
> > Just the problem I have with the Asterisk Management API is, that the 
things 
> > I've implemented up to now follow the same output scheme, easy to parse.
> > There are plenty of more possibilities, but the other commands and their 
> > output follow the output from the Asterisk command line interface. So 
for
> > every additional command an own parser has to be written, therefore I 
got a 
> > bit stuck with the AsteriskUI at that point. In my eyes it would be 
cleaner
> > to tune the Asterisk to make the missing commands follow the AGI output 
> > scheme too, but I never took a closer look at that route. However, sth. 
> > needs to be done there.
> 
> Not familiar enough with Asterisk to really comment on any of that.  As
> long as the UI uses commands or an API/protocol to interact with the
> underlying device the details all will be well.
yeah, nothing to worry about here. These are some asterisk internal details, 
whoever implements the protocol for the asterisk, that person has to care.


Sebastian