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

[Adam Tauno Williams]

--=-hqZPLC7VhnfKFomImAeJ
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

> > <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 sufficien=
t,=20
> so no need to change there sth. besides adding new Dialer bundles.

I agree, but the bundle only provides the functionality for the dialer.

> I started the whole thing quite some time ago, my objective-c/webobjects=20
> skills where at a low level at the beginning. So there is very likely cod=
e
> in the actual AsteriskUI that will hurt your eyes.=20

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,=20
> with some write permissions for me there, and anybody else who wants to w=
ork=20
> on the PBXUI.

Agree.

> I think integrating the whole CDR stuff into the PBXUI first, keeping it =
as=20
> a separate bundle, makes sense.
> Does the Nortel PBX also record these details to a database?=20

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.

> However, I take a look at all that stuff I implemented already, and will=20
> propose a list of high level methods for the wrapper class for further=20
> 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 thi=
ngs=20
> 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=20
> 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=20
> bit stuck with the AsteriskUI at that point. In my eyes it would be clean=
er
> to tune the Asterisk to make the missing commands follow the AGI output=20
> scheme too, but I never took a closer look at that route. However, sth.=20
> 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.

> > My ultimate dream would be to see a IMAP<->DAV gateway [1] in ZideStore
> > and a UnifiedMessage<->DAV gateway so apps could use a "real" Unified
> > Message store to at least see a user's messages.  The latter should be
> > relatively easy if there is a Unified Messaging bundle/interface.  But =
I
> > suppose that may be a ways off [ first I have to get some *@&$*&^@$@$
> > content to appear in a ^@&^@#*&@# ZideStore folder ].
> > <aside>The current model of something-plugs-into-MUA-x is both flaky an=
d
> > limiting,  something on the sever would way more useful.  I don't reall=
y
> > want to built support for the Unified Messaging architecture into
> > multiple places - Consonance, our intranet, our business system, etc...=
.
> > and this seems like groupware-ish functionality to me.</aside>
> for sure.

--=-hqZPLC7VhnfKFomImAeJ
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)

iD8DBQBHZoF0LRePpNle04MRAjwZAJ488OZp/iixM1KJR7OcGa+a+ozMUgCfUkLY
IXbglNXmHj25udGX0e2VkFc=
=MCSZ
-----END PGP SIGNATURE-----

--=-hqZPLC7VhnfKFomImAeJ--