Buscando en el software de desarrollo IVR [cerrar]
https://stackoverflow.com/questions/1457479
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
La empresa donde trabajo está buscando una aplicación IVR que es altamente compatible con cualquier potencial PBX / IVR o PBX combinado o para proporcionar nuestra propia solución de alojamiento.
Así que la idea sería crear una aplicación que se conecta a cualquier plataforma potencial y proporcionar control de llamadas de voz y de diálogo / interacción para el IVR.
Tecnologías que he visto hasta ahora (nos gustaría utilizar Java) son de Java API de telefonía (JTAPI) la API JAIN-CCM (Control de llamadas de Java) y otros. La esencia básica de estas API tiene sentido para mí, pero lo que no puedo poner juntos es exactamente cómo la aplicación me gustaría crear para el control de llamadas y de voz IVR / VXML podría interactuar de una manera independiente de la plataforma para el sistema telefónico. ¿Cómo funciona exactamente soy yo para recibir la llamada del sistema telefónico?
Estas bibliotecas de API y parecen dejar esta pregunta sin respuesta que me lleva a creer que una solución independiente de la plataforma no es posible y que siempre va a ser de aplicación específica. También ha Jain en SIP, si puedo convertir todas las llamadas SIP a continuación, tal vez pueda crear una aplicación genérica de control de llamadas / IVR de esta manera.
Si he pronuncié ningún ignorancias aquí o malentendidos por favor, perdóname, soy completamente nuevo en cualquier tipo de tecnología de telecomunicaciones - cualquier persona que quiera me puso recta? Estaría muy agradecido, las conexiones en el nivel de aplicación detalle son muy, muy difusa en este punto y, a veces necesitan un poco de explotación de la mano. Cualquier ayuda o empuja en la dirección correcta sería de gran ayuda.
He estado vertiendo sobre especificaciones y API para la última semana. :)
EDITAR - se me ha olvidado mencionar que preferimos desarrollar esto en casa si es posible e inteligente en términos de costo / beneficio - sin mirar a gastar dinero en una plataforma integrada, si es posible - esa es mi trabajo :)
Solución
VoiceGenie hace unos años: hicieron (estoy usando el tiempo pasado aquí sólo porque no sé lo que están haciendo ahora, no porque están ya no lo hace) un motor VoiceXML, que:
- ¿Es una máquina Linux
- Tiene 3 ª parte de voz a texto y motores de texto a voz conectado (mediante la interacción con la API específico del motor)
- Interpreta VoiceXML (utilizando su propio analizador VoiceXML), y lo ejecuta por la conducción de la 3 ª parte de voz a texto y motores de texto a voz
Me contrataron para interconectar su caja para llamar a los sistemas de control, y el primer sistema que lo hice fue para Cisco (por el contrario, veo que VoiceGenie son ahora propiedad de Genesys). Su motor también apoyó aplicaciones no VoiceXML, por ejemplo que expone una interfaz de aplicaciones Java.
En conclusión:
- Varios sistemas telefónicos tienen APIs de control de llamadas de propiedad; y / o pueden soportar protocolos estándar de control de llamada (por ejemplo, SIP) y / o API (por ejemplo JTAPI, TAPI, CCXML) y, si lo hacen, lo hacen más o menos bien.
- Usted puede encontrar los motores de 3 ª parte (por ejemplo, el Genesys Voice Platform , de Microsoft Office Communications Server , y otros) que le dan cierta API unificada y asas y soportes (o, no) la interoperabilidad con otros componentes.
No soy un gerente de producto, ingeniero de sistemas, arquitecto de la red, dominio de expertos en este campo.
Pero todos ellos generalmente apoyan un puñado de protocolos y API
una o más normas Algunos sostenida sólo un propietario, ad / o algún tipo de apoyo.
Así que la idea es hacer interfaz con el API o protocolo que admite la mayoría.
me pregunta el caso de negocio para eso, pero creo que usted debe encontrar y hablar con un ingeniero de telefonía, que tiene experiencia en el campo específico y el conocimiento del producto / aplicación. Me encontré con lo que he publicado anteriormente, trabajando como desarrollador de software, pero no tienen la experiencia en el campo.
¿Sería SIP?
SIP es un protocolo, no una API. Esta materia es en capas, por ejemplo, como una aplicación puede usar:
-
nivel inferior: una pila de protocolos SIP con el propio API; utiliza esta API, entender lo SIP diálogos parecen, y hablan (sólo) con sistemas que comprenden SIP
-
nivel superior: un motor VoiceXML / CCXML (o una TAPI o un motor JTAPI); se escribe XML (o utilizar el TAPI y JTAPI API); y el motor (dependiendo de que el motor es) puede tener incorporado un pila SIP que utiliza para hablar a los componentes que utilizan SIP, y / o podría tener otras pilas de protocolo para los componentes que utilizan otros protocolos (no-SIP) .
Cisco sólo tenía un protocolo (patentada) que podría utilizar, para hablar con su sistema "Intelligent Contact Management" (es decir, centro de llamadas). Genesys y creo que tenía un API propietario / protocolo cerrado.
Si es así, sería mi control de llamadas y solución IVR se implementan mejor como interfaz SIP a una aplicación JTAPI o alguna variante?
Estoy confundido acerca de lo que quiere hacer, en qué parte del grupo al que desea ser (no es que yo pudiera decir algo útil si lo supiera).
Creo que tal vez debería estar hablando con los vendedores:. Para averiguar lo que puede hacer por usted (a menos que estés tratando de completar con ellos, lo que sería difícil)
¿Se puede reducir lo que "cualquier PBX / IVR o PBX combo potenciales" significa?
Otros consejos
He trabajado en este espacio para un número de años. La respuesta de ChrisW es muy bueno. Aquí hay alguna información adicional que pueda ser útil para las personas en situaciones similares.
Estoy asumiendo que usted está ofreciendo una solución premisa de que la mayor parte de sus preocupaciones de integración desaparece si se está hospedando su aplicación. Si es necesario cambiar las instalaciones, y se aisló la lógica de la telefonía de su lógica de diálogo y de negocios, la traducción no debe ser demasiado difícil.
IVR / PBX retos de integración aparecen en un número de maneras:
Telefonía:
Por la telefonía, me refiero a la primera parte de control de llamadas. Características de la línea telefónica.
- información de la llegada de llamada (ANI / DNIS). Suponiendo que está trabajando en un nivel superior, como VoiceXML, todavía puede tener una variedad de temas. Solo algunos:
- existencia de datos. No todos los conmutadores proporcionan estos datos. Lo que es peor, son los datos pueden estar disponibles sólo con ciertas configuraciones del switch. Esa configuración puede estar en conflicto con otras necesidades (transferencias) de su aplicación o el centro de llamadas.
- Formato de datos. Dependiendo de la aplicación, esto puede o no ser un problema, pero el formato de los datos puede variar un poco de interruptor para cambiar.
- La variación de los tipos de transferencia. En función de la arquitectura de la red de telefonía circundante, el tipo de transferencia puede tener que variar. Por lo general, la transferencia de gancho flash predeterminado disponible en VoiceXML funcionará cuando se transfieren a los agentes o ACD en un centro de atención telefónica local. Sin embargo, fuera de las transferencias PBX-PBX sitio / off PBX /, necesitan ser realizado como una transferencia supervisada (2 pasos). Tenga en cuenta, el estándar VoiceXML no cubre este tipo de transferencia. Sólo cubre las transferencias y conferencias ciegos, pero la mayoría de las plataformas proporcionan una mechansim acceder a la lógica de transferencia adicional.
Computer Telephony Integration (CTI):
Por CTI, me refiero a la primera o tercera control de llamadas a través de una integración de datos con la central.
- Características diferencias. Más que la mayoría posiblemente puede imaginar. Puede ser muy complicado si se encuentra en un centro de llamadas con un ACD. ACD características pueden ser muy diferentes proveedor a otro. formatos
- flujos de eventos / datos. Una vez más, pueden ser muy diferentes. En algunos interruptores que obtendrá un rico conjunto de eventos. En algunos entornos, se puede ver prácticamente ninguno.
- seguimiento de llamadas. El seguimiento de una llamada en torno a un interruptor para un estallido de datos no siempre es tan fácil como conseguir una identificación de referencia de llamada y pegarse datos en una base de datos utilizando como una clave. En varios interruptores, los identificadores árbitro cambian a medida que la llamada pasa todo el sistema. Tendrá que escribir software para realizar un seguimiento de las transiciones y actualizarlo en contra de un ref id interna. Ah, y no todos los switches soportan los identificadores de ref ...
En resumen, usted no sólo ver las diferencias entre los switches, pero el mismo conmutar diferentes protocolos, diferencias debidas a la clase de servicio / configuración e incluso por dispositivo. En la tarde, es decir se puede ver un comportamiento diferente basado en el sistema de teléfono en el escritorio del agente (relevante para los estallidos de datos CTI).
No hay una solución única que oculta todo esto y teniendo en cuenta algunas de las diferencias no puede existir una solución de propósito general. Sin embargo, un modelo limitado de casos de uso específicos puede ser creado. Simplemente no es muy fácil y requiere mucha experiencia con los conmutadores para crear la capa de normalización.
Así que ahora que he descrito las áreas más grandes del problema (sí, hay otros :-(), un consejo:
- Disociar la lógica de la aplicación de la lógica de la telefonía. Suponga que necesita enchufe múltiple en módulos para su integración de telefonía.
- Evite las funciones del conmutador específico cerca de la capa de normalización. Usted no será capaz de evitarlos si va a implementar el agente de escritorios como centros de llamadas esperan que va a aprovechar o al menos honor a su configuración específica ACD (si sus llamadas no aparecen correctemente en sus informes, se arriesga a perder un cliente)
- Pick un proveedor IVR principal que soporta una amplia gama de protocolos de telefonía y expone un rico conjunto ampliado de características de transferencia.
- Si bien los estándares son pobres ... ... son todo lo que tienes. Escriba su aplicación en VoiceXML. Estar en condiciones de cambiar de proveedor de IVR si tiene una oferta en un interruptor o en un centro de llamadas que el proveedor primario no puede soportar.
- Hay una variedad de protocolos CTI. TAPI, JTAPI, TSAPI, CSTA y así sucesivamente. No hay una sola respuesta. Hay un par de capas de normalización comerciales que le dan una API más consistente, pero los flujos de características y eventos aún varían por switch. De cualquier planes de escribir a múltiples interfaces o el pago de una API de tercera parte. No hay una respuesta fácil ya que el coste para el producto tercera parte puede ser un complemento caro, pero el esfuerzo de desarrollo para implementar una amplia gama de interruptores puede ser aún más.
- Asociarse con un conjunto limitado de fabricantes de conmutadores o servidores CTI (por ejemplo Cisco ICM, Genesys T-Server). Limita su mercado, pero minimiza los costes de integración. Sin embargo, esa asociación puede ayudar a las ventas de apalancamiento y obtener acceso a más clientes.
También como una respuesta alternativa a la pregunta que nos hemos tropezado en un proyecto de código abierto que crea una interfaz usando JTAPI para proporcionar soporte para múltiples sistemas de telefonía PBX (chapas, y telefonía IP) y plataformas. De esta manera puedo desarrollar una aplicación como yo estaba mencionando para que funcionen durante muchos sistemas diferentes, independientemente del sistema. Estoy seguro de que hay excepciones, pero esto se supone que funciona con la mayoría de ellos - teniendo en cuenta que TAPI es una especie de estándar ampliamente aceptado de todos modos:
Se llama 'JTAPI genérico':
Ahórrate el dolor y el tiempo de desarrollo con Twilio . Básicamente se ocupan de la conexión PSTN / VoIP y sólo dicen lo que tienen que ver con REST XML / HTTP. Tienen en una variedad de idiomas , incluyendo Java.
