La recherche dans le développement logiciel SVI [fermé]

Question

La société pour laquelle je travaille est à la recherche d'une mise en œuvre de RVI qui est très compatible avec tout combo PBX potentiel / IVR ou PBX ou de fournir notre propre solution d'hébergement.

L'idée serait de créer une application qui interface avec une plate-forme potentielle et fournir un contrôle d'appel et de dialogue vocal / interaction pour l'IVR.

Technologies j'ai regardé jusqu'à présent (nous voudrions utiliser Java) Java Telephony API (JTAPI) Jain-JCC (Java Call Control) API et d'autres. L'essentiel de base de ces API de sens pour moi, mais ce que je ne peux pas mettre ensemble est exactement comment l'application je créerais pour le contrôle d'appel et de la voix IVR / VXML serait l'interface d'une plate-forme de manière indépendante au système téléphonique. Comment suis-je exactement pour obtenir l'appel du système téléphonique?

Ces API et les bibliothèques semblent laisser cette question sans réponse qui me porte à croire qu'une plate-forme indépendante solution n'est pas possible et que ça va toujours être spécifique de mise en œuvre. Il y a aussi si je Jain-SIP, puis convertir tous les appels vers SIP alors peut-être que je peux créer un contrôle d'appel générique / application IVR ainsi.

Si je l'ai prononcé des ignorances ici ou malentendus s'il vous plaît pardonnez-moi, je suis tout à fait nouveau pour tout type de technologie des télécommunications - tous ceux qui veulent me détromper? Je serais très reconnaissant, les connexions sur le niveau de détail de mise en œuvre sont très très floue à ce stade et parfois je besoin d'un peu tenir la main. Toute aide ou pousse dans la bonne direction serait utile.

J'ai afflué sur les spécifications et les API pour la dernière semaine. :)

EDIT - J'ai oublié de mentionner que nous préférons développer ce dans la maison, si possible, et intelligent en termes de coûts / avantages - ne cherche pas vraiment à dépenser de l'argent sur une plate-forme intégrée si possible - des thats mon travail :)

Answer 1

J'ai travaillé pour VoiceGenie il y a quelques années: ils ont fait (j'utilise le passé ici seulement parce que je ne sais pas ce qu'ils font maintenant, non pas parce qu'ils ne font plus il) un moteur VoiceXML qui:

• est une boîte Linux
• A moteurs à synthèse vocale 3e partie vocale à texte et connecté (en interface avec les API spécifiques au moteur)
• VoiceXML Interpréter (en utilisant son propre analyseur VoiceXML) et l'exécute en conduisant les moteurs à synthèse vocale 3e partie Speech-to-text et

