直接路由-SIP 协议Direct Routing - SIP protocol

本文介绍直接路由如何实现会话初始协议(SIP)。This article describes how Direct Routing implements the Session Initiation Protocol (SIP). 若要正确路由会话边界控制器(SBC)和 SIP 代理之间的流量,某些 SIP 参数必须具有特定值。To properly route traffic between a Session Border Controller (SBC) and the SIP proxy, some SIP parameters must have specific values. 本文面向负责配置本地 SBC 和 SIP 代理服务之间的连接的语音管理员。This article is intended for voice administrators who are responsible for configuring the connection between the on-premises SBC and the SIP proxy service.

处理传入请求:查找租户和用户Processing the incoming request: finding the tenant and user

在传入呼叫中,SIP 代理需要找到呼叫指向的租户,并在此租户内找到特定用户。On an incoming call, the SIP proxy needs to find the tenant to which the call is destined and find the specific user within this tenant. 租户管理员可以在多个租户中配置非已完成号码(例如 + 1001)。The tenant administrator might configure non-DID numbers, for example +1001, in multiple tenants. 因此,查找要在其上执行数字查找的特定租户非常重要,因为在多个 Microsoft 365 或 Office 365 组织中的非数字可能相同。Therefore, it is important to find the specific tenant on which to perform the number lookup because the non-DID numbers might be the same in multiple Microsoft 365 or Office 365 organizations.

本部分介绍 SIP 代理如何查找租户和用户,并对传入连接执行 SBC 身份验证。This section describes how the SIP proxy finds the tenant and the user, and performs authentication of the SBC on the incoming connection.

下面是一个传入呼叫的 SIP 邀请消息的示例:The following is an example of the SIP Invite message on an incoming call:

参数名称Parameter name 值的示例Example of the value
请求 URIRequest-URI 邀请 sip:+18338006777@sip.pstnhub.microsoft.com SIP/2。0INVITE sip:+18338006777@sip.pstnhub.microsoft.com SIP /2.0
通过页眉Via Header Via: SIP/2.0/TLS sbc1 biz: 5058; alias; branch = z9hG4bKac2121518978Via: SIP/2.0/TLS sbc1.adatum.biz:5058;alias;branch=z9hG4bKac2121518978
最大转发标题Max-Forwards header 最大转发:68Max-Forwards:68
从页眉From Header 来自以下内容的页眉: <sip: 7168712781@sbc1 biz; transport = udp; tag = 1c747237679From Header From: sip:7168712781@sbc1.adatum.biz;transport=udp;tag=1c747237679</span
到页眉To Header 收件人: sip:+183338006777@sbc1.adatum.bizTo: sip:+183338006777@sbc1.adatum.biz
CSeq 标头CSeq header CSeq:1个邀请CSeq: 1 INVITE
联系人页眉Contact Header 联系: <sip: 68712781@sbc1 biz: 5058; transport = tls>Contact: <sip: 68712781@sbc1.adatum.biz:5058;transport=tls>

