Azure 通訊服務的服務限制
本文說明 Azure 通訊服務 API 和可能解決方式的限制。
節流模式和架構
當您達到服務限制時,您會收到 HTTP 狀態代碼 429 (要求太多)。 一般而言,下列最佳做法用於節流:
- 減少每個要求的作業數目。
- 減少通話的頻率。
- 避免立即做出重試,因為所有的要求都會納入使用量限制的計算。
如需如何設定服務架構以處理節流模式的 Azure 架構檔中的節流和限制,請尋找更多一般指引。 若要增加節流限制,請向 Azure 支援提出要求。
- 開啟 Azure 入口網站並登入。
- 選取 [說明 + 支援]。
- 選取 [ 建立新的支援要求]。
- 在 [ 描述問題] 文本框中,輸入 Technical,然後選取 [ Go]。
- 從 [ 選取服務 ] 下拉功能表中,選取 [服務與訂用帳戶限制],然後選取 [ 下一步]。
- 在 [問題描述] 中,選擇 [問題類型]、[訂用帳戶] 和 [配額類型] 值,然後選取 [下一步]。
- 如果有的話,請檢閱任何建議的解決方案,然後選取 [ 下一步]。
- 視需要新增其他詳細數據,然後選取 [ 下一步]。
- 在 [檢閱 + 建立] 中,檢查資訊、視需要進行變更,然後選取 [ 建立]。
請遵循步驟向 Azure 支援提出要求。
取得電話號碼
取得電話號碼之前,請確定您的訂用帳戶符合 地理和訂用帳戶 需求。 否則,您無法購買一組門號 (電話號碼)。 下列限制適用於透過電話號碼 SDK 和 Azure 入口網站 購買號碼。
作業 | 範圍 | 時間範圍 | 限制 (要求數目) |
---|---|---|---|
購買門號 (電話號碼) | Azure 租用戶 | - | 1 |
搜尋門號 (電話號碼) | Azure 租用戶 | 一週 | 5 |
要採取的動作
若要增加購買數量限制,請向 Azure 支援提出要求。
- 開啟 Azure 入口網站並登入。
- 選取 [說明 + 支援]。
- 選取 [ 建立新的支援要求]。
- 在 [ 描述問題] 文本框中,輸入 Technical,然後選取 [ Go]。
- 從 [ 選取服務 ] 下拉功能表中,選取 [服務與訂用帳戶限制],然後選取 [ 下一步]。
- 在 [問題描述] 中,選擇 [問題類型]、[訂用帳戶] 和 [配額類型] 值,然後選取 [下一步]。
- 如果可用,請檢閱任何建議的解決方案,然後選取 [ 下一步]。
- 視需要新增更多詳細數據,然後選取 [ 下一步]。
- 在 [檢閱 + 建立] 中檢查資訊、視需要進行變更,然後選取 [ 建立]。
身分識別
作業 | 時間範圍(秒) | 限制 (要求數目) |
---|---|---|
建立身分識別 | 30 | 1,000 |
刪除身分識別 | 30 | 500 |
核發存取權杖 | 30 | 1,000 |
撤銷存取權杖 | 30 | 500 |
createUserAndToken |
30 | 1,000 |
exchangeTokens |
30 | 500 |
要採取的動作
建議您先取得身分識別和令牌,再建立聊天線程或開始呼叫。 例如,當網頁載入或應用程式啟動時,請執行這項工作。
如需詳細資訊,請參閱驗證至 Azure 通訊服務。
SMS
當您傳送或接收大量訊息時,您可能會收到 429
錯誤。 此錯誤表示您即將達到服務限制。 您的訊息會排入佇列,並在要求數目低於閾值之後傳送。
SMS 的速率限制:
作業 | 數字類型 | 範圍 | 時間範圍 | 限制 (要求號碼) | 每分鐘的訊息單位 |
---|---|---|---|---|---|
傳送訊息 | 免付費 | 每個數位 | 60 | 200 | 200 |
傳送訊息 | 簡短代碼 | 每個數位 | 60 | 6000 | 6000 |
傳送訊息 | 英數字元傳送者識別碼 | 每項資源 | 60 | 600 | 600 |
要採取的動作
如果您有超過速率限制的需求,請向 Azure 支援提交要求,以啟用更高的輸送量。
如需 SMS SDK 和服務的詳細資訊,請參閱 SMS SDK 概觀 或 SMS 常見問題。
電子郵件
您可傳送有限數量的電子郵件訊息。 如果您超過 訂用帳戶的電子郵件速率限制 ,則會拒絕您的要求。 您可以在稍候再試時間經過後,再次嘗試這些要求。 視需要要求提高傳送數量限制,以在達到限制之前採取動作。
Azure 通訊服務 電子郵件服務的設計目的是支援高輸送量。 不過,此服務會強制初始速率限制,協助客戶順利上線,並避免切換至新電子郵件服務時可能發生的一些問題。
建議您在兩到四周內逐步增加電子郵件數量,並使用 Azure 通訊服務 Email,同時密切監視電子郵件的傳遞狀態。 此漸進式增加可讓第三方電子郵件服務提供者適應網域電子郵件流量的IP變更。 漸進式變更可讓您有時間保護您的寄件人信譽,並維護電子郵件傳遞的可靠性。
Azure 通訊服務 電子郵件服務每小時最多可支援 1-200 萬封郵件。 您可以根據數個因素來啟用高輸送量,包括:
- 客戶尖峰流量
- 商務需求
- 管理失敗率的能力
- 網域聲譽
失敗率需求
若要啟用高電子郵件配額,您的電子郵件失敗率必須小於 1% (1%)。 如果您的失敗率很高,您必須先解決問題,才能要求增加配額。 客戶預期會主動監視其失敗率。
如果失敗率在配額增加後增加,Azure 通訊服務 會連絡客戶,以立即採取行動和解決時程表。 在極端情況下,如果未在指定的時間軸內管理失敗率,Azure 通訊服務 可能會降低或暫停服務,直到問題解決為止。
相關文章
Azure 通訊服務 提供豐富的記錄和分析,以協助監視和管理失敗率。 如需詳細資訊,請參閱下列文章:
- 改善 Azure 通訊服務 電子郵件中的寄件人信譽
- Email Insights
- 透過 Azure 監視器中的診斷設定啟用記錄
- 快速入門:處理電子郵件事件
- 快速入門:使用管理客戶端連結庫管理 Azure 通訊服務 中的網域隱藏清單
注意
若要要求更高的限制,請遵循電子郵件網域配額增加中的指示。 較高的配額僅適用於已驗證的自定義網域,而非 Azure 受控網域。
電子郵件的速率限制
作業 | 範圍 | 時間範圍 (分鐘) | 限制 (電子郵件數目) | 可用的限制較高 |
---|---|---|---|---|
傳送電子郵件 | 每個訂用帳戶 | 1 | 30 | Yes |
傳送電子郵件 | 每個訂用帳戶 | 60 | 100 | Yes |
取得電子郵件狀態 | 每個訂用帳戶 | 1 | 60 | Yes |
取得電子郵件狀態 | 每個訂用帳戶 | 60 | 200 | Yes |
作業 | 範圍 | 時間範圍 (分鐘) | 限制 (電子郵件數目) | 可用的限制較高 |
---|---|---|---|---|
傳送電子郵件 | 每個訂用帳戶 | 1 | 5 | No |
傳送電子郵件 | 每個訂用帳戶 | 60 | 10 | No |
取得電子郵件狀態 | 每個訂用帳戶 | 1 | 10 | No |
取得電子郵件狀態 | 每個訂用帳戶 | 60 | 20 | No |
電子郵件的大小限制
名稱 | 限制 |
---|---|
電子郵件中的收件者數目 | 50 |
電子郵件要求大小總計 (包括附件) | 10 MB |
每個訂用帳戶的已驗證連線上限 | 250 |
針對所有訊息大小限制,請考慮Base64編碼會增加訊息的大小。 您需要增加大小值,以應對訊息附件和任何其他二進位資料進行 Base64 編碼後訊息大小增加的情況。 Base64 編碼會使訊息大小增加約 33%,因此訊息大小比編碼前的訊息大小約大 33%。 例如,如果您指定訊息大小上限值大約 10 MB,您可以預期訊息大小上限大約為 7.5 MB。
傳送大於 10 MB 的附件
若要傳送最多 30 MB 的電子郵件檔附件,請提出 支援要求。
如果您需要傳送大於 30 MB 的電子郵件檔附件,請使用此替代解決方案。 將檔案儲存在 Azure Blob 儲存體帳戶中,並在電子郵件中包含檔案的連結。 您可以使用共用存取簽章來保護檔案 (SAS)。 SAS 提供儲存體帳戶中資源的安全委派存取權。 藉由使用 SAS,您可以更細微地控制用戶端如何存取您的數據。
使用 Blob 記憶體帳戶的優點:
- 您可以處理大規模的檔案。
- 您可以使用 SAS 或金鑰來精確管理檔案存取。
如需詳細資訊,請參閱
要採取的動作
若要增加電子郵件配額,請遵循電子郵件網域配額增加中的指示。
注意
電子郵件配額增加要求最多可能需要 72 小時才能進行評估和核准,尤其是針對週五下午提出的要求。
聊天
Azure 通訊服務 支援聊天。
聊天的大小限制
名稱 | 限制 |
---|---|
電子郵件討論串中的參與者數目 | 250 |
參與者批次: CreateThread |
200 |
參與者批次: AddParticipant |
200 |
頁面大小: ListMessages |
200 |
訊息大小 | 28 KB |
每個 Azure Bot Service 的 Azure 通訊服務 資源數目 | 1,000 |
聊天的速率限制
作業 | 範圍 | 每 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 天內開啟支援票證,以便我們協助您。
語音和視訊呼叫
Azure 通訊服務 支援語音和視訊通話。
PSTN 通話限制
名稱 | 範圍 | 限制 |
---|---|---|
撥出並行通話的預設數目 | 每個數位 | 2 |
注意
輸入並行呼叫沒有限制。 您也可以將要求提交至 Azure 支援 ,以增加輸出並行呼叫的限制。 我們的審查小組會檢閱所有要求。
通話最大限制量
名稱 | 限制 |
---|---|
參與者數 | 350 |
通話 SDK 串流支援
Azure 通訊服務的通話 SDK 支援下列串流設定:
限制 | Web | Windows/Android/iOS |
---|---|---|
您可以同時傳送的傳出本機數據流數目上限。 | 一個視訊或一個屏幕共用 | 一個影片 + 一個螢幕共用 |
您可以同時轉譯的傳入遠端資料流數目上限。 | 九個影片 + 一個螢幕共用 | 九個影片 + 一個螢幕共用 |
通話 SDK 不會強制執行這些限制,但如果您超過這些限制,您的使用者可能會遇到效能降低的情況。
通話 SDK 逾時
下列逾時適用於 Azure 通訊服務 呼叫 SDK:
動作 | 逾時 (單位秒) |
---|---|
重新連線或移除參與者。 | 120 |
從呼叫新增或移除新形式。 (啟動或停止視訊或屏幕共用。) | 40 |
通話轉移作業逾時。 | 60 |
1:1 通話建立逾時。 | 85 |
群組通話建立逾時。 | 85 |
PSTN 通話建立逾時。 | 115 |
將 1:1 通話升級為群組通話逾時。 | 115 |
要採取的動作
如需語音和視訊通話 SDK 和服務的詳細資訊,請參閱 SDK 概觀 或 SDK 和 API 中的已知問題。 您也可以將要求提交至 Azure 支援 ,以增加一些限制。 我們的審查小組會檢閱所有要求。
工作路由器
當您傳送或接收大量要求時,您可能會收到 ThrottleLimitExceededException
錯誤。 此錯誤表示您達到服務限制。 您的要求會失敗,直到用來處理要求的令牌貯體會在一段特定時間後補足。
作業路由器的速率限制
作業 | 範圍 | 時間範圍(秒) | 限制 (要求數目) | 逾時 (單位秒) |
---|---|---|---|---|
一般要求 | 每項資源 | 10 | 1,000 | 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 節流限制的詳細資訊。