3

私が働いている会社は、潜在的な PBX/IVR または PBX コンボとの互換性が高く、独自のホスティング ソリューションを提供する IVR 実装を探しています。

そのため、考えられるのは、あらゆる潜在的なプラットフォームに接続し、通話制御と音声ダイアログ/IVR の対話を提供するアプリケーションを作成することです。

私がこれまで見てきた技術 (Java を使用したい) は、Java Telephony API (JTAPI)、JAIN-JCC (Java Call Control) API などです。これらの API の基本的な要旨は理解できますが、まとめられないのは、通話制御および音声 IVR / VXML 用に作成するアプリケーションが、プラットフォームに依存しない方法で電話システムにインターフェイスする方法です。電話システムから電話を受けるにはどうすればよいですか?

これらの API とライブラリは、この質問に答えていないように思われるため、プラットフォームに依存しないソリューションは不可能であり、常に実装固有のものになると考えています。JAIN-SIPもあります。すべての通話をSIPに変換できれば、この方法で汎用の通話制御/IVRアプリケーションを作成できるかもしれません。

ここで無知や誤解を口にした場合は、ご容赦ください。私はあらゆる種類の通信技術にまったく慣れていません-私を正したい人はいますか? 私は非常に感謝しています.詳細な実装レベルでの接続は、この時点では非常に曖昧であり、時には少し手を握る必要があります. 正しい方向への助けやプッシュは役に立ちます。

私は先週、仕様と API について詳しく説明してきました。:)

編集 - 可能であればこれを社内で開発することを好み、費用対効果の点で賢明であることを忘れていました-可能であれば統合プラットフォームにお金を費やすつもりはありません-それが私の仕事です:)

4

5 に答える 5

5

私はこの分野で何年も働いてきました。ChrisWの答えはとても良いです。これは、同様の状況にある人々に役立つ可能性のあるいくつかの追加情報です。

アプリケーションをホストしている場合、統合に関する懸念のほとんどがなくなるため、前提ソリューションを提供していると思います。ファシリティを変更する必要があり、テレフォニーロジックをダイアログおよびビジネスロジックから分離した場合、変換はそれほど難しくありません。

IVR / PBX統合の課題は、さまざまな形で現れます。

テレフォニー：

テレフォニーとは、ファーストパーティのコール制御を意味します。電話回線の特徴。

  • 到着情報（ANI / DNIS）を呼び出します。VoiceXMLなどのより高いレベルで作業していると仮定すると、さまざまな問題が発生する可能性があります。ほんの一部：
    • データの存在。すべてのスイッチがこのデータを提供するわけではありません。さらに悪いことに、データは特定のスイッチ構成でのみ利用できる場合があります。その構成は、アプリケーションまたはコールセンターの他のニーズ（転送）と競合している可能性があります。
    • データ形式。アプリケーションによっては、これが問題になる場合と問題にならない場合がありますが、データの形式はスイッチごとに少し異なる場合があります。
  • さまざまな転送タイプ。周囲のテレフォニーネットワークのアーキテクチャに応じて、転送タイプを変更する必要がある場合があります。通常、VoiceXMLで使用可能なデフォルトのフックフラッシュ転送は、ローカルコールセンターのエージェントまたはACDに転送するときに機能します。ただし、オフサイト/オフPBX / PBX-PBX転送は、監視対象（2ステップ）転送として実行する必要があります。VoiceXML標準は、このタイプの転送をカバーしていないことに注意してください。ブラインド転送と会議のみを対象としていますが、ほとんどのプラットフォームには、追加の転送ロジックにアクセスするためのメカニズムが用意されています。

コンピューターテレフォニーインテグレーション（CTI）：

