시스코 미팅 서버 2.5.2. 화상 회의 녹화 기능을 갖춘 확장 가능하고 복원력 있는 모드의 클러스터

이번 호에서는 장애 조치 클러스터 모드에서 CMS 서버를 설정하는 복잡한 과정 중 일부를 보여주고 설명하겠습니다.


Теория일반적으로 CMS 서버 배포에는 세 가지 유형이 있습니다.

• 단일 결합(단일 결합), 즉 이는 필요한 모든 서비스가 실행되는 하나의 서버입니다. 대부분의 경우 이러한 유형의 배포는 내부 클라이언트 액세스 및 단일 서버의 확장성 및 중복성 제한이 중요한 문제가 아닌 소규모 환경이나 CMS가 임시와 같은 특정 기능만 수행하는 상황에만 적합합니다. Cisco UCM 컨퍼런스.

  대략적인 작업 계획:
  

• 단일 분할(단일 분할)은 외부 액세스를 위해 별도의 서버를 추가하여 이전 배포 유형을 확장합니다. 레거시 배포에서 이는 외부 클라이언트가 액세스할 수 있는 DMZ(완충 네트워크 세그먼트)에 CMS 서버를 배포하고 내부 클라이언트가 CMS에 액세스할 수 있는 네트워크 코어에 CMS 서버 하나를 배포하는 것을 의미했습니다. 이 특정 배포 모델은 이제 소위 유형으로 대체되고 있습니다. 단일 가장자리, 서버로 구성됨 시스코 고속도로, 동일한 방화벽 우회 기능이 많거나 많을 것이므로 클라이언트는 전용 에지 CMS 서버를 추가할 필요가 없습니다.

  대략적인 작업 계획:
  

• 확장성과 탄력성(확장 가능 및 내결함성) 이 유형에는 각 구성 요소에 대한 중복성이 포함되어 있어 필요에 따라 시스템을 최대 용량까지 확장하는 동시에 장애 발생 시 중복성을 제공할 수 있습니다. 또한 단일 에지 개념을 사용하여 안전한 외부 액세스를 제공합니다. 이것이 이번 에피소드에서 살펴볼 유형입니다. 이러한 유형의 클러스터를 배포하는 방법을 이해하면 다른 유형의 배포도 이해할 수 있을 뿐만 아니라 잠재적인 수요 증가를 수용하기 위해 CMS 서버 클러스터를 만드는 방법도 이해할 수 있습니다.

배포를 진행하기 전에 다음과 같은 몇 가지 기본 사항을 이해해야 합니다.

주요 CMS 소프트웨어 구성 요소:

• 데이터베이스: 다이얼 플랜, 사용자 공간, 사용자 자체 등 일부 구성을 결합할 수 있습니다. 고가용성을 위한 클러스터링(단일 마스터)만 지원합니다.
• 콜 브리지: 통화 및 멀티미디어 프로세스의 관리 및 처리를 완벽하게 제어할 수 있는 오디오 및 비디오 회의 서비스입니다. 고가용성과 확장성을 위해 클러스터링을 지원합니다.
• XMPP 서버: Cisco Meeting Application 및/또는 WebRTC(실시간 통신 또는 단순히 브라우저에서), 상호 구성 요소 신호 전달도 가능합니다. 고가용성을 위해서만 클러스터링할 수 있습니다.
• 웹브릿지: WebRTC에 대한 클라이언트 액세스를 제공합니다.
• 로드밸런서: 단일 분할 모드에서 Cisco Meeting Apps에 대한 단일 연결 지점을 제공합니다. 들어오는 연결에 대해 외부 인터페이스와 포트를 수신합니다. 마찬가지로 로드 밸런서는 XMPP 서버에서 들어오는 TLS 연결을 수락하고 이를 통해 외부 클라이언트의 TCP 연결을 전환할 수 있습니다.
  우리 시나리오에서는 필요하지 않습니다.
• 턴 서버: 방화벽 우회 기술을 제공합니다.
  Cisco Meeting App 또는 SIP 장치를 사용하여 외부 클라이언트를 연결하려면 CMS를 방화벽 또는 NAT 뒤에 배치하십시오. 우리 시나리오에서는 필요하지 않습니다.
• 웹 관리자: 특별 Unified CM 회의를 포함한 관리 인터페이스 및 API 액세스.

구성 모드

대부분의 다른 Cisco 제품과 달리 Cisco Meeting Server는 모든 유형의 배포를 수용할 수 있는 세 가지 구성 방법을 지원합니다.

