Guardando in IVR di sviluppo del software [chiusa]
https://stackoverflow.com/questions/1457479
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianDomanda
L'azienda per cui lavoro è alla ricerca di un'implementazione IVR che è altamente compatibile con qualsiasi potenziale PBX / IVR o PBX combo o per fornire la nostra soluzione di hosting.
Quindi l'idea sarebbe quella di creare un'applicazione che si interfaccia con qualsiasi piattaforma potenziale e fornire il controllo delle chiamate e la voce di dialogo / interazione per l'IVR.
Tecnologie ho guardato finora (vorremmo utilizzare Java) sono Java Telephony API (JTAPI) il (Java Call Control) API JCC-Jain e altri. La sostanza di base di queste API ha senso per me, ma quello che non posso mettere insieme è esattamente come l'applicazione Vorrei creare per il controllo delle chiamate e la voce IVR / VXML sarebbe interfacciarsi in una piattaforma modo indipendente per il sistema telefonico. Esattamente come sono io per ottenere la chiamata dal sistema telefonico?
Queste delle API e biblioteche sembrano lasciare questa domanda senza risposta, che mi porta a credere che una soluzione indipendente dalla piattaforma non è possibile e che è sempre sarà specifica implementazione. C'è anche Jain-SIP, se posso convertire tutte le chiamate per sorseggiare allora forse posso creare un generico di controllo delle chiamate / applicazioni IVR in questo modo.
Se ho pronunciato alcun ignoranze qui o incomprensioni ti prego perdonami, io sono completamente nuovo per qualsiasi tipo di tecnologia delle telecomunicazioni - chi vuole impostare me dritto? Sarei molto molto grato, i collegamenti sul livello di implementazione dettagli sono molto molto confusa, a questo punto e, a volte ho bisogno di un po 'di partecipazione mano. Qualsiasi aiuto o spinge nella giusta direzione, sarebbe utile.
Sono stato versando su specifiche e API per l'ultima settimana. :)
EDIT - Ho dimenticato di dire che noi preferiamo sviluppare questa in casa se possibile e intelligente in termini di costi / benefici - non proprio cercando di spendere soldi su una piattaforma integrata se possibile - questo è il mio lavoro :)
Soluzione
Ho lavorato per VoiceGenie a pochi anni fa: hanno fatto (sto usando il tempo passato qui solo perché non so cosa stanno facendo ora, non perché sono più a farlo) un motore di VoiceXML, che:
- è una scatola di Linux
- Ha 3rd-party Speech-to-text e motori text-to-speech collegato (interfacciandosi con le API specifiche del motore)
- Interpreta VoiceXML (utilizzando il proprio parser VoiceXML), e lo esegue guidando il 3rd-party Speech-to-text e motori text-to-speech
Mi hanno assunto per interfacciare la loro scatola di chiamare i sistemi di controllo: e il primo sistema ho fatto per era Cisco (al contrario, vedo che VoiceGenie sono ora di proprietà di Genesys). Loro motore supportato anche applicazioni non-VoiceXML, ad esempio esposto un'interfaccia dell'applicazione Java.
In conclusione:
- I vari sistemi telefonici hanno API di controllo delle chiamate di proprietà; e / o possono supportare protocolli standard di controllo delle chiamate (ad esempio SIP) e / o API (ad esempio JTAPI, TAPI, CCXML) e, se lo fanno, lo fanno più o meno bene.
- Si potrebbe trovare motori di terze parti (ad esempio, la Genesys Voice Platform , il Microsoft Office Communications Server , e altri) che vi darà alcune API unificata , e le maniglie e supporti (o non) l'interoperabilità con gli altri componenti.
Non sono un product manager, system engineer, architetto di rete, esperto di dominio in questo campo.
Ma tutti generalmente supportano una manciata di protocolli e API
uno o più standard Alcuni supportato solo un proprietario, AD / o di qualche supporto.
Quindi l'idea è quella di interfacciarsi alle API o protocollo supportato di più.
Mi piacerebbe in discussione il business case per questo, ma mi sa che si dovrebbe trovare e parlare con un ingegnere di telefonia, che ha esperienza di dominio specifico e conoscenza del prodotto / implementazione. Ho incontrato quello che ho postato sopra lavorando come sviluppatore di software, ma non ho l'esperienza di dominio.
Vorrei che essere SIP?
SIP è un protocollo, non un'API. Questa roba è a strati, ad esempio come un'applicazione è possibile utilizzare:
-
livello inferiore: uno stack di protocollo SIP con propria API; si utilizza questa API, capire che cosa SIP dialoghi assomigliano, e parlano (solo) con i sistemi che comprendono SIP
-
Un livello di più: un motore di VoiceXML / CCXML (o un TAPI o di un motore JTAPI); si scrive XML (o utilizzare il TAPI e JTAPI API); e il motore (a seconda di quale motore è) può essere dotato in pila SIP che utilizza per comunicare con componenti che utilizzano SIP, e / o potrebbe avere altri stack di protocollo per i componenti che utilizzano altri protocolli (non SIP) .
Cisco aveva solo un protocollo (proprietario) ho potuto utilizzare, per parlare con il loro sistema "Intelligent Contact Management" (vale a dire call center). E penso che Genesys ha avuto un chiuso, API proprietarie / protocollo.
Se è così allora sarebbe il mio controllo delle chiamate e la soluzione IVR essere meglio implementati come un front-end SIP a un'applicazione JTAPI o qualche variante?
Sono confuso su ciò che si vuole fare, dove nello stack si vuole essere (non che io potessi dire qualcosa utile se lo sapevo).
Credo che forse si dovrebbe essere parlare con i venditori:. Per scoprire cosa possono fare per voi (a meno che non si sta cercando di completare con loro, che sarebbe difficile)
Si può limitare ciò che "qualsiasi potenziale PBX / IVR o PBX combo" significa?
Altri suggerimenti
Ho lavorato in questo spazio per un certo numero di anni. La risposta di ChrisW è molto buona. Ecco alcune informazioni aggiuntive che possono essere utili alle persone in situazioni simili.
Sto assumendo che stai offrendo una soluzione premessa come la maggior parte delle vostre preoccupazioni di integrazione andare via se si sta ospitando la vostra applicazione. Se avete bisogno di cambiare strutture e voi isolato la logica di telefonia e la logica di dialogo e di business, la traduzione non dovrebbe essere troppo difficile.
IVR / PBX sfide di integrazione visualizzati in diversi modi:
Telefonia:
Per la telefonia, voglio dire prima controllo chiamata terza parte. Caratteristiche della linea telefonica.
- le informazioni di chiamata arrivo (ANI / DNIS). Supponendo che si sta lavorando a un livello più alto, come VoiceXML, è ancora possibile avere una varietà di problemi. Solo alcuni:
- l'esistenza di dati. Non tutti gli interruttori forniscono questi dati. Quel che è peggio, sono i dati possono essere disponibili con determinate configurazioni di commutazione solo. Questa configurazione può essere in conflitto con altre esigenze (trasferimenti) della vostra applicazione o il call center.
- Formato dati. A seconda dell'applicazione, questo può o non può essere un problema, ma il formato dei dati può variare un po 'da interruttore per cambiare.
- Variare tipi di trasferimento. A seconda della architettura della rete di telefonia circostante, il tipo di trasferimento può avere bisogno di variare. Solitamente, il trasferimento hook-flash predefinita disponibile in VoiceXML funzionerà durante il trasferimento di agenti o ACD in un call center locale. Tuttavia, off site / off PBX / trasferimenti PBX-PBX, devono essere eseguite come supervisionato (2 step) di trasferimento. Si noti, lo standard VoiceXML non copre questo tipo di trasferimento. Esso copre solo i trasferimenti ciechi e conferenze, ma maggior parte delle piattaforme fornire un mechansim per accedere logica di trasferimento aggiuntivo.
Computer Telephony Integration (CTI):
Per CTI, voglio dire prima o terza controllo chiamata terza parte attraverso un'integrazione dei dati con il PBX.
- Caratteristiche differenze. Più della maggior parte può immaginare. Può essere davvero complicato se ci si trova in un call center con un ACD. Caratteristiche ACD possono essere molto diverse fornitore a fornitore. formati
- flussi di eventi / dati. Ancora una volta, essi possono essere molto diversi. Su alcuni switch si otterrà una ricca serie di eventi. In alcuni ambienti, è possibile vedere praticamente nessuno.
- il monitoraggio delle chiamate. Monitoraggio di una chiamata intorno a un interruttore per un pop di dati non è sempre così facile come ottenere un ID di riferimento chiamata e attaccare i dati in un database utilizzando come chiave. In diverse interruttori, i ids ref cambiano la chiamata viene trasferita attorno al sistema. Avrai bisogno di scrivere software per monitorare le transizioni e aggiornarlo contro un ref id interna. Oh, e non tutti gli switch supportano gli ID ref ...
In sintesi, si sarà non solo vedere le differenze tra gli switch, ma lo stesso passare protocolli diversi, differenze dovute alla classe di servizio / configurazione e persino per dispositivo. Sul tardi, voglio dire che si può vedere un comportamento diverso in base al telefono impostato sulla scrivania dell'agente (rilevante per il pop dati CTI).
Non esiste un'unica soluzione che nasconde tutto questo e dato alcune delle differenze una soluzione general purpose non può esistere. Tuttavia, un modello vincolata per specifici casi d'uso può essere creato. E 'solo che non è molto facile e richiede un sacco di esperienza con switch per creare lo strato di normalizzazione.
Quindi, ora che ho delineato le aree più grandi del problema (sì, ci sono altri :-(), un consiglio:
- disaccoppiare le nostre logica dell'applicazione e la logica di telefonia. Si supponga dovrai connettore a baionetta in moduli per l'integrazione di telefonia.
- Evitare interruttore specifico caratteristiche vicino il vostro livello di normalizzazione. Non sarà in grado di evitare, se si distribuisce su agent desktop come i call center si aspettano che si leva o almeno onorare la loro configurazione specifica ACD (se le chiamate non vengono visualizzati correctly nelle loro relazioni, si rischia di perdere un cliente)
- Scegliere un fornitore di IVR primario che supporta una vasta gamma di protocolli di telefonia ed espone un ricco set esteso di funzionalità di trasferimento.
- Mentre gli standard ... sono poveri ... sono tutto quello che hai. Scrivi la tua applicazione in VoiceXML. Essere in grado di cambiare fornitori IVR se si dispone di un accordo su uno switch o in un call center che il fornitore primario non può sostenere.
- Ci sono una varietà di protocolli di CTI. TAPI, JTAPI, TSAPI, CSTA e così via. Non c'è una sola risposta. Ci sono un paio di strati di normalizzazione commerciali che ti danno un'API più consistente, ma i flussi di funzionalità e di eventi ancora variano per ogni switch. In entrambi intenzione di scrivere a più interfacce o pagare per un 3 ° API partito. Nessuna risposta facile qui come il costo per il prodotto 3a parte può essere un costoso add-on, ma lo sforzo di sviluppo per realizzare una vasta gamma di switch può essere anche di più.
- Partner con una serie limitata di fornitori di switch o server CTI (ad esempio Cisco ICM, Genesys T-Server). Limita il vostro mercato, ma minimizza i costi di integrazione. Ma, che il partenariato può aiutare le vendite di leva e ottenere l'accesso a più clienti.
anche come una risposta alternativa alla mia domanda che abbiamo imbattuti in un progetto open source che crea un'interfaccia con JTAPI per fornire il supporto per più sistemi di telefonia (tavole, PBXes e telefonia IP) e le piattaforme. In questo modo posso sviluppare un'applicazione come accennavo e farlo funzionare per molti sistemi diversi a prescindere dal sistema. Sono sicuro che ci sono delle eccezioni, ma questo dovrebbe funzionare con la maggior parte di loro - considerando che TAPI è una sorta di standard ampiamente accettato in ogni caso:
La sua chiamata 'JTAPI generico':
risparmiare un po 'di dolore e lo sviluppo del tempo con Twilio . In sostanza si occupano con la connessione PSTN / VOIP e basta dire loro che cosa fare con il riposo XML / HTTP. Hanno librerie di supporto in una varietà di lingue , tra cui Java.
