Ideen für CTI-Tool unter Linux vorhanden - Programmierer gesucht

Bin auf jeden fall noch dabei, aber die nächsten 2 Wochen aber noch zeitlich ziemlich knapp dran.

Ich melde mich. Wie ich aber weiter oben schonmal angedeutet habe: Ideal wäre 'ne Middleware, mit der man auch andere Anlagen integrieren kann, sonst bleibt das 'ne Insel-Lösung.

Mario
 
Da bleibt dir auf der "Server-Seite" nur CSTA oder TAPI(TSP-Client). Dann könnte man einen allgemeinen CTI-Client/Server bauen der mit anderen Anlagen funktionieren kann. Zudem würde ich nicht auf einfache TCP-Verbindungen setzen, sonder lieber XMPP nehmen. Hätte den Vorteil das man gleich IM, Presence, Filetransfer usw. hätte. Stichwort: Unified Communications :). Einen einfachen XMPP-Server könnte ich beisteuern. Da wäre nur noch die Frage der Lizenz, am liebsten hätte ich eine Art LGPL.
 
mit jtapi wäre das ja denkbar.
wobei meine ziele weit niedriger als eure angesetzt sind.
ich will einfach etwas wie meine agfeo suite für asterisk. und fop gleich direkt integriert.
schaun wir mal wie sich das ganze entwickelt.
 
Ich stimme heldenhaft zu. Für Linux wird's Zeit ein TAPI pendant zu bekommen.
Wünschte, ich könnte da jetzt schon weiter machen. Das Thema reizt mich schon lange.

Mario
 
Hab' mir das mal angeschaut - jtapi wäre in etwa, was man bräuchte, zumindest so auf den ersten Blick. Will mir das mal die nächsten Tage genauer anschauen.

Gruß Mario
 
JTAP stellt aber nur die Client-Seite zur Verfügung!? Man benötigt noch irgendetwas auf der Server-Seite. Mit JTAPI kann man aus Java-Anwednungen wählen...mehr nicht.
 
Soweit ich das verstanden habe ist JTAPI eine Middleware, per Default kein PBX Link und Client Link (integriert). Das wird dann jeweils per Schnittstelle gehandelt.
Bin aber noch nicht dazugekommen, mir das näher anzuschauen....

Gruß Mario
 
Nach nochmaligem anschauen der Beschreibung von JTAPI komme ich zum Schluss, dass Heldenhaft doch recht hat.
JTAPI ist als TAPI für Java Anwendungen gedacht. Hatte die Grafik beim Server-Teil falsch interpretiert. Ist der aktuelle Stand also: es wird doch wieder eine Middleware programmiert werden.
Ist nicht unlösbar, aber auch nicht mal so eben gemacht... Leider.

Mario
 
Habe mir jetzt mal kurz das Thema XMPP Server angeschaut.
Das kommt dem prinzipiell schon näher, was ich mir vorstelle. Der Vorteil ist, es ist ein offener Standard, auf dem man wieder bis hin zum TAPI TSP arbeiten könnte.
Leider habe ich bisher noch keine tieferen Erfahrungen mit XML (speziell das Programmieren von XML-Anwendungen). Wobei ich XML aber für dieses Thema schon einsetzen würde.

Ein XMPP Server erschiesst mich hierbei praktisch, da ich mich zuerst mit diesem Thema beschäftigen muss, bevor ich überhaupt nur an meine CSTA Geschichte denken brauche.

@Heldenhaft: wie war das Angebot mit dem XMPP Server doch gleich? :)

Meinem Verständnis nach brauchts nun einen XMPP-Gateway zur PBX und den passenden Client.

Bin mir momentan nicht 100% sicher, ob das der beste Weg ist. Der einfachste jedenfalls nicht.

Mario
 