• 명령줄(CLI): 초기 구성 및 인증서 작업을 위한 MMP로 알려진 명령줄 인터페이스입니다.
• 웹 관리자: 주로 CallBridge 관련 구성에 사용되며, 특히 단일 비클러스터형 서버를 설정할 때 더욱 그렇습니다.
• REST API: 가장 복잡한 구성 작업 및 클러스터형 데이터베이스 관련 작업에 사용됩니다.

위의 프로토콜 외에도 사용되는 프로토콜은 다음과 같습니다. SFTP CMS 서버와 파일(일반적으로 라이센스, 인증서 또는 로그)을 전송합니다.

Cisco의 배포 가이드에는 클러스터를 배포해야 한다는 내용이 흰색과 영어로 적혀 있습니다. 적어도 XNUMX개 데이터베이스 컨텍스트의 서버(노드). 왜냐하면 홀수 개의 노드에서만 새 데이터베이스 마스터를 선택하는 메커니즘이 작동하며 일반적으로 데이터베이스 마스터는 대부분의 CMS 서버 데이터베이스와 연결됩니다.

그리고 실습에서 알 수 있듯이 두 개의 서버(노드)로는 실제로 충분하지 않습니다. 선택 메커니즘은 마스터가 재부팅될 때 작동하며, 슬레이브 서버는 재부팅된 서버가 가동된 후에만 마스터가 됩니다. 그러나 두 서버로 구성된 클러스터에서 마스터 서버가 갑자기 나가면 슬레이브 서버가 마스터가 되지 않고, 슬레이브가 나가면 나머지 마스터 서버가 슬레이브가 된다.

그러나 XMPP의 맥락에서는 서버 XNUMX개로 구성된 클러스터를 조립하는 것이 실제로 필요합니다. 예를 들어 XMMP가 리더 상태인 서버 중 하나에서 XMPP 서비스를 비활성화하면 나머지 서버에서 XMPP는 팔로어 상태로 유지되고 XMPP에 대한 CallBridge 연결이 끊어집니다. CallBridge는 리더 상태로 XMPP에만 연결됩니다. 그리고 이것은 매우 중요합니다. 왜냐면... 단 한 통의 통화도 통과되지 않습니다.

또한 동일한 배포 가이드에서는 하나의 XMPP 서버가 있는 클러스터를 보여줍니다.

그리고 위의 내용을 고려하면 그 이유가 분명해집니다. 장애 조치 모드에 있기 때문에 작동합니다.

우리의 경우 XMPP 서버는 세 노드 모두에 존재합니다.

세 대의 서버가 모두 작동 중이라고 가정합니다.

DNS 레코드

서버 설정을 시작하기 전에 DNS 레코드를 만들어야 합니다. А и SRV 유형:

우리의 DNS 레코드에는 example.com과 example.com이라는 두 개의 도메인이 있습니다. conf의.example.com. example.com은 모든 Cisco Unified Communication Manager 가입자가 자신의 인프라에 있거나 존재할 가능성이 가장 높은 URI에 사용할 수 있는 도메인입니다. 또는 example.com은 사용자가 이메일 주소로 사용하는 것과 동일한 도메인과 일치합니다. 또는 노트북의 Jabber 클라이언트에 URI가 있을 수 있습니다. [이메일 보호]. 도메인 conf의.example.com은 Cisco Meeting Server 사용자에 대해 구성될 도메인입니다. Cisco Meeting Server의 도메인은 다음과 같습니다. conf의.example.com, 동일한 Jabber 사용자의 경우 Cisco Meeting Server에 로그인하려면 user@ URI를 사용해야 합니다.conf의.example.com.

기본 구성

아래 설명된 모든 설정은 하나의 서버에 표시되지만 클러스터의 각 서버에서 수행해야 합니다.

QoS를

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(Network Time Protocol)는 통화 및 회의의 정확한 타임스탬프를 제공할 뿐만 아니라 인증서를 확인하는 데에도 중요합니다.

다음과 같은 명령을 사용하여 인프라에 NTP 서버를 추가하세요.

ntp server add <server>

우리의 경우에는 그러한 서버가 두 대 있으므로 두 개의 팀이 있습니다.
우리는 다음을 확인합니다.

그리고 서버의 시간대를 설정합니다.

DNS

다음과 같은 명령을 사용하여 CMS에 DNS 서버를 추가합니다.

dns add forwardzone <domain-name> <server ip>

우리의 경우에는 그러한 서버가 두 대 있으므로 두 개의 팀이 있습니다.
우리는 다음을 확인합니다.

네트워크 인터페이스 구성

다음과 같은 명령으로 인터페이스를 구성합니다.

ipv4 <interface> add <address>/<prefix length> <gateway>

우리는 다음을 확인합니다.

서버 이름(호스트 이름)

다음과 같은 명령을 사용하여 서버 이름을 설정합니다.

