次の方法で共有

着信の概念

  • [アーティクル]

Azure Communication Services の Call Automation を使用すると、開発者は呼び出しを行って受信できるアプリケーションを作成することができます。 Event Grid サブスクリプションを利用して IncomingCall イベントを配信するため、アプリケーションが呼び出しを効果的にリダイレクトまたは応答するために、これらの通知を受信するように環境を構成することが重要になります。 そのため、Azure Communication Services の Call Automation の可能性を最大限に活用するには、着信呼び出しの基礎を理解することが不可欠です。

呼び出しシナリオ

環境を設定する前に、IncomingCall イベントをトリガーできるシナリオを理解しておくことが重要です。 IncomingCall イベントをトリガーするには、Azure Communication Services リソースに関連付けられている Azure Communication Services ID または公衆交換電話網 (PSTN) 番号に対して呼び出しを行う必要があります。 これらのリソースの例を次に示します。

  1. Azure Communication Services の ID
  2. Azure Communication Services リソースが所有する PSTN 電話番号

これらの例では、次のシナリオで Event Grid に送信される IncomingCall イベントがトリガーされます。

source 到着地 シナリオ
Azure Communication Services の ID Azure Communication Services の ID 通話、リダイレクト、参加者の追加、転送
Azure Communication Services の ID Azure Communication Services リソースが所有する PSTN 番号 通話、リダイレクト、参加者の追加、転送
パブリック PSTN Azure Communication Services リソースが所有する PSTN 番号 通話、リダイレクト、参加者の追加、転送

Note

Azure Communication Services ID は、ユーザーやアプリケーションを表すことができるということを理解しておくことが重要です。 プラットフォームには、ユーザーやアプリケーションに ID を明示的に割り当てる組み込み機能はありませんが、アプリケーションまたはサポート インフラストラクチャでこれを実現できます。 このトピックの詳細については、ID の概念に関するガイドを参照してください。

Event Grid リソース プロバイダーを登録する

これまでに Azure サブスクリプションで Event Grid を使ったことがない場合は、Event Grid リソース プロバイダーの登録が必要な可能性があります。 プロバイダーを登録するには、次の手順のようにします。

  1. Azure Portal にアクセスします。
  2. 左側のメニューで [サブスクリプション] を選択します。
  3. Event Grid に使うサブスクリプションを選びます。
  4. 左側のメニューの [設定] で、 [リソース プロバイダー] を選択します。
  5. Microsoft.EventGrid を探します。
  6. リソース プロバイダーが登録されていない場合は、[登録] を選びます。

Event Grid からの着信呼び出し通知の受信

Azure Communication Services では、Event Grid サブスクリプションを通じて IncomingCall 通知を受信できます。 通知の受信者は、それを処理する方法を柔軟に選択できます。 Call Automation API はイベントに Webhook コールバックを利用するため、"Webhook" Event Grid サブスクリプションを使用するのが一般的です。 ただし、サービスにはさまざまな種類のサブスクリプションが用意されており、ご自身のニーズに最も適したものを選択できます。

このアーキテクチャには次のような利点があります。

  • Event Grid サブスクリプション フィルターを使用すると、IncomingCall 通知を特定のアプリケーションにルートできます。
  • PSTN 番号の割り当てとルーティング ロジックは、オンラインで静的に構成されているのではなく、アプリケーションに存在させることができます。
  • 呼び出しシナリオのセクションで確認したように、ユーザーが相互に呼び出しを行った場合でも、アプリケーションは通知を受け取ることができます。 その後、このシナリオを Call Recording API と組み合わせて、コンプライアンスのニーズを満たすことができます。

イベントのサンプル ペイロードと、Event Grid に発行されたその他の呼び出しイベントの詳細については、こちらのガイドを参照してください。

イベントの種類フィルターが IncomingCall イベントのみをリッスンしている Event Grid Webhook サブスクリプションの例を次に示します。