Ok...mein Plan:
Für Asterisk müssen wir einen Manager-Event->CSTA Adapter schreiben. Dieser Übersetzt also Asterisk-Manager-Events auf CSTA Nachrichten. CSTA selber wiederum besteht aus XML-Messages (SOAP-Nachrichten) die wir im Funktionsumfang anhand der Profile definieren müssen. CSTA beschreibt aber kein Transportweg. Wie kommen die Nachrichten zum Client? Hierfür wollte ich XMPP einsetzten, da XMPP schon jetzt im Protokoll-Standard vorgesehen hat SOAP(XML-Nachrichten) zu kapseln, also einfach mit transportiert werden können.
Ein weitere Vorteil sehe ich in der generellen Infrastruktur. Authentifizierung, Routing, Message-Protokoll und vieles mehr ist einfach schon vorhanden bzw. definiert. Für den Client gibt es gute Libraries (z.B. Smack?)die wir nutzen könnten.
Für die Client-Visualisierung schwebt mir entweder Eclipse(Equinox) oder wenn es Hip sein soll JavaFX vor.

Für klassische Anlagen müssten man eine TAPI(TSP)/CSTA/XMPP Bridge bauen.

Bis dann,
Heldenhaft

PS: Arbeite noch an der Seite für den XMPP-Server. Poste das hier die Tage...
 
Zuletzt bearbeitet:
wenn ich das recht verstehe:
Du willst CSTA zum Client bringen? Ob das aufgrund der Komplexität des Protokolls gut ankommt erscheint mir fraglich. Sinnvoller wäre IMHO da eher sowas wie eine einfachere TAPI Schnittstelle...

Mario
 
??. CSTA (UA) ist doch gerade dafür gedacht auch von Clients verarbeitet zu werden. Sieht man z.B. bei Snom oder Microsoft. Letzerer nutzt allerdings mit dem Live-Communication-Manager SIP als Übertragungsprotokoll. Das finde ich fraglich...
 
Wie sollte das User-Management aussehen? 'Ne Authentifizierung ist da Pflicht, um eine Zuordnung der Endgeräte zu bekommen. Mir schwebt da was Modulares vor. Wahlweise integriert (kleine Installationen) oder LDAP/Kerberos (/ADS) bei großen Geschichten.

Was mir im Moment am meisten Kopfschmerzen bereitet ist, das ich was fertiges Anwendungsmäßiges brauche, um weiter testen zu können. Kontact, Evolution - es muss im Prinzip jetzt nicht gleich eines der großen sein, eine spätere einfache Integration sollte aber das Ziel sein.
Vermutlich sollte ich meine CSTA Bibliothek erst in einen nutzbaren Zustand bringen, bevor weitere Integrationen überhaupt sinnvoll sind.

Ich sehe schon, da liegt noch VIEL mehr arbeit vor uns.

Am besten fand ich bis jetzt die Idee vom Decibel Framework - ist zwar bis jetzt eine KDE-Sache, die könnte sich aber weiterentwickeln... Zumindest gibt es da schon Kcall mit Kontact Anbindung (jedenfalls, was ich so gelesen habe). Ich befürchte aber, dass das Projekt schon tot ist. Bei KDE ist im websvn nichts mehr zu finden und die Entwickler haben nicht auf meine Anfragen reagiert.

Mario
 
Hi,
meinen XMPP-Server habe ich mit Dependency Injection (Spring) aufgebaut. Ich hab eine XML-basierte Benutzerverwaltung integriert (Umgeschrieben). Durch die DI kann man natürlich das ganze neu "verdrahten" und z.B. LDAP nutzen.
Die Zuordnung zwischen den Lines und den Benutzern muss man natürlich noch programmieren.

Xphone bietet in der neuesten Variante eine XML-CSTA Implementierung. Es gibt auch eine Demo-Lizenz-Key mit dem wir deine CSTA-Implementierung testen könnten.

Welcher der beste Weg wäre für eine Linux-Telefonie Unterstützung kann ich im Moment auch nicht beantworten. Gibt es in dem Bereich überhaupt keine Standards?

Gruß,
Heldenhaft

PS: Wo kommst du her? Vielleicht kann man sich mal zusammen setzen?
 
Hi,
meinen XMPP-Server habe ich mit Dependency Injection (Spring) aufgebaut. Ich hab eine XML-basierte Benutzerverwaltung integriert (Umgeschrieben). Durch die DI kann man natürlich das ganze neu "verdrahten" und z.B. LDAP nutzen.
Die Zuordnung zwischen den Lines und den Benutzern muss man natürlich noch programmieren.
klingt nett, muss ich mir mal anschauen