收到邀请后,SIP 代理执行以下步骤:On receiving the invite, the SIP proxy performs the following steps:

  1. 检查证书。Check the certificate. 在初始连接中,直接路由服务获取在联系人标头中显示的 FQDN 名称,并将其与所显示的证书的公用名或使用者备用名称相匹配。On the initial connection, the Direct Routing service takes the FQDN name presented in the Contact header and matches it to the Common Name or Subject Alternative name of the presented certificate. SBC 名称必须匹配以下选项之一:The SBC name must match one of the following options:

    • 选项 1.Option 1. 在联系人标题中显示的完整 FQDN 名称必须与所显示的证书的通用名称/使用者备用名称相匹配。The full FQDN name presented in the Contact header must match the Common Name/Subject Alternative name of the presented certificate.

    • 选项 2.Option 2. 在联系人标题中显示的 FQDN 名称的域部分(例如 FQDN 名称 sbc1.adatum.biz 的 adatum.biz)必须与公用名称/使用者可选名称(例如 *. adatum.biz)中的通配符相匹配。The domain portion of the FQDN name presented in the Contact header (for example adatum.biz of the FQDN name sbc1.adatum.biz) must match the wildcard value in Common Name/Subject Alternative Name (for example *.adatum.biz).

  2. 尝试使用在联系人标题中显示的完整 FQDN 名称查找租户。Try to find a tenant using the full FQDN name presented in the Contact header.

    检查联系人标题(sbc1.adatum.biz)中的 FQDN 名称是否注册为任何 Microsoft 365 或 Office 365 组织中的 DNS 名称。Check if the FQDN name from the Contact header (sbc1.adatum.biz) is registered as a DNS name in any Microsoft 365 or Office 365 organization. 如果找到,将在具有注册为域名的 SBC FQDN 的租户中执行用户查找。If found, the lookup of the user is performed in the tenant that has the SBC FQDN registered as a Domain name. 如果未找到,则应用步骤3。If not found, Step 3 applies.

  3. 步骤3仅适用于步骤2失败的情况。Step 3 only applies if Step 2 failed.

    从 FQDN 中删除主机部分,显示在联系人标头(FQDN: sbc12.adatum.biz 中,删除主机部分后: adatum.biz),然后检查此名称是否注册为任何 Microsoft 365 或 Office 365 组织中的 DNS 名称。Remove the host portion from the FQDN, presented in the Contact header (FQDN: sbc12.adatum.biz, after removing the host portion: adatum.biz), and check if this name is registered as a DNS name in any Microsoft 365 or Office 365 organization. 如果找到,将在此租户中执行用户查找。If found, the user lookup is performed in this tenant. 如果找不到,调用将失败。If not found, the call fails.

  4. 使用请求 URI 中显示的电话号码,在步骤2或3中发现的租户内执行反向号码查找。Using the phone number presented in the Request-URI, perform the reverse number lookup within the tenant found in Step 2 or 3. 将所提供的电话号码与上一步中找到的租户内的用户 SIP URI 相匹配。Match the presented phone number to a user SIP URI within the tenant found on the previous step.

  5. 应用干线设置。Apply trunk settings. 查找由租户管理员为此 SBC 设置的参数。Find the parameters set by the tenant admin for this SBC.

    Microsoft 不支持在 Microsoft SIP 代理和成对的 SBC 之间拥有第三方 SIP 代理或用户代理服务器,这可能会修改成对的 SBC 创建的请求 URI。Microsoft does not support having a third-party SIP proxy or User Agent Server between the Microsoft SIP proxy and the paired SBC, which might modify the Request URI created by the paired SBC.

    本文稍后部分将介绍两个查找(步骤2和3)所需的情况(步骤2和步骤3)。The requirements for the two lookups (steps 2 and 3) needed for the scenario where one SBC is interconnected to many tenants (carrier scenario) are covered later in this article.

联系人标题和请求 URI 的详细要求Detailed requirements for Contact header and Request-URI

联系人页眉Contact header

对于所有传入的 Microsoft SIP 代理呼叫,联系人头必须在 URI 主机名中具有成对的 SBC FQDN,如下所示:For all incoming calls to the Microsoft SIP proxy, the Contact header must have the paired SBC FQDN in the URI hostname as follows:

语法: Contact: <sip: SBC 的电话或 sip address@FQDN; 传输 = tls>Syntax: Contact: <sip:phone or sip address@FQDN of the SBC;transport=tls>

此名称还必须位于所显示的证书的 "公用名" 或 "主题备用名称" 字段中。This name must also be in the Common Name or Subject Alternative name field(s) of the presented certificate. Microsoft 支持在证书的 "公用名" 或 "主题备用名称" 字段中使用名称的通配符。Microsoft supports using wildcard values of the name(s) in the Common Name or Subject Alternative Name fields of the certificate.

RFC 2818 的第3.1 节中介绍了对通配符的支持。The support for wildcards is described in RFC 2818, section 3.1. 具体地说Specifically:

"名称可以包含通配符, * 该字符被视为匹配任何单个域名组件或组件片段。例如, * a.com 匹配 foo.a.com,而不是 bar.foo.a.com * 匹配 foo.com,而不是 bar.com。 ""Names may contain the wildcard character * which is considered to match any single domain name component or component fragment. E.g., *.a.com matches foo.a.com but not bar.foo.a.com. f*.com matches foo.com but not bar.com."

如果由 SBC 发送 SIP 消息中显示的联系人标头中的多个值,则仅使用联系人标头第一个值的 FQDN 部分。If more than one value in the Contact header presented in a SIP message is sent by the SBC, only the FQDN portion of the first value of the Contact header is used.

请求 URIRequest-URI

对于所有传入呼叫,请求 URI 用于匹配用户的电话号码。For all incoming calls, the Request-URI is used to match the phone number to a user.

当前电话号码必须包含加号(+),如以下示例中所示。Currently The phone number must contain a plus sign (+) as shown in the following example.

INVITE sip:+18338006777@sip.pstnhub.microsoft.com SIP /2.0

联系人和记录-路线标题注意事项Contact and Record-Route headers considerations

