直接路由 SIP 通訊協定Direct Routing - SIP protocol

本文說明直接路由如何實現會話初始通訊協定(SIP)。This article describes how Direct Routing implements the Session Initiation Protocol (SIP). 若要在會話邊界控制器(SBC)與 SIP proxy 之間正確路由流量,某些 SIP 參數必須有特定的值。To properly route traffic between a Session Border Controller (SBC) and the SIP proxy, some SIP parameters must have specific values. 本文適用于負責設定內部部署 SBC 與 SIP proxy 服務之間的連線的語音系統管理員。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 proxy 需要尋找通話是目的地的租使用者,並在這個租使用者中找到特定使用者。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 proxy 如何找到租使用者與使用者,以及如何在傳入連線上執行 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 頁首Via Header Via: SIP/2.0/TLS sbc1 biz: 5058; 別名; 分支 = z9hG4bKac2121518978Via: SIP/2.0/TLS sbc1.adatum.biz:5058;alias;branch=z9hG4bKac2121518978
Max-轉寄頁首Max-Forwards header 最大轉寄:68Max-Forwards:68
從頁首From Header 從頁首開始: <sip: 7168712781@sbc1. biz; 傳輸 = 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 proxy 會執行下列步驟: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. 使用在 Request 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 proxy 與成對式 SBC 之間擁有協力廠商 SIP proxy 或使用者代理伺服器,這可能會修改成對 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)的需求,在這篇文章的稍後部分中,您需要有一個 SBC 互相連接到許多租使用者的情形(載波案例)。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 proxy,連絡人報頭在 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; transport = 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 支援在憑證的 [通用名稱] 或 [Subject 替換名稱] 欄位中,使用名稱的萬用字元。Microsoft supports using wildcard values of the name(s) in the Common Name or Subject Alternative Name fields of the certificate.

