本產品的文件集力求使用無偏見用語。針對本文件集的目的,無偏見係定義為未根據年齡、身心障礙、性別、種族身分、民族身分、性別傾向、社會經濟地位及交織性表示歧視的用語。由於本產品軟體使用者介面中硬式編碼的語言、根據 RFP 文件使用的語言,或引用第三方產品的語言,因此本文件中可能會出現例外狀況。深入瞭解思科如何使用包容性用語。
思科已使用電腦和人工技術翻譯本文件,讓全世界的使用者能夠以自己的語言理解支援內容。請注意,即使是最佳機器翻譯,也不如專業譯者翻譯的內容準確。Cisco Systems, Inc. 對這些翻譯的準確度概不負責,並建議一律查看原始英文文件(提供連結)。
本檔案介紹思科會議伺服器(CMS)(前身為Acano產品)的通話路由邏輯,此邏輯已分割為多個通話路由表。本文檔介紹呼叫通過這些呼叫路由表可以採取的不同階段和方案。
思科建議您瞭解以下主題:
本檔案中的資訊是根據2.3.x版中的思科會議伺服器。
本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除(預設)的組態來啟動。如果您的網路運作中,請確保您瞭解任何指令可能造成的影響。
CMS上的呼叫路由涉及幾個呼叫路由不同的表。通過可下載的流程圖,您可以遵循到達CMS的每個呼叫的呼叫路由邏輯。這適用於所有型別的呼叫:除非另有說明,否則思科會議應用(CMA — 胖客戶端或WebRTC)、標準會話初始協定(SIP)呼叫或Microsoft SIP呼叫。
附註:唯一的例外是CMS發起的呼叫(CMS直接用於TelePresence Management Suite(TMS)計畫的出站呼叫或CMA客戶端撥出),呼叫轉發表被繞過。
這是CMS中呼叫路由過程的順序:
每個表格將在本文檔後面進行更詳細的說明,其中包括僅顯示相關部分的影象。
附註:CMS僅基於域路由執行呼叫路由,因此基於統一資源識別符號(URI)的右側(RHS)。 沒有基於URI左側(LHS)的呼叫路由功能,就像在具有目錄號碼路由(路由模式)的Cisco Unified Communications Manager(CUCM)中一樣。
附註:每個表都是由優先順序屬性設定的有序清單。優先順序越高,表示它會先嘗試匹配。如果不匹配,則繼續執行清單中的下一個規則。作為一般經驗法則,為更一般的規則(如匹配任何域的*)提供比更具體的規則更低的優先順序。這樣,首先處理特定規則,您可能會退回到更一般的規則。
這是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)。
如果呼叫未命中傳入呼叫匹配表上的任何規則,或者沒有用於繼續呼叫的匹配項(例如,使用者撥打了不存在的或錯誤的空間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)。 這是因為存在以下路由規則:
在重寫域時,它與來自Lync呼叫的回撥相關。未接的INVITE的From標頭指向呼叫來自的特定callbridge。然後,Lync傳送一個包含與callbridge FQDN匹配的SIP請求URI的新請求(INVITE)。然後,通過這些重寫規則將其轉換為SIP域。一旦呼叫被轉發,它就會對註冊了SIP終結點的CUCM或Expressway-C使用出站規則。
這裡有兩個可以在轉發規則上設定的選項。它被設定為通過,然後不對出站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。
這是呼叫路由邏輯中最後一個表,它將呼叫傳送到不同的伺服器,如下所示:
從圖中可以看出邏輯相對簡單。如果表中沒有任何條目,它仍允許出站呼叫,但假設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)
OutboundDialPlanRules(適用於必須允許進行該呼叫的所有非美國callbridge)(每個呼叫橋需要一個)
目前沒有適用於此組態的驗證程序。
目前尚無適用於此組態的具體疑難排解資訊。
附註:有關配置示例,請參閱以下指南:
修訂 | 發佈日期 | 意見 |
---|---|---|
1.0 |
30-Sep-2021 |
初始版本 |