SIP 代理需要为新的对话客户端事务(如再见或重新邀请)和答复 SIP 选项计算下一个跃点 FQDN。The SIP proxy needs to calculate the next hop FQDN for new in-dialog client transactions (for example Bye or Re-Invite), and when replying to SIP Options. 使用 "联系人" 或 "记录"-路线。Either Contact or Record-Route are used.

根据 RFC 3261,任何可能导致新对话的请求都需要联系人标题。According to RFC 3261, Contact header is required in any request that can result in a new dialog. 仅当代理希望在对话框中保留未来请求的路径时,才需要记录路由。The Record-Route is only required if a proxy wants to stay on the path of future requests in a dialog. 如果代理 SBC 与用于直接路由的本地媒体优化一起使用,则需要配置记录路由,因为代理 sbc 需要保留在路由中。If a proxy SBC is in use with Local Media Optimization for Direct Routing, a record route will need to be configured as the proxy SBC needs to stay in the route.

如果未使用代理 SBC,Microsoft 建议仅使用联系人标头:Microsoft recommends using only Contact header if a proxy SBC is not used:

  • 在每个 RFC 3261 中,如果代理希望在对话框中保留未来请求的路径,并且在 Microsoft SIP 代理和成对的 SBC 之间进行所有通信时,这不是必需的,则使用记录路由。Per RFC 3261, Record-Route is used if a proxy wants to stay on the path of future requests in a dialog, which is not essential if no proxy SBC is configured as all traffic goes between the Microsoft SIP proxy and the paired SBC.

  • Microsoft SIP 代理仅使用联系人头(而不是记录路由)来确定发送出站 ping 选项时的下一跃点。The Microsoft SIP proxy uses only Contact header (not Record-Route) to determine the next hop when sending outbound ping Options. 如果代理 SBC 未使用,则仅配置一个参数(联系人),而不是两个(联系人和记录路由)可简化管理。Configuring only one parameter (Contact) instead of two (Contact and Record-Route) simplifies the administration if a proxy SBC is not in use.

要计算下一跃点,SIP 代理使用:To calculate the next hop, the SIP proxy uses:

  • 优先级1。Priority 1. 顶层记录-路由。Top-level Record-Route. 如果顶级记录路由包含 FQDN 名称或 IP,则 FQDN 名称或 IP 用于创建出站内置对话连接。If the top-level Record-Route contains the FQDN name or IP, the FQDN name or IP is used to make the outbound in-dialog connection.

  • 优先级2。Priority 2. 联系人标题。Contact header. 如果记录路径不存在,SIP 代理将查找联系人标头的值以建立出站连接。If Record-Route does not exist, the SIP proxy will look up the value of the Contact header to make the outbound connection. (这是推荐的配置。)(This is the recommended configuration.)

如果同时使用了联系人和记录路线,则 SBC 管理员必须保持其值相同,从而导致管理开销。If both Contact and Record-Route are used, the SBC administrator must keep their values identical, which causes administrative overhead.

在联系人或记录中使用 FQDN 名称-路由Use of FQDN name in Contact or Record-Route

在记录-路由或联系人中不支持使用 IP 地址。Use of an IP address is not supported in either Record-Route or Contact. 唯一支持的选项是 FQDN,它必须与 SBC 证书的公用名称或使用者备用名称匹配(证书中的通配符受支持)。The only supported option is an FQDN, which must match either the Common Name or Subject Alternative Name of the SBC certificate (wildcard values in the certificate are supported).

  • 如果 IP 地址显示在 "记录"-"路由" 或 "联系人" 中,则证书检查失败,并且呼叫失败。If an IP address is presented in Record-route or Contact, the certificate check fails and the call fails.

  • 如果 FQDN 与所显示的证书中的常见或主题备用名称的值不匹配,则调用将失败。If the FQDN does not match the value of the Common or Subject Alternative Name in the presented certificate, the call fails.

入站呼叫: SIP 对话框说明Inbound call: SIP dialog description

下表总结了非绕过和绕过模式之间的通话流差异和相似性:The following table below summarizes the call flow differences and similarities between non-bypass and bypass modes:

参数名称Parameter name 非绕过模式Non-bypass mode 绕过模式Bypass mode
183和200消息中的媒体候选人来自Media candidates in 183 and 200 messages coming from 媒体处理器Media processors 客户端Clients
SBC 可以接收的183消息数Number of 183 messages SBC can receive 每个会话一个One per session Multiple
可通过临时答案进行呼叫(183)Call can be with provisional answer (183) Yes Yes
通话可能没有临时应答(183)Call can be without provisional answer (183) Yes Yes

