Azure 通訊服務的服務限制
本文件說明 Azure 通訊服務 API 和可能解決方式的限制。
節流模式和架構
當您達到服務限制時，您會收到 HTTP 狀態代碼 429 （要求太多）。 一般而言，以下是處理節流的最佳作法：
- 減少每個要求的作業數目。
- 減少呼叫的頻率。
- 避免立即重試，因為所有要求都會因使用限制而累算。
如需如何設定服務架構以處理節流模式的 Azure 架構檔中的節流和限制，您可以找到更多一般指引。 您可以透過對 Azure 支援的要求來增加節流限制。
- 前往 Azure 入口網站
- 選取 [說明+支援]
- 按兩下 [建立新的支援要求]
- 在 [問題描述] 中，選擇 [問題類型 ] 作為 [技術 ]，並在詳細數據中新增 。
您可以遵循檔來 建立對 Azure 支援的要求。
取得電話號碼
取得電話號碼之前，請確定您的訂用帳戶符合 地理和訂用帳戶 需求。 否則，您無法購買電話號碼。 下列限制適用於透過 電話 Numbers 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 常見問題 頁面。
電子郵件
您可以傳送的電子郵件訊息數目有限制。 如果您超過訂用帳戶的下列限制，您的要求將會遭到拒絕。 您可以在經過 Retry-After 時間之後，再次嘗試這些要求。 請採取必要的動作，並要求視需要提高傳送磁碟區限制。
速率限制
| 作業 | 範圍 | 時間範圍（分鐘） | 限制 （電子郵件數目） |
|---|---|---|---|
| 傳送電子郵件 | 每個訂用帳戶 | 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 通訊服務 會無限期地儲存聊天訊息，直到客戶刪除為止。
從 CY24 Q1 開始，客戶必須在 90 天后選擇無限期的郵件保留或自動刪除。 現有的訊息不會受到影響，但客戶可以視需要選擇90天的保留期間。
注意
系統無法復原意外刪除的訊息。
語音和視訊呼叫
PSTN 通話限制
| 名稱 | 範圍 | 限制 |
|---|---|---|
| 輸出並行呼叫的預設數目 | 每個數位 | 2 |
呼叫最大限制
| 名稱 | 限制 |
|---|---|
| 參與者數目 | 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 概觀 頁面或 已知問題。
作業路由器
傳送或接收大量要求時，您可能會收到 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 節流限制的詳細資訊。
網路周遊
| 作業 | 時間範圍（秒） | 限制 （要求數目） |
|---|---|---|
| 問題 TURN 認證 | 5 | 30000 |
| 問題轉寄組態 | 5 | 30000 |
要採取的動作
建議您先取得令牌，再啟動其他交易，例如建立轉寄連線。
如需詳細資訊，請參閱 網路周遊概念概觀 頁面。
下一步
請參閱說明和支援選項。