hostname <name>

그리고 재부팅합니다.


이것으로 기본 구성이 완료되었습니다.

인증서

ТеорияCisco Meeting Server에는 다양한 구성 요소 간의 암호화된 통신이 필요하므로 모든 CMS 배포에는 X.509 인증서가 필요합니다. 이는 다른 서버/서비스가 해당 서비스/서버를 신뢰하는지 확인하는 데 도움이 됩니다.

각 서비스에는 인증서가 필요하지만 각 서비스에 대해 별도의 인증서를 만들면 혼란과 불필요한 복잡성이 발생할 수 있습니다. 다행히 인증서의 공개-개인 키 쌍을 생성한 다음 여러 서비스에서 재사용할 수 있습니다. 우리의 경우 Call Bridge, XMPP Server, Web Bridge 및 Web Admin에 동일한 인증서가 사용됩니다. 따라서 클러스터의 각 서버에 대해 공개 및 개인 인증서 키 쌍을 생성해야 합니다.

그러나 데이터베이스 클러스터링에는 몇 가지 특별한 인증서 요구 사항이 있으므로 다른 서비스와는 다른 자체 인증서가 필요합니다. CMS는 다른 서버에서 사용하는 인증서와 유사한 서버 인증서를 사용하지만 데이터베이스 연결에 사용되는 클라이언트 인증서도 있습니다. 데이터베이스 인증서는 인증과 암호화 모두에 사용됩니다. 클라이언트가 데이터베이스에 연결하기 위한 사용자 이름과 비밀번호를 제공하는 대신 서버에서 신뢰하는 클라이언트 인증서를 제공합니다. 데이터베이스 클러스터의 각 서버는 동일한 공개 및 개인 키 쌍을 사용합니다. 이를 통해 클러스터의 모든 서버는 동일한 키 쌍을 공유하는 다른 서버에서만 해독할 수 있는 방식으로 데이터를 암호화할 수 있습니다.

중복성이 작동하려면 데이터베이스 클러스터는 최소 3대, 최대 5대 서버로 구성되어야 하며 클러스터 멤버 간 최대 왕복 시간은 200ms입니다. 이 제한은 통화 브리지 클러스터링보다 더 제한적이므로 지리적으로 분산된 배포에서는 제한 요소가 되는 경우가 많습니다.

CMS의 데이터베이스 역할에는 여러 가지 고유한 요구 사항이 있습니다. 다른 역할과 달리 클라이언트 인증서에는 서버에 제공되는 특정 CN 필드가 있는 클라이언트 및 서버 인증서가 필요합니다.

CMS는 하나의 마스터와 여러 개의 완전히 동일한 복제본이 있는 postgres 데이터베이스를 사용합니다. 한 번에 하나의 기본 데이터베이스(“데이터베이스 서버”)만 있습니다. 클러스터의 나머지 구성원은 복제본 또는 "데이터베이스 클라이언트"입니다.

데이터베이스 클러스터에는 전용 서버 인증서와 클라이언트 인증서가 필요합니다. 일반적으로 내부 개인 인증 기관인 인증서로 서명해야 합니다. 데이터베이스 클러스터의 모든 멤버가 마스터가 될 수 있으므로 데이터베이스 서버와 클라이언트 인증서 쌍(공개 및 개인 키 포함)을 모든 서버에 복사하여 클라이언트 또는 데이터베이스 서버의 ID를 가정할 수 있도록 해야 합니다. 또한 클라이언트 및 서버 인증서를 확인할 수 있도록 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

어디에서 DB클러스터서버 и DB클러스터클라이언트 요청 이름 및 향후 인증서, 호스트 이름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 주소입니다. 간단하게는 마스터입니다.

다음 명령을 사용하여 데이터베이스 클러스터가 모든 서버에서 어떻게 작동하는지 확인합니다.

database cluster status

나머지 세 번째 서버에서도 동일한 작업을 수행합니다.

결과적으로 첫 번째 서버는 마스터이고 나머지는 슬레이브인 것으로 나타났습니다.

웹 관리 서비스

웹 관리자 서비스를 활성화합니다:

webadmin listen a 445

포트 445은 웹 클라이언트에 대한 사용자 액세스에 사용되므로 포트 443가 선택되었습니다.

다음과 같은 명령을 사용하여 인증서 파일로 Web Admin 서비스를 구성합니다.

webadmin certs <keyfile> <certificatefile> <ca bundle>

그리고 다음 명령을 사용하여 Web Admin을 활성화합니다.

webadmin enable

모든 것이 정상이면 Web Admin이 네트워크와 인증서에 대해 올바르게 구성되었음을 나타내는 SUCCESS 라인을 받게 됩니다. 웹 브라우저를 사용하여 서비스 기능을 확인하고 웹 관리자의 주소를 입력합니다. 예: cms.example.com: 445