非媒体旁路流Non-media bypass flow

团队用户可能同时具有多个终结点。A Teams user might have multiple endpoints at the same time. 例如,Windows 客户端团队、iPhone 客户端团队和团队手机(团队 Android 客户端)。For example, Teams for Windows client, Teams for iPhone client, and Teams Phone (Teams Android client). 每个终结点可能发出 HTTP rest 的信号,如下所示:Each endpoint might signal an HTTP rest as follows:

  • 呼叫进度–由 SIP 代理将其转换为 SIP 消息180。Call progress – converted by the SIP proxy to the SIP message 180. 在接收消息180时,SBC 必须生成本地震铃。On receiving message 180, the SBC must generate local ringing.

  • 媒体应答–通过 SIP 代理将其转换为消息183,在会话描述协议(SDP)中使用媒体候选人。Media answer – converted by the SIP proxy to message 183 with media candidates in Session Description Protocol (SDP). 在接收消息183时,SBC 预期连接到在 SDP 消息中接收的媒体候选人。On receiving message 183, the SBC expects to connect to the media candidates received in the SDP message. 请注意,在某些情况下,可能不会生成媒体答案,并且终结点可能会收到 "接受通话" 消息的答案。Note that in some cases the Media answer might not be generated, and the end point might answer with “Call Accepted” message.

  • 通话被接受–由 SIP 代理通过 SDP 转换到 SIP 消息200。Call accepted – converted by the SIP proxy to SIP message 200 with SDP. 在接收消息200时,SBC 应在提供的 SDP 候选人中发送和接收媒体。On receiving message 200, the SBC is expected to send and receive media to and from the provided SDP candidates.

多个终结点通过临时答案进行铃声Multiple endpoints ringing with provisional answer

  1. 收到来自 SBC 的第一个邀请后,SIP 代理会发送消息 "SIP SIP/2.0 100 尝试",并通知所有最终用户终结点的传入呼叫。On receiving the first Invite from the SBC, the SIP proxy sends the message "SIP SIP/2.0 100 Trying" and notifies all end user endpoints about the incoming call.

  2. 收到通知后,每个终结点将开始向 SIP 代理发送 "呼叫进度" 消息。Upon notification, each endpoint will start ringing and sending "Call progress” messages to the SIP proxy. 由于团队用户可以有多个终结点,因此 SIP 代理可能会收到多个呼叫进度消息。Because a Teams user can have multiple end points, the SIP proxy might receive multiple Call Progress messages.

  3. 对于从客户收到的每个呼叫进度消息,SIP 代理将呼叫进度消息转换为 SIP 消息 "SIP SIP/2.0 180 尝试"。For every Call Progress message received from the clients, the SIP proxy converts the Call Progress message to the SIP message "SIP SIP/2.0 180 Trying". 发送此类消息的间隔由来自呼叫控制器的接收邮件的间隔定义。The interval for sending such messages is defined by the interval of the receiving messages from the Call Controller. 在下图中,SIP 代理生成了 2 180 封邮件。In the following diagram, there are two 180 messages generated by the SIP proxy. 这些消息来自用户的两个团队终结点。These messages come from the two Teams endpoints of the user. 每个客户都有一个唯一的标记 ID。The clients each have a unique Tag ID. 来自不同终结点的每条消息将是一个单独的会话("收件人" 字段中的参数 "tag" 将不同)。Every message coming from a different endpoint will be a separate session (the parameter “tag” in the “To” field will be different). 但是,终结点可能不会生成消息180并立即发送消息183,如下图中所示。But an endpoint might not generate message 180 and send message 183 right away as shown in the following diagram.

  4. 一旦终结点生成带有终结点媒体候选人的 IP 地址的媒体答案消息,SIP 代理会将收到的消息转换为 "SIP 183 会话进度" 消息,该消息包含客户端从媒体处理器替换的来自客户端的 sdp。Once an endpoint generates a Media Answer message with the IP addresses of endpoint’s media candidates, the SIP proxy converts the message received to a "SIP 183 Session Progress" message with the SDP from the client replaced by the SDP from the Media Processor. 在下图中,派生2的终结点应答呼叫。In the following diagram, the endpoint from Fork 2 answered the call. 如果主干是非绕过的,则 183 SIP 消息仅生成一次(即环机器人或客户端终结点)。If the trunk is non-bypassed, the 183 SIP message is generated only once (either Ring Bot or Client End Point). 183可能会产生一个现有的分叉或开始一个新的分叉。The 183 might come on an existing fork or start a new one.

  5. 将使用接受呼叫的终结点的最终候选项发送呼叫接受消息。A Call Acceptance message is sent with the final candidates of the endpoint that accepted the call. 通话接受消息将转换为 SIP 消息200。The Call Acceptance message is converted to SIP message 200.

