你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure 通信服务的服务限制
本文档介绍 Azure 通信服务 API 的限制和可能的解决方案。
限制模式和体系结构
当达到服务限制时，你会收到 HTTP 状态代码 429（请求过多）。 通常，以下是处理限制的最佳实践：
- 减少每个请求的操作数。
- 降低调用频率。
- 避免立即重试，因为所有请求都根据使用限制产生累积。
可以在限制模式的 Azure 体系结构文档中找到有关如何设置服务体系结构以处理限制的更多常规指南。 可以通过对 Azure 支持的请求提高带宽限制。
- 转到 Azure 门户并登录。
- 选择“帮助+支持”。
- 单击新建支持请求。
- 在“描述问题”文本框中，输入
Technical，然后单击“转到”。 - 在“选择服务”下拉菜单中，选择“服务和订阅限制（配额）”，然后单击“下一步”。
- 在问题说明中，选择问题类型、订阅以及配额类型，然后单击“下一步”。
- 查看任何建议的解决方案（如果可用），然后单击 下一步”。
- 根据需要添加其他详细信息，然后单击“下一步”。
- 在“查看 + 创建”中检查信息，根据需要进行更改，然后单击“创建”。
可以按照有关创建面向 Azure 支持的请求的文档进行操作。
获取电话号码
在获取电话号码之前，请确保订阅满足地理位置和订阅要求。 否则无法购买电话号码。 以下限制适用于通过电话号码 SDK 和 Azure 门户购买号码。
| 操作 | 范围 | 时间范围 | 限制（请求数） |
|---|---|---|---|
| 购买电话号码 | Azure 租户 | - | 1 |
| 搜索电话号码 | Azure 租户 | 一周 | 5 |
采取的操作
有关详细信息，请参阅电话号码类型概念页和电话服务概念概述页。
可以通过向 Azure 支持部门提交请求来提高购买数量限制。
- 转到 Azure 门户并登录。
- 选择“帮助+支持”。
- 单击新建支持请求。
- 在“描述问题”文本框中，输入
Technical，然后单击“转到”。 - 在“选择服务”下拉菜单中，选择“服务和订阅限制（配额）”，然后单击“下一步”。
- 在问题说明中，选择问题类型、订阅以及配额类型，然后单击“下一步”。
- 查看任何建议的解决方案（如果可用），然后单击 下一步”。
- 根据需要添加其他详细信息，然后单击“下一步”。
- 在“查看 + 创建”中检查信息，根据需要进行更改，然后单击“创建”。
标识
| 操作 | 时间范围（秒） | 限制（请求数） |
|---|---|---|
| 创建标识 | 30 | 1000 |
| 删除标识 | 30 | 500 |
| 颁发访问令牌 | 30 | 1000 |
| 撤销访问令牌 | 30 | 500 |
| createUserAndToken | 30 | 1000 |
| exchangeTokens | 30 | 500 |
采取的操作
建议在创建聊天线程或开始调用之前获取标识和令牌。 例如，当网页加载或应用程序启动时。
有关详细信息，请参阅标识概念概述页。
短信
发送或接收大量消息时，可能会收到 429 错误。 此错误表示即将达到服务限制，请求数低于阈值后，消息将排队等待发送。
文本消息的速率限制
| 操作 | 号码类型 | 范围 | 时间范围（秒） | 限制（请求数） | 每分钟请求单位数 |
|---|---|---|---|---|---|
| 发送消息 | 免费电话 | 按号码 | 60 | 200 | 200 |
| 发送消息 | 短代码 | 按号码 | 60 | 6000 | 6000 |
| 发送消息 | 字母数字发件人 ID | 按资源 | 60 | 600 | 600 |
采取的操作
如果你的需求超出了速率限制，请向 Azure 支持提交请求，以启用更高的吞吐量。
有关 SMS SDK 和服务的详细信息，请参阅 SMS SDK 概述页或 SMS 常见问题解答页。
电子邮件
你可以发送有限数量的电子邮件。 如果超出订阅的电子邮件速率限制，你的请求将被拒绝。 在“Retry-After”时间过后，可以尝试重新发起这些请求。 如果需要，请在达到限制之前采取行动，请求提高你的发送量上限。
Azure 通信服务中的电子邮件服务旨在支持高吞吐量。 但是，该服务会施加初始速率限制，以帮助客户顺利加入进来，并避免切换到新电子邮件服务时可能出现的一些问题。
建议在两到四周内逐步增加使用 Azure 通信服务的电子邮件服务处理的电子邮件量，同时密切监视电子邮件的传递状态。 这种逐步增加的方式可让第三方电子邮件服务提供商适应域中电子邮件流量的 IP 变化。 循序渐进的变化让你有时间保护发件人信誉，并维护电子邮件传递的可靠性。
Azure 通信服务电子邮件服务支持每小时最多 100-200 万封邮件。 可以根据以下几个因素启用高吞吐量，包括：
- 客户高峰流量
- 业务需求
- 能够管理失败率
- 域声誉
失败率要求
若要启用高电子邮件配额，电子邮件失败率必须小于 1%。 如果失败率很高，则必须在请求增加配额之前解决问题。 客户应主动监视其失败率。
如果在增加配额后失败率增加，Azure 通信服务将联系客户立即采取行动，确定解决时间线。 在极端情况下，如果在指定的时间线内未管理失败率，Azure 通信服务可能会减少或暂停服务，直到问题得到解决。
相关文章
Azure 通信服务提供丰富的日志和分析来帮助监视和管理失败率。 有关详细信息，请参阅以下文章：
- 提高发件人在 Azure 通信服务电子邮件中的信誉
- Email Insights
- 在 Azure Monitor 中通过诊断设置启用日志
- 快速入门：处理电子邮件事件
- 快速入门：使用管理客户端库管理 Azure 通信服务中的域抑制列表
注意
若要请求更高的限制，请按照电子邮件域的配额提升中的说明进行操作。 更高的配额仅适用于经过验证的自定义域，而不适用于 Azure 托管域。
电子邮件的速率限制
| 操作 | 范围 | 时间范围（分钟） | 限制（电子邮件数目） |
|---|---|---|---|
| 发送电子邮件 | 每个订阅 | 1 | 30 |
| 发送电子邮件 | 每个订阅 | 60 | 100 |
| 获取电子邮件状态 | 每个订阅 | 1 | 60 |
| 获取电子邮件状态 | 每个订阅 | 60 | 200 |
| 操作 | 范围 | 时间范围（分钟） | 限制（电子邮件数目） |
|---|---|---|---|
| 发送电子邮件 | 每个订阅 | 1 | 5 |
| 发送电子邮件 | 每个订阅 | 60 | 10 |
| 获取电子邮件状态 | 每个订阅 | 1 | 10 |
| 获取电子邮件状态 | 每个订阅 | 60 | 20 |
电子邮件的大小限制
| Name | 限制 |
|---|---|
| 电子邮件中的收件人数 | 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 可以精细控制客户端访问数据的方式。
使用 Azure Blob 存储帐户的好处：
- 可以处理大型文件。
- 可以使用 SAS 密钥精确管理文件访问。
有关详细信息，请参阅：
采取的操作
若要提升电子邮件配额，请按照电子邮件域的配额提升中的说明进行操作。
注意
电子邮件配额增加请求可能需要最多 72 小时才能得到评估和批准，尤其是周五下午收到的请求。
聊天
聊天的大小限制
| Name | 限制 |
|---|---|
| 线程中的参与者数 | 250 |
| 参与者批处理 - CreateThread | 200 |
| 参与者批处理 - AddParticipant | 200 |
| 页面大小 - ListMessages | 200 |
| 消息大小 | 28 KB |
| 每个 Azure 机器人的 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 通话限制
| Name | 范围 | 限制 |
|---|---|---|
| 默认并发外呼*数量 | 每个号码 | 2 |
注意
* 并发拨入呼叫没有数量限制。 还可以向 Azure 支持部门提交请求，请求提升出站并发呼叫上限，审核团队会审查该请求。
呼叫最大限制
| Name | 限制 |
|---|---|
| 参与者数 | 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 限制的详细信息。
后续步骤
请参阅帮助和支持选项。