Image showing IncomingCall subscription.

Call Automation と Event Grid を使用した呼び出しルーティング オプション

Call Automation と Event Grid では、呼び出しルーティングを特定のニーズに合わせて調整できます。 Event Grid サブスクリプションで高度なフィルターを使用することで、特定の送信元/宛先の電話番号または Azure Communication Services ID に関係する IncomingCall 通知をサブスクライブすることができます。 この通知は、Webhook サブスクリプションなどのエンドポイントに送信できます。 その後、Call Automation SDK を使用すると、そのエンドポイント アプリケーションでは、呼び出しを別の Azure Communication Services ID または PSTN にリダイレクトすることを決定できます。

Note

アプリケーションが必要なイベントのみを確実に受信できるようにするには、Event Grid でフィルター処理を構成することをお勧めします。 これは、受信 PSTN 呼び出しを Azure Communication Services エンドポイントにリダイレクトするなど、IncomingCall イベントを生成するシナリオで特に重要です。 フィルターを使用しない場合、Event Grid サブスクリプションは、最初の通知のみを受信することを意図した場合でも、2 つの IncomingCall イベント (PSTN 呼び出し用と Azure Communication Services ユーザー用) を受け取ります。 アプリケーションでフィルターやその他のメカニズムを使用してこのようなシナリオを処理しないと、無限ループやその他の望ましくない動作が発生する可能性があります。

PSTN 電話番号 '+18005551212 で始まる data.to.PhoneNumber.Value 文字列を監視している Event Grid サブスクリプションの高度なフィルターの例を次に示します。

Image showing Event Grid advanced filter.

数値の割り当て

Azure Communication Services で IncomingCall 通知を使用する場合、特定の数字を任意のエンドポイントに関連付けることができます。 たとえば、+14255551212 の PSTN 電話番号を取得し、それをアプリケーションで 375f0e2f-e8db-4449-9bf7-2054b02e42b4 の ID を持つユーザーに割り当てる場合、その番号の ID へのマッピングは維持されます。 [宛先] フィールドの電話番号と一致する IncomingCall 通知が送信されたら、Redirect API を呼び出して、ユーザーの ID を提供できます。 つまり、アプリケーション内で番号の割り当てを維持し、実行時に呼び出しをルーティングまたは応答することができます。

ベスト プラクティス

  1. Event Grid が Webhook エンドポイントにイベントを配信し、悪意のあるユーザーがイベントでエンドポイントを氾濫させないようにするには、エンドポイントの所有権を証明する必要があります。 イベントの受信に関する問題に対処するには、構成した Webhook が SubscriptionValidationEvent の処理によって検証されていることを確認します。 詳しくは、こちらのガイドを参照してください。

  2. 着信呼び出しイベントを受信した際に、アプリケーションが必要な概算時間内に Event Grid に 200Ok 状態コードで応答できない場合、Event Grid はエクスポネンシャル バックオフ再試行を利用してイベントを再度送信します。 ただし、着信呼び出しは 30 秒間だけ呼び出されるため、その後に呼び出しに応答しても効果はありません。 有効期限が切れたり、古くなったりした呼び出しに対する再試行を回避するには、[イベント配信の最大試行回数] を 2 に、[イベントの Time to Live] を 1 分になるように再試行ポリシーを設定することをお勧めします。 これらの設定は、イベント サブスクリプションの [追加の機能] タブで確認できます。 再試行の詳細については、こちらを参照してください。

  3. Event Grid リソースのログ記録を有効にして、配信に失敗したイベントを監視することをお勧めします。 これを行うには、通信リソースの [イベント] タブにあるシステム トピックに移動し、[診断設定] からログ記録を有効にします。 エラー ログは、"AegDeliveryFailureLogs" テーブルにあります。

    AegDeliveryFailureLogs
| limit 10 
| where Message has "incomingCall"

次のステップ