Xphone bietet in der neuesten Variante eine XML-CSTA Implementierung. Es gibt auch eine Demo-Lizenz-Key mit dem wir deine CSTA-Implementierung testen könnten.
ich habe hier momentan noch ein großes Problem.
Da ich Phase II CSTA auswerten muss, müsste ich alles nach XML konvertieren. Bevor ich das machen kann muss ich aber erstmal die wichtigsten Sachen aus ASN.1 dekodieren (bzw den Code dafür schreiben).
Das geht leider alleine nicht so schnell.

Ich denke, bevor ich soweit bin, mich mit meiner CSTA Schnittstelle dran zu hängen, hast du schon eine Middleware am laufen :) .

Ich werde mir hier jetzt doch erstmal eine Mini-Middleware zum Testen schreiben (AMI ähnlich), wo ich nicht noch XML handeln muss. Mir fehlt da einfach der Anfang...

Welcher der beste Weg wäre für eine Linux-Telefonie Unterstützung kann ich im Moment auch nicht beantworten. Gibt es in dem Bereich überhaupt keine Standards?
ich denke decibel war ein Anfang - ansonsten: NEIN. Leider.
Das ist sicher auch der Grund, warum es da von den großen Herstellern nichts für Linux gibt.
Bei Alcatel laufen die CTI Server unter Linux, es gibt nur keinen Client für Linux. Das nervt...

PS: Wo kommst du her? Vielleicht kann man sich mal zusammen setzen?
Gotha, Thüringen

Gruß Mario
 
Da kommen mir gerade diese Projekte in den Sinn: [...]

[Edit foschi: bitte Fullquotes unterlassen. Danke!]

Falls du dich auf die Frage nach Standards beziehst. Die Projekte integrieren die AMI Schnittstelle - hier wird aber kein CTI Standard definiert.
Aber Danke für die Links, hudlite kannte ich noch nicht, das schaut mal interessant aus.

Mario
 
@Heldenhaft:
ich habe mir zwischenzeitlich mal XMPP genauer angeschaut und habe beschlossen, auch diesen Weg zu gehen. Meine CSTA implementierung ist nun soweit, dass ich für die weitere Entwicklung dringend eine Middleware benötige. DBus direkt und Decibel sind einfach zu kompliziert, um das relativ schnell aufzusetzen (zumindest wenn man keine vernünftige, fertige Java-Klasse hat).
Ein kleines Testprogramm mit XMPP war dagegen mit wenigen Zeilen schnell aufgesetzt und für andere Sprachen(/Betriebssysteme) gibts auch mehr als ausreichend Bibliotheken.

Gibts da bei dir was neues?

Gruß Mario
 
@Heldenhaft:

Gibts da bei dir was neues?

Gruß Mario

Hi,
leider habe ich noch ein paar andere Punkte auf meiner Liste. XMPP ist allerdings fähig Soap-Nachrichten in den ganz normalen XML-Strom transparent weiter zu reichen. Wenn du also CSTA über XMPP verschicken möchtest ist das kein Problem. Microsoft arbeitet in den Clients (IMHO) auch mit CSTA. War deine CSTA-Implementierung Close-Source?

Gruß,
Heldenhaft
 
Nein, ich will es offen machen.
Aber wie gesagt: CSTA ist kompliziert genug, ich will da jetzt nicht noch eine Umsetzung von Phase 2 (binär) auf Phase 3 (XML) machen. Ich hatte das eher einfacher Gedacht, sonst müsste ich ja im Prinzip zusätzlich zum Client noch eine PBX simulieren.
Ähnlich AMI Protokoll. Hätte noch den Vorteil, das man vorhandene Asterisk-Clients mit geringem Aufwand integrieren könnte.
Vom Prinzip ist da ja sogar egal, welches Protokoll auf XMPP Seite genommen wird da ich Schnittstellen definieren will, mit denen man das einfach ändern könnte...

Mario
 

Statistik des Forums

Themen
246,101
Beiträge
2,246,181
Mitglieder
373,583
Neuestes Mitglied
df3ei
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.