통화 브리지 클러스터

콜 브리지는 모든 CMS 배포에 존재하는 유일한 서비스입니다. 통화 브리지는 주요 회의 메커니즘입니다. 또한 Cisco Unified CM 등을 통해 통화를 라우팅하거나 수신할 수 있도록 SIP 인터페이스도 제공합니다.

아래 설명된 명령은 적절한 인증서를 사용하여 각 서버에서 실행되어야 합니다.
그래서 :

다음과 같은 명령을 사용하여 인증서를 Call Bridge 서비스와 연결합니다.

callbridge certs <keyfile> <certificatefile>[<cert-bundle>]

다음 명령을 사용하여 CallBridge 서비스를 필요한 인터페이스에 바인딩합니다.

callbridge listen a

그리고 다음 명령을 사용하여 서비스를 다시 시작합니다.

callbridge restart

이제 통화 브리지가 구성되었으므로 통화 브리지 클러스터링을 구성할 수 있습니다. 통화 브리지 클러스터링은 데이터베이스 또는 XMPP 클러스터링과 다릅니다. 통화 브리지 클러스터는 아무런 제한 없이 2~8개의 노드를 지원할 수 있습니다. 이는 중복성뿐만 아니라 로드 밸런싱도 제공하므로 지능형 통화 분배를 사용하여 통화 브리지 서버 전체에 회의를 적극적으로 분산할 수 있습니다. CMS에는 추가 관리에 사용할 수 있는 추가 기능, 통화 브리지 그룹 및 관련 기능이 있습니다.

콜 브리지 클러스터링은 주로 웹 관리 인터페이스를 통해 구성됩니다.
아래 설명된 절차는 클러스터의 각 서버에서 수행되어야 합니다.
따라서,

1. 웹을 통해 구성 > 클러스터로 이동합니다.
2. 있음 브리지 ID 호출 고유 이름으로는 서버 이름에 해당하는 callbridge[01,02,03]을 입력합니다. 이러한 이름은 임의적이지만 이 클러스터에 대해 고유해야 합니다. 이는 서버 식별자[01,02,03]임을 나타내기 때문에 본질적으로 설명적입니다.
3.V 클러스터된 통화 브리지 클러스터에 있는 서버의 웹 관리자 URL을 입력하고, CMS[01,02,03].example.com:445(주소 필드) 포트를 반드시 지정하세요. 피어 링크 SIP 도메인을 비워 둘 수 있습니다.
4. 각 서버의 CallBridge 신뢰에 인증서를 추가합니다. 이 파일에는 다음과 같은 명령을 사용하여 맨 처음에 이 파일에 병합한 서버의 모든 인증서가 포함되어 있습니다.

callbridge trust cluster <trusted cluster certificate bundle>

그리고 다음 명령을 사용하여 서비스를 다시 시작합니다.

callbridge restart

결과적으로 각 서버에서 다음 그림을 얻을 수 있습니다.

XMPP 클러스터

CMS의 XMPP 서비스는 CMA WebRTC 웹 클라이언트를 포함하여 CMA(Cisco Meeting Apps)에 대한 모든 등록 및 인증을 처리하는 데 사용됩니다. 콜 브리지 자체도 인증 목적으로 XMPP 클라이언트 역할을 하므로 다른 클라이언트처럼 구성해야 합니다. XMPP 내결함성은 버전 2.1부터 프로덕션 환경에서 지원되는 기능입니다.

아래 설명된 명령은 적절한 인증서를 사용하여 각 서버에서 실행되어야 합니다.
그래서 :

다음과 같은 명령을 사용하여 인증서를 XMPP 서비스와 연결합니다.

xmpp certs <keyfile> <certificatefile>[<cert-bundle>]

그런 다음 다음 명령을 사용하여 청취 인터페이스를 정의하십시오.

xmpp listen a

XMPP 서비스에는 고유한 도메인이 필요합니다. 사용자를 위한 로그인입니다. 즉, 사용자가 CMA 앱(또는 WebRTC 클라이언트를 통해)을 사용하여 로그인을 시도하면 userID@logindomain을 입력합니다. 우리의 경우 userid@입니다.conf의.example.com. 왜 example.com이 아닌가요? 특정 배포에서는 Jabber 사용자가 Unified CM에서 example.com으로 사용할 Unified CM 도메인을 선택했기 때문에 CMS 사용자가 SIP 도메인을 통해 CMS와 통화를 라우팅하려면 다른 도메인이 필요했습니다.

다음과 같은 명령을 사용하여 XMPP 도메인을 설정합니다.

