瞭解會議伺服器上的呼叫路由邏輯

簡介

本檔案介紹思科會議伺服器(CMS)（前身為Acano產品）的通話路由邏輯，此邏輯已分割為多個通話路由表。本文檔介紹呼叫通過這些呼叫路由表可以採取的不同階段和方案。

必要條件

需求

思科建議您瞭解以下主題：

• 思科會議伺服器呼叫橋元件。

採用元件

本檔案中的資訊是根據2.3.x版中的思科會議伺服器。

本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路運作中，請確保您瞭解任何指令可能造成的影響。

思科會議伺服器(CMS)的呼叫路由邏輯是什麼？

CMS上的呼叫路由涉及幾個呼叫路由不同的表。通過可下載的流程圖，您可以遵循到達CMS的每個呼叫的呼叫路由邏輯。這適用於所有型別的呼叫：除非另有說明，否則思科會議應用（CMA — 胖客戶端或WebRTC）、標準會話初始協定(SIP)呼叫或Microsoft SIP呼叫。

附註：唯一的例外是CMS發起的呼叫(CMS直接用於TelePresence Management Suite(TMS)計畫的出站呼叫或CMA客戶端撥出)，呼叫轉發表被繞過。

這是CMS中呼叫路由過程的順序： 

1. 來電匹配表
2. 來電轉接表
3. 出站呼叫表

每個表格將在本文檔後面進行更詳細的說明，其中包括僅顯示相關部分的影象。

附註：CMS僅基於域路由執行呼叫路由，因此基於統一資源識別符號(URI)的右側(RHS)。 沒有基於URI左側(LHS)的呼叫路由功能，就像在具有目錄號碼路由（路由模式）的Cisco Unified Communications Manager(CUCM)中一樣。

附註：每個表都是由優先順序屬性設定的有序清單。優先順序越高，表示它會先嘗試匹配。如果不匹配，則繼續執行清單中的下一個規則。作為一般經驗法則，為更一般的規則（如匹配任何域的*）提供比更具體的規則更低的優先順序。這樣，首先處理特定規則，您可能會退回到更一般的規則。

步驟1.來電匹配表

