Azure 通訊服務的服務限制
本文件說明 Azure Communication Services API 的限制和可能的解決方案。
節流模式和架構
當您達到服務的限制數量時，您會收到 HTTP 狀態碼 429 (太多要求)。 一般而言，以下是處理節流的最佳作法：
- 減少每個要求的作業數目。
- 減少通話的頻率。
- 避免立即做出重試，因為所有的要求都會納入使用量限制的計算。
您可以在適用於節流模式的 Azure 架構文件中找到有關如何設定服務架構以處理節流和限制的更多一般指引。 節流限制數量可透過對 Azure 支援提出要求來增加。
- 開啟 Azure 入口網站並登入。
- 選取 [說明 + 支援]。
- 按一下 [建立新的支援要求]。
- 在 [描述您的問題] 文字輸入框中，輸入
Technical，然後按一下 [Go]。 - 從 [選取服務] 下拉式功能表中，選取 [服務與訂用帳戶限制 (配額)]，然後按 [下一步]。
- 在 [問題描述] 選擇 [問題類型]、[訂用帳戶] 和 [配額類型]，然後按 [下一步]。
- 如果有的話，請檢閱任何 [建議的解決方案]，然後按 [下一步]。
- 視需要新增 [其他詳細資料]，然後按 [下一步]。
- 在 [檢閱 + 建立] 檢查資訊、視需要進行變更，然後按一下 [建立]。
您可以遵循 對 Azure 支援建立要求 的文件。
取得電話號碼
在取得一組門號 (電話號碼) 之前，請確定您的訂用帳戶符合地理和訂用帳戶的需求。 否則，您無法購買一組門號 (電話號碼)。 下列限制適用於透過電話號碼 SDK 和 Azure 入口網站中來購買門號 (電話號碼)。
| 作業 | 範圍 | 時間範圍 | 限制 (要求數目) |
|---|---|---|---|
| 購買門號 (電話號碼) | Azure 租用戶 | - | 1 |
| 搜尋門號 (電話號碼) | Azure 租用戶 | 一週 | 5 |
要採取的動作
如需詳細資訊，請參閱電話號碼類型概念頁面和電話語音概念概觀頁面。
可以透過向 Azure 支援提出要求來增加購買數量限制。
- 開啟 Azure 入口網站並登入。
- 選取 [說明 + 支援]。
- 按一下 [建立新的支援要求]。
- 在 [描述您的問題] 文字輸入框中，輸入
Technical，然後按一下 [Go]。 - 從 [選取服務] 下拉式功能表中，選取 [服務與訂用帳戶限制 (配額)]，然後按 [下一步]。
- 在 [問題描述] 選擇 [問題類型]、[訂用帳戶] 和 [配額類型]，然後按 [下一步]。
- 如果有的話，請檢閱任何 [建議的解決方案]，然後按 [下一步]。
- 視需要新增 [其他詳細資料]，然後按 [下一步]。
- 在 [檢閱 + 建立] 檢查資訊、視需要進行變更，然後按一下 [建立]。
身分識別
| 作業 | 時間範圍 (秒) | 限制 (要求數目) |
|---|---|---|
| 建立身分識別 | 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 常見問題頁面。
電子郵件
您可傳送有限數量的電子郵件訊息。 如果您超過訂用帳戶的下列限制，則會拒絕您的要求。 您可以在稍候再試時間經過後，再次嘗試這些要求。 視需要要求提高傳送數量限制，以在達到限制之前採取動作。
Azure 通訊服務 電子郵件服務的設計目的是支援高輸送量。 不過，此服務會強制初始速率限制，協助客戶順利上線，並避免切換至新電子郵件服務時可能發生的一些問題。 建議您在兩到四周內，使用 Azure 通訊服務 Email 逐漸增加您的電子郵件量，同時密切監視電子郵件的傳遞狀態。 這種漸進式增加可讓第三方電子郵件服務提供者適應網域電子郵件流量 IP 的變更，從而保護您的寄件者信譽，並維護電子郵件傳遞的可靠性。
我們會根據使用案例需求、網域信譽、流量模式和失敗率，核准更高的客戶限制。 若要要求更高的限制，請遵循電子郵件網域配額增加中的指示。 請注意，較高的配額僅適用於已驗證的自定義網域，而不是 Azure 受控網域。
速率限制
| 作業 | 範圍 | 時間範圍 (分鐘) | 限制 (電子郵件數目) |
|---|---|---|---|
| 傳送電子郵件 | 每個訂用帳戶 | 1 | 30 |
| 傳送電子郵件 | 每個訂用帳戶 | 60 | 100 |
| 取得電子郵件狀態 | 每個訂用帳戶 | 1 | 60 |
| 取得電子郵件狀態 | 每個訂用帳戶 | 60 | 200 |
| 作業 | 範圍 | 時間範圍 (分鐘) | 限制 (電子郵件數目) |
|---|---|---|---|
| 傳送電子郵件 | 每個訂用帳戶 | 1 | 5 |
| 傳送電子郵件 | 每個訂用帳戶 | 60 | 10 |
| 取得電子郵件狀態 | 每個訂用帳戶 | 1 | 10 |
| 取得電子郵件狀態 | 每個訂用帳戶 | 60 | 20 |
大小限制
| 名稱 | 限制 |
|---|---|
| 電子郵件中的收件者數目 | 50 |
| 電子郵件要求大小總計 (包括附件) | 10 MB |
對於所有訊息大小限制，您需要考慮 base64 編碼會增加訊息的大小。 您需要增加大小值，以應對訊息附件和任何其他二進位資料進行 Base64 編碼後訊息大小增加的情況。 Base64 編碼會使訊息大小增加約 33%，因此訊息大小比編碼前的訊息大小約大 33%。 例如，如果您指定的最大訊息大小值為約 10 MB，則可以預期實際的最大訊息大小值約為 7.5 MB。
傳送大於 10 MB 的附件
若要傳送高達 30 MB 的電子郵件檔案附件，請完成支援要求。
如果您需要傳送大於 30 MB 的電子郵件檔案附件，您可使用此替代解決方案。 將檔案儲存在 Azure Blob 儲存體帳戶中，並在電子郵件中包含檔案的連結。 您可使用共用存取簽章 (SAS) 來保護檔案。 SAS 提供儲存體帳戶中資源的安全委派存取權。 您可使用 SAS 來精確控制用戶端存取資料的方式。
使用 Azure Blob 儲存體帳戶的優點：
- 您可處理大規模的檔案。
- 您可使用 SAS 金鑰來精確管理檔案存取。
如需詳細資訊，請參閱
要採取的動作
若要增加電子郵件配額，請遵循增加電子郵件網域配額中的指示。
注意
電子郵件配額增加要求最多可能需要 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 |
|---|---|---|
| 您可以同時傳送的最大傳出本機串流數目 | 一支影片或一個螢幕共用 | 一支影片 + 一個螢幕共用 |
| 您可以同時轉譯呈現的最大傳入遠端串流數目 | 九支影片 + 一個螢幕共用 | 九支影片 + 一個螢幕共用 |
通話 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 節流限制的詳細資訊。
下一步
請參閱說明及支援選項。