Ein Blick in IVR Software-Entwicklung [geschlossen]
https://stackoverflow.com/questions/1457479
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianFrage
Das Unternehmen für die ich arbeite sucht eine IVR-Implementierung, die in hohem Maße kompatibel mit alle möglichen PBX / IVR oder PBX-Combo ist oder unsere eigene Hosting-Lösung zur Verfügung zu stellen.
So ist die Idee wäre, eine Anwendung zu erstellen, die auf alle mögliche Plattform-Schnittstellen und Anrufsteuerung bietet und Sprachdialog / Interaktion für den IVR.
Technologies Ich habe in so weit sieht (wir möchten Java verwenden) sind Java Telefonie-API (JTAPI) die JAIN-JCC (Java Call Control) API und andere. Der grundlegende Kern dieser API macht Sinn für mich, aber was ich kann nicht zusammen genau gesetzt ist, wie die Anwendung, die ich für die Anrufsteuerung und Spricht IVR / VXML in einer plattformunabhängigen Art und Weise an das Telefonsystem würde eine Schnittstelle schaffen würde. Wie genau bin ich den Anruf von der Telefonanlage bekommen?
Diese APIs und Bibliotheken scheinen diese Frage unbeantwortet zu lassen, die mich führt zu glauben, dass eine plattformunabhängige Lösung nicht möglich ist, und dass es immer Implementierung spezifischer sein würde. Es gibt auch Jain-SIP, wenn ich alle Anrufe dann umwandeln kann auf SIP vielleicht kann ich auf diese Weise eine generische Anrufsteuerung / IVR-Anwendung erstellen.
Wenn ich irgendwelche Unwissenheit hier geäußert haben oder Missverständnisse bitte verzeihen Sie mir, ich bin völlig neu auf jede Art von Telekommunikationstechnik - jeder, der will, dass ich gerade setzen? Ich wäre sehr sehr dankbar, die Verbindungen auf der Detailimplementierungsebene sind sehr sehr unscharf an dieser Stelle und manchmal brauche ich ein wenig Hand hält. Jede Hilfe oder drückt in der richtigen Richtung wäre hilfreich.
Ich habe seit der letzten Woche Spezifikationen und API Gießen über. :)
EDIT - ich habe vergessen zu erwähnen, dass wir das im Haus zu entwickeln, es vorziehen, wenn überhaupt möglich und intelligent in Bezug auf Kosten / Nutzen - nicht wirklich Geld auf einer integrierten Plattform zu verbringen suchen, wenn überhaupt möglich - mein Job das ist :)
Lösung
Ich arbeite für Voicegenie vor ein paar Jahren: sie gemacht (ich bin die Vergangenheit hier mit nur weil ich nicht weiß, was sie jetzt tun, nicht, weil sie nicht mehr tun es) einen VoiceXML-Motor, die:
- Ist eine Linux-Box
- Hat 3rd-Party-Speech-to-Text und Text-to-Speech-Engines verbunden (durch den Motor-spezifische APIs Schnittstelle)
- Interpretiert VoiceXML (seinen eigenen VoiceXML-Parser) und führt sie durch die 3rd-Party-Speech-to-Text-Lenk- und Text-to-Speech-Engines
Sie stellten mir ihre Box Interface Steuerungssysteme zu nennen: und das erste System, ich habe die für Cisco war (umgekehrt, ich sehe, dass Voicegenie wird jetzt von Genesys Besitz). Deren Motor auch nicht-VoiceXML-Anwendungen unterstützt, z.B. es ausgesetzt, um eine Java-Anwendung Schnittstelle.
Fazit:
- Verschiedene Telefonsysteme haben proprietäre Call-Control APIs; und / oder sie können Standard-Call-Control-Protokolle unterstützen (zum Beispiel SIP) und / oder APIs (z JTAPI, TAPI, CCXML), und wenn sie es tun, tun es mehr oder weniger gut.
- Sie können 3rd-Party-Motoren finden (zB die Genesys Voice Platform , die Microsoft Office Communications Server und andere), die Ihnen einige einheitliche API geben und Griffe und Halterungen (oder nicht) die Interop mit anderen Komponenten.
Ich bin kein Produktmanager, Systemingenieur, Netzwerk-Architekt, Domain-Experte auf diesem Gebiet.
Aber sie alle unterstützen in der Regel eine Handvoll Protokolle und APIs
Einige unterstützt nur eine proprietäre, Anzeige / oder eine gewisse Unterstützung einen oder mehrere Standards.
Die Idee ist an die API oder Protokoll als Schnittstelle, die unterstützt wird am meisten.
würde ich die Business Case für diese Frage, aber ich denke, dass Sie sollten finden und mit einem Telefonie-Ingenieure, die spezifische Fachkompetenz hat und Produkt- / Implementierung Wissen zu sprechen. Ich begegnete, was ich durch die Arbeit als Software-Entwickler oben geschrieben, aber ich habe nicht die Domain-Know-how haben.
Wäre das SIP sein?
SIP ist ein Protokoll, kein API. Dieses Material ist in Schichten, zum Beispiel als eine Anwendung, die Sie verwenden können:
-
Untere Ebene: ein SIP-Protokoll-Stack mit eigenen API; Sie verwenden diese API, verstehen, welche SIP Dialoge sehen wie und (nur) mit Systemen sprechen, die SIP verstehen
-
Higher level: ein VoiceXML / CCXML Motor (oder eine TAPI oder ein JTAPI-Motor); Sie schreiben XML (oder die TAPI und JTAPI-APIs verwenden); und der Motor (je nach Motor es ist) kann ein Einbau-SIP-Stack, die es verwendet, um Komponenten zu sprechen, die SIP verwenden, und / oder es könnte andere Protokollstapel für die Komponenten aufweisen, die andere verwenden (non-SIP) -Protokolle .
Cisco hatte nur ein (proprietär) Protokoll I, nutzen könnte, um ihr "Intelligent Contact Management" (das heißt Call-Center-System) zu sprechen. Und Genesys glaube, ich hatte ein geschlossenes, proprietäre API / Protokoll.
Wenn dies der Fall wäre dann meine Anrufsteuerung und IVR-Lösung am besten als ein SIP-Frontend zu einer JTAPI Anwendung oder eine Variante umgesetzt werden?
Ich bin verwirrt darüber, was Sie tun wollen, wo im Stapel Sie sein wollen (nicht, dass ich nützlich etwas sagen konnte, wenn ich weiß).
Ich denke, dass vielleicht sollten Sie mit Anbietern zu sprechen:., Um herauszufinden, was sie für Sie tun kann (es sei denn, Sie mit ihnen abzuschließen're versuchen, was schwierig sein würde)
Können Sie verengen, was "potenzielle PBX / IVR oder PBX-Combo" bedeutet?
Andere Tipps
Ich habe für eine Reihe von Jahren in diesem Raum gearbeitet. ChrisW Antwort ist sehr gut. Hier sind einige zusätzliche Informationen, die in ähnlichen Situationen Menschen hilfreich sein können.
Ich gehe davon aus Sie eine Premise-Lösung bieten als die meisten Ihrer Integration Sorgen gehen weg, wenn Sie Ihre Anwendung hosten. Wenn Sie Einrichtungen ändern müssen, und Sie isolieren Telefonie Logik von Ihrem Dialog und Business-Logik sollte die Übersetzung nicht allzu schwierig sein.
IVR / PBX-Integration Herausforderungen zeigen sich in einer Reihe von Möglichkeiten:
Telefonie:
Mit dem Telefonie, ich meine erste Party Call Control. Merkmale der Telefonleitung.
- Anrufankunftsinformationen (ANI / DNIS). Angenommen, Sie sind auf einem höheren Niveau arbeiten, wie VoiceXML, können Sie immer noch eine Vielzahl von Fragen. Nur etwas:
- Daten Existenz. Nicht alle Switches bieten diese Daten. Was noch schlimmer ist, ist die Daten nur mit bestimmten Switch-Konfigurationen verfügbar. Diese Konfiguration kann mit anderen Anforderungen (Transfer) der Anwendung oder dem Call Centers in Konflikt.
- Datenformat. Je nach Anwendung, dies kann oder kann nicht ein Problem sein, aber das Format der Daten, die ein bisschen von dem Schalter variieren zu wechseln.
- Unterschiedliche Übertragungsarten. Abhängig von der Architektur des umgebenden Telefonienetzes, Ihr Übertragungstyp müssen variieren. Normalerweise ist der Standardanschluß Flash-Übertragung in VoiceXML funktioniert, wenn in einem lokalen Call-Center-Agenten oder ACDs zu übertragen. Jedoch off site / off PBX / PBX-Nebenstellenanlage überträgt, muß als überwachtes (2-Schritt) Übertragung durchgeführt werden. Beachten Sie, dass der VoiceXML-Standard bezieht sich nicht auf diese Art der Übertragung. Sie gilt nur für blinden Transfer und Konferenzen, aber die meisten Plattformen bieten einen mechansim zusätzliche Transferlogik zugreifen zu können.
Computer Telephony Integration (CTI):
Mit dem CTI, ich meine erste oder dritte Partei Anrufsteuerung über eine Datenintegration mit der TK-Anlage.
- Eigenschaften Unterschiede. Mehr als die meisten sich vorstellen kann. Man kann wirklich kompliziert, wenn Sie in einem Call-Center mit einem ACD sind. ACD-Funktionen können sehr unterschiedliche Anbieter zu Anbieter sein.
- Ereignisströme / Datenformate. Auch hier können sie sehr unterschiedlich sein. Bei einigen Schaltern finden Sie eine breite Palette von Veranstaltungen. In einigen Umgebungen können Sie praktisch keine sehen.
- Anrufverfolgung. um einen Schalter für einen Daten Pop Anruf-Tracking ist nicht immer so einfach wie ein Anruf-Referenz-ID und das Festhalten von Daten in einer Datenbank bekommen es als Schlüssel. Bei mehreren Schaltern, ändern sich die ref ids als Anruf bewegt sich um das System. Sie benötigen Software zu schreiben, die Übergänge zu verfolgen und gegen eine interne Referenz-ID zu aktualisieren. Oh, und nicht alle Switches unterstützen ref ids ...
Insgesamt werden Sie nicht nur Unterschiede zwischen den Schaltern sehen, aber gleichen Schalter verschiedene Protokolle, Unterschiede aufgrund Serviceklasse / Konfiguration und sogar pro Gerät. Auf der später meine ich Ihnen ein anderes Verhalten basierend auf dem Telefon auf die Agenten Schreibtisch (relevant für CTI Daten POPs).
gesetzt sehenEs gibt keine einzige Lösung, die all dies verbirgt und einige der Unterschiede eine Allzweck-Lösung existieren kann nicht gegeben. Jedoch kann eine eingeschränkte Modell für spezifische Anwendungsfälle erstellt werden. Es ist einfach nicht sehr einfach und erfordert viel Erfahrung mit den Schaltern der Normierungsschicht zu schaffen.
So, jetzt, dass ich die größeren Bereiche des Problems skizziert habe (ja, es gibt andere :-(), einige Ratschläge:
- entkoppeln Ihre Anwendungslogik von Telefonie Logik. Angenommen, Sie mehr Plug-in-Module für Ihre Telefonie-Integration benötigen.
- Vermeiden Schalter Besonderheiten in der Nähe Ihrer Normalisierungsschicht. Sie werden sie nicht in der Lage zu vermeiden, wenn Sie auf Mittel bereitstellen Desktops als Call-Center erwarten werden Sie ihre spezifische ACD-Konfiguration nutzen oder zumindest zu ehren (wenn Ihre Anrufe correc nicht angezeigttly in ihren Berichten, riskieren Sie einen Kunden zu verlieren)
- Wählen Sie einen primären IVR-Anbieter, der eine breite Palette von Telefonie-Protokollen unterstützt und umfasst eine Vielzahl erweiterter Satz von Übertragungsfunktionen.
- Während die Standards ... schlecht sind ... sie sind alles, was Sie haben. Schreiben Sie Ihre Anwendung in VoiceXML. Seien Sie in der Lage, IVR-Anbieter zu wechseln, wenn Sie ein Geschäft auf einem Switch oder in einem Call-Center haben, dass die primären Anbieter nicht unterstützen können.
- Es gibt eine Vielzahl von CTI-Protokolle. TAPI, JTAPI, TSAPI, CSTA und so weiter. Es gibt keine einzige Antwort. Es gibt ein paar kommerzielle Normalisierung Schichten, die Ihnen konsistente API geben, aber die Funktion und Ereignisströme variieren nach wie vor pro Switch. Entweder Plan, um mehrere Schnittstellen zu schreiben oder für einen 3rd-Party-API zu bezahlen. Keine einfache Antwort hier, da die Kosten für das 3rd-Party-Produkt kann ein teueren Add-on sein, aber der Entwicklungsaufwand eine Vielzahl von Schaltern implementieren kann noch mehr sein.
- Partner mit einer begrenzten Anzahl von Switch-Anbietern oder CTI-Server (zum Beispiel Cisco ICM, Genesys T-Server). Es begrenzt Ihren Markt, sondern minimiert die Integrationskosten. Aber diese Partnerschaft können Sie Hebel Verkäufe helfen und den Zugang zu mehr Kunden.
Auch als Alternative Antwort auf meine Frage haben wir auf einem Open-Source-Projekt gestolpert, die eine Schnittstelle mit JTAPI schafft Unterstützung für mehrere Telefoniesysteme zur Verfügung zu stellen (Bohlen, TK-Anlagen und IP-Telefonie) und Plattformen. So kann ich eine Anwendung entwickeln kann, wie ich war zu erwähnen und es ist für viele verschiedenen Systeme, unabhängig von dem System arbeiten. Ich bin sicher, es gibt Ausnahmen, aber das soll mit der Mehrheit von ihnen arbeiten - man bedenkt, dass TAPI Art eines allgemein akzeptierten Standard ist sowieso:
Sein genannt 'Generic JTAPI':