xmpp domain <domain>

그리고 다음 명령을 사용하여 XMPP 서비스를 활성화합니다.

xmpp enable

XMPP 서비스에서는 XMPP 서비스에 등록할 때 사용할 각 통화 브리지에 대한 자격 증명을 생성해야 합니다. 이러한 이름은 임의적이며 통화 브리지 클러스터링을 위해 구성한 고유 이름과 관련이 없습니다. 이 구성은 클러스터 데이터베이스에 맞지 않기 때문에 하나의 XMPP 서버에 세 개의 호출 브리지를 추가한 다음 클러스터의 다른 XMPP 서버에 해당 자격 증명을 입력해야 합니다. 나중에 이 이름과 비밀을 사용하여 XMPP 서비스에 등록하도록 각 통화 브리지를 구성합니다.

이제 세 개의 통화 브리지 callbridge01, callbridge02 및 callbridge03이 있는 첫 번째 서버에서 XMPP 서비스를 구성해야 합니다. 각 계정에는 무작위 비밀번호가 할당됩니다. 나중에 이 XMPP 서버에 로그인하기 위해 다른 Call Bridge 서버에 입력됩니다. 다음 명령을 입력하십시오.

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 클러스터에 연결하도록 통화 브리지 서비스를 구성해야 합니다. 이 구성은 웹 관리자를 통해 수행됩니다.

각 서버에서 구성 > 일반으로 이동한 후 해당 필드에서 고유한 통화 브리지 이름 서버 콜 브리지에 해당하는 고유한 이름을 작성합니다. 콜브리지[01,02,03]... 현장에서 도메인 conf.example.ru 해당 비밀번호를 감시할 수 있습니다.
다음 명령을 사용하여 클러스터의 모든 서버에서:

xmpp callbridge list

"서버" 필드를 비워 두세요. 콜브릿지 DNS SRV 조회를 수행합니다. _xmpp-컴포넌트._tcp.conf.example.com사용 가능한 XMPP 서버를 찾으려면 콜브리지를 XMPP에 연결하기 위한 IP 주소는 서버마다 다를 수 있으며 녹음 요청에 반환되는 값에 따라 다릅니다. _xmpp-컴포넌트._tcp.conf.example.com 콜브리지는 주어진 DNS 레코드의 우선순위 설정에 따라 달라집니다.

다음으로 상태 > 일반으로 이동하여 Call Bride 서비스가 XMPP 서비스에 성공적으로 연결되었는지 확인합니다.

웹브릿지

클러스터의 각 서버에서 다음 명령을 사용하여 웹 브리지 서비스를 활성화합니다.

webbridge listen a:443

다음과 같은 명령을 사용하여 인증서 파일로 웹 브리지 서비스를 구성합니다.

webbridge  certs <keyfile> <certificatefile> <ca bundle>

웹 브리지는 HTTPS를 지원합니다. "http-redirect"를 사용하도록 구성된 경우 HTTP를 HTTPS로 리디렉션합니다.
HTTP 리디렉션을 활성화하려면 다음 명령을 사용하십시오.

webbridge http-redirect enable

Web Bridge가 Call Bridge의 연결을 신뢰할 수 있음을 Call Bridge에 알리려면 다음 명령을 사용합니다.

webbridge trust <certfile>

여기서 이는 클러스터에 있는 각 서버의 인증서 XNUMX개를 모두 포함하는 파일입니다.

이 그림은 클러스터의 모든 서버에 있어야 합니다.


이제 "appadmin" 역할을 가진 사용자를 생성해야 합니다. 클러스터의 각 서버를 별도로 구성하는 것이 아니라 클러스터(!)를 구성할 수 있도록 이 역할이 필요합니다. 이렇게 하면 설정이 한 번은 만들어질 것이라는 사실.


추가 설정을 위해 우리는 우편 집배원.

인증을 받으려면 인증 섹션에서 기본을 선택하세요.

CMS 서버에 명령을 올바르게 보내려면 필요한 인코딩을 설정해야 합니다.

다음 명령으로 Webbridge를 지정합니다. POST 매개변수 포함 URL 그리고 의미 cms.example.com



웹브리지 자체에는 게스트 액세스, 보호된 액세스 등 필수 매개변수가 표시됩니다.

통화 브리지 그룹

기본적으로 CMS는 항상 회의 리소스를 가장 효율적으로 사용하지는 않습니다.