显示多个终结点和临时应答的图表

多个终结点在没有临时应答的情况下响铃Multiple endpoints ringing without provisional answer

  1. 收到来自 SBC 的第一个邀请后,SIP 代理会发送消息 "SIP SIP/2.0 100 尝试",并通知所有最终用户终结点的传入呼叫。On receiving the first Invite from the SBC, the SIP proxy sends the message "SIP SIP/2.0 100 Trying" and notifies all end user endpoints about the incoming call.

  2. 收到通知后,每个终结点将开始向 SIP 代理发送消息 "呼叫进度"。Upon notification, each endpoint will start ringing and sending the message "Call progress” to the SIP proxy. 由于团队用户可以有多个终结点,因此 SIP 代理可能会收到多个呼叫进度消息。Because a Teams user can have multiple end points, the SIP proxy might receive multiple Call Progress messages.

  3. 对于从客户收到的每个呼叫进度消息,SIP 代理将呼叫进度消息转换为 SIP 消息 "SIP SIP/2.0 180 尝试"。For every Call Progress message received from the clients, the SIP proxy converts the Call Progress message to the SIP message "SIP SIP/2.0 180 Trying". 发送消息的间隔由接收来自呼叫控制器的邮件的间隔定义。The interval for sending the messages is defined by the interval of receiving the messages from the Call Controller. 在下面的图片中,SIP 代理生成 2 180 消息,这意味着用户登录到三个团队客户和每个客户端发送呼叫进度。On the picture below there are two 180 messages generated by the SIP proxy, meaning that user logged into three Teams clients and each client send the call progress. 每封邮件都将是单独的会话("收件人" 字段中的参数 "标记" 不同)Every message will be a separate session (parameter “tag” in “To” field is different)

  4. 将使用接受呼叫的终结点的最终候选项发送呼叫接受消息。A Call Acceptance message is sent with the final candidates of the endpoint that accepted the call. 通话接受消息将转换为 SIP 消息200。The Call Acceptance message is converted to SIP message 200.

图表显示多个终结点在没有临时应答的情况下响铃

媒体绕过流Media bypass flow

媒体绕过方案中使用的消息(100尝试、180、183)相同。The same messages (100 Trying, 180, 183) are used in the media bypass scenario.

下面的架构显示了绕过通话流的示例。The schema below shows an example of the bypass call flow. 请注意,媒体候选人可以来自不同的终结点。Note that the media candidates can come from different endpoints.

显示多个终结点和临时应答的图表

替换选项Replaces option

SBC 必须支持替换的邀请。The SBC must support Invite with Replaces.

SDP 注意事项的大小Size of SDP considerations

直接路由接口可能会发送超过1500字节的 SIP 消息。The Direct Routing interface might send a SIP message exceeding 1,500 bytes. SDP 的大小主要是导致这种情况。The size of SDP primarily causes this. 但是,如果在 SBC 后面有一个 UDP 主干,则它可能会在从 Microsoft SIP 代理转发到未修改的中继时拒绝该消息。However, if there is a UDP trunk behind the SBC, it might reject the message if it is forwarded from the Microsoft SIP proxy to the trunk unmodified. Microsoft 建议在 SBC 上将消息发送到 UDP 中继时,在 SBC 上去除一些值。Microsoft recommends stripping some values in SDP on the SBC when sending the message to the UDP trunks. 例如,可以删除 ICE 候选人或未使用的编解码器。For example, the ICE candidates or unused codecs can be removed.

呼叫转接Call transfer

直接路由支持呼叫转接的两种方法:Direct Routing supports two methods for call transfer:

  • 选项 1.Option 1. SIP 代理进程从本地引用客户端,并充当 RFC 3892 第7.1 节中所述的 Referee。SIP proxy processes Refer from the client locally and acts as a Referee as described in section 7.1 of RFC 3892.

    使用此选项,SIP 代理将终止传输并添加新邀请。With this option, the SIP proxy terminates the transfer and adds a new Invite.

  • 选项 2.Option 2. SIP 代理发送对 SBC 的引用并充当 Transferor,如 RFC 5589 的第6节中的描述所述。SIP proxy sends the Refer to the SBC and acts as a Transferor as describing in Section 6 of RFC 5589.

    使用此选项,SIP 代理会发送一个指向 SBC 的参考,并期望 SBC 完全处理传输。With this option, the SIP proxy sends a Refer to the SBC and expects the SBC to handle the Transfer fully.