CTIとは、PBXとのデータ統合によるファーストパーティまたはサードパーティの通話制御を意味します。

  • 機能の違い。ほとんどの人が想像できる以上のものです。ACDのあるコールセンターにいる場合は、非常に複雑になる可能性があります。ACDの機能は、ベンダーごとに大きく異なる可能性があります。
  • イベントストリーム/データ形式。繰り返しますが、それらは非常に異なる可能性があります。一部のスイッチでは、豊富なイベントのセットを取得します。一部の環境では、事実上何も表示されません。
  • 通話追跡。データポップのスイッチ周辺の通話を追跡することは、通話参照IDを取得し、それをキーとして使用してデータベースにデータを貼り付けることほど簡単ではありません。いくつかのスイッチでは、コールがシステム内を移動するときにrefidが変化します。遷移を追跡し、内部参照IDに対して更新するソフトウェアを作成する必要があります。ああ、すべてのスイッチがrefidsをサポートしているわけではありません...

要約すると、スイッチ間の違いだけでなく、同じスイッチの異なるプロトコル、サービス/構成のクラスによる違い、さらにはデバイスごとの違いもわかります。後で、エージェントのデスクに設定された電話に基づいて異なる動作を確認できることを意味します（CTIデータポップに関連）。

これらすべてを隠す単一のソリューションはなく、いくつかの違いを考えると、汎用ソリューションは存在できません。ただし、特定のユースケースの制約付きモデルを作成できます。簡単ではなく、正規化レイヤーを作成するにはスイッチに関する多くの経験が必要です。