這是CMS確定入站呼叫是否發往思科會議伺服器本身，是否需要在其上進一步處理，或者是否發往另一個系統的呼叫(其中CMS是處理呼叫並處理媒體和信令(例如，Skype網關呼叫標準SIP終端（反之亦然）。

它檢查傳入URI的域部分是否與傳入匹配表匹配。如果匹配，則它能夠將呼叫路由到空間、使用者、IVR或根據您為此撥號計畫規則的配置進行Lync會議查詢（內部或外部）。該表不允許使用萬用字元域，它要求完全匹配。

附註：如果您沒有配置任何傳入呼叫匹配域，則CMS會接受來自SIP或Lync呼叫的所有傳入URI，這些呼叫會落入callbridge。對於CMA客戶端（WebRTC或胖客戶端），儘管它接受呼叫，但不會自動路由到正確的空間或使用者。因此，在這種情況下使用CMA客戶端撥號到空格或使用者時，必須在正確的域中輸入。

例如，如下圖所示為呼叫匹配表(它僅顯示Targets spaces和Targets users選項，以便簡潔明瞭):

在這裡，域設定為acano.steven.lab，客戶端通常撥打該域。但是，它還允許通過CUCM（或Expressway搜尋規則）臨時呼叫或特定SIP路由模式，這些模式僅以表中的第一和第二回退規則為目標特定callbridge（如果是群集），該回退規則匹配callbridge的IP地址（本例中為10.48.54.160）或callbridge的完全限定域名(FQDN)（本例中為acano1.acano.steven.lab）。

步驟2.來電轉接表

如果呼叫未命中傳入呼叫匹配表上的任何規則，或者沒有用於繼續呼叫的匹配項（例如，使用者撥打了不存在的或錯誤的空間URI），則呼叫會通過稱為呼叫轉發表的第二表。這也僅基於域，並允許您專門阻止對某些域的呼叫，或專門只允許對特定域的呼叫。如果要執行此操作，則更重要的是具有更高優先順序的更多特定規則，以便首先檢查這些規則。

此示例顯示，對dummy.com的呼叫被拒絕，而對tplab.local的呼叫被轉發：

如果將呼叫轉送表留空，則會導致CMS不作為Skype和SIP參與者之間的網關的狀態，例如沒有任何呼叫轉送規則。假設傳入呼叫的域在傳入呼叫匹配表上不匹配，或者域匹配，但在空間、使用者或IVR（或Skype會議）上沒有匹配，則不會針對傳出呼叫表轉發呼叫。

附註：不過CMA客戶端（胖客戶端和WebRTC）可以發出出站呼叫，因此確實會發生這種情況（*3.0中的Web App無法發出出站呼叫，而是由Callbridge發出的CMS空間發出的呼叫）。 同樣，通過API（例如TMS預先安排的會議）進行CMS上的出站呼叫也可以正常工作。 通常，從CMS本身（直接或通過CMA）發起的呼叫不得遵循呼叫轉發邏輯。

在事件日誌中，您可以看到突出顯示的forwarding消息，例如CMS作為SIP和Skype呼叫的網關時。在此之前，您可以看到來電和之後的去電。

2018-10-04  06:36:24.612  Info     call 788: incoming SIP call from "sip:1060@10.48.36.215" to local URI "sip:stejanss@any.com"
2018-10-04  06:36:24.624  Info     forwarding call to 'sip:stejanss@any.com' to 'stejanss@any.com'
2018-10-04  06:36:24.625  Info     call 789: outgoing SIP call to "stejanss@any.com"

如果轉發表沒有任何規則或拒絕規則，則事件日誌不會明確顯示這一點。它只是通知您SIP呼叫不匹配（任何空間、使用者、IVR或Lync會議），並且您錯過轉發規則（或設定為拒絕）以移動到出站規則部分。

2018-10-04  06:47:12.482  Info     call 790: incoming SIP call from "sip:1060@10.48.36.215" to local URI "sip:stejanss@any.com"
2018-10-04  06:47:12.495  Info     call 790: ending; local teardown, destination URI not matched - not connected after 0:00

對於通過TMS安排的會議發起的CMA客戶端呼叫或CMS的出站呼叫，在事件日誌中不會看到任何來電。呼叫會立即轉到出站撥號計畫表，並且呼叫轉送表不會處理該呼叫。

在呼叫轉送表中，還有兩個配置選項：重寫域和呼叫方ID。

重寫域

此選項允許您將入站呼叫的域重寫為另一個域，並更改SIP消息SIP Request-URI的域部分以及To報頭。

例如，在此映像上的配置中，對於域any.com的入站呼叫，但傳入呼叫匹配表（在空間、使用者、IVR或Skype會議上）上沒有匹配項，此處將顯示事件日誌（啟用SIP跟蹤）：

2018-10-04  07:02:24.818  Info     SIP trace: connection 0: incoming SIP TCP data from 10.48.36.215:56457 to 10.48.80.71:5060, size 1000:
2018-10-04  07:02:24.818  Info     SIP trace: INVITE sip:stejanss@any.com SIP/2.0
2018-10-04  07:02:24.818  Info     SIP trace: Via: SIP/2.0/TCP 10.48.36.215:5060;branch=z9hG4bK53e4c4ce29394
2018-10-04  07:02:24.818  Info     SIP trace: From: "EX60 Steven" <sip:1060@steven.lab>;tag=742103~ee545a46-516a-4de6-87d7-7b1f5a5b848a-26001856
2018-10-04  07:02:24.818  Info     SIP trace: To: <sip:stejanss@any.com>
..
2018-10-04  07:02:24.822  Info     call 797: incoming SIP call from "sip:1060@10.48.36.215" to local URI "sip:stejanss@any.com"
2018-10-04  07:02:24.834  Info     forwarding call to 'sip:stejanss@any.com' to 'stejanss@newany.com'
2018-10-04  07:02:24.835  Info     call 798: outgoing SIP call to "stejanss@newany.com"
..
2018-10-04  07:02:24.838  Info     SIP trace: connection 19: outgoing SIP TCP data to 10.48.36.215:5060 from 10.48.80.71:57854, size 3286:
2018-10-04  07:02:24.838  Info     SIP trace: INVITE sip:stejanss@newany.com SIP/2.0
2018-10-04  07:02:24.838  Info     SIP trace: Via: SIP/2.0/TCP 10.48.80.71:5060;branch=z9hG4bKefc98b81a2961b37aee24f03c2142d8e
2018-10-04  07:02:24.839  Info     SIP trace: Call-ID: 18644f28-e998-4032-a7df-75325e9d11b0
2018-10-04  07:02:24.839  Info     SIP trace: CSeq: 659590315 INVITE
2018-10-04  07:02:24.839  Info     SIP trace: Max-Forwards: 70
2018-10-04  07:02:24.839  Info     SIP trace: Contact: <sip:1060@10.48.80.71;transport=tcp>
2018-10-04  07:02:24.839  Info     SIP trace: To: <sip:stejanss@newany.com>
2018-10-04  07:02:24.839  Info     SIP trace: From: "EX60 Steven" <sip:1060@steven.lab>;tag=2aa2a49bba231a1b

在此轉接呼叫線路中，顯示已發生的修改。如果您未啟用SIP追蹤功能，仍會顯示any.com變更為newany.com。

此域重寫的最常見用法是內建的Lync與CMS群集的集成，建議在出站規則中將Contact標頭和From標頭設定為Lync/Skype以設定callbridge特定的完全限定域名(FQDN)。 這是因為存在以下路由規則：

• Skype將對話框內的新事務（例如INVITE - 200 OK之後的ACK）傳送到從CMS收到的200 OK中指定的聯絡人標頭。  對於從Skype到CMS的入站連線，Skype首先會傳送一條NEGOTIATE SIP消息，其中包含ms-fe標頭的To標頭，該標頭指定在INVITE上的200 OK回覆中必須如何填寫Contact標頭（因為它使用相同的TCP通道）
• Skype會將新的對話語言（如內容共用，因為它是單獨的呼叫，如果呼叫未接則傳送回叫）傳送到原始INVITE的From標頭

在重寫域時，它與來自Lync呼叫的回撥相關。未接的INVITE的From標頭指向呼叫來自的特定callbridge。然後，Lync傳送一個包含與callbridge FQDN匹配的SIP請求URI的新請求(INVITE)。然後，通過這些重寫規則將其轉換為SIP域。一旦呼叫被轉發，它就會對註冊了SIP終結點的CUCM或Expressway-C使用出站規則。

來電者ID

這裡有兩個可以在轉發規則上設定的選項。它被設定為通過，然後不對出站INVITE的From標頭進行修改，或者被設定為使用撥號計畫，該撥號計畫允許系統根據出站規則修改From標頭。此設定與是否重寫域無關，因為僅涉及SIP請求URI以及出站INVITE的To標頭。

例如，與之前進行的呼叫相同，但現在newany.com有一個出站撥號計畫規則（與對傳入呼叫轉發表進行重寫後一樣），該規則被設定為Lync型別呼叫（例如，Ms-Conversation-ID作為額外SIP報頭）。 相應地，會填充本地源域（和本地聯絡域），以指向先前為Lync呼叫指示的callbridge FQDN。然後，這將反映出站SIP INVITE的自和聯絡人報頭上的更改。如圖所示，它們填充了相同的值，並且可以根據您的要求單獨選擇。

2018-10-12  09:09:24.488  Info     SIP trace: connection 28: incoming SIP TCP data from 10.48.36.215:44460 to 10.48.80.71:5060, size 1000:
2018-10-12  09:09:24.489  Info     SIP trace: INVITE sip:stejanss@any.com SIP/2.0
2018-10-12  09:09:24.489  Info     SIP trace: Via: SIP/2.0/TCP 10.48.36.215:5060;branch=z9hG4bKf4a230ec178e
2018-10-12  09:09:24.489  Info     SIP trace: From: "EX60 Steven" <sip:1060@steven.lab>;tag=118288~ee545a46-516a-4de6-87d7-7b1f5a5b848a-32900729
2018-10-12  09:09:24.489  Info     SIP trace: To: <sip:stejanss@any.com>
2018-10-12  09:09:24.489  Info     SIP trace: Call-ID: 81e67f80-bc0164c4-f2c6-d724300a@10.48.36.215

2018-10-12  09:09:24.494  Info     call 803: incoming SIP call from "sip:1060@10.48.36.215" to local URI "sip:stejanss@any.com"
2018-10-12  09:09:24.506  Info     forwarding call to 'sip:stejanss@any.com' to 'stejanss@newany.com'
2018-10-12  09:09:24.507  Info     call 804: outgoing SIP call to "stejanss@newany.com" (Lync)

2018-10-12  09:09:24.507  Info     SIP trace: connection 33: allocated for outgoing connection to 10.48.36.46:5060
2018-10-12  09:09:24.508  Info     SIP trace: connection 33: outgoing connection successful, 10.48.80.71:39782 to 10.48.36.46:5060
2018-10-12  09:09:24.510  Info     SIP trace: connection 33: outgoing SIP TCP data to 10.48.36.46:5060 from 10.48.80.71:39782, size 2971:
2018-10-12  09:09:24.510  Info     SIP trace: INVITE sip:stejanss@newany.com SIP/2.0
2018-10-12  09:09:24.510  Info     SIP trace: Via: SIP/2.0/TCP 10.48.80.71:5060;branch=z9hG4bK15bdde97ab641b586f162187cfdd98b5
2018-10-12  09:09:24.510  Info     SIP trace: Call-ID: c366ddaf-e602-4fa5-b1d6-2e16ec08534a
2018-10-12  09:09:24.510  Info     SIP trace: CSeq: 1498747095 INVITE
2018-10-12  09:09:24.510  Info     SIP trace: Max-Forwards: 70
2018-10-12  09:09:24.510  Info     SIP trace: Contact: <sip:1060@callbridgefqdn.any.com;transport=tcp>
2018-10-12  09:09:24.510  Info     SIP trace: Ms-Conversation-ID: 3P5Hu8grR1GGDF1BSMZAmw==
2018-10-12  09:09:24.510  Info     SIP trace: To: <sip:stejanss@newany.com>
2018-10-12  09:09:24.510  Info     SIP trace: From: "EX60 Steven" <sip:1060@callbridgefqdn.any.com>;tag=fb4ae780677e9d9b

如果轉發規則僅設定為pass through，則From報頭上不會出現任何修改，如上例所示（在這種情況下，轉發規則設定為pass through）。 當CMS啟動新的callLeg時，始終會調整聯絡報頭，因此必須新增聯絡報頭到其自身。

可以使用來電者ID和Local Contact Domain以及Local From Domain的不同組合。出站SIP INVITE上的From報頭結構如下表所示，其中入站呼叫使用usera@from.com的From報頭進入CMS。

步驟3.出站呼叫表

這是呼叫路由邏輯中最後一個表，它將呼叫傳送到不同的伺服器，如下所示：

• 傳入呼叫不在本地處理（在傳入呼叫匹配域上）。
• 它是來自CMS空間的出站呼叫(通過CMA或通過API，如果是TMS安排的會議，例如思科會議管理器(CMM)指示出站呼叫)或來自CMA客戶端的出站呼叫。

從圖中可以看出邏輯相對簡單。如果表中沒有任何條目，它仍允許出站呼叫，但假設CMS伺服器能夠在SIP請求URI中提到的該特定域的SIP SRV記錄(_sips._tcp / _sip._tcp / _sip._udp)上解析。如果表不為空，但所撥打域沒有匹配項，則執行相同的DNS查詢邏輯。如果域上有匹配項，則遵循該特定規則的邏輯。在這方面，如果要阻止來自CMA的出站呼叫或通過TMS或CMM進行的出站呼叫，可以通過兩種方式執行此操作。沒有任何DNS SRV記錄（或無法由CMS解析），或者將這些呼叫路由到您的呼叫控制（例如CUCM或Expressway）並阻止那裡的呼叫。

該圖顯示了一個出站呼叫表示例：

結尾有一個<match all domains>規則，第一個規則指向steven.lab的域，但沒有SIP Proxy可供使用（因此它依賴於DNS SRV記錄）。

請注意，這是一個具有更高優先順序值（首先覆蓋）的有序清單。如果匹配規則且Behavior設定為Stop，則呼叫不會在該匹配之後通過表的其餘部分，例如，如果SIP代理無法路由呼叫，則呼叫失敗。當該設定設定為Continue時，可以允許回退到集群中的不同路由或不同節點。例如，您可以為同一域中的每個規則指定不同的SIP代理。 

Local Contact Domain和Local From Domain的設定將在傳入呼叫轉發表的前一部分中介紹。Trunk type允許您指定需要進行的呼叫型別，該型別可以是取決於接收系統的標準SIP、Lync或Avaya。

Encryption欄位會判斷通話的信令必須未經加密或加密。但是請注意，這並不意味著任何在SIP媒體加密配置中設定的媒體加密，如Configuration > Call Settings選單中所示。在此配置中，您還可以選擇自動嘗試首先使用加密信令進行呼叫，並可能回退到未加密信令。如果您事先知道另一端已加密或未加密，則強烈建議相應地定義該端，以避免由於回退過程而導致任何呼叫建立延遲。

在將DNS跟蹤和SIP跟蹤設定為detailed的情況下，指向steven.lab的呼叫（在重寫傳入呼叫轉發表上的域之後）的日誌檔案的輸出示例顯示了查詢的SRV記錄以及加密設定為Auto時的回退機制。

2018-10-12  11:25:16.168  Info     call 821: incoming SIP call from "sip:1060@steven.lab" to local URI "sip:stejanss@any.com"
2018-10-12  11:25:16.179  Info     forwarding call to 'sip:stejanss@any.com' to 'stejanss@steven.lab'
2018-10-12  11:25:16.180  Info     call 822: outgoing SIP call to "stejanss@steven.lab"

2018-10-12  11:25:16.180  Info     DNS trace: resolving "steven.lab" (SRV "_sips._tcp", dnsType:1) for call 822
2018-10-12  11:25:16.181  Info     DNS trace: resolution of "steven.lab" (SRV "_sips._tcp") for call 822 returned result, addresses: 1
2018-10-12  11:25:16.181  Info     DNS trace: resolution of "steven.lab" (SRV "_sips._tcp") for call 822 succeeded; results: 1
2018-10-12  11:25:16.181  Info     DNS trace: resolution of "steven.lab" (SRV "_sips._tcp") for call 822 using 10.48.36.215:5061
2018-10-12  11:25:16.181  Info     SIP trace: connection 45: allocated for outgoing encrypted connection to 10.48.36.215:5061
2018-10-12  11:25:16.201  Info     handshake error 336151576 on outgoing connection 45 to 10.48.36.215:5061 from 10.48.80.71:54864
2018-10-12  11:25:16.201  Info     SIP trace: connection 45: shutting down...

2018-10-12  11:25:16.201  Info     call 822: falling back to unencrypted control connection...

2018-10-12  11:25:16.201  Info     DNS trace: resolving "steven.lab" (SRV "_sip._tcp", dnsType:1) for call 822
2018-10-12  11:25:16.202  Info     DNS trace: resolution of "steven.lab" (SRV "_sip._tcp") for call 822 returned result, addresses: 1
2018-10-12  11:25:16.202  Info     DNS trace: resolution of "steven.lab" (SRV "_sip._tcp") for call 822 succeeded; results: 1
2018-10-12  11:25:16.202  Info     DNS trace: resolution of "steven.lab" (SRV "_sip._tcp") for call 822 using 10.48.36.215:5060
2018-10-12  11:25:16.202  Info     SIP trace: connection 46: allocated for outgoing connection to 10.48.36.215:5060
2018-10-12  11:25:16.203  Info     SIP trace: connection 46: outgoing connection successful, 10.48.80.71:59776 to 10.48.36.215:5060
2018-10-12  11:25:16.205  Info     SIP trace: connection 46: outgoing SIP TCP data to 10.48.36.215:5060 from 10.48.80.71:59776, size 3290:
2018-10-12  11:25:16.205  Info     SIP trace: INVITE sip:stejanss@steven.lab SIP/2.0

附註：如果群集環境具有多個呼叫橋，則可以在通過API配置每個callbridge並在該API對象上指定callbridge ID（或callbridgeGroup ID）時，設定每個callbridge的出站撥號計畫規則。 例如，假設您希望所有呼叫都從特定域的一個特定callbridge發出(例如，當您撥打us.example.com時，您希望它從您基於美國的伺服器發出)。 然後確保您具有出站DialPlanRules的API配置，以便除了基於美國的callbridge之外，其他各callbridge都能將呼叫路由到美國callbridge（在本例中）。

OutboundDialPlanRule(適用於US callbridge)

• 域= us.example.com
• sipProxy = <使用DNS SRV/IP或FQDN（如果手動設定）時為空>
• 範圍= callbridge
• callbridge = <UScallbridge-ID>

OutboundDialPlanRules（適用於必須允許進行該呼叫的所有非美國callbridge）（每個呼叫橋需要一個）

• 域= us.example.com
• sipProxy = <IP-or-FQDN-of-US-Callbridge>
• 範圍= callbridge
• callbridge = <non-US-callbridge-ID>

驗證 

目前沒有適用於此組態的驗證程序。

疑難排解 

目前尚無適用於此組態的具體疑難排解資訊。

相關資訊

• 技術支援與文件 - Cisco Systems
• 合作解決方案分析器工具 
• CMS文檔

---

附註：有關配置示例，請參閱以下指南：

• 配置和整合CMS單一組合指南
• 配置思科會議伺服器和CUCM指南