Azure 通訊服務的服務限制
本文件說明 Azure Communication Services API 的限制和可能的解決方案。
節流模式和架構
當您達到服務限制時，您會收到 HTTP 狀態代碼 429 （要求太多）。 一般而言，以下是處理節流的最佳作法：
- 減少每個要求的作業數目。
- 減少通話的頻率。
- 避免立即做出重試，因為所有的要求都會納入使用量限制的計算。
您可以在適用於節流模式的 Azure 架構文件中找到有關如何設定服務架構以處理節流和限制的更多一般指引。 節流限制數量可透過對 Azure 支援提出要求來增加。
- 開啟 Azure 入口網站 並登入。
- 選取 [ 說明+支援]。
- 按兩下 [ 建立新的支援要求]。
- 在 [ 描述您的問題 ] 文本框中，輸入
Technical，然後按兩下 [ 移至]。 - 從 [ 選取服務 ] 下拉功能表中，選取 [服務與訂用帳戶限制]， 然後按 [ 下一步]。
- 在 [問題描述] 中，選擇 [問題類型]、 [訂用帳戶] 和 [配額類型 ]，然後按 [ 下一步]。
- 如果有的話，請檢閱任何 建議的解決方案 ，然後按 [下一步]。
- 視需要新增 其他詳細數據 ，然後按 [下一步]。
- 在 [檢閱 + 建立] 中檢查信息，視需要進行變更，然後按兩下 [ 建立]。
您可以遵循 對 Azure 支援建立要求 的文件。
取得電話號碼
在取得一組門號 (電話號碼) 之前，請確定您的訂用帳戶符合地理和訂用帳戶的需求。 否則，您無法購買一組門號 (電話號碼)。 下列的限制適用於透過電話號碼 SDK 和 Azure 入口網站中來購買門號 (電話號碼)。
| 作業 | 範圍 | 時間範圍 | 限制 (要求數目) |
|---|---|---|---|
| 購買門號 (電話號碼) | Azure 租用戶 | - | 1 |
| 搜尋門號 (電話號碼) | Azure 租用戶 | 一週 | 5 |
要採取的動作
如需詳細資訊，請參閱電話號碼類型概念頁面和電話語音概念概觀頁面。
如果您想要購買更多組的門號 (電話號碼) 或下特殊的訂單，請遵循這裡的指示。 如果您想要將免付費電話號碼從外部帳戶移植到其 Azure 通訊服務帳戶，請遵循這裡的指示。
身分識別
| 作業 | 時間範圍 (秒) | 限制 (要求數目) |
|---|---|---|
| 建立身分識別 | 30 | 1000 |
| 刪除身分識別 | 30 | 500 |
| 核發存取權杖 | 30 | 1000 |
| 撤銷存取權杖 | 30 | 500 |
| createUserAndToken | 30 | 1000 |
| exchangeTokens | 30 | 500 |
要採取的動作
建議您先取得身分識別和權杖，再建立聊天對話串或開始通話。 例如，當網頁載入或應用程式啟動時。
如需詳細資訊，請參閱身分識別概念概觀頁面。
SMS
傳送或接收大量訊息時，您可能會收到 429 錯誤。 此錯誤表示您遇到服務限制，而且訊息會排入佇列，一旦要求數目低於臨界值，就會傳送訊息。
簡訊 (SMS) 的比率限制：
| 作業 | 號碼類型 | 範圍 | 時間範圍 | 限制 (要求 #) | 每分鐘的訊息單位 |
|---|---|---|---|---|---|
| 傳送訊息 | 免付費電話 | 每個號碼 | 60 | 200 | 200 |
| 傳送訊息 | 簡短程式碼 | 每個號碼 | 60 | 6000 | 6000 |
| 傳送訊息 | 英數字元傳送者識別碼 | 每項資源 | 60 | 600 | 600 |
要採取的動作
如果您有超過速率限制的需求，請提交 要求給 Azure 支援，以啟用更高的輸送量。
如需 SMS SDK 和服務的詳細資訊，請參閱 SMS SDK 概觀頁面或 SMS 常見問題頁面。
電子郵件
您可以傳送一段時間的電子郵件訊息數目有限制。 如果您超過訂用帳戶的下列限制，就會拒絕您的要求。 當重試后時間經過時，您可以再次嘗試這些要求。 如有需要，您可以提出要求來提高傳送磁碟區限制。
速率限制
| 作業 | 範圍 | 時間範圍 (分鐘) | 限制 (電子郵件數目) |
|---|---|---|---|
| 傳送電子郵件 | 每個訂用帳戶 | 1 | 30 |
| 傳送電子郵件 | 每個訂用帳戶 | 60 | 100 |
| 取得電子郵件狀態 | 每個訂用帳戶 | 1 | 60 |
| 取得電子郵件狀態 | 每個訂用帳戶 | 60 | 200 |
| 作業 | 範圍 | 時間範圍 (分鐘) | 限制 (電子郵件數目) |
|---|---|---|---|
| 傳送電子郵件 | 每個訂用帳戶 | 1 | 5 |
| 傳送電子郵件 | 每個訂用帳戶 | 60 | 10 |
| 取得電子郵件狀態 | 每個訂用帳戶 | 1 | 10 |
| 取得電子郵件狀態 | 每個訂用帳戶 | 60 | 20 |
大小限制
| 名稱 | 限制 |
|---|---|
| 電子郵件中的收件者數目 | 50 |
| 電子郵件要求大小總計 (包括附件) | 10 MB |
要採取的動作
此沙箱設定是為了協助開發人員開始建置應用程式。 透過傳送郵件建立傳送者信譽後，您可以要求增加傳送量限制。 如果您需要傳送超過比率限制的郵件訊息量，請提交支援要求來提高您想要的傳送限制量。 電子郵件配額增加要求不會自動核准。 檢閱小組會考慮您的整體發件人信譽，其中包括您在判斷核准狀態時的電子郵件傳遞失敗率、網域信譽，以及垃圾郵件和濫用報告等因素。
注意
電子郵件配額增加要求最多可能需要 72 小時才能進行評估和核准，特別是針對週五下午提出的要求。
聊天
大小限制
| 名稱 | 限制 |
|---|---|
| 電子郵件討論串中的參與者數目 | 250 |
| 大批參與者 - CreateThread | 200 |
| 大批參與者 - AddParticipant | 200 |
| 頁面大小 - ListMessages | 200 |
| 訊息大小 | 28 KB |
| 每個 Azure Bot 的 Azure 通訊服務資源數目 | 1000 |
速率限制
| 運算 | 範圍 | 每 10 秒的限制量 | 每分鐘的限制量 |
|---|---|---|---|
| 建立聊天對話串 | 每位使用者 | 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 |
注意
** 超過 20 名參與者的聊天對話串不支援讀取收據和輸入指標。
聊天儲存體
Azure 通訊服務 根據您在建立聊天對話時所設定的保留原則來儲存聊天訊息。
重要
本文所述的功能目前處於公開預覽狀態。 此預覽版本沒有服務等級協定，不建議用於處理生產工作負載。 可能不支援特定功能，或可能已經限制功能。 如需詳細資訊，請參閱 Microsoft Azure 預覽版增補使用條款。
您可以透過建立聊天對話 API 上的保留原則，選擇無限期訊息保留或自動刪除 30 到 90 天。 或者，您可以選擇不要在聊天對話上設定保留原則。
如果您有嚴格的合規性需求，建議您使用 API 刪除聊天對話來刪除聊天線程。 除非您特別變更該線程的原則，否則在新的保留原則之前建立的任何線程都不會受到影響。
注意
如果您不小心刪除了訊息，系統就無法復原它們。 此外，如果您在保留原則刪除該線程之後提交已刪除聊天對話的支援要求，就無法再擷取該線程，也無法取得該線程的相關信息。 如有需要，請在建立線程之後，儘快在 30 天內開啟支援票證，以便我們協助您。
語音和視訊呼叫
PSTN 通話限制
| 名稱 | 範圍 | 限制 |
|---|---|---|
| 默認輸出數目* 並行呼叫 | 每個號碼 | 2 |
*：輸入並行呼叫沒有限制。 您也可以 將要求提交至 Azure 支援 ，以增加輸出並行通話限制，並由我們的審查小組檢閱。
通話最大限制量
| 名稱 | 限制 |
|---|---|
| 參與者數 | 350 |
通話 SDK 串流支援
通訊服務的通話 SDK 支援下列串流設定：
| 限制 | Web | Windows/Android/iOS |
|---|---|---|
| 您可以同時傳送的最大傳出本機串流數目 | 一支影片或一個螢幕共用 | 一支影片 + 一個螢幕共用 |
| 您可以同時轉譯呈現的最大傳入遠端串流數目 | 9 支影片 + 一個螢幕共用 | 9 支影片 + 一個螢幕共用 |
雖然通話 SDK 不會強制執行這些限制，但若超過這些限制，您的使用者可能會遇到效能降低的情況。
通話 SDK 逾時
下列逾時適用於通訊服務通話 SDK：
| 動作 | 逾時 (單位秒) |
|---|---|
| 重新連線/移除參與者 | 120 |
| 從通話 (開始/停止視訊或螢幕共用) 新增或移除新形式 | 40 |
| 通話轉接作業逾時 | 60 |
| 1：1 通話建立逾時 | 85 |
| 群組通話建立逾時 | 85 |
| PSTN 通話建立逾時 | 115 |
| 將 1：1 通話升階為群組通話逾時 | 115 |
要採取的動作
如需語音和視訊通話 SDK 和服務的詳細資訊，請參閱通話 SDK 概觀頁面或已知問題。 您也可以 將要求提交至 Azure 支援 ，以增加一些限制，然後由我們的審查小組檢閱。
工作路由器
傳送或接收大量要求時，您可能會收到 ThrottleLimitExceededException 錯誤。 此錯誤表示您遇到服務限制，而且您的要求將會遭到捨棄，直到在特定時間後補足處理要求的貯體權杖為止。
工作路由器的比率限制：
| 作業 | 範圍 | 時間範圍 (秒) | 限制 (要求數目) | 逾時 (單位秒) |
|---|---|---|---|---|
| 一般要求 | 每個資源 | 10 | 1000 | 10 |
要採取的動作
如果您需要傳送超過比率限制的訊息數量，請傳送電子郵件給我們:acs-ccap@microsoft.com。
Teams 互通性和 Microsoft Graph
使用 Teams 互通性實務範例時，您可能會使用一些 Microsoft Graph API 來建立會議。
透過 Microsoft Graph 所提供的每一個服務都有不同的限制;服務特定的限制會在這裡地更詳細地說明。
要採取的動作
實作錯誤處理時，請使用 HTTP 錯誤碼 429 來偵測用戶端節流。 失敗的回應包括 Retry-After 回應標頭。 使用 Retry-After 延遲來暫停要求，是從節流中復原的最快方式，因為 Microsoft Graph 會在用戶端處於節流狀態時持續記錄資源使用量。
您可以在 Microsoft Graph 文件中找到 Microsoft Graph 節流限制的詳細資訊。
下一步
請參閱說明及支援選項。
意見反映
即將推出：我們會在 2024 年淘汰 GitHub 問題，並以全新的意見反應系統取代並作為內容意見反應的渠道。 如需更多資訊，請參閱：https://aka.ms/ContentUserFeedback。
提交及檢視以下的意見反映：