SIP 代理根据 SBC 所报告的功能选择该方法。The SIP proxy selects the method based on the capabilities reported by the SBC. 如果 SBC 指示它支持方法 "参阅",则 SIP 代理将对呼叫转移使用选项2。If the SBC indicates that it supports the method “Refer”, the SIP proxy will use Option 2 for call transfers.

下面是一个 SBC 的示例,该示例发送消息指出支持引用方法:The following is an example of an SBC sending the message that the Refer method is supported:

ALLOW: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY

如果 SBC 未指示引用为受支持的方法,直接路由将使用选项1(SIP 代理充当 Referee)。If the SBC doesn’t indicate that Refer as a supported method, Direct Routing will use Option 1 (SIP proxy acts as a Referee) . SBC 还必须发出支持 Notify 方法的信号:The SBC must also signal that it supports the Notify method:

SBC 的示例(指示不支持参考方法):Example of SBC indicating that Refer method is not supported:

ALLOW: INVITE, ACK, CANCEL, BYE, INFO, NOTIFY, PRACK, UPDATE, OPTIONS

SIP 代理进程在本地引用客户端并充当 RefereeSIP proxy processes Refer from the client locally and acts as a Referee

如果 SBC 指示不支持参阅方法,则 SIP 代理充当 Referee。If the SBC indicated that the Refer method is not supported, the SIP proxy acts as a Referee.

