在本期中，我將展示並解釋在故障轉移叢集模式下設定 CMS 伺服器的一些複雜問題。
理論一般來說，CMS伺服器部署有以下三種：
- 單組合（單一組合），即這是一台運行所有必要服務的伺服器。 在大多數情況下，這種類型的部署僅適用於內部客戶端存取以及單一伺服器的可擴展性和冗餘限制不是關鍵問題的較小環境，或者CMS 只執行某些功能（例如ad hoc）的情況. Cisco UCM 會議。
大致工作方案：
- 單分體（單分割）透過新增單獨的伺服器用於外部存取來擴展先前的部署類型。 在傳統部署中，這意味著在外部用戶端可以存取的非軍事網段 (DMZ) 中部署一台 CMS 伺服器，並在內部用戶端可以存取 CMS 的網路核心中部署一台 CMS 伺服器。 這種特定的部署模型現在正在被所謂的類型所取代 單邊，由伺服器組成 思科高速公路，它具有或將具有許多相同的防火牆繞過功能，因此客戶端無需添加專用的邊緣 CMS 伺服器。
大致工作方案：
- 可擴展且有彈性（可擴展且容錯）此類型包括每個組件的冗餘，允許系統根據您的需求增長到其最大容量，同時在發生故障時提供冗餘。 它還使用單邊緣概念來提供安全的外部存取。 這就是我們將在本集中看到的類型。 如果我們了解如何部署這種類型的集群，我們不僅能夠了解其他類型的部署，而且還能夠了解如何建立 CMS 伺服器集群來適應潛在的需求成長。
在繼續部署之前，您需要了解一些基本知識，即
主要 CMS 軟體元件：
- 數據庫：允許您組合一些配置，例如撥號計劃、使用者空間和使用者本身。 僅支援叢集以實現高可用性（單主）。
- 呼叫橋：音訊和視訊會議服務，可完全控制呼叫和多媒體進程的管理和處理。 支援叢集以實現高可用性和可擴展性。
- XMPP伺服器：負責使用思科會議應用程式和/或 WebRTC 進行客戶端的註冊和身份驗證（即時通信，或只是在瀏覽器中），以及組件間訊號傳輸。 只能為了高可用性而叢集。
- 橋：提供對 WebRTC 的客戶端存取。
- 負載平衡器：為單分割模式下的思科會議應用程式提供單一連接點。 偵聽外部介面和連接埠的傳入連線。 同樣，負載平衡器接受來自 XMPP 伺服器的傳入 TLS 連接，透過該連接它可以切換來自外部客戶端的 TCP 連接。
在我們的場景中，不需要它。 - TURN伺服器：提供防火牆旁通技術，允許
將我們的 CMS 置於防火牆或 NAT 後面，以使用思科會議應用程式或 SIP 裝置連接外部用戶端。 在我們的場景中，不需要它。 - 網頁管理：管理介面和 API 訪問，包括特殊的 Unified CM 會議。
配置模式
與大多數其他思科產品不同，思科會議伺服器支援三種設定方法來適應任何類型的部署。
- 命令列 (CLI)：稱為 MMP 的命令列介面，用於初始設定和證書任務。
- 網頁管理員：主要用於 CallBridge 相關配置，尤其是在設定單一非叢集伺服器時。
- REST API：用於最複雜的配置任務和叢集資料庫相關任務。
除了上述之外，還使用該協議 SFTP 與 CMS 伺服器之間傳輸檔案（通常是許可證、憑證或日誌）。
思科的部署指南中用白色和英文寫著需要部署集群 至少三個 資料庫上下文中的伺服器（節點）。 因為只有在奇數個節點時，選擇新Database Master的機制才會運作，而且一般來說Database Master與大多數CMS伺服器資料庫都有連線。
實踐表明，兩台伺服器（節點）確實不夠。 選擇機制在Master重新啟動時起作用，只有在重新啟動的伺服器啟動後，Slave伺服器才成為Master。 但是，如果在兩台伺服器組成的叢集中，Master 伺服器突然宕機，那麼 Slave 伺服器就不會成為 Master，而如果 Slave 宕機，那麼剩下的 Master 伺服器就會變成 Slave。
但在 XMPP 的背景下，確實有必要組裝一個由三台伺服器組成的集群，因為例如，如果您在 XMMP 處於 Leader 狀態的其中一台伺服器上停用 XMPP 服務，那麼在其餘伺服器上，XMPP 將保持 Follower 狀態，並且 CallBridge 與 XMPP 的連線將斷開，因為CallBridge 專門連接到具有領導者狀態的 XMPP。 這很關鍵，因為… 一個電話都不會接通。
在同一部署指南中也示範了具有一台 XMPP 伺服器的叢集。
考慮到上述情況，原因就很清楚了：它之所以有效，是因為它處於故障轉移模式。
在我們的例子中，XMPP 伺服器將出現在所有三個節點上。
假設我們的所有三台伺服器都已啟動。
DNS 記錄
在開始設定伺服器之前，您需要建立 DNS 記錄 А и SRV 類型：
請注意，在我們的 DNS 記錄中有兩個網域 example.com 和 機密.example.com。 example.com 是所有 Cisco Unified Communications Manager 訂閱者都可以將其用作 URI 的網域，該網域很可能存在於您的基礎架構中或很可能存在。 或 example.com 與使用者用於其電子郵件地址的網域相符。 或者您筆記型電腦上的 Jabber 用戶端可能有一個 URI [電子郵件保護]. 領域 機密.example.com 是將為 Cisco Meeting Server 使用者設定的網域。 思科會議伺服器的網域將是 機密.example.com，因此對於同一個 Jabber 用戶，需要使用 user@ URI 登入 Cisco Meeting Server機密.example.com。
基本配置
以下所述的所有設定均顯示在一台伺服器上，但需要在叢集中的每台伺服器上完成。
服務質量
由於 CMS 生成 實時的 流量對延遲和封包遺失敏感，大多數情況下建議配置服務品質 (QoS)。 為了實現這一點，CMS 支援使用它產生的差分服務代碼 (DSCP) 來標記封包。 儘管基於 DSCP 的流量優先順序取決於基礎架構的網路元件處理流量的方式，但在我們的範例中，我們將使用基於 QoS 最佳實踐的典型 DSCP 優先權來設定 CMS。
在每個伺服器上我們將輸入這些命令
dscp 4 multimedia 0x22
dscp 4 multimedia-streaming 0x22
dscp 4 voice 0x2E
dscp 4 signaling 0x1A
dscp 4 low-latency 0x1A因此，所有視訊流量都標記為 AF41 (DSCP 0x22)，所有語音流量都標記為 EF (DSCP 0x2E)，其他類型的低延遲流量（例如 SIP 和 XMPP）使用 AF31 (DSCP 0x1A)。
我們檢查：
NTP
網路時間協定 (NTP) 不僅對於提供準確的通話和會議時間戳很重要，而且對於驗證證書也很重要。
使用以下命令將 NTP 伺服器新增至您的基礎架構中
ntp server add <server>
在我們的例子中，有兩個這樣的伺服器，所以會有兩個團隊。
我們檢查：
並設定我們伺服器的時區
DNS
我們使用以下命令將 DNS 伺服器新增至 CMS：
dns add forwardzone <domain-name> <server ip>
在我們的例子中，有兩個這樣的伺服器，所以會有兩個團隊。
我們檢查：
網路介面配置
我們使用以下命令配置介面：
ipv4 <interface> add <address>/<prefix length> <gateway>
我們檢查：
伺服器名稱（主機名稱）
我們使用以下命令設定伺服器名稱：
hostname <name>
然後我們重新啟動。
這樣就完成了基本配置。
認證
理論Cisco Meeting Server 需要各個元件之間的加密通信，因此所有 CMS 部署都需要 X.509 憑證。 它們有助於確保服務/伺服器受到其他伺服器/服務的信任。
每個服務都需要一個證書，但為每個服務建立單獨的證書可能會導致混亂和不必要的複雜性。 幸運的是，我們可以產生憑證的公鑰-私鑰對，然後在多個服務中重複使用它們。 在我們的範例中，相同的憑證將用於呼叫橋接器、XMPP 伺服器、Web 橋接器和 Web 管理。 因此，您需要為叢集中的每台伺服器建立一對公鑰和私鑰憑證金鑰。
然而，資料庫叢集有一些特殊的憑證要求，因此需要有自己的與其他服務不同的憑證。 CMS 使用伺服器證書，該證書與其他伺服器使用的證書類似，但也有用於資料庫連接的用戶端證書。 資料庫證書用於身份驗證和加密。 它不提供客戶端連接資料庫的使用者名稱和密碼，而是提供伺服器信任的客戶端憑證。 資料庫叢集中的每台伺服器都將使用相同的公鑰和私鑰對。 這允許叢集中的所有伺服器以只能由也共享相同金鑰對的其他伺服器解密的方式加密資料。
為了實現冗餘，資料庫叢集必須至少包含 3 台伺服器，但不得超過 5 台，任何叢集成員之間的最大往返時間為 200 毫秒。 此限制比呼叫橋群集更具限制性，因此它通常是地理分散部署中的限制因素。
CMS 的資料庫角色有許多獨特的要求。 與其他角色不同，它需要客戶端和伺服器證書，其中客戶端證書具有呈現給伺服器的特定 CN 欄位。
CMS 使用具有一個主資料庫和多個完全相同的副本的 postgres 資料庫。 一次只有一個主資料庫（「資料庫伺服器」）。 叢集的其餘成員是副本或「資料庫客戶端」。
資料庫叢集需要專用伺服器憑證和客戶端憑證。 它們必須由憑證簽名，通常是內部私有憑證授權單位。 由於資料庫叢集的任何成員都可以成為主伺服器，因此必須將資料庫伺服器和客戶端憑證對（包含公鑰和私鑰）複製到所有伺服器，以便它們可以採用客戶端或資料庫伺服器的身份。 另外，還必須載入CA根證書，以確保客戶端和伺服器端的證書能夠被驗證。
因此，我們建立一個憑證請求，該憑證將由除資料庫之外的所有伺服器服務使用（對此將有一個單獨的請求），命令如下：
pki csr hostname CN:cms.example.com subjectAltName:hostname.example.com,example.com,conf.example.com,join.example.com
在 CN 中，我們寫下我們伺服器的通用名稱。 例如，如果我們伺服器的主機名 server01, server02, server03，那麼 CN 將是 server.example.com
我們在其餘兩台伺服器上執行相同的操作，不同之處在於命令將包含相應的“主機名稱”
我們產生兩個證書請求，資料庫服務將使用這些證書，命令如下：
pki csr dbclusterserver CN:hostname1.example.com subjectAltName:hostname2.example.com,hostname3.example.com
pki csr dbclusterclient CN:postgres哪裡 資料庫叢集伺服器 и 資料庫叢集客戶端 我們的請求和未來證書的名稱， 主機名稱1(2)(3) 相應伺服器的名稱。
我們僅在一台伺服器上執行此程序（！），並將憑證和相應的 .key 檔案上傳到其他伺服器。
在 AD CS 中啟用用戶端憑證模式
您還需要將每台伺服器的憑證合併到一個檔案中。在 *NIX 上：
cat server01.cer server02.cer server03.cer > server.cer在 Windows/DOS 上：
copy server01.cer + server02.cer + server03.cer server.cer
並上傳到各個伺服器：
1.「個人」伺服器憑證。
2. 根證書（連同中間證書，如果有的話）。
3. 資料庫（「伺服器」和「客戶端」）的憑證以及帶有 .key 副檔名的文件，這些憑證是在建立「伺服器」和「客戶端」資料庫憑證的請求時產生的。 這些文件在所有伺服器上必須相同。
4. 所有三份「個人」證書的歸檔。
因此，您應該在每台伺服器上獲得類似此文件圖片的內容。
數據庫集群
現在您已將所有憑證上傳到 CMS 伺服器，您可以在三個節點之間設定和啟用資料庫叢集。 第一步是選擇一台伺服器作為資料庫叢集的主節點並對其進行全面配置。
主資料庫
設定資料庫複製的第一步是指定將用於資料庫的憑證。 這是使用以下命令完成的：
database cluster certs <server_key> <server_crt> <client_key> <client_crt> <ca_crt>現在讓我們使用以下命令告訴 CMS 使用哪個介面進行資料庫叢集：
database cluster localnode a然後我們使用以下命令初始化主伺服器上的叢集資料庫：
database cluster initialize
客戶端資料庫節點
我們執行相同的過程，只是代替命令 資料庫叢集初始化 輸入如下命令：
database cluster join <ip address existing master>其中 ip 位址 初始化叢集的 CMS 伺服器的現有主 IP 位址，簡稱 Master。
我們使用以下命令檢查資料庫叢集在所有伺服器上的工作情況：
database cluster status
我們在剩餘的第三台伺服器上執行相同的操作。
結果發現我們的第一台伺服器是Master，其餘的都是Slave。
網路管理服務
啟用Web管理員服務：
webadmin listen a 445選擇連接埠 445 是因為連接埠 443 用於使用者存取 Web 用戶端
我們使用憑證檔案來設定 Web 管理服務，命令如下：
webadmin certs <keyfile> <certificatefile> <ca bundle>並使用以下命令啟用 Web Admin：
webadmin enable
如果一切順利，我們將收到 SUCCESS 行，表示 Web 管理已正確設定網路和憑證。 我們使用網頁瀏覽器檢查服務的功能並輸入網路管理員的位址，例如： ：445
呼叫橋集群
呼叫橋是每個 CMS 部署中唯一存在的服務。 呼叫橋是主要的會議機制。 它還提供一個 SIP 接口，以便可以透過 Cisco Unified CM 等將呼叫路由至該接口或從該接口路由出呼叫。
必須在具有適當憑證的每台伺服器上執行下面所述的命令。
所以：
我們使用以下命令將憑證與呼叫橋接服務關聯起來：
callbridge certs <keyfile> <certificatefile>[<cert-bundle>]我們使用以下命令將 CallBridge 服務綁定到我們需要的介面：
callbridge listen a並使用以下命令重新啟動服務：
callbridge restart
現在我們已經配置了呼叫橋，我們可以配置呼叫橋集群。 呼叫橋群集不同於資料庫或 XMPP 群集。 呼叫橋集群可以支援 2 到 8 個節點，沒有任何限制。 它不僅提供冗餘，還提供負載平衡，以便可以使用智慧呼叫分配在呼叫橋伺服器之間主動分配會議。 CMS 具有附加功能、呼叫橋接群組和可用於進一步管理的相關功能。
呼叫橋集群主要透過 Web 管理介面進行配置
必須在叢集中的每台伺服器上執行下述過程。
因此，
1. 透過 Web 存取配置 > 叢集。
2。 在 呼叫橋身份 輸入與伺服器名稱相對應的 callbridge[01,02,03] 作為唯一名稱。 這些名稱是任意的，但對於該叢集必須是唯一的。 它們本質上是描述性的，因為它們表明它們是伺服器標識符[01,02,03]。
3.B 叢集呼叫橋 輸入叢集中伺服器的 Web 管理員 URL， [01,02,03].example.com:445，位於位址欄位中。 請務必指定連接埠。 您可以將對等連結 SIP 網域留空。
4. 在每個伺服器的CallBridge信任中新增一個證書，該檔案包含我們伺服器的所有證書，我們一開始就合併到這個檔案中，命令如下：
callbridge trust cluster <trusted cluster certificate bundle>並使用以下命令重新啟動服務：
callbridge restart
因此，在每台伺服器上您都應該得到這樣的圖片：
XMPP集群
CMS 中的 XMPP 服務用於處理思科會議應用程式 (CMA) 的所有註冊和身份驗證，包括 CMA WebRTC Web 用戶端。 呼叫橋本身也充當用於身份驗證目的的 XMPP 用戶端，因此必須像其他用戶端一樣進行設定。 XMPP容錯是從2.1版本開始在生產環境中支援的功能
必須在具有適當憑證的每台伺服器上執行下面所述的命令。
所以：
我們使用以下命令將憑證與 XMPP 服務關聯起來：
xmpp certs <keyfile> <certificatefile>[<cert-bundle>]然後使用命令定義監聽介面：
xmpp listen aXMPP 服務需要唯一的網域。 這是用戶的登入。 換句話說，當使用者嘗試使用 CMA 應用程式（或透過 WebRTC 用戶端）登入時，他們輸入 userID@logindomain。 在我們的例子中，它將是 userid@機密.example.com。 為什麼不只是 example.com？ 在我們的特定部署中，我們選擇 Jabber 使用者將在 Unified CM 中使用的 Unified CM 網域為 example.com，因此我們需要一個不同的網域供 CMS 使用者透過 SIP 網域將呼叫路由到 CMS 或從 CMS 路由。
使用以下命令設定 XMPP 網域：
xmpp domain <domain>並使用以下命令啟用 XMPP 服務：
xmpp enable在 XMPP 服務中，您必須為註冊 XMPP 服務時所使用的每個呼叫橋建立憑證。 這些名稱是任意的（並且與您為呼叫橋群集配置的唯一名稱無關）。 您必須在一台 XMPP 伺服器上新增三個呼叫橋，然後在叢集中的其他 XMPP 伺服器上輸入這些憑證，因為此設定不適合叢集資料庫。 稍後我們將配置每個呼叫橋以使用此名稱和金鑰來註冊 XMPP 服務。
現在我們需要在第一台伺服器上設定 XMPP 服務，其中包含三個呼叫橋 callbridge01、callbridge02 和 callbridge03。 每個帳戶將被分配隨機密碼。 稍後將在其他呼叫橋接伺服器上輸入它們以登入此 XMPP 伺服器。 輸入以下命令：
xmpp callbridge add callbridge01
xmpp callbridge add callbridge02
xmpp callbridge add callbridge03結果，我們用命令檢查發生了什麼事：
xmpp callbridge list
完成下述步驟後，其餘伺服器上應該會出現完全相同的圖片。
接下來，我們在其餘兩台伺服器上添加完全相同的設置，僅使用命令
xmpp callbridge add-secret callbridge01
xmpp callbridge add-secret callbridge02
xmpp callbridge add-secret callbridge03我們非常小心地添加 Secret，以便其中沒有多餘的空格。
因此，每個伺服器應該有相同的圖片：
接下來，在叢集中的所有伺服器上，我們以信任方式指定包含所有三個憑證的文件，該文件是先前使用以下命令建立的：
xmpp cluster trust <trust bundle>我們使用以下命令在所有叢集伺服器上啟用 xmpp 叢集模式：
xmpp cluster enable在叢集的第一台伺服器上，我們使用以下命令啟動 xmpp 叢集的建立：
xmpp cluster initialize在其他伺服器上，使用以下命令將叢集新增至 xmpp：
xmpp cluster join <ip address head xmpp server>我們使用以下命令檢查每台伺服器是否成功建立 XMPP 叢集：
xmpp status
xmpp cluster status第一個伺服器：
第二台伺服器：
第三台伺服器：
將呼叫橋連接到 XMPP
現在 XMPP 叢集正在運行，您需要設定呼叫橋接服務以連接到 XMPP 叢集。 此配置是透過網路管理員完成的。
在每台伺服器上，前往設定 > 常規並在欄位中 唯一的呼叫橋名稱 寫入與伺服器 Call Bridge 對應的唯一名稱 呼叫橋[01,02,03]... 在現場 域 conf.example.ru 以及相應的密碼，您可以監視它們
在叢集中的任何伺服器上使用以下命令：
xmpp callbridge list
將“伺服器”欄位留空 呼叫橋 將執行 DNS SRV 查找 _xmpp-component._tcp.conf.example.com尋找可用的 XMPP 伺服器。 每個伺服器上用於將 Callbridge 連接到 XMPP 的 IP 位址可能有所不同，這取決於記錄請求傳回的值 _xmpp-component._tcp.conf.example.com callbridge，這又取決於給定 DNS 記錄的優先權設定。
接下來，進入“狀態 > 常規”，驗證 Call Bride 服務是否成功連線到 XMPP 服務。
橋
在叢集中的每台伺服器上，使用下列命令啟用 Web Bridge 服務：
webbridge listen a:443我們使用憑證檔案來設定 Web Bridge 服務，指令如下：
webbridge certs <keyfile> <certificatefile> <ca bundle>Web Bridge 支援 HTTPS。 如果配置為使用“http-redirect”，它將把 HTTP 重新導向到 HTTPS。
若要啟用 HTTP 重新導向，請使用下列命令：
webbridge http-redirect enable要讓 Call Bridge 知道 Web Bridge 可以信任來自 Call Bridge 的連接，請使用以下命令：
webbridge trust <certfile>其中這是一個包含叢集中每台伺服器的所有三個憑證的檔案。
該圖片應該位於叢集中的每台伺服器上。
現在我們需要建立一個具有「appadmin」角色的用戶，我們需要它，以便我們可以配置我們的叢集（！），而不是單獨配置叢集中的每個伺服器，這樣設定將平等地應用於每個伺服器，儘管事實上它們只會被製作一次。
為了進一步設置，我們將使用 .
對於授權，請在“授權”部分中選擇“基本”
為了正確地發送命令到CMS伺服器，需要設定所需的編碼
我們使用下列命令指定 Webbridge 解決方案&帖子 帶參數 網址 和意義
在網橋本身中，我們指示所需的參數：訪客訪問、受保護的訪問等。
呼叫橋接組
預設情況下，CMS 並不總是最有效地利用可用的會議資源。
例如，對於具有三個參與者的會議，每個參與者最終可能會進入三個不同的呼叫橋。 為了使這三個參與者能夠相互通信，呼叫橋將自動在同一空間中的所有伺服器和客戶端之間建立連接，這樣看起來就好像所有客戶端都在同一台伺服器上一樣。 不幸的是，這樣做的缺點是單一 3 人會議現在將消耗 9 個媒體連接埠。 這顯然是對資源的低效率利用。 此外，當呼叫橋真正過載時，預設機制是繼續接受呼叫並向該呼叫橋的所有訂戶提供降低品質的服務。
使用呼叫橋接組功能可以解決這些問題。 此功能在 Cisco Meeting Server 軟體 2.1 版中引入，並已擴展為支援入站和出站 Cisco Meeting App (CMA) 呼叫（包括 WebRTC 參與者）的負載平衡。
為了解決重新連接問題，為每個呼叫橋引入了三個可配置的負載限制：
負載限制 — 這是特定呼叫橋的最大數位負載。 每個平台都有建議的負載限制，例如 CMS96000 為 1000，虛擬機器每個 vCPU 為 1.25 GHz。 不同的呼叫會消耗一定量的資源，這取決於參與者的解析度和幀速率。
新會議負載限制基礎點 （預設 50% loadLimit）- 設定伺服器負載限制，超過此限制後新會議將被拒絕。
現有會議負載限制基本點 （預設為 loadLimit 的 80%）- 伺服器負載值，超過該值後，參加者加入現有會議將被拒絕。
雖然此功能是為呼叫分配和負載平衡而設計的，但其他群組（例如 TURN 伺服器、Web Bridge 伺服器和錄音機）也可以指派給呼叫橋接組，以便它們也可以正確分組以實現最佳使用。 如果這些物件中的任何一個未指派給呼叫群組，則假定它們對所有伺服器可用，沒有任何特定優先權。
這些參數在這裡配置： ：445 / api / v1 /系統/配置/集群
接下來，我們向每個 Callbridge 指示它屬於哪個 Callbridge 群組：
第一個呼叫橋
第二個呼叫橋
第三呼叫橋
因此，我們配置了呼叫橋接群組，以更有效地使用 Cisco Meeting Server 叢集的資源。
從 Active Directory 匯入用戶
Web Admin 服務有一個 LDAP 配置部分，但它不提供複雜的配置選項，而且資訊不會儲存在叢集資料庫中，因此必須透過 Web 介面在每個伺服器上手動完成配置，或透過API，所以我們「三聲不起來」仍然會透過API來設定資料。
使用URL訪問 :445/api/v1/ldapServers 建立 LDAP Server 對象，指定參數，例如：
- 服務器 IP
- 端口號
- 用戶名
- 密碼
- 安全
安全性 - 根據連接埠選擇 true 或 false，389 - 不安全，636 - 受保護。
將 LDAP 來源參數對應到 Cisco Meeting Server 中的屬性。
LDAP 對應將 LDAP 目錄中的屬性對應到 CMS 中的屬性。 實際屬性：
- jid映射
- 名稱映射
- coSpace名稱映射
- coSpaceUri映射
- coSpaceSecondaryUriMapping
屬性說明美洲開發銀行 代表使用者在CMS中的登入ID。 由於這是 Microsoft Active Directory LDAP 伺服器，因此 CMS JID 會對應到 LDAP 中的 sAMAccountName，這本質上是使用者的 Active Directory 登入 ID。 另請注意，您採用 sAMAccountName 並將網域 conf.pod6.cms.lab 新增至其末尾，因為這是您的使用者將用於登入 CMS 的登入名稱。
名稱映射 將 Active Directory displayName 欄位中包含的內容與使用者的 CMS 名稱欄位進行比對。
coSpace名稱映射 根據 displayName 欄位建立 CMS 空間名稱。 此屬性與 coSpaceUriMapping 屬性一起是為每個使用者建立空間所必需的。
coSpaceUri映射 定義與使用者個人空間關聯的 URI 的使用者部分。 某些網域可以設定為撥入太空。 如果使用者部分與這些網域之一的此欄位匹配，則呼叫將定向到該使用者的空間。
coSpaceSecondaryUriMapping 定義第二個 URI 來到達空間。 這可用於新增數字別名，以將呼叫路由到匯入的使用者空間，作為 coSpaceUriMapping 參數中定義的字母數字 URI 的替代方案。
LDAP 伺服器和 LDAP 映射已配置。 現在您需要透過建立 LDAP 來源將它們連結在一起。
使用URL訪問 :445/api/v1/ldapSource 建立 LDAP Source 對象，指定參數，例如：
- 服務器
- 映射
- 基本Dn
- 過濾器
現在LDAP配置已完成，您可以執行手動同步操作。
我們可以在每個伺服器的 Web 介面中按一下 立即同步 部分 活動目錄
或透過 API 使用以下命令 解決方案&帖子 使用URL訪問 :445/api/v1/ldapSyncs
臨時會議
這是什麼？在傳統概念中，會議是指兩個參與者正在彼此交談，其中一個參與者（使用註冊了 Unified CM 的設備）按下“會議”按鈕，呼叫另一個人，並與該第三方通話後，再次按下「會議」按鈕，將所有與會者加入三方會議。
Ad-Hoc 會議與 CMS 中的預定會議的差異在於 Ad-Hoc 會議不僅僅是對 CMS 的 SIP 通話。 當會議發起者再次按一下「會議」按鈕邀請所有人參加同一個會議時，Unified CM 必須對 CMS 進行 API 呼叫以建立即時會議，然後將所有通話轉接至該會議。 所有這一切都在參與者沒有註意到的情況下發生。
這表示 Unified CM 必須將 API 憑證和服務的 WebAdmin 位址/連接埠以及直接連接到 CMS 伺服器的 SIP 中繼配置為繼續呼叫。
如果有必要，CUCM可以在CMS中動態建立一個空間，以便每個呼叫都可以到達CMS並匹配用於空間的來電規則。
與 CUCM 集成 按照文章中所述的相同方式配置 除了在Cisco UCM 上，您需要為CMS 建立三個中繼、三個會議橋、在SIP 安全性設定檔中指定三個主題名稱、路由組、路由列表、媒體資源組和媒體資源組列表，並添加一些路由規則到思科會議伺服器。
SIP 安全設定檔:
內褲:
每個行李箱看起來都一樣：
會議橋
每個會議橋看起來都一樣：
航線組
路線列表
媒體資源組
媒體資源組列表
通話規則
與 Unified CM 或 Expressway 等更進階的呼叫管理系統不同，CMS 僅在 SIP 請求 URI 欄位中尋找新呼叫的網域。 因此，如果 SIP INVITE 用於 sip： [電子郵件保護]CMS 只關心domain.com。 CMS 遵循以下規則來決定要將呼叫路由到何處：
1. CMS 首先嘗試將 SIP 網域與來電規則中設定的網域進行比對。 然後，這些呼叫可以路由到（「目標」）空間或特定使用者、內部 IVR 或直接整合的 Microsoft Lync/Skype for Business (S4B) 目的地。
2. 如果來電規則中沒有符合的內容，CMS 將嘗試匹配呼叫轉接表中配置的網域。 如果匹配，規則可以明確拒絕呼叫或轉接呼叫。 此時，CMS 可能會重寫網域，這有時對於呼叫 Lync 域很有用。 您也可以選擇傳遞 throw，這意味著不會進一步修改任何字段，或使用內部 CMS 撥號計劃。 如果呼叫轉移規則不匹配，則預設拒絕呼叫。 請記住，在 CMS 中，雖然呼叫被“轉發”，但媒體仍然綁定到 CMS，這意味著它將位於信令和媒體流量路徑中。
那麼只有轉接的呼叫才受去電規則的約束。 這些設定決定呼叫傳送到的目的地、中繼類型（是新的 Lync 呼叫還是標準 SIP 呼叫）以及在呼叫轉接規則中未選擇轉接時可以執行的任何轉換。
這是臨時會議期間發生的情況的實際日誌
截圖顯示效果很差（我不知道如何讓它變得更好），所以我會這樣寫日誌：
Info 127.0.0.1:35870: API user "api" created new space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)
Info call create failed to find coSpace -- attempting to retrieve from database
Info API "001036270012" Space GUID: 7986bb6c-af4e-488d-9190-a75f16844e44 <--> Call GUID: 93bfb890-646c-4364-8795-9587bfdc55ba <--> Call Correlator GUID: 844a3c9c-8a1e-4568-bbc3-8a0cab5aed66 <--> Internal G
Info 127.0.0.1:35872: API user "api" created new call 93bfb890-646c-4364-8795-9587bfdc55ba
Info call 7: incoming SIP call from "sip:[email protected]" to local URI "sip:[email protected]:5060" / "sip:[email protected]"
Info API call leg bc0be45e-ce8f-411c-be04-594e0220c38e in call 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API call 93bfb890-646c-4364-8795-9587bfdc55ba)
Info conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 has control/media GUID: fb587c12-23d2-4351-af61-d6365cbd648d
Info conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 named "001036270012"
Info call 7: configured - API call leg bc0be45e-ce8f-411c-be04-594e0220c38e with SIP call ID "[email protected]"
Info call 7: setting up UDT RTP session for DTLS (combined media and control)
Info conference "001036270012": unencrypted call legs now present
Info participant "[email protected]" joined space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)
Info participant "[email protected]" (e8371f75-fb9e-4019-91ab-77665f6d8cc3) joined conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP
Info call 8: incoming SIP call from "sip:[email protected]" to local URI "sip:[email protected]:5060" / "sip:[email protected]"
Info API call leg db61b242-1c6f-49bd-8339-091f62f5777a in call 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API call 93bfb890-646c-4364-8795-9587bfdc55ba)
Info call 8: configured - API call leg db61b242-1c6f-49bd-8339-091f62f5777a with SIP call ID "[email protected]"
Info call 8: setting up UDT RTP session for DTLS (combined media and control)
Info call 9: incoming SIP call from "sip:[email protected]" to local URI "sip:[email protected]:5060" / "sip:[email protected]"
Info API call leg 37a6e86d-d457-47cf-be24-1dbe20ccf98a in call 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API call 93bfb890-646c-4364-8795-9587bfdc55ba)
Info call 9: configured - API call leg 37a6e86d-d457-47cf-be24-1dbe20ccf98a with SIP call ID "[email protected]"
Info call 9: setting up UDT RTP session for DTLS (combined media and control)
Info call 8: compensating for far end not matching payload types
Info participant "[email protected]" joined space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)
Info participant "[email protected]" (289e823d-6da8-486c-a7df-fe177f05e010) joined conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP
Info call 7: compensating for far end not matching payload types
Info call 8: non matching payload types mode 1/0
Info call 8: answering offer in non matching payload types mode
Info call 8: follow-up single codec offer received
Info call 8: non matching payload types mode 1/0
Info call 8: answering offer in non matching payload types mode
Info call 8: sending response to single-codec additional offer
Info call 9: compensating for far end not matching payload types
Info participant "[email protected]" joined space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)
Info participant "[email protected]" (d27e9a53-2c8a-4e9c-9363-0415cd812767) joined conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP
Info call 9: BFCP (client role) now active
Info call 9: sending BFCP hello as client following receipt of hello when BFCP not active
Info call 9: BFCP (client role) now active
Info call 7: ending; remote SIP teardown - connected for 0:13
Info call 7: destroying API call leg bc0be45e-ce8f-411c-be04-594e0220c38e
Info participant "[email protected]" left space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)
Info call 9: on hold
Info call 9: non matching payload types mode 1/0
Info call 9: answering offer in non matching payload types mode
Info call 8: on hold
Info call 8: follow-up single codec offer received
Info call 8: non matching payload types mode 1/0
Info call 8: answering offer in non matching payload types mode
Info call 8: sending response to single-codec additional offer
Info call 9: ending; remote SIP teardown - connected for 0:12臨時會議本身：
來電規則
為了能夠在 CMS 中接收呼叫，需要配置來電參數。 如您在 LDAP 設定中所看到的，所有使用者都是透過網域 conf.pod6.cms.lab 匯入的。 因此，您至少希望調用該域以定位空間。 您還需要為每個 CMS 伺服器的完全限定網域名稱（甚至可能是 IP 位址）設定所有規則。 我們的外部呼叫控制 Unified CM 將單獨配置專用於每個 CMS 伺服器的 SIP 中繼。 根據這些 SIP 幹線的目的地是 IP 位址還是伺服器的 FQDN，將確定 CMS 是否需要配置為接受定向到其 IP 位址或 FQDN 的呼叫。
具有最高優先權入站規則的網域將用作任何使用者空間的網域。 當使用者透過 LDAP 同步時，CMS 會自動建立空間，但僅建立 URI 的使用者部分 (coSpaceUriMapping)，例如 user.space。 部分 完整的 URI 是根據此規則產生的。 事實上，如果您此時登入 Web Bridge，您會看到 Space URI 沒有網域。 透過將此規則設為最高優先級，您可以將產生的空間的網域設定為 conf。example.com。
呼出規則
若要允許使用者向 Unified CM 叢集發出出站呼叫，您必須設定出站規則。 向 Unified CM 註冊的端點（例如 Jabber）的網域是 example.com。 對此域的呼叫應以標準 SIP 呼叫路由至 Unified CM 呼叫處理節點。 主伺服器是 cucm-01.example.com，附加伺服器是 cucm-02.example.com。
第一條規則描述了在叢集伺服器之間最簡單的呼叫路由。
領域 來自網域的本地 負責在「@」符號之後在呼叫者的 SIP-URI 中顯示被呼叫者的內容。 如果我們將其留空，那麼在「@」符號之後將是該呼叫所通過的 CUCM 的 IP 位址。 如果我們指定一個域，那麼「@」符號後面實際上會有一個域。 為了能夠回叫，這是必要的，否則將無法透過 SIP-URI name@ip-address 回叫。
如有指示請致電 來自網域的本地
打電話時 不 已指示 來自網域的本地
請務必為撥出呼叫明確指定“加密”或“未加密”，因為“自動”參數不起作用。
記錄
視訊會議由錄製伺服器錄製。 錄音機與 Cisco Meeting Server 完全相同。 Recorder 不需要安裝任何授權。 執行 CallBridge 服務的伺服器需要錄製許可證，即需要錄製許可證，並且必須將其應用於 CallBridge 元件，而不是應用於執行 Recorder 的伺服器。 Recorder 可作為可擴充訊息傳遞和狀態協定 (XMPP) 用戶端，因此必須在託管 CallBridge 的伺服器上啟用 XMPP 伺服器。
因為我們有一個集群，許可證需要在集群中的所有三台伺服器上「延伸」。 然後，只需在您的個人帳戶中的授權中關聯（新增）叢集中包含的所有 CMS 伺服器的 a 介面的 MAC 位址即可。
這是叢集中每台伺服器上應該會出現的圖片
一般來說，放置Recorder有幾個場景，但我們會堅持這種：
在設定Recorder之前，您需要準備一個實際錄製視訊會議的地方。 其實在這裡 ，如何設定所有錄音。 我重點關注要點和細節：
1. 最好從叢集中的第一台伺服器取得憑證。
2. 由於記錄器信任中指定了錯誤的證書，可能會出現「記錄器不可用」錯誤。
3. 如果指定錄製的NFS目錄不是根目錄，則可能無法寫入。
有時需要自動錄製某個特定使用者或空間的會議。
為此，請建立兩個 CallProfile：
停用錄音
並具有自動錄音功能
接下來，我們將一個具有自動錄音功能的CallProfile「附加」到所需的空間。
在 CMS 中，它是這樣建立的：如果 CallProfile 明確綁定到任何空間或空間，則該 CallProfile 僅在與這些特定空間相關時運作。 如果 CallProfile 未綁定到任何空間，則預設情況下它將應用於未明確綁定 CallProfile 的那些空間。
下次我將嘗試描述如何在組織內部網路之外存取 CMS。
來源：
來源： www.habr.com