예를 들어 참가자가 3명인 회의의 경우 각 참가자는 세 가지 다른 통화 브리지에 연결될 수 있습니다. 이 세 참가자가 서로 통신할 수 있도록 콜 브리지는 동일한 공간에 있는 모든 서버와 클라이언트 간에 자동으로 연결을 설정하므로 모든 클라이언트가 동일한 서버에 있는 것처럼 보입니다. 불행히도 이것의 단점은 단일 9인 회의가 이제 XNUMX개의 미디어 포트를 소비한다는 것입니다. 이는 분명히 자원을 비효율적으로 사용하는 것입니다. 또한 통화 브리지가 실제로 과부하된 경우 기본 메커니즘은 계속해서 통화를 수락하고 해당 통화 브리지의 모든 가입자에게 낮은 품질의 서비스를 제공하는 것입니다.

이러한 문제는 통화 브리지 그룹 기능을 사용하여 해결됩니다. 이 기능은 Cisco Meeting Server 소프트웨어 버전 2.1에 도입되었으며 WebRTC 참가자를 포함하여 인바운드 및 아웃바운드 CMA(Cisco Meeting App) 통화에 대한 로드 밸런싱을 지원하도록 확장되었습니다.

재연결 문제를 해결하기 위해 각 통화 브리지에 대해 세 가지 구성 가능한 로드 제한이 도입되었습니다.

로드한도 — 이는 특정 통화 브리지에 대한 최대 수치 부하입니다. 각 플랫폼에는 CMS96000의 경우 1000, 가상 머신의 경우 vCPU당 1.25GHz와 같은 권장 로드 제한이 있습니다. 다양한 호출은 참가자의 해상도와 프레임 속도에 따라 특정 양의 리소스를 소비합니다.
NewConferenceLoadLimitBasisPoints (기본값 50% loadLimit) - 서버 로드 제한을 설정하며 그 이후에는 새 회의가 거부됩니다.
기존컨퍼런스LoadLimitBasisPoints (기본값은 loadLimit의 80%) - 기존 컨퍼런스에 참여하는 참가자가 거부되기 전까지의 서버 로드 값입니다.

이 기능은 통화 분산 및 로드 밸런싱을 위해 설계되었지만 TURN 서버, 웹 브리지 서버 및 녹음기와 같은 다른 그룹도 통화 브리지 그룹에 할당하여 최적의 사용을 위해 적절하게 그룹화할 수 있습니다. 이러한 개체 중 하나라도 통화 그룹에 할당되지 않은 경우 특별한 우선 순위 없이 모든 서버에서 사용할 수 있는 것으로 간주됩니다.

이러한 매개변수는 여기에서 구성됩니다. cms.example.com:445/api/v1/시스템/구성/클러스터

다음으로, 각 콜브리지 그룹이 속한 콜브리지 그룹을 표시합니다.

첫 번째 콜브리지

두 번째 콜브리지

세 번째 콜브리지


따라서 Cisco Meeting Server 클러스터의 리소스를 보다 효율적으로 사용하도록 Call Brdige 그룹을 구성했습니다.

Active Directory에서 사용자 가져오기

Web Admin 서비스에는 LDAP 구성 섹션이 있지만 복잡한 구성 옵션을 제공하지 않으며 정보가 클러스터 데이터베이스에 저장되지 않으므로 웹 인터페이스를 통해 각 서버에서 수동으로 구성하거나 웹 인터페이스를 통해 구성을 수행해야 합니다. API를 통해 "일어나지 마세요"라고 세 번이나 계속해서 API를 통해 데이터를 설정합니다.

URL을 사용하여 액세스 cms01.example.com:445/api/v1/ldapServers는 다음과 같은 매개변수를 지정하여 LDAP 서버 객체를 생성합니다.

• 서버 IP
• 포트 번호
• имя пользователя
• 암호
• 안전해야합니다.

보안 - 포트에 따라 true 또는 false를 선택합니다. 389 - 보안되지 않음, 636 - 보호됨.


Cisco Meeting Server의 속성에 LDAP 소스 매개변수 매핑.
LDAP 매핑은 LDAP 디렉터리의 특성을 CMS의 특성에 매핑합니다. 실제 속성:

• jid매핑
• 이름매핑
• coSpaceName매핑
• coSpaceUri매핑
• coSpaceSecondaryUri매핑

속성 설명JID CMS에서 사용자의 로그인 ID를 나타냅니다. 이는 Microsoft Active Directory LDAP 서버이므로 CMS JID는 기본적으로 사용자의 Active Directory 로그인 ID인 ​​LDAP의 sAMAccountName에 매핑됩니다. 또한 sAMAccountName을 가져와서 끝에 conf.pod6.cms.lab 도메인을 추가하십시오. 이는 사용자가 CMS에 로그인하는 데 사용할 로그인이기 때문입니다.

이름매핑 Active Directory displayName 필드에 포함된 내용을 사용자의 CMS 이름 필드와 일치시킵니다.

