Olhando para o desenvolvimento de software IVR [fechado]
https://stackoverflow.com/questions/1457479
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPergunta
A empresa que eu trabalho para está à procura de uma implementação de IVR que é altamente compatível com qualquer PBX potencial IVR ou PBX combo / ou para fornecer nossa própria solução de hospedagem.
Assim, a idéia seria a criação de um aplicativo que interfaces para qualquer plataforma potencial e fornecer controle de chamadas e de diálogo voz / interação para o IVR.
Technologies eu olhei até agora (gostaríamos de usar Java) são Java Telephony API (JTAPI) o JAIN JCC API (Java Call Control) e outros. A essência básica destes da API faz sentido para mim, mas o que eu não posso colocar juntos é exatamente como o aplicativo eu iria criar para controle de chamadas e de voz IVR / VXML iria interagir de uma forma independente de plataforma para o sistema de telefone. Como exatamente sou eu para obter a chamada do sistema de telefone?
Essas API e bibliotecas parecem deixar esta pergunta sem resposta que me leva a crer que uma solução independente de plataforma não é possível e que ele está sempre vai ser implementação específica. Há também JAIN-SIP, se posso converter todas as chamadas para SIP, em seguida, talvez eu possa criar um aplicativo de controle de chamadas genérica / IVR desta forma.
Se eu tenho dado a conhecer qualquer ignorâncias aqui ou mal-entendidos por favor me perdoe, eu sou completamente novo para qualquer tipo de tecnologia de telecomunicações - quem quer me definir reta? Eu ficaria muito, muito grato, as conexões no nível de implementação detalhes são muito, muito confusa neste momento e às vezes eu preciso de um pouco de exploração de mão. Qualquer ajuda ou empurra na direção certa seria útil.
Eu tenho derramando sobre especificações e API de para a última semana. :)
EDIT - Esqueci de mencionar que nós preferimos a desenvolver esta em casa se possível e inteligente em termos de custo / benefício - não realmente olhando para gastar dinheiro em uma plataforma integrada, se possível - isso é o meu trabalho :)
Solução
Eu trabalhei para VoiceGenie há alguns anos: eles fizeram (estou usando o verbo no passado aqui só porque eu não sei o que eles estão fazendo agora, não porque eles não fazê-lo) um motor VoiceXML, que:
- É uma caixa de Linux
- Tem 3-parte Speech-to-text e motores de text-to-speech conectados (por interface com as APIs específicas-Engine)
- Interpreta VoiceXML (usando seu próprio analisador VoiceXML), e executa-lo por dirigir o 3-parte Speech-to-text e motores de text-to-speech
Eles me contrataram para fazer a interface seu caixa para sistemas de controle de chamada: eo primeiro sistema Eu fiz isso para era da Cisco (por outro lado, vejo que VoiceGenie são agora propriedade da Genesys). Seu motor também suportada aplicações não-VoiceXML, v.g. expôs uma interface de aplicativo Java.
Em conclusão:
- Vários sistemas de telefone têm APIs de controle de chamadas de propriedade; e / ou podem suportar protocolos de controle de chamadas padrão (por exemplo SIP) e / ou APIs (por exemplo JTAPI, TAPI, CCXML) e, se o fizerem, fazê-lo mais ou menos bem.
- Você pode achar motores de 3-parte (por exemplo, o Genesys Voice Platform , o Microsoft Office Communications Server , e outros) que lhe dão alguma API unificada e alças e suportes (ou não) a interoperabilidade com outros componentes.
Eu não sou um gerente de produto, engenheiro de sistemas, arquiteto de rede, especialista de domínio neste campo.
mas todos eles geralmente suportam um punhado de protocolos e da API
Alguns suportado apenas um proprietário, ad / ou alguma um apoio ou mais padrões.
Assim, a idéia é fazer a interface com a API ou protocolo que é suportado mais.
Eu questionar o business case para isso, mas eu acho que você deve encontrar e falar com um engenheiro de telefonia, que tem experiência de domínio específico e produto / conhecimento implementação. Eu encontrei o que eu postei acima, trabalhando como um desenvolvedor de software, mas eu não tenho a experiência de domínio.
Isso seria SIP?
SIP é um protocolo, não uma API. Este material é em camadas, por exemplo como um aplicativo que você pode usar:
-
Nível inferior: uma pilha de protocolos SIP com o próprio API; você usar essa API, entender o que SIP diálogos parecem, e falar (apenas) com sistemas que entender SIP
-
Nível superior: um motor de VoiceXML / CCXML (ou um TAPI ou um motor JTAPI); você escreve XML (ou use o TAPI e JTAPI APIs); e o motor (dependendo de qual o motor é) pode ter um embutido SIP pilha que ele usa para falar com componentes que utilizam o SIP, e / ou pode ter outras pilhas de protocolos para os componentes que utilizam outros protocolos (não-SIP) .
Cisco só tinha um protocolo (proprietário) eu poderia usar, para falar com o seu sistema de "Intelligent Contact Management" (ou seja, call center). E Genesys Eu acho que tinha um, API proprietária / protocolo fechado.
Se sim, então seria o meu controle de chamadas e solução IVR ser melhor implementada como uma final SIP frente a uma aplicação JTAPI ou alguma variante?
Estou confuso sobre o que você quer fazer, onde na pilha você quer ser (não que eu pudesse dizer qualquer coisa útil se eu sabia).
Eu acho que talvez você deveria estar falando com fornecedores: para descobrir o que eles podem fazer por você (a menos que você está tentando concluir com eles, o que seria difícil)
.Você pode diminuir o que "qualquer PBX potencial / IVR ou PBX de combinação" significa?
Outras dicas
Eu tenho trabalhado neste espaço para um número de anos. A resposta de ChrisW é muito bom. Aqui estão algumas informações adicionais que podem ser úteis para as pessoas em situações semelhantes.
Eu estou supondo que você está oferecendo uma solução premissa como a maioria das suas preocupações de integração ir embora se você está hospedando a sua aplicação. Se você precisa de instalações de mudança, e você isolado a sua lógica de telefonia da sua lógica de diálogo e de negócios, a tradução não deve ser muito difícil.
desafios de integração IVR / PBX aparecer em um número de maneiras:
Telefonia:
Por telefonia, quero dizer controle primeira chamada festa. Características da linha de telefone.
- informações de chegada de chamada (ANI / DNIS). Assumindo que você está trabalhando em um nível mais alto, como VoiceXML, você ainda pode ter uma variedade de questões. Apenas algum:
-
existência
- Data. Nem todos os interruptores de fornecer esses dados. O que é pior, são os dados só podem estar disponíveis em determinadas configurações de switch. Essa configuração pode estar em conflito com outras necessidades (transferências) de sua aplicação ou call center. formato
- Data. Dependendo da sua aplicação, este pode ou não ser um problema, mas o formato dos dados pode variar um pouco de switch para switch.
tipos de transferência - variadas. Dependendo da arquitetura da rede de telefonia circundante, o seu tipo de transferência pode precisar variar. Normalmente, a transferência gancho-flash padrão disponível em VoiceXML vai funcionar quando transferir a agentes ou ACDs em um call center local. No entanto, fora do local / off transferências PBX / PABX-PBX, necessidade de ser realizada como uma transferência supervisionada (2 etapa). Note, o padrão VoiceXML não cobre este tipo de transferência. Ele só abrange as transferências e conferências cegos, mas a maioria das plataformas de fornecer uma mechansim de acesso lógica para transferência adicional.
Computer Telephony Integration (CTI):
Por CTI, quero dizer primeiro ou terceiro controle de chamada do partido através de uma integração de dados com o PBX.
- Características diferenças. Mais do que a maioria pode imaginar. Ele pode ser realmente complicado se você estiver em um call center com uma ACD. características ACD pode ser muito diferente fornecedor para fornecedor.
- fluxos de eventos formatos / dados. Novamente, eles podem ser muito diferentes. Em alguns switches você terá um rico conjunto de eventos. Em alguns ambientes, você pode ver nenhum virtualmente.
- Chamada de rastreamento. Rastreamento de uma chamada em torno de um interruptor para um pop de dados nem sempre é tão fácil como obter uma ID de referência de chamada e aderindo dados em um banco de dados usando-o como uma chave. Em vários switches, os ids ref mudar à medida que as chamadas se move em torno do sistema. Você vai precisar de software de gravação para acompanhar as transições e atualizá-lo contra um ref id interno. Oh, e não todos os switches suportam ref ids ...
Em resumo, você não só vai ver as diferenças entre switches, mas mesmo switch diferentes protocolos, as diferenças devido à classe de serviço / configuração e até mesmo por dispositivo. Na tarde, eu quero dizer que você pode ver um comportamento diferente com base no conjunto de telefone na mesa do agente (relevante para pops dados CTI).
Não há uma solução única que esconde tudo isso e dado algumas das diferenças uma solução de propósito geral não pode existir. No entanto, um modelo restrito para casos de uso específicos podem ser criados. Ele só não é muito fácil e exige muita experiência com switches para criar a camada de normalização.
Portanto, agora que eu esbocei as maiores áreas do problema (sim, há outros :-(), um conselho:
- Dissociar a lógica do aplicativo de sua lógica de telefonia. Suponha que você vai precisar de vários plug em módulos para sua integração de telefonia.
- apresenta interruptor Evite específica perto de sua camada de normalização. Você não será capaz de evitá-los se você estiver implantando em desktops agente como call centers esperam que você irá alavancar ou pelo menos honra sua específica configuração ACD (se as suas chamadas não aparecem correcqüentemente, nos seus relatórios, o risco de perder um cliente)
- Escolha um fornecedor IVR primária que suporta uma ampla gama de protocolos de telefonia e expõe um rico conjunto alargado de recursos de transferência.
- Enquanto os padrões ... são pobres ... eles são tudo que você tem. Escrever sua aplicação em VoiceXML. Estar em uma posição para fornecedores mudança IVR se você tem um negócio em um switch ou em um call center que o fornecedor primário não pode suportar.
- Há uma variedade de protocolos CTI. TAPI, JTAPI, TSAPI, CSTA e assim por diante. Não há uma resposta única. Há um par de camadas de normalização comerciais que lhe dão uma API mais consistente, mas os fluxos de recursos e eventos ainda variam por switch. De qualquer plano em escrever para várias interfaces ou pagar por uma parte 3 API. Nenhuma resposta fácil aqui como o custo para o produto 3o partido pode ser um caro add-on, mas o esforço de desenvolvimento a implementar uma ampla gama de switches pode ser ainda mais.
- Parceria com um conjunto limitado de fornecedores de switches ou servidores CTI (por exemplo Cisco ICM, Genesys T-Server). Ela limita o seu mercado, mas minimiza os custos de integração. Mas, que a parceria pode ajudar a alavancar as vendas e obter acesso a mais clientes.
Além disso, como uma resposta alternativa à minha pergunta que você tropeçou em um projeto open source que cria uma interface usando JTAPI para fornecer suporte para vários sistemas de telefonia (placas, PBXes e telefonia IP) e plataformas. Dessa forma eu posso desenvolver uma aplicação que eu estava mencionando e tê-lo trabalhar para muitos sistemas diferentes, independentemente do sistema. Estou certo de que há exceções, mas isto é suposto para trabalhar com a maioria deles - considerando que TAPI é uma espécie de qualquer maneira padrão amplamente aceito:
Seu chamado 'Generic JTAPI':
Salvar-se algum tempo a dor e desenvolvimento com Twilio . Basicamente eles lidam com a conexão PSTN / VOIP e você apenas dizer-lhes o que fazer com XML / HTTP REST. Eles têm ajudante bibliotecas em uma variedade de línguas , incluindo Java.