Ils m'a engagé pour interfacer leur boîte pour appeler les systèmes de contrôle: et le premier système, je l'ai fait pour Cisco était (à l'inverse, je vois que VoiceGenie sont maintenant la propriété de Genesys). Leur moteur a également soutenu les applications non-VoiceXML, par exemple il a exposé une interface d'application Java.

En conclusion:

• Divers systèmes téléphoniques ont des API de contrôle d'appel de propriété; et / ou ils peuvent prendre en charge les protocoles de contrôle d'appel standards (par exemple SIP) et / ou API (par exemple JTAPI, TAPI, CCXML) et, si elles le font, le font plus ou moins bien.
• Vous trouverez peut-être des moteurs 3 parties (par exemple, le Genesys Voice Platform , la Microsoft office Communications Server, et d'autres) qui vous donnent une API unifiée et les poignées et les supports (ou non) l'interopérabilité avec les autres composants.

Je ne suis pas un chef de produit, ingénieur système, architecte réseau, expert de domaine dans ce domaine.

---

  

mais ils soutiennent tous en général une poignée de protocoles et API

Certains pris en charge uniquement un propriétaire, ad / ou un support une ou plusieurs normes.

  

L'idée est de l'interface à l'API ou d'un protocole qui est pris en charge le plus.

Je remets en question l'analyse de rentabilisation pour cela, mais je pense que vous devriez trouver et parler avec un ingénieur de téléphonie, qui possède une expertise de domaine spécifique et / connaissance des produits de mise en œuvre. J'ai rencontré ce que je posté ci-dessus en travaillant en tant que développeur de logiciels, mais je n'ai pas l'expertise de domaine.

  

Serait-ce SIP?

SIP est un protocole, pas une API. Ce truc est en couches, par exemple comme une application vous pouvez utiliser:

• Niveau inférieur: une pile de protocole SIP avec l'API propre; vous utilisez cette API, les boîtes de dialogue comprennent ce que SIP ressemblent et parlent (seulement) avec des systèmes qui comprennent SIP

• niveau supérieur: un moteur VoiceXML / CCXML (ou un TAPI ou un moteur JTAPI); vous écrivez XML (ou utilisez le TAPI et les API JTAPI); et le moteur (en fonction du moteur qu'il est) peut avoir une pile SIP intégré qu'il utilise pour parler à des composants qui utilisent SIP, et / ou il peut avoir d'autres piles de protocoles pour les composants qui utilisent d'autres protocoles (non-SIP) .

Protocole

Cisco avait seulement un (propriétaire) je pourrais utiliser, pour parler à leur système « Intelligent Contact Management » (à savoir le centre d'appels). Et je pense que Genesys avait une API / protocole propriétaire fermé,.

  

Si oui, alors seraient mieux mis en œuvre mon contrôle d'appel et de la solution IVR comme extrémité avant SIP à une application JTAPI ou une variante?

Je suis confus au sujet de ce que vous voulez faire, où dans la pile que vous voulez être (pas que je pourrais dire quelque chose d'utile si je ne savais).

Je pense que vous devriez peut-être parler avec les fournisseurs. Pour savoir ce qu'ils peuvent faire pour vous (sauf si vous essayez de terminer avec eux, ce qui serait difficile)

Pouvez-vous limiter ce que signifie "tout combo PBX potentiels / IVR ou PBX"?

Answer 2

Je travaille dans cet espace pour un certain nombre d'années. La réponse de ChrisW est très bonne. Voici quelques informations supplémentaires qui peuvent être utiles aux personnes dans des situations similaires.

Je suppose que vous offrez une solution de principe que la plupart de vos préoccupations d'intégration disparaissent si vous hébergez votre application. Si vous avez besoin de changer les installations, et vous isolé votre logique de téléphonie à partir de votre boîte de dialogue et la logique métier, la traduction ne devrait pas être trop difficile.

défis d'intégration IVR / PBX apparaissent dans plusieurs façons:

Téléphonie:

Par la téléphonie, je veux dire d'abord appeler contrôle du parti. Caractéristiques de la ligne téléphonique.

• Appel d'informations d'arrivée (ANI / SINC). En supposant que vous travaillez à un niveau supérieur, comme VoiceXML, vous pouvez toujours avoir une variété de questions. Juste un peu:
  • existence de données. Tous les commutateurs fournissent ces données. Pire encore, ce sont les données ne peuvent être disponibles avec certaines configurations de commutation. Cette configuration peut être en conflit avec d'autres besoins (transferts) de votre application ou le centre d'appels.
  • Format de données. En fonction de votre application, cela peut ou peut ne pas être un problème, mais le format des données peut varier un peu du commutateur pour passer.
• types de transfert Varier. En fonction de l'architecture du réseau de téléphonie environnant, le type de transfert peut devoir varier. Habituellement, le transfert crochet flash par défaut disponible dans VoiceXML fonctionnera lors du transfert à des agents ou DAA dans un centre d'appel local. Cependant, hors site / off PBX / transferts PBX-PBX, doivent être effectués comme supervisé (étape 2) transfert. Remarque, la norme VoiceXML ne couvre pas ce type de transfert. Elle ne couvre que les transferts aveugles et des conférences, mais la plupart des plates-formes offrent une mechansim pour accéder à la logique de transfert supplémentaire.

couplage téléphonie-informatique (CTI):

Par CTI, je veux dire d'abord ou le contrôle d'appel tiers par une intégration de données avec le PBX.

• Caractéristiques des différences. Plus que la plupart peuvent imaginer. Il peut être vraiment compliqué si vous êtes dans un centre d'appels avec un ACD. Caractéristiques ACD peut être fournisseur très différent fournisseur.
• flux d'événements / formats de données. Encore une fois, ils peuvent être très différents. Sur certains commutateurs, vous aurez un ensemble riche d'événements. Dans certains environnements, vous pouvez voir pratiquement aucun.
• Suivi des appels. Le suivi d'un appel autour d'un commutateur pour une pop données ne sont pas toujours aussi facile que d'obtenir un identifiant de référence d'appel et coller les données dans une base de données en utilisant comme une clé. Sur plusieurs commutateurs, l'arbitre change ids que l'appel se déplace autour du système. Vous aurez besoin d'écrire des logiciels pour suivre les transitions et mettre à jour contre un identifiant interne réf. Oh, et tous les commutateurs prennent en charge ids ref ...

En résumé, vous verrez non seulement les différences entre les commutateurs, mais même passer différents protocoles, les différences dues à la classe de service / configuration et même par appareil. Au plus tard, je veux dire que vous pouvez voir le comportement différent en fonction du téléphone situé sur le bureau de l'agent (pertinent pour pops de données CTI).

Il n'y a pas de solution unique qui cache tout cela et donné quelques-unes des différences d'une solution à usage général ne peut pas exister. Cependant, un modèle contraint pour des cas d'utilisation spécifiques peuvent être créés. Il est tout simplement pas très facile et nécessite beaucoup d'expérience avec des commutateurs pour créer la couche de normalisation.

Alors maintenant que je l'ai souligné les zones plus larges du problème (oui, il y en a d'autres :-(), quelques conseils:

• Dissocier votre logique d'application de votre logique de téléphonie. Supposons que vous aurez besoin dans les modules prise multiple pour votre intégration de la téléphonie.
• Évitez les caractéristiques spécifiques de commutation à proximité de votre couche de normalisation. Vous ne serez pas en mesure de les éviter si vous déployez sur l'agent des postes de travail en tant que centres d'appels vous attendent tirerons parti ou tout au moins honorer leur configuration spécifique ACD (si vos appels ne se présentent pas correcTLY dans leurs rapports, vous risquez de perdre un client)
• Choisissez un fournisseur de RVI primaire qui prend en charge une large gamme de protocoles de téléphonie et expose une riche ensemble étendu de fonctions de transfert.
• Alors que les normes ... sont pauvres ... ils sont tout ce que vous avez. Écrivez votre application dans VoiceXML. Être en mesure de changer de fournisseur IVR si vous avez un accord sur un commutateur ou dans un centre d'appels que le fournisseur principal ne peut pas supporter.
• Il existe une variété de protocoles CTI. TAPI, JTAPI, TSAPI, CSTA et ainsi de suite. Il n'y a pas une seule réponse. Il y a deux ou trois couches de normalisation commerciale qui vous donnent une API plus cohérente, mais les flux de fonctionnalités et d'événements varient toujours par commutateur. Soit un plan sur l'écriture à plusieurs interfaces ou de payer pour une API 3ème partie. Pas de réponse facile ici que le coût du produit 3ème partie peut être un add-on, mais l'effort de développement coûteux à mettre en œuvre une large gamme de commutateurs peut être encore plus.
• Partner avec un ensemble limité de fournisseurs de commutateurs ou des serveurs CTI (par exemple Cisco ICM, Genesys T-Server). Elle limite votre marché, mais minimise les coûts d'intégration. Mais, ce partenariat peut vous aider à la vente de levier et avoir accès à plus de clients.

Answer 3

En outre comme une réponse alternative à ma question que nous avons trébuché sur un projet open source qui crée une interface à l'aide JTAPI pour fournir un soutien pour les systèmes de téléphonie multiples (cartes, PBXes et téléphonie IP) et les plates-formes. De cette façon, je peux développer une application comme je le mentionnais et le faire fonctionner pour de nombreux systèmes différents indépendamment du système. Je suis sûr qu'il ya des exceptions, mais cela est censé travailler avec la majorité d'entre eux - étant donné que TAPI est en quelque sorte une norme largement acceptée de toute façon:

Son appelé 'JTAPI générique':

http://gjtapi.sourceforge.net/

Answer 4

Epargnez-vous un peu de temps de la douleur et le développement avec Twilio . Essentiellement, ils traitent avec la connexion PSTN / VoIP et que vous venez de leur dire ce qu'il faut faire avec REST XML / HTTP. Ils ont bibliothèques d'aide dans une variété de langues , y compris Java.

Answer 5

Il est beaucoup plus facile à utiliser Web / API RESTful pour développer un serveur vocal. Il y a quelques fournisseurs de ces API.

Twilio est la solution la plus populaire autour aux États-Unis, et récemment le soutien également au Royaume-Uni.

Hoiio est bon pour les pays d'Asie, comme Hong Kong et Singapour.