coSpaceName매핑 displayName 필드를 기반으로 CMS 공간 이름을 생성합니다. coSpaceUriMapping 속성과 함께 이 속성은 각 사용자에 대한 공간을 만드는 데 필요합니다.

coSpaceUri매핑 사용자의 개인 공간과 연관된 URI의 사용자 부분을 정의합니다. 일부 도메인은 공간으로 전화를 걸도록 구성할 수 있습니다. 사용자 부분이 이러한 도메인 중 하나에 대해 이 필드와 일치하는 경우 통화는 해당 사용자의 공간으로 연결됩니다.

coSpaceSecondaryUri매핑 공간에 도달하기 위한 두 번째 URI를 정의합니다. 이는 coSpaceUriMapping 매개변수에 정의된 영숫자 URI 대신 가져온 사용자 공간으로 호출을 라우팅하기 위한 숫자 별칭을 추가하는 데 사용할 수 있습니다.

LDAP 서버 및 LDAP 매핑이 구성되었습니다. 이제 LDAP 소스를 생성하여 이들을 서로 연결해야 합니다.

URL을 사용하여 액세스 cms01.example.com:445/api/v1/ldapSource는 다음과 같은 매개변수를 지정하여 LDAP 소스 객체를 생성합니다.

• 섬기는 사람
• 매핑
• 베이스Dn
• 필터링

이제 LDAP 구성이 완료되었으므로 수동 동기화 작업을 수행할 수 있습니다.

각 서버의 웹 인터페이스에서 다음 중 하나를 클릭하여 이 작업을 수행합니다. 지금 동기화 섹션 Active Directory의


또는 API를 통해 명령을 사용하여 POST URL을 사용하여 액세스 cms01.example.com:445/api/v1/ldapSyncs

임시 회의

이 무엇입니까?전통적인 개념에서는 두 명의 참가자가 서로 대화를 나누고 참가자 중 한 명이 (Unified CM에 등록된 장치를 사용하여) "회의" 버튼을 누르고 상대방에게 전화를 걸어 해당 제XNUMX자와 대화하는 것을 회의라고 합니다. , "회의" 버튼을 다시 눌러 XNUMX자 회의에 모든 참가자를 참여시킵니다.

임시 회의와 CMS의 예약된 회의를 구별하는 점은 임시 회의가 CMS에 대한 단순한 SIP 통화가 아니라는 것입니다. 회의 개시자가 회의 버튼을 두 번째로 클릭하여 모든 사람을 동일한 회의에 초대하면 Unified CM은 CMS에 API 호출을 수행하여 모든 통화가 전송되는 즉석 회의를 생성해야 합니다. 이 모든 일은 참가자가 눈치 채지 못한 채 발생합니다.

이는 통화를 계속하려면 Unified CM이 서비스의 API 자격 증명과 WebAdmin 주소/포트는 물론 SIP 트렁크를 CMS 서버에 직접 구성해야 함을 의미합니다.

필요한 경우 CUCM은 CMS에 스페이스를 동적으로 생성하여 각 통화가 CMS에 도달하고 스페이스용 수신 통화 규칙과 일치할 수 있도록 합니다.

CUCM과 통합 기사에 설명된 것과 같은 방식으로 구성되었습니다. 이전 단, Cisco UCM에서는 CMS용 트렁크 XNUMX개, 컨퍼런스 브리지 XNUMX개를 생성해야 하며 SIP 보안 프로필에서 제목 이름 XNUMX개, 경로 그룹, 경로 목록, 미디어 리소스 그룹 및 미디어 리소스 그룹 목록을 지정하고 몇 가지 라우팅 규칙을 추가해야 합니다. Cisco 미팅 서버에.

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 도메인을 호출하는 데 유용합니다. 또한 통과를 선택하여 필드가 더 이상 수정되지 않거나 내부 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인지에 따라 IP 주소 또는 FQDN으로 전달된 통화를 수락하도록 CMS를 구성해야 하는지 여부가 결정됩니다.

인바운드 규칙의 우선순위가 가장 높은 도메인이 모든 사용자 공간의 도메인으로 사용됩니다. 사용자가 LDAP를 통해 동기화하면 CMS는 자동으로 공간을 생성하지만 URI(coSpaceUriMapping)의 사용자 부분(예: user.space)만 생성합니다. 부분 도메인 전체 URI는 이 규칙에 따라 생성됩니다. 실제로 이 시점에서 Web Bridge에 로그인하면 Space URI에 도메인이 없다는 것을 알 수 있습니다. 이 규칙을 가장 높은 우선순위로 설정하면 생성된 공간의 도메인이 다음과 같이 설정됩니다. 회의example.com.


발신 통화 규칙