来自客户端的引用请求将在 SIP 代理上终止。The Refer request that comes from the client will be terminated on the SIP proxy. (客户端的引用请求在下图中显示为 "呼叫转接至 Dave"。(The Refer request from the client is shown as “Call transfer to Dave” in the following diagram. 有关详细信息,请参阅RFC 3892的7.1 节。For more information, see section 7.1 of RFC 3892.

显示多个终结点和临时应答的图表

SIP 代理发送对 SBC 的引用并充当 TransferorSIP proxy send the Refer to the SBC and acts as a Transferor

这是呼叫转接的首选方法,对于寻找媒体绕过证书的设备是必需的。This is the preferred method for call transfers, and it is mandatory for devices seeking media bypass certification. 在媒体绕过模式下不支持 SBC 能够处理引用的呼叫转接。Call Transfer without the SBC being able to handle Refer is not supported in media bypass mode.

标准将在 RFC 5589 的第6节中介绍。The standard is explained in Section 6 of RFC 5589. 相关 Rfc 包括:The related RFCs are:

此选项假定 SIP 代理充当 Transferor,并向 SBC 发送一条参考消息。This option assumes that the SIP proxy acts as a Transferor and sends a Refer message to the SBC. SBC 充当 Transferee 并处理用于传输的新优惠的参考。The SBC acts as a Transferee and handles the Refer to generate a new offer for transfer. 有两种可能的情况:There are two possible cases:

  • 将呼叫转移到外部 PSTN 参与者。The call is transferred to an external PSTN participant.
  • 通过 SBC 将呼叫从一个团队用户转移到同一租户中的另一个团队用户。The call is transferred from one Teams user to another Teams user in the same tenant via the SBC.

如果通过 SBC 将呼叫从一个团队用户转移到另一个团队,则 SBC 应使用参考消息中接收的信息为传输目标(团队用户)发出新的邀请(开始新的对话框)。If the call is transferred from one Teams user to another via the SBC, the SBC is expected to issue a new invite (start a new dialog) for the transfer target (the Teams user) using the information received in the Refer message.

要为请求的内部事务填充 "收件人/Transferor" 字段,SIP 代理需要将此信息传达在 "引用"/"引用方" 标题内。To populate the To/Transferor fields for the transaction of the request internally, the SIP proxy needs to convey this information inside the REFER-TO/REFERRED-BY headers.

SIP 代理将作为 SIP URI (由主机名中的 SIP 代理 FQDN 和下列任一项之一)组成的 "引用为 SIP URI":The SIP proxy will form the REFER-TO as a SIP URI comprised of a SIP proxy FQDN in the hostname and either one of the following:

  • URI 的用户名部分中的 E.i 电话号码,如果转移目标是电话号码,则为An E.164 phone number in the username part of the URI in case the transfer target is a phone number, or

  • 每个 x-m 和 x t 参数分别编码完整的传输目标 MRI 和租户 IDx-m and x-t parameters encoding the full transfer target MRI and tenant ID respectively

被引用的标头是 transferor MRI 编码的 SIP URI,以及 transferor 租户 ID 和其他传输上下文参数,如下表所示:The REFERRED-BY header is a SIP URI with transferor MRI encoded in it as well as transferor tenant ID and other transfer context parameters as shown in the following table:

参数Parameter Value 说明Description
x-mx-m MRIMRI Transferor 的所有 MRI/转移目标(由 CC 填充)Full MRI of transferor/transfer target as populated by CC
x-tx-t 租户 IDTenant ID x-t 租户 ID 由 CC 填充的可选租户 Idx-t Tenant ID Optional Tenant Id as populated by CC
x-tix-ti Transferor 相关性 IdTransferor Correlation Id 对 transferor 的调用的相关 IdCorrelation Id of the call to the transferor
x-ttx-tt 传输目标呼叫 URITransfer target call URI 已编码的调用替换 URIEncoded call replacement URI

在这种情况下,引用页眉的大小最多可以为400符号。The size of the Refer Header can be up to 400 symbols in this case. SBC 必须支持处理引用的消息大小最多为400个符号。The SBC must support handling Refer messages with size up to 400 symbols.

显示多个终结点和临时应答的图表

会话计时器Session timer

SIP 代理支持(始终提供)在非绕过呼叫中的会话计时器,但不在绕过呼叫时提供。The SIP proxy supports (always offers) the Session Timer on non-bypass calls but does not offer it on bypass calls. SBC 使用会话计时器不是必需的。Use of the Session Timer by the SBC is not mandatory.

使用请求 URI 参数 user = phoneUse of Request-URI parameter user=phone

SIP 代理分析请求 URI,如果参数 user = phone 存在,服务会将请求 URI 作为电话号码处理,并将该号码与用户相匹配。The SIP proxy analyses the Request-URI and if the parameter user=phone is present, the service will handle the Request-URI as a phone number, matching the number to a user. 如果参数不存在,SIP 代理会应用试探法来确定请求 URI 用户类型(电话号码或 SIP 地址)。If parameter is not present the SIP proxy applies heuristics to determine the Request-URI user type (phone number or a SIP address).

Microsof 建议始终应用 user = phone 参数以简化呼叫设置过程。Microsof recommends always applying the user=phone parameter to simplify the call setup process.

历史记录-信息标题History-Info header

历史记录信息标头用于 retargeting SIP 请求和 "提供一种用于捕获请求历史记录信息的标准机制,以便为网络和最终用户提供多种服务。"The History-Info header is used for retargeting SIP requests and “provide(s) a standard mechanism for capturing the request history information to enable a wide variety of services for networks and end-users.” 有关详细信息,请参阅RFC 4244 –第1.1 部分For more information, see RFC 4244 – Section 1.1. 对于 Microsoft Phone 系统,在 Simulring 和呼叫转发方案中使用此标题。For Microsoft Phone System, this header is used in Simulring and Call Forwarding scenarios.

如果发送,则将启用历史记录信息,如下所示:If sending, the History-Info is enabled as follows:

  • SIP 代理将在包含历史记录信息头(已发送到 PSTN 控制器)的单个历史记录信息条目中插入一个包含相关电话号码的参数。The SIP proxy will insert a parameter containing the associated phone number in individual History-Info entries that comprise the History-Info header sent to the PSTN Controller. PSTN 控制器仅使用具有电话号码参数的条目,它将重建新的历史记录信息标头,并通过 SIP 代理将其传递到 SIP 中继提供程序。Using only entries that have the phone number parameter, the PSTN Controller will rebuild a new History-Info header, and pass it on to the SIP trunk provider via SIP proxy.

  • 将为同时拨打和呼叫转移案例添加历史记录-信息标题。History-Info header will be added for simultaneous ring and call forwarding cases.

  • 将不会为呼叫转移案例添加历史记录-信息标题。History-Info header will not be added for call transfer cases.

  • 已重建历史记录-信息标头中的单个历史记录项将提供与直接路由 FQDN (sip.pstnhub.microsoft.com)组合的电话号码参数,该参数设置为 URI 的主机部分;"user = phone" 的参数将作为 SIP URI 的一部分添加。An individual history entry in the reconstructed History-Info header will have the phone number parameter provided combined with the Direct Routing FQDN (sip.pstnhub.microsoft.com) set as the host part of the URI; a parameter of ‘user=phone’ will be added as part of the SIP URI. 除了手机上下文参数外,与原始历史记录信息标题关联的任何其他参数都将在重新构建的历史记录信息标题中传递。Any other parameters associated with the original History-Info header, except for phone context parameters, will be passed through in the re-constructed History-Info header. 请注意,专用项(由 RFC 4244 的3.3 中定义的机制确定)将按原样转发,因为 SIP 中继提供程序是受信任的对等。Note that entries that are private (as determined by the mechanisms defined in Section 3.3 of RFC 4244) will be forwarded as is because the SIP trunk provider is a trusted peer.

  • 入站历史记录-信息被忽略。Inbound History-Info is ignored.

以下是 SIP 代理发送的历史记录信息头的格式:Following is the format of the History-info header sent by the SIP proxy:

<sip:UserB@sip.pstnhub.microsoft.com?Privacy=history&Reason=SIP%3B\cause%3D486>;index=1.2,

如果多次呼叫被重定向,则有关每次重定向的信息都包含在按时间顺序排列的相应原因中。If the call was redirected several times, information about every redirect is included with the appropriate reason in chronological order.

页眉示例:Header Example:

History-info: 
<sip:+14257123456@sip.pstnhub.microsoft.com;user=phone?Reason=SIP;cause=302;text=”Move Temporarily”>;index=1
<sip:+14257123457@sip.pstnhub.microsoft.com;user=phone?Reason=SIP;cause=496;text=”User Busy”>;index=1.1

历史记录-信息受强制 TLS 机制的保护。The History-Info is protected by a mandatory TLS mechanism.

与直接路由和故障转移机制的 SBC 连接SBC connection to Direct Routing and failover mechanism

请参阅计划中用于直接路由的 SIP 信号的故障转移机制部分。See the section Failover mechanism for SIP signaling in Plan for Direct Routing.

重试-在Retry-After

如果直接路由数据中心正忙,则该服务可以向 SBC 发送一秒钟间隔后的重试消息。If a Direct Routing datacenter is busy, the service can send a Retry-After message with a one-second interval to the SBC. 当 SBC 收到503消息,并且使用重试头响应某个邀请时,SBC 必须终止该连接并尝试下一个可用的 Microsoft 数据中心。When the SBC receives a 503 message with a Retry-After header in response to an INVITE, the SBC must terminate that connection and try the next available Microsoft datacenter.

ICE 重启:转到不支持媒体绕过的终结点的媒体旁路呼叫。ICE Restart: Media bypass call transferred to an endpoint that does not support media bypass

SBC 必须支持"9.1.1.1" 部分中的 RFC 5245中所述的 ICE 重启。The SBC must support ICE restarts as described in RFC 5245, section 9.1.1.1.

直接路由中的重启按照 RFC 的以下段落实现:The restart in Direct Routing is implemented according to the following paragraphs of the RFC:

若要重新启动 ICE,工程师必须在优惠中更改媒体流的冰密码和 ice ufrag。 请注意,允许在一个提供中使用会话级属性,但在后续优惠中提供与媒体级属性相同的 ice pwd 或 ice ufrag。 这不是密码更改,而是对其表示形式的更改,并且不会导致 ICE 重启。To restart ICE, an agent MUST change both the ice-pwd and the ice-ufrag for the media stream in an offer. Note that it is permissible to use a session-level attribute in one offer, but to provide the same ice-pwd or ice-ufrag as a media-level attribute in a subsequent offer. This is not a change in password, just a change in its representation, and does not cause an ICE restart.

在此媒体流的初始提供中,代理将此媒体流的其他字段设置为该媒体流的其他字段(请参阅4.3 节)。 因此,候选集可能包含该流的部分、全部或所有候选项,并且可能包括一组全新的候选项,如4.1.1 节中所述。An agent sets the rest of the fields in the SDP for this media stream as it would in an initial offer of this media stream (see Section 4.3). Consequently, the set of candidates MAY include some, none, or all of the previous candidates for that stream and MAY include a totally new set of candidates gathered as described in Section 4.1.1.

如果呼叫最初是使用 "媒体绕过" 建立的,并且呼叫转移到 Skype for business 客户端,直接路由需要插入媒体处理器-这是因为直接路由无法与具有媒体旁路的 Skype for Business 客户端配合使用。If the call was initially established with media bypass, and the call is transferred to a Skype for Business client, Direct Routing needs to insert a Media Processor--this is because Direct Routing cannot be used with a Skype for Business client with media bypass. 直接路由通过更改 ice-pwd 和 ice ufrag 并在 reinvite 中提供新的媒体候选人来启动 ICE 重启过程。Direct Routing starts the ICE restart process by changing the ice-pwd and ice-ufrag and offering new media candidates in a reinvite.