通过直接路由接收公用电话交换网（PSTN）呼叫时，可能会遇到问题。 本文讨论其中一些问题，并提供可以尝试的解决方案。
当 Teams 从 PSTN 终结点收到呼叫时，没有回响音
此问题发生在以下方案中：
当Microsoft Teams 客户端收到呼叫时，它首先发送 SIP 180 响铃消息，然后将 SIP 183 会话进度消息与媒体产品/服务（SDP）一起发送。
根据 RFC 3261 和 RFC 3960 标准，当调用方使用的终结点收到 SIP 180 响铃消息时，它必须在本地生成铃声。 如果调用方的设备收到 SDP 的 SIP 183 会话进度消息，则它允许目标（此方案中的 Teams 客户端）在呼叫用户接受会话之前播放音频或铃声。 此类音频称为早期媒体。
但是，当某些呼叫方设备和运营商收到 SIP 183 会话进度消息时，它们会在本地停止生成铃声。 即使设备和运营商应继续生成环形音调，直到收到实际的媒体数据包，也会发生这种情况。
解决方法
若要解决此问题，必须更新会话边界控制器（SBC）配置来处理多个 SIP 18x 消息。
大多数 SBC 提供以下缓解选项之一：
- 仅转发第一条 SIP 18x 消息，并忽略后续消息，直到接听或结束呼叫。 例如，AudioCodes SBC 提供此选项。
- 从 SIP 183 会话进度消息中删除 SDP 信息，然后将消息更改为 SIP 180 响铃消息。 例如，Metaswitch SBC 提供此选项。
有关更新 SBC 中的 SIP作规则的说明，请参阅特定于 SBC 模型的文档，并联系 SBC 供应商获取其他建议选项。
有关错过呼叫的多个通知
当 Teams 收到呼叫并拒绝呼叫时，因为用户正忙或不想当时接受呼叫，PSTN 运营商或 SBC 可能会多次重试呼叫。 Teams 将每个重试的呼叫解释为单独的呼叫，并显示多个错过的呼叫通知。
出现此问题的原因是不同的通信标准（如 RFC 4497 标准和 NICC 标准 ND1017：2006/07）将相同的 SIP 响应代码映射到不同的 Q.850 原因代码。
例如，RFC 4497 将 SIP 响应代码 486 映射到 Q.850 原因代码 34，ND1017：2006/07（直接路由使用）将代码 486 映射到 Q.850 原因代码 17。 由于这种差异，使用 RFC 4497 标准的 PSTN 提供商解释 Teams 拒绝呼叫错误的原因。 因此，PSTN 提供程序多次重试呼叫。
解决方法
若要解决此问题，请将 SBC 中的 SIP作规则更新为删除映射到 SIP 响应代码 486 的 Q.850 原因代码，或将原因代码从 34 更改为 17。 有关更新 SIP作规则的说明，请参阅特定于 SBC 模型的文档。
如果更新规则无法解决问题，则可能是 SBC、通信路径中的网络设备或 PSTN 提供商在收到 SIP 4xx 响应代码后重试呼叫。 不建议使用此行为。 在这种情况下，请更新 SBC 和网络设备的配置，或要求 PSTN 提供商更新其配置，以确保他们在收到 SIP 4xx 响应以结束呼叫后不重试呼叫。
为入站呼叫显示不正确的调用方 ID （CLI）
当 Teams 收到呼叫时，它会显示 SIP INVITE 消息中标头中指定的 From 呼叫者号码。 但是，某些 PSTN 提供程序可能会使用 P-Asserted-Identity 标头而不是 From 标头来存储调用方号码。 在这种情况下，向 Teams 用户显示的信息不正确。
解决方法
若要解决此问题，请检查 PSTN 提供程序是否使用 P-Asserted-Identity 标头。 如果是这样，请将 SBC 配置为使用标头中的信息P-Asserted-Identity重写标头的内容From。
若要重写 From 标头，请参阅特定于 SBC 模型的文档以获取说明。
备注
From如果标头包含“Anonymous”作为其信息，Teams 有时会将其转换为数字并改为显示266696687。
传入呼叫被错误地标记为“垃圾邮件可能”
如果 启用了呼叫 的垃圾邮件筛选，则会检查所有传入呼叫的呼叫方 ID 并分配垃圾邮件分数。 如果呼叫方 ID 的分数高于特定阈值，Teams 将显示一条通知，指出呼叫可能是垃圾邮件。
解决方法
若要减少呼叫者的电话号码被标记为垃圾邮件的可能性，请确保以 E.164 格式提供号码。
传入呼叫未按预期阻止
将 Teams 配置为阻止来自满足预定义特定条件的调用方 ID 的调用。 但是，你继续接收来自此类电话号码的呼叫。
此问题通常是由用于筛选传入呼叫的表达式所期望的调用方 ID 格式与 SIP 消息标头中 From 调用方 ID 的格式不匹配引起的。
例如，调用方 ID 可能以国际格式指定，包括前导加号（+）符号和国际前缀。 但是，表达式仅检查以国家格式指定的数字。 这种情况也可能逆转。
解决方法
若要解决此问题，请更新用于通过添加加号（+）符号作为可选字符来检查传入调用的表达式。 此修订后的表达式涵盖多个呼叫方 ID 格式，如果使用直接路由和通话套餐，其中数字以不同的格式显示，则尤其有用。
在 Teams 中应答 PSTN 呼叫时延迟
当 Teams 从 PSTN 终结点收到呼叫时，你要么在接听呼叫时遇到延迟，要么在 Teams 接听呼叫后没有听到任何音频。
这些问题通常是由在成功连接呼叫之前在 SBC 和 SIP 代理之间发送的多个 SIP 重新邀请引起的。 这在涉及媒体旁路或本地媒体优化的情况下尤其常见，需要设计多次重新邀请。 此外，在 SBC 未在原始邀请中提供适当的媒体 IP 的情况下，SBC 必须发送具有正确信息的重新邀请。 如果 SBC 的重新邀请按错误顺序或错误的时间（从而导致争用条件），则重新邀请可能需要更长的时间才能协商。 这种情况可能会导致音频延迟。
解决方法
若要解决这些问题，请更新 SBC 配置。 确保它默认提供最有可能的媒体 IP，以最大程度地减少重新邀请的数量。 例如，如果大多数呼叫需要来自内部用户，请将 SBC 配置为首先提供内部 IP。 有关 SBC 配置的详细说明，请参阅特定于 SBC 模型的文档。
特定持续时间之后的呼叫会下降
在 Teams 中，正在进行的呼叫和仍在尝试连接的传入呼叫可能会因各种原因而中断。
根据调用的下降时间长度，尝试适用于你的方案的解决方法。
通话在大约四秒后下降
此问题通常是由连接不良或 SBC 和 SIP 代理之间存在的通信问题引起的。 例如：
- SBC 可能不会收到 SIP 100 尝试消息，因为消息被防火墙阻止或由于网络问题而未发送。
- SBC 接收 SIP 消息，但不会通过发送 SIP ACK 消息来确认它。
解决方法
若要解决此问题，请更新 SBC 和网络配置，以允许来自直接路由功能用于 SIP 信号的所有 IP 地址范围的流量。 此外，请确保 SBC 根据用于通信 SIP 信号的标准进程发送消息。
有关 SBC 配置的详细说明，请参阅特定于 SBC 模型的文档。
通话在大约 10 到 20 秒后下降
如果传入呼叫在尝试连接的 10 到 20 秒之间下降，并且没有音频，原因可能是该时间范围内未收到媒体信息或交互式连接机构（ICE）连接检查失败。 在这种情况下，Teams 将放弃呼叫。
解决方法
若要解决此问题，请确保 SBC 的 SDP 消息中包含正确的 ICE 候选项。 此外，请根据需要更新网络和防火墙配置，以确保它们可以处理来自 ICE 候选项的请求和响应。
通话在几分钟后下降
持续调用在连接后不返回错误代码，并在 10 到 60 分钟之间保持活动状态。 如果问题影响 SIP INVITE 消息标头中指定的 SESSION-EXPIRES 会话计时器或会话刷新机制，则可能会出现这种情况。 除非在结束时间之前将重新邀请发送到刷新会话，否则调用将计划在标头中指定的 SESSION-EXPIRES 时间之后结束。
在以下示例中， SESSION-EXPIRES 标头指定调用将在 1,800 秒（30 分钟）后结束：
SESSION-EXPIRES : 1800;refresher=uac
备注
- 重新邀请通常在会话计时器指定的时间点发送。
- 如果标头
uac中的参数值为refresher，发送 SIP INVITE 消息的参与方负责发送重新邀请以刷新会话。 - 如果标头
uas中的参数值为refresher，则接收 SIP INVITE 消息的参与方负责发送重新邀请以刷新会话。
解决方法
若要解决此问题，请更新 SBC 配置，以确保正确的参与方在会话计时器过期之前在适当时间发送重新邀请消息。
会话计时器问题也可能发生在呼叫的其他部分，例如通信路径中的 PSTN 运营商。 如果呼叫在 PSTN 运营商处失败，则会向 SBC 发送 SIP BYE 消息。 然后，此消息将发送到 SIP 代理，代理结束调用。 若要解决此问题，请确定 SIP BYE 消息的源，然后在源中解决问题。