IVR ソフトウェア開発を検討中 [終了]
https://stackoverflow.com/questions/1457479
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian質問
私が働いている会社は、潜在的な PBX/IVR または PBX コンボとの互換性が高い IVR 実装、または独自のホスティング ソリューションを提供する IVR 実装を探しています。
したがって、考えられるアイデアは、あらゆる潜在的なプラットフォームに接続し、IVR に通話制御と音声ダイアログ/インタラクションを提供するアプリケーションを作成することです。
私がこれまで検討してきたテクノロジー (Java を使用したいと考えています) は、Java Telephony API (JTAPI)、JAIN-JCC (Java Call Control) API などです。これらの API の基本的な要点は理解できますが、まとめることができないのは、通話制御および音声 IVR / VXML 用に作成するアプリケーションが、プラットフォームに依存しない方法で電話システムにどのように接続されるかということです。電話システムから電話を受けるにはどうすればよいですか?
これらの API とライブラリでは、この質問は未解決のままになっているようです。そのため、プラットフォームに依存しないソリューションは不可能であり、常に実装固有のものになると私は考えています。JAIN-SIP もあります。すべての通話を SIP に変換できれば、この方法で汎用の通話制御/IVR アプリケーションを作成できるかもしれません。
ここで私が無知や誤解を述べた場合は、お許しください。私はあらゆる種類の通信テクノロジーについて全くの初心者です。私を正してほしい人はいますか?非常に感謝しています。詳細な実装レベルの接続は現時点では非常に曖昧であり、場合によっては少し手を貸す必要があります。正しい方向への助けや後押しがあれば助かります。
ここ 1 週間、仕様と API を徹底的に調べてきました。:)
編集 - できれば社内でこれを開発し、コスト/利益の観点から賢明であることを好むことを言及するのを忘れていました - 可能であれば統合プラットフォームにお金をかけたくありません - それが私の仕事です:)
解決
私はのために働いていました ボイスジーニー 数年前：彼らは、次のような VoiceXML エンジンを作成しました (ここで過去形を使っているのは、彼らが今何をしているのかわからないからであり、もうやっていないからではありません)。
- Linuxボックスです
- サードパーティの Speech-to-text および text-to-speech エンジンが接続されています (エンジン固有の API とのインターフェースにより)
- VoiceXML を (独自の VoiceXML パーサーを使用して) 解釈し、サードパーティの Speech-to-text および text-to-speech エンジンを駆動して実行します。
彼らは私を、自社のボックスと通話制御システムのインターフェースとして雇いました。そして私がそれを行った最初のシステムは Cisco のものでした (逆に、VoiceGenie は現在 Genesys によって所有されているようです)。彼らのエンジンは、VoiceXML 以外のアプリケーションもサポートしていました。Java アプリケーション インターフェイスを公開しました。
結論は：
- さまざまな電話システムには独自の通話制御 API があります。および/または標準の通話制御プロトコル (例:SIP) および/または API (例:JTAPI、TAPI、CCXML)、もしそうなら、それは多かれ少なかれうまくいきます。
- サードパーティのエンジンが見つかるかもしれません (例:の ジェネシス音声プラットフォーム, 、 Microsoft Office コミュニケーション サーバー, など）は、いくつかの統合された API を提供し、他のコンポーネントとの相互運用性を処理およびサポートします (またはサポートしません)。
私は、この分野のプロダクト マネージャー、システム エンジニア、ネットワーク アーキテクト、ドメインの専門家ではありません。
ただし、それらはすべて通常、少数のプロトコルと API をサポートしています。
独自規格のみをサポートするものもあれば、1 つ以上の標準をサポートするものもあります。
したがって、最もサポートされている API またはプロトコルに接続するという考え方です。
そのビジネスケースには疑問を持ちますが、特定の分野の専門知識と製品/実装の知識を持つテレフォニー エンジニアを見つけて相談するべきだと思います。私はソフトウェア開発者として働いていて、上記に投稿したことに遭遇しましたが、その分野の専門知識はありません。
それはSIPでしょうか？
SIP はプロトコルであり、API ではありません。これは、たとえば次のようなアプリケーションとしてレイヤー内にあります。
下位レベル:独自の API を備えた SIP プロトコル スタック。この API を使用し、SIP ダイアログがどのようなものかを理解し、SIP を理解するシステム (のみ) と通信します。
より高いレベル:VoiceXML/CCXML エンジン (または TAPI または JTAPI エンジン)。XML を作成します (または TAPI および JTAPI API を使用します)。また、エンジン (どのエンジンかによって異なります) には、SIP を使用するコンポーネントと通信するために使用する組み込みの SIP スタックが含まれる場合や、他の (非 SIP) プロトコルを使用するコンポーネント用の他のプロトコル スタックが含まれる場合があります。 。
Cisco には、「Intelligent Contact Management」と通信するために使用できる (独自の) プロトコルが 1 つしかありませんでした。コールセンター）システムです。そして、Genesys はクローズドで独自の API/プロトコルを持っていたと思います。
もしそうなら、私の通話制御および IVR ソリューションは、JTAPI アプリケーションまたはそのバリアントへの SIP フロントエンドとして実装するのが最適でしょうか?
あなたが何をしたいのか、スタックのどこにいたいのか、私は混乱しています（知っていても役立つことは何も言えません）。
おそらくベンダーと話し合うべきだと思います。彼らがあなたのために何をしてくれるのかを知るためです（あなたが彼らと一緒にやり遂げようとしているのでなければ、それは難しいでしょう）。
「潜在的な PBX/IVR または PBX の組み合わせ」の意味を絞り込めますか?
他のヒント
私はこの分野で何年も働いてきました。ChrisW の答えはとても良いです。ここでは、同様の状況にある人々に役立つ可能性のある追加情報をいくつか紹介します。
アプリケーションをホストしている場合、統合に関する懸念のほとんどは解消されるため、前提ソリューションを提供していると思います。設備を変更する必要があり、テレフォニー ロジックをダイアログやビジネス ロジックから分離している場合、翻訳はそれほど難しくないはずです。
IVR/PBX 統合の課題は、さまざまな形で現れます。
電話:
電話とは、ファーストパーティの通話制御を意味します。電話回線の特徴。
- 着信情報（ANI/DNIS）。VoiceXML などのより高いレベルで作業していると仮定しても、さまざまな問題が発生する可能性があります。ほんの一部:
- データの存在。すべてのスイッチがこのデータを提供するわけではありません。さらに悪いことに、データは特定のスイッチ構成でのみ利用できる場合があります。その構成は、アプリケーションまたはコールセンターの他のニーズ (転送) と競合する可能性があります。
- データ形式。アプリケーションによっては、これが問題になる場合もあれば問題ない場合もありますが、データの形式はスイッチごとに若干異なる場合があります。
- さまざまな転送タイプ。周囲のテレフォニー ネットワークのアーキテクチャに応じて、転送タイプを変更する必要がある場合があります。通常、VoiceXML で利用可能なデフォルトのフックフラッシュ転送は、ローカル コールセンターのエージェントまたは ACD に転送するときに機能します。ただし、オフサイト/オフ PBX/PBX-PBX 転送は、監視付き (2 ステップ) 転送として実行する必要があります。VoiceXML 標準はこのタイプの転送をカバーしていないことに注意してください。ここではブラインド転送と会議のみをカバーしていますが、ほとんどのプラットフォームには追加の転送ロジックにアクセスするためのメカニズムが用意されています。
コンピュータ テレフォニー統合 (CTI):
CTI とは、PBX とのデータ統合によるファースト パーティまたはサード パーティの通話制御を意味します。
- 機能の違い。ほとんどの人が想像できる以上のものです。ACD を備えたコールセンターにいる場合、これは非常に複雑になる可能性があります。ACD の機能はベンダーごとに大きく異なる場合があります。
- イベントストリーム/データ形式。繰り返しますが、それらは大きく異なる場合があります。一部のスイッチでは、豊富なイベント セットを入手できます。環境によっては、ほとんど何も表示されないこともあります。
- 通話追跡。データ ポップの交換機周辺のコールを追跡することは、コール参照 ID を取得し、それをキーとして使用してデータベースにデータを保存するほど簡単ではありません。いくつかのスイッチでは、コールがシステム内を移動するにつれて ref ID が変化します。遷移を追跡し、内部参照 ID に対して更新するソフトウェアを作成する必要があります。ああ、すべてのスイッチが参照 ID をサポートしているわけではありません...
要約すると、スイッチ間の違いだけでなく、同じスイッチの異なるプロトコル、サービス クラス/構成による違い、さらにはデバイスごとの違いも確認できます。後者については、エージェントのデスクにある電話機に基づいてさまざまな動作が確認できることを意味します (CTI データ ポップに関連)。
これらすべてを隠す単一のソリューションは存在せず、いくつかの違いを考慮すると、汎用ソリューションは存在できません。ただし、特定のユースケース向けの制約付きモデルを作成することはできます。正規化層を作成するには、それほど簡単ではなく、スイッチに関する多くの経験が必要です。
さて、問題のより大きな領域を概説しました (はい、他にもあります :-( )、いくつかのアドバイス:
- アプリケーション ロジックをテレフォニー ロジックから切り離します。テレフォニーの統合には複数のプラグイン モジュールが必要になると想定します。
- 正規化層の近くで特定の機能を切り替えることは避けてください。エージェントのデスクトップに展開している場合、コール センターは特定の ACD 設定を利用するか少なくとも尊重することを期待しているため、これらを回避することはできません (通話がレポートに正しく表示されない場合、顧客を失うリスクがあります) ）
- 幅広いテレフォニー プロトコルをサポートし、豊富な拡張転送機能セットを公開している主要 IVR ベンダーを選択してください。
- 基準は...貧弱ですが...それがあなたが持っているすべてです。アプリケーションを VoiceXML で作成します。プライマリ ベンダーがサポートできないスイッチまたはコール センターで契約を結んでいる場合は、IVR ベンダーを変更できる立場にあります。
- CTI プロトコルにはさまざまなものがあります。TAPI、JTAPI、TSAPI、CSTA など。答えは一つではありません。より一貫性のある API を提供する商用正規化レイヤーがいくつかありますが、機能とイベント ストリームは依然としてスイッチごとに異なります。複数のインターフェイスに書き込むことを計画するか、サードパーティ API の料金を支払うことを計画してください。サードパーティ製品のコストは高価なアドオンになる可能性があるため、簡単な答えはありませんが、幅広いスイッチを実装するには開発労力がさらにかかる可能性があります。
- 限られたスイッチ ベンダーまたは CTI サーバーと提携します (例:Cisco ICM、Genesys T-Server）。市場は制限されますが、統合コストは最小限に抑えられます。しかし、そのパートナーシップにより、販売を活用し、より多くの顧客にアクセスできるようになる可能性があります。
また、私の質問に代わる答えとして、私たちは、複数の電話システム（ボード、PBXではおよびIPテレフォニー）およびプラットフォームのサポートを提供するために、JTAPIを使用して、インターフェイスを作るオープンソースプロジェクトにつまずいてきました。この方法では、私が言及したように、アプリケーションを開発し、それは関係なく、システムの多くの異なるシステムのために働くことができます。私は例外があると確信していますが、これはそれらの大半で動作するようになっている - TAPIはとにかく広く受け入れられている標準の一種であることを考慮ます：
その '一般的なJTAPI' と呼ばれるます：
Twilio にして自分自身にいくつかの痛みや開発時間を節約できます。基本的に彼らは、PSTN / VoIP接続に対処し、あなただけのXML / HTTPのRESTをどうするか、それらを教えてください。彼らは、Javaを含むに、さまざまな言語でヘルパーライブラリを持っています。
