イベントの流れ

システム内の異なるコンポーネントとVonage API間の関係を理解するために、イベントDispatchのシステムフローを考えてみよう。

説明のために、電話からアプリのユーザーに電話をかけるというユースケースを考えてみよう。

この流れをまとめるとこうなる：

  1. 電話がかかる。
  2. Vonageは通話を受信し、次の番号にコールバックします。 answer_url ウェブフック
  3. NCCOが実行される。
  4. 通話が作成され、ユーザーが接続される。
  5. イベントがディスパッチされる。

注： 前述のユースケースでは、エントリーポイントはVonage番号への電話である。しかし、以下のダイアグラムと、イベントがシステム内でディスパッチされる方法は、他のすべてのイベントタイプで同様に機能します。

これは以下の図に示されている：

BackendVoice APIConversation APIApplicationClientBackendVoice APIConversation APIApplicationClientEstablish ConversationHandle events1. Calls Vonage number2. Establishes `answer_url `and `event_url` webhooks3. `answer_url` returns NCCO4. Call is created and Users added5a. Voice API events trigger`event_url`5b. RTC events trigger `event_url`5c. Events sent to your app via Client SDK

順序は以下の通り：

  1. に電話をかける。 Vonage番号であった。 Vonageアプリケーションに割り当てられる.

  2. Vonageはコールを受信し、Vonageアプリケーションの answer_url ウェブフックバックエンドが公開する。

  3. それは answer_url は、通話をどのように処理するか、通話を誰に接続するかを決定する。それは、NCCOを実行することによって行われる。 Voice API.

  4. A コール が作成され、要求されたユーザーがそれに接続される。通話は、Vonageの通信イベントと同様に 会話 オブジェクトがある。

その結果 answer_url を実行すると、新しい 会話 が作成されるか、既存のものがフェッチされ、リクエストされたユーザーがそれに追加され、呼び出しに接続される。すべてのイベントはConversation APIを通過し、Conversation APIからアクセスできる。そのため、Conversationは非常に強力です。Conversationはユーザーごとのすべてのチャネルのコミュニケーションイベントを保持し、コミュニケーションのコンテキストを保持し、ユーザーにより良い、よりスマートなコミュニケーション体験を提供することができます。

  1. それぞれのイベントはすべてアプリケーションにディスパッチされます。これらのイベントは、バックエンドまたはクライアントアプリに送られます：

    a. と b. バックエンドへ 経由 event_url ウェブフックVonageアプリケーションに割り当てることができます。音声イベントとRTCイベントの両方があります。Vonageアプリケーションの 声 event_url ウェブフック は Voice API から Dispatch されます。VonageアプリケーションのRTC機能へのアプリケーション event_url webhookはConversation APIによってディスパッチされます。

    c. クライアント側アプリケーションへである。 Client SDKとの統合.これらのイベントは、ユーザーがSDKにログインしている場合、Client SDKがトリガーするコールバック経由で受け取ることができます。また、プッシュ通知によって受け取ることもできます。 有効になっているアプリはバックグラウンドにある。

注： 選択されたイベントのみがクライアント SDK にディスパッチされます。すべてのイベントを受信するには、以下を確認してください。 セット event_url Vonageアプリケーション用webhooks.イベントウェブフックの設定は必須ではありませんが、強くお勧めします。

参考

詳細については、以下の文書を参照のこと：

ガイド

APIリファレンス