着信の概念

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

呼び出しシナリオ

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

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

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

情報源	行き先	シナリオ
Azure Communication Services 識別子	Azure Communication Services 識別子	通話、リダイレクト、参加者の追加、転送
Azure Communication Services 識別子	Azure Communication Services リソースが所有する PSTN 番号	通話、リダイレクト、参加者の追加、転送
パブリック PSTN	Azure Communication Services リソースが所有する PSTN 番号	通話、リダイレクト、参加者の追加、転送

注

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

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

Azure サブスクリプションで Event Grid をまだ使用していない場合は、Event Grid リソース プロバイダーの登録が必要になることがあります。 プロバイダーを登録するには、次の手順に従います。

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

イベントグリッドからの受信通知の処理

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

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

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

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

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

コール オートメーションと Event Grid を使用した通話ルーティング オプション

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

注

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

以下は、data.to.PhoneNumber.Value 文字列が +18005551212 の PSTN 電話番号で始まることを監視する Event Grid サブスクリプションに対する高度なフィルターの例です。

番号の割り当て

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

ベスト プラクティス

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

2. アプリケーションが必要な時間内に 200 OK 状態コードで Event Grid に応答できない場合、Event Grid は指数バックオフ再試行を使用してイベントを再送信します。 ただし、着信呼び出しは 30 秒間しか呼び出されないため、その後の呼び出しへの応答は有効ではありません。 期限切れまたは古い呼び出しの再試行を防ぐには、再試行ポリシーを [最大イベント配信試行回数] を 2 に、イベントの有効期間を 1 分に設定することをお勧めします。 これらの設定は、イベント サブスクリプションの [追加機能] タブにあります。 再試行の詳細については 、こちらをご覧ください。

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

   AegDeliveryFailureLogs
   | limit 10 
   | where Message has "incomingCall"
   

4. すぐに応答できるコンピューティングで呼び出しに応答するアプリケーションをホストします。 呼び出しへの応答はリアルタイム操作です。 IncomingCall イベントを受信するエンドポイントには、通知を処理して AnswerCall または Redirect API を呼び出すリングの期間 (30 秒) しかありません。 このエンドポイントは、ゼロにスケーリングするか、コールド スタート待機時間を持つコンピューティングでホストしないようにします。 たとえば、従量課金ベースのプランのサーバーレス関数アプリは、最近のトラフィックがない場合に休止状態になることがあります。 IncomingCall イベントがコールド インスタンスに到着すると、ホストの起動にかかる時間によって応答可能な時間が使い果たされ、その呼び出しには応答されません。 同時呼び出しが急増すると、別のリスクが発生します。 リアクティブにスケールアウトするコンピューティングは需要に遅れる可能性があるため、エンドポイントが Event Grid を時間内に確認できない可能性があります。 このパスでタイムアウトまたはエラー応答が発生すると、呼び出しが失敗します。

   呼び出しに確実に応答するには:

   • スケールアウトが追いつくまでの間に想定される負荷の急増を吸収するには、十分なウォーム容量を備えた、常時稼働の事前プロビジョニング済みコンピュート環境で Webhook ハンドラーを実行します。 たとえば、Always On を有効にした Azure App Service、常時準備完了（事前ウォーム済み）インスタンスが維持されるプランの Azure Functions、最小レプリカ数が 0 より大きい Azure Container Apps、または十分なベースライン容量を備えた Azure Kubernetes Service が該当します。
   • IncomingCall イベントと AnswerCall API の間のパスを短くして直接保持します。 ゲートウェイや Web アプリケーション ファイアウォールなど、応答パスの中間ホップを最小限に抑えます。 データベース参照やビジネス ロジックなどの重要でない作業を応答パスから移動して、迅速に応答できるようにします。
   • 重複するイベントを安全に処理するようにハンドラーを設計します。 Event Grid は少なくとも 1 回イベントを配信するため、アプリケーションは同じ IncomingCall イベントを複数回受信できます。

次のステップ

• 発信通話を行うクイック スタートをお試しください。