RFC 2818 (section 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 proxy 需要針對新的對話用戶端事務(例如再見或重新邀請),以及在回復 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. 只有在 proxy 想要在對話方塊中保留未來要求的路徑時,才需要記錄路由。The Record-Route is only required if a proxy wants to stay on the path of future requests in a dialog. 如果將 proxy SBC 與本機媒體優化搭配使用以進行直接路由,則必須將記錄路由設定為 proxy 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.

如果不使用 proxy SBC,Microsoft 建議只使用連絡人標頭:Microsoft recommends using only Contact header if a proxy SBC is not used:

  • 根據 RFC 3261,如果您的 proxy 想要在對話方塊中保留未來要求的路徑(如果沒有 proxy SBC 已設定為 Microsoft SIP proxy 與成對的 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 proxy 只會使用連絡人頭(而非記錄路由)來決定傳送輸出 ping 選項時的下一個躍點。The Microsoft SIP proxy uses only Contact header (not Record-Route) to determine the next hop when sending outbound ping Options. 如果不使用 proxy 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 proxy 會使用: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 proxy 會查詢連絡人標頭的值,以產生輸出連線。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 proxy 將其轉換成 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 proxy 轉換成在會話描述通訊協定(SDP)中有媒體候選人的訊息183。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 proxy 轉換為 SIP 訊息200與 SDP。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 proxy 就會傳送「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 proxy。Upon notification, each endpoint will start ringing and sending "Call progress” messages to the SIP proxy. 因為團隊使用者可以有多個端點,所以 SIP proxy 可能會收到多個呼叫進度訊息。Because a Teams user can have multiple end points, the SIP proxy might receive multiple Call Progress messages.

  3. 針對從用戶端收到的每個呼叫進度訊息,SIP proxy 會將呼叫進度訊息轉換為 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 proxy 產生 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. 用戶端每個都有唯一的標記識別項。The clients each have a unique Tag ID. 來自不同端點的每一封郵件都將是一個獨立的會話([至] 欄位中的參數「標記」會不同)。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 proxy 會將收到的訊息轉換為「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 訊息只會產生一次(Ring Bot 或用戶端結束點)。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 proxy 就會傳送「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 proxy。Upon notification, each endpoint will start ringing and sending the message "Call progress” to the SIP proxy. 因為團隊使用者可以有多個端點,所以 SIP proxy 可能會收到多個呼叫進度訊息。Because a Teams user can have multiple end points, the SIP proxy might receive multiple Call Progress messages.

  3. 針對從用戶端收到的每個呼叫進度訊息,SIP proxy 會將呼叫進度訊息轉換為 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 proxy 產生的 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 必須支援以 replace 取代的邀請。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 proxy 轉寄到不修改中繼的情況下,拒絕該訊息。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 建議您在將訊息傳送至 UDP trunks 時,在 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 proxy 進程會從本機參照用戶端,並做為 Referee,如 RFC 3892 的7.1 一節所述。SIP proxy processes Refer from the client locally and acts as a Referee as described in section 7.1 of RFC 3892.

    使用此選項時,SIP proxy 會終止傳輸並新增邀請。With this option, the SIP proxy terminates the transfer and adds a new Invite.

  • 選項2。Option 2. SIP proxy 會傳送參照給 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 proxy 會傳送對 SBC 的參照,並預期 SBC 完全處理傳輸。With this option, the SIP proxy sends a Refer to the SBC and expects the SBC to handle the Transfer fully.

SIP proxy 會根據 SBC 所報告的功能,選取該方法。The SIP proxy selects the method based on the capabilities reported by the SBC. 如果 SBC 指出它支援「參考」這個方法,SIP proxy 將會使用 Option 2 進行來電轉接。If the SBC indicates that it supports the method “Refer”, the SIP proxy will use Option 2 for call transfers.

下列是一個 SBC 範例,該範例會傳送支援 method 方法的訊息: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 proxy 充當 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 proxy 進程是從本機引用用戶端,並做為 RefereeSIP proxy processes Refer from the client locally and acts as a Referee

如果 SBC 指出不支援 method 方法,SIP proxy 就會充當 Referee。If the SBC indicated that the Refer method is not supported, the SIP proxy acts as a Referee.

來自用戶端的參考要求將會在 SIP proxy 上終止。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 proxy 傳送參照給 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 proxy 充當 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.

若要在內部填入要求交易的 [To/Transferor] 欄位,SIP proxy 需要在 [參考資料]/[參照者] 標頭內傳達這項資訊。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 proxy 會將「參考」視為 SIP URI,由主機名稱中的 SIP proxy FQDN 以及下列其中一項: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. 164 電話號碼,或者An E.164 phone number in the username part of the URI in case the transfer target is a phone number, or

  • 分別對完整轉接目標 MRI 與租使用者識別碼進行編碼的 x-y 和 x-y 參數x-m and x-t parameters encoding the full transfer target MRI and tenant ID respectively

[被參照] 標頭是一個 SIP URI,其上有 transferor MRI,以及 transferor 租使用者識別碼和其他傳輸內容參數,如下表所示: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/轉讓目標的完整 MRIFull MRI of transferor/transfer target as populated by CC
x-yx-t 租使用者識別碼Tenant ID x-y 的租使用者識別碼(由 CC 填入)選用的租使用者識別碼x-t Tenant ID Optional Tenant Id as populated by CC
x-tix-ti Transferor 相關識別碼Transferor Correlation Id 呼叫 transferor 的相關識別碼Correlation 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 proxy 支援(永遠提供)非旁路呼叫中的會話計時器,但不會在旁路呼叫中提供。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.

使用 Request-URI 參數 user = phoneUse of Request-URI parameter user=phone

SIP proxy 會分析要求-URI,如果參數使用者 = 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 proxy 會套用啟發式來判斷要求 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 = 電話參數,以簡化通話設定處理常式。Microsof recommends always applying the user=phone parameter to simplify the call setup process.

[歷程記錄-資訊] 標題History-Info header

[歷程記錄-資訊] 標頭是用來 retargeting SIP 要求,而「提供(s)可捕獲要求歷程記錄資訊以針對網路和使用者提供多種服務的標準機制」。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 – Section 1.1For more information, see RFC 4244 – Section 1.1. 針對 Microsoft Phone System,此標頭是用於 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 proxy 會在個別的歷程記錄資訊專案中插入一個包含相關電話號碼的參數,這些內容包含傳送至 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 proxy 將它傳送給 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. 請注意,只有當 SIP 幹線提供者是受信任的對等專案時,才能轉寄私人(由 RFC 4244 的3.3 區段中定義的機制所決定)。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 proxy 傳送之歷程記錄資訊標頭的格式: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-在Retry-After

如果直接路由資料中心處於忙碌狀態,則服務可以在 SBC 中以一秒的間隔傳送一個 Retry 訊息。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 必須支援以RFC 5245 (章節9.1.1.1)所述的 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 密碼和 ice ufrag。 請注意,您可以在一個優惠中使用會話階層屬性,但在後續優惠中提供相同的 ice 密碼或 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 用戶端,則直接傳送必須插入媒體處理器,這是因為直接路由無法與使用媒體旁路的商務用 Skype 用戶端搭配使用。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. 直接傳送:透過變更冰密碼和冰 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.