Azure Communication Services のサービス制限
このドキュメントでは、Azure Communication Services API の制限事項と考えられる解決策について説明します。
調整パターンとアーキテクチャ
サービスの制限に遭遇した場合、HTTP 状態コード 429 (要求が多すぎる) が返されます。 調整を処理するための一般的なベスト プラクティスを次に示します。
- 要求あたりの操作の数を減らす。
- 呼び出しの頻度を減らします。
- すべての要求が使用制限に加算されるため、すぐに再試行することは避けてください。
調整と制限を処理するようにサービス アーキテクチャを設定する方法に関するより一般的なガイダンスについては、調整パターンに関する Azure Architecture のドキュメントを参照してください。 調整の制限は、Azure サポートへのリクエストによって引き上げることができます。
- Azure portal にアクセスする
- [ヘルプとサポート] を選択します
- [新しいサポート リクエスト] をクリックします
- [問題の説明] で、[問題の種類] として [技術的] を選択し、詳細を追加してください。
「Azure サポートへのリクエストを作成する」のドキュメントに従うことができます。
電話番号の取得
電話番号を取得する前に、サブスクリプションが地理的およびサブスクリプションの要件を満たしていることを確認してください。 そうでない場合、電話番号を購入することはできません。 電話番号 SDK と Azure portal を使用した番号の購入には、以下の制限事項が適用されます。
操作 | Scope | 時間枠 | 制限 (要求の数) |
---|---|---|---|
電話番号を購入する | Azure テナント | - | 1 |
電話番号の検索 | Azure テナント | 1 週間 | 5 |
実行するアクション
詳細については、電話番号の種類の概念およびテレフォニーの概念の概要に関するページを参照してください。
さらに多くの電話番号を購入したい場合や、特別な注文で購入する場合は、こちらの手順に従ってください。 外部アカウントから Azure Communication Services アカウントに無料電話番号を移植する場合はこちらの手順に従ってください。
ID
操作 | 期間 (秒) | 制限 (要求の数) |
---|---|---|
ID の作成 | 30 | 1000 |
ID の削除 | 30 | 500 |
アクセス トークンの発行 | 30 | 1000 |
アクセス トークンの取り消し | 30 | 500 |
createUserAndToken | 30 | 1000 |
exchangeTokens | 30 | 500 |
実行するアクション
チャット スレッドを作成する前または通話を開始する前に、ID とトークンを取得することをお勧めします。 たとえば、Web ページの読み込み時やアプリケーションの起動時などです。
詳細については、ID の概念の概要に関するページを参照してください。
SMS
大量のメッセージを送信または受信するときに、429
エラーが発生することがあり ます。 このエラーは、サービスの制限に達していることを示します。要求の数がしきい値を下回ったときにメッセージが送信のためのキューに入れられます。
SMS の転送率の制限:
操作 | 数値の種類 | Scope | 期間 (秒) | 制限 (要求数) | 1 分あたりのメッセージ単位 |
---|---|---|---|---|---|
メッセージを送信する | フリーダイヤル | 数ごと | 60 | 200 | 200 |
メッセージを送信する | 短いコード | 数ごと | 60 | 6000 | 6000 |
メッセージを送信する | 英数字送信者 ID | リソースあたり | 60 | 600 | 600 |
実行するアクション
レート制限を超える要件がある場合は、より高いスループットを実現するための要求を Azure サポートに送信します。
SMS SDK とサービスの詳細については、SMS SDK の概要に関するページまたは SMS の FAQ に関するページを参照してください。
メール
送信できるメール メッセージの数には制限があります。 サブスクリプションで以下の制限を超えた場合、要求は拒否されます。 再試行までの時間が経過した後に、これらの要求をもう一度試すことができるようになります。 必要なアクションを実行し、必要に応じて送信ボリューム制限の引き上げを要求してください。
レート制限
操作 | Scope | 時間枠 (分) | 制限 (電子メールの数) |
---|---|---|---|
電子メールの送信 | サブスクリプションあたり | 1 | 30 |
電子メールの送信 | サブスクリプションあたり | 60 | 100 |
電子メールの状態の取得 | サブスクリプションあたり | 1 | 60 |
電子メールの状態の取得 | サブスクリプションあたり | 60 | 200 |
操作 | Scope | 時間枠 (分) | 制限 (電子メールの数) |
---|---|---|---|
電子メールの送信 | サブスクリプションあたり | 1 | 5 |
電子メールの送信 | サブスクリプションあたり | 60 | 10 |
電子メールの状態の取得 | サブスクリプションあたり | 1 | 10 |
電子メールの状態の取得 | サブスクリプションあたり | 60 | 20 |
サイズ制限
名前 | 制限 |
---|---|
電子メールの受信者の数 | 50 |
電子メール要求の合計サイズ (添付ファイルを含む) | 10 MB |
実行するアクション
このサンドボックスの設定は、開発者によるアプリケーションのビルド開始を支援するためのものです。 メールを送信することで送信者レピュテーションを確立すると、送信ボリューム制限の引き上げを要求できるようになります。 レート制限を超える量のメッセージを送信する必要がある場合は、必要なメール送信制限を引き上げるように求めるサポート リクエストを送信してください。 メール クォータの引き上げ要求は自動的に承認されるわけではありません。 レビュー チームは承認状態を決定するときに、あなたの全体的な送信者レピュテーションを考慮します。これには、メール配信の失敗率、ドメインのレピュテーション、スパムや不正使用のレポートなどの要因が含まれます。
Note
メール クォータの引き上げ要求の評価と承認には最大で 72 時間かかる可能性があります (金曜日の午後に行われる要求は特に時間がかかります)。
チャット
サイズ制限
名前 | 制限 |
---|---|
通話あたりの参加者数 | 250 |
参加者のバッチ - CreateThread | 200 |
参加者のバッチ - AddParticipant | 200 |
ページ サイズ - ListMessages | 200 |
メッセージ サイズ | 28 KB |
Azure Bot あたりの Azure Communication Services リソースの数 | 1000 |
レート制限
操作 | スコープ | 10 秒あたりの制限 | 1 分あたりの制限 |
---|---|---|---|
チャット スレッドを作成する | ユーザーごと | 10 | - |
チャット スレッドの削除 | ユーザーごと | 10 | - |
チャット スレッドの更新 | チャット スレッドごと | 5 | - |
参加者の追加/参加者の削除 | チャット スレッドごと | 10 | 30 |
チャット スレッドの取得/チャット スレッドの一覧表示 | ユーザーごと | 50 | - |
チャット メッセージを取得する | チャット スレッドあたりのユーザーごと | 50 | - |
チャット メッセージを取得する | チャット スレッドごと | 250 | - |
チャット メッセージを一覧表示する | チャット スレッドあたりのユーザーごと | 50 | 200 |
チャット メッセージを一覧表示する | チャット スレッドごと | 250 | 400 |
開封確認メッセージを取得する (20 人の参加者の制限**) | チャット スレッドあたりのユーザーごと | 5 | - |
開封確認メッセージを取得する (20 人の参加者の制限**) | チャット スレッドごと | 100 | - |
チャット スレッドの参加者を一覧表示する | チャット スレッドあたりのユーザーごと | 10 | - |
チャット スレッドの参加者を一覧表示する | チャット スレッドごと | 250 | - |
メッセージの送信/メッセージの更新/メッセージの削除 | チャット スレッドごと | 10 | 30 |
開封確認メッセージを送信する | チャット スレッドあたりのユーザーごと | 10 | 30 |
入力インジケーターの送信 | チャット スレッドあたりのユーザーごと | 5 | 15 |
入力インジケーターの送信 | チャット スレッドごと | 10 | 30 |
Note
** 20 名を超える参加者がいるチャット スレッドの場合は、開封確認メッセージと入力インジケーターの機能はサポートされません。
チャットの保存
Azure Communication Services は、顧客によって削除されるまでチャット メッセージを無期限に格納します。
CY24 Q1 以降、お客様は 90 日後にメッセージを無期限に保持または自動削除を選択する必要があります。 既存のメッセージは影響を受けませんが、お客様は必要に応じて 90 日間の保持期間を選択できます。
Note
誤って削除されたメッセージは、システムによって回復できません。
音声およびビデオによる通話
PSTN 通話の制限事項
名前 | スコープ | なし |
---|---|---|
同時発信呼び出しの既定数 | 番号あたり | 2 |
呼び出しの最大制限
名前 | 制限 |
---|---|
参加者数 | 350 |
Calling SDK ストリーミング サポート
Communication Services Calling SDK では、次のストリーミング構成がサポートされています。
制限 | Web | Windows/Android/iOS |
---|---|---|
同時に送信できる発信ローカル ストリームの最大数 | 1 つのビデオまたは 1 つの画面共有 | 1 つのビデオ + 1 つの画面共有 |
同時にレンダリングできる着信リモート ストリームの最大数 | 9 つのビデオ + 1 つの画面共有 | 9 つのビデオ + 1 つの画面共有 |
Calling SDK ではこれらの制限は適用されませんが、これらを超えた場合、パフォーマンスの低下が生じる場合があります。
Calling SDK のタイムアウト
Communication Services Calling SDK では、次のタイムアウトが適用されます。
アクション | タイムアウト (秒) |
---|---|
参加者の再接続/削除 | 120 |
通話に対する新しいモダリティの追加または削除 (ビデオまたはスクリーン共有の開始/停止) | 40 |
通話転送操作に関わるタイムアウト | 60 |
1:1 通話確立に関わるタイムアウト | 85 |
グループ通話確立に関わるタイムアウト | 85 |
PSTN 通話確立に関わるタイムアウト | 115 |
1:1 通話のグループ通話への昇格に関わるタイムアウト | 115 |
実行するアクション
音声およびビデオの Calling SDK とサービスの詳細については、Calling SDK の概要ページまたは既知の問題に関するページを参照してください。
Job Router
大量の要求の送信または受信時には、ThrottleLimitExceededException
エラーが発生する場合があります。 このエラーは、あなたがサービスの制限に達していることを意味し、要求を処理するバケットのトークンが一定時間後に補充されるまで、要求は破棄されます。
Job Router のレート制限:
操作 | Scope | 期間 (秒) | 制限 (要求の数) | タイムアウト (秒) |
---|---|---|---|---|
一般的な要求 | リソースあたり | 10 | 1000 | 10 |
実行するアクション
レート制限を超える量のメッセージを送信する必要がある場合は、acs-ccap@microsoft.com へメールでお問い合わせください。
Teams の相互運用性と Microsoft Graph
Teams 相互運用性シナリオを使用している場合は、おそらく、いくつかの Microsoft Graph API を使用して会議を作成することになります。
Microsoft Graph によって提供される各サービスにはさまざまな制限があります。ここでは、サービス固有の制限について詳しく説明します。
実行するアクション
エラー処理を実装するときに、HTTP エラー コード 429 を使用して調整を検出します。 失敗した応答には、Retry-After
応答ヘッダーが含まれます。 クライアントが調整されている間も Microsoft Graph がリソースの使用状況を継続的にログに記録するため、Retry-After
遅延を使用して要求をオフにする方法が、調整から回復する最も簡単な方法です。
Microsoft Graph の調整の制限の詳細については、Microsoft Graph のドキュメントを参照してください。
次のステップ
ヘルプとサポートのオプションを参照してください。