사용자가 Unified CM 클러스터에 아웃바운드 전화를 걸 수 있도록 허용하려면 아웃바운드 규칙을 구성해야 합니다. Jabber 등 Unified CM에 등록된 엔드포인트의 도메인은 example.com입니다. 이 도메인에 대한 통화는 표준 SIP 통화로 Unified CM 통화 처리 노드로 라우팅되어야 합니다. 메인 서버는 cucm-01.example.com이고, 추가 서버는 cucm-02.example.com입니다.

첫 번째 규칙은 클러스터 서버 간의 가장 간단한 통화 라우팅을 설명합니다.

분야 도메인의 로컬 "@" 기호 다음에 전화를 받는 사람에 대한 발신자의 SIP-URI에 표시되는 내용을 담당합니다. 비워 두면 "@" 기호 뒤에 이 호출이 통과하는 CUCM의 IP 주소가 있습니다. 도메인을 지정하면 "@" 기호 뒤에 실제로 도메인이 표시됩니다. 이는 콜백을 위해 필요합니다. 그렇지 않으면 SIP-URI name@ip-address를 통해 콜백을 할 수 없습니다.

지정되면 전화하세요 도메인의 로컬


언제 전화하세요 NOT 가리키는 도메인의 로컬


Auto 매개변수로는 아무 것도 작동하지 않으므로 발신 통화에 대해 암호화됨 또는 암호화되지 않음을 명시적으로 지정해야 합니다.

녹음

화상 회의는 레코드 서버에 의해 녹화됩니다. Recorder는 Cisco Meeting Server와 정확히 동일합니다. 레코더에는 라이센스 설치가 필요하지 않습니다. CallBridge 서비스를 실행하는 서버에는 녹음 라이센스가 필요합니다. 녹음 라이센스가 필요하며 녹음기를 실행하는 서버가 아닌 CallBridge 구성 요소에 적용해야 합니다. Recorder는 XMPP(Extensible Messaging and Presence Protocol) 클라이언트로 작동하므로 CallBridge를 호스팅하는 서버에서 XMPP 서버를 활성화해야 합니다.

왜냐하면 클러스터가 있고 클러스터에 있는 세 서버 모두에 라이센스를 "확장"해야 합니다. 그런 다음 라이선스의 개인 계정에서 클러스터에 포함된 모든 CMS 서버의 a-인터페이스 MAC 주소를 연결(추가)합니다.

그리고 이것은 클러스터의 모든 서버에 있어야 하는 그림입니다.

일반적으로 레코더를 배치하는 데에는 여러 가지 시나리오가 있지만 우리는 다음을 고수하겠습니다.


녹화기를 설정하기 전에 실제로 화상회의를 녹화할 장소를 준비해야 합니다. 사실 여기 링크, 모든 녹음 설정 방법. 나는 중요한 사항과 세부 사항에 중점을 둡니다.

1. 클러스터의 첫 번째 서버에서 인증서를 가져오는 것이 좋습니다.
2. Recorder Trust에 잘못된 인증서가 지정되어 "Recorder available" 오류가 발생할 수 있습니다.
3. 녹화를 위해 지정한 NFS 디렉토리가 루트 디렉토리가 아닐 경우 쓰기가 되지 않을 수 있습니다.

특정 사용자나 공간의 회의를 자동으로 녹화해야 하는 경우가 있습니다.

이를 위해 두 개의 CallProfile이 생성됩니다.
녹음이 비활성화된 상태에서


그리고 자동 녹음 기능이 있어서


다음으로 자동 녹음 기능이 있는 CallProfile을 원하는 공간에 "부착"합니다.


CMS에서는 CallProfile이 명시적으로 공간이나 공간에 연결된 경우 이 CallProfile이 이러한 특정 공간과 관련해서만 작동하도록 설정되어 있습니다. 그리고 CallProfile이 어떤 공간에도 바인딩되지 않은 경우 기본적으로 CallProfile이 명시적으로 바인딩되지 않은 공간에 적용됩니다.

다음번에는 조직 내부 네트워크 외부에서 CMS에 액세스하는 방법에 대해 설명하겠습니다.

출처 :

• www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Deployment_Guide/Version-2-5/Cisco-Meeting-Server-2-5-Single-Combined-Server-Deployment.pdf
• www.cisco.com/c/en/us/support/docs/conferencing/meeting-server/202722-Configure-Recorder-in-CMS-Acano-Call-Bri.html
• www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Reference_Guides/Version-2-3/Cisco-Meeting-Server-MMP-Command-Reference-2-3.pdf
• www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Reference_Guides/Version-2-5/Cisco-Meeting-Server-API-Reference-Guide-2-4-and-later. PDF

출처 : habr.com