これで、問題のより大きな領域の概要を説明しました（はい、他にもあります:-(）、いくつかのアドバイス：

  • アプリケーションロジックをテレフォニーロジックから切り離します。テレフォニー統合のために複数のプラグインモジュールが必要になると想定します。
  • 正規化レイヤーの近くで特定の機能を切り替えることは避けてください。コールセンターが特定のACD構成を活用するか、少なくとも尊重することを期待しているため、エージェントデスクトップに展開している場合、それらを回避することはできません（コールがレポートに正しく表示されない場合、顧客を失うリスクがあります）。
  • 幅広いテレフォニープロトコルをサポートし、転送機能の豊富な拡張セットを公開しているプラ​​イマリIVRベンダーを選択してください。
  • 基準は...貧弱ですが...あなたが持っているのはそれらだけです。アプリケーションをVoiceXMLで記述します。プライマリベンダーがサポートできないスイッチまたはコールセンターで取引がある場合は、IVRベンダーを変更する立場にあります。
  • さまざまなCTIプロトコルがあります。TAPI、JTAPI、TSAPI、CSTAなど。答えは1つではありません。より一貫性のあるAPIを提供する商用正規化レイヤーがいくつかありますが、機能とイベントストリームはスイッチごとに異なります。複数のインターフェースへの書き込みを計画するか、サードパーティのAPIに料金を支払うことを計画してください。サードパーティ製品のコストは高価なアドオンになる可能性があるため、ここでは簡単な答えはありませんが、さまざまなスイッチを実装するための開発作業はさらに多くなる可能性があります。
  • 限られたスイッチベンダーまたはCTIサーバー（Cisco ICM、Genesys T-Serverなど）と提携します。それはあなたの市場を制限しますが、統合コストを最小限に抑えます。しかし、そのパートナーシップは、販売を活用し、より多くの顧客にアクセスするのに役立つ可能性があります。
于 2009-09-28T13:13:58.583 に答える
4

私は数年前、 VoiceGenieで働いていました。彼らは、VoiceXML エンジンを作成しました (私がここで過去形を使用しているのは、彼らが現在何をしているのかを知らないからです。もう行っていないからではありません)。

  • Linuxボックスです
  • サードパーティの音声テキスト変換エンジンとテキスト読み上げエンジンが接続されている (エンジン固有の API とのインターフェイスにより)
  • (独自の VoiceXML パーサーを使用して) VoiceXML を解釈し、サードパーティの音声テキスト変換およびテキスト音声変換エンジンを駆動して実行します。

彼らは私を雇って、彼らのボックスを通話制御システムに接続させました。私が最初にそれを行ったのは Cisco のシステムでした (逆に言えば、VoiceGenie は現在 Genesys が所有しているようです)。同社のエンジンは、VoiceXML 以外のアプリケーションもサポートしていました。たとえば、Java アプリケーション インターフェイスを公開していました。

結論は：

  • さまざまな電話システムには、独自の呼制御 API があります。また、標準の呼制御プロトコル (SIP など) や API (JTAPI、TAPI、CCXML など) をサポートしている場合もあります。
  • いくつかの統合 API を提供し、他のコンポーネントとの相互運用性を処理およびサポートする (またはサポートしない)サードパーティ エンジン ( Genesys Voice Platform、Microsoft Office Communications Serverなど) を見つけることができます。

私は、この分野のプロダクト マネージャー、システム エンジニア、ネットワーク アーキテクト、ドメイン エキスパートではありません。

しかし、それらはすべて一般的に少数のプロトコルと API をサポートしています。

独自の広告のみをサポートするものもあれば、1 つ以上の標準をサポートするものもあります。

そのため、最もサポートされている API またはプロトコルにインターフェースするという考え方です。

そのためのビジネスケースについては質問しますが、特定の分野の専門知識と製品/実装の知識を持っているテレフォニーエンジニアを見つけて話し合うべきだと思います. ソフトウェア開発者として働いていて、上記の投稿に遭遇しましたが、その分野の専門知識がありません。

それはSIPでしょうか？

SIP はプロトコルであり、API ではありません。このようなものは、たとえば、使用する可能性のあるアプリケーションとしてレイヤーになっています。

  • 下位レベル: 独自の API を持つ SIP プロトコル スタック。この API を使用し、SIP ダイアログがどのように見えるかを理解し、SIP を理解するシステムと (のみ) 会話します。

  • 高レベル: VoiceXML/CCXML エンジン (または TAPI または JTAPI エンジン)。XML を記述します (または TAPI および JTAPI API を使用します)。また、エンジン (エンジンによって異なります) には、SIP を使用するコンポーネントと通信するために使用する組み込みの SIP スタックがある場合や、他の (非 SIP) プロトコルを使用するコンポーネント用の他のプロトコル スタックがある場合があります。 .

Cisco には、私が使用できる (独自の) プロトコルが 1 つしかなく、「Intelligent Contact Management」(つまり、コール センター) システムと通信できました。そして、ジェネシスには、クローズドな独自の API/プロトコルがあったと思います。

もしそうなら、私のコール制御と IVR ソリューションは、JTAPI アプリケーションまたは何らかのバリアントへの SIP フロント エンドとして最適に実装されますか?

あなたが何をしたいのか、スタックのどこになりたいのか、私は混乱しています（私が知っていたとしても、役に立つことは何も言えません）。

おそらくベンダーと話し合うべきだと思います: 彼らがあなたのために何ができるかを知るために (あなたが彼らと一緒に完成させようとしているのでなければ、それは難しいでしょう).

「潜在的な PBX/IVR または PBX コンボ」の意味を絞り込めますか?

于 2009-09-22T00:20:38.537 に答える
0

Web /RESTfulAPIを使用してIVRを開発する方がはるかに簡単です。そのようなAPIプロバイダーはいくつかあります。

Twilioは米国で最も人気のあるソリューションであり、最近では英国もサポートしています。

Hoiioは、香港やシンガポールなどのアジア諸国に適しています。

于 2011-11-03T08:55:27.297 に答える
0

また、私の質問に対する別の回答として、JTAPI を使用してインターフェイスを作成し、複数のテレフォニー システム (ボード、PBX、および IP テレフォニー) およびプラットフォームをサポートするオープン ソース プロジェクトを見つけました。このようにして、私が言及したようにアプリケーションを開発し、システムに関係なく多くの異なるシステムで動作させることができます. 例外があると確信していますが、TAPI が広く受け入れられている標準であることを考えると、これはそれらの大部分で動作するはずです。

「汎用 JTAPI」と呼ばれます。

http://gjtapi.sourceforge.net/

于 2009-09-22T21:32:30.947 に答える
0

Twilioを使用すると、手間と開発時間を節約できます。基本的に、彼らは PSTN/VOIP 接続を処理し、XML/HTTP REST をどう処理するかを指示するだけです。Java を含むさまざまな言語のヘルパー ライブラリがあります。

于 2009-09-27T03:42:34.437 に答える