Cisco Meeting Server 2.9에서 3.0으로 원활하게 업그레이드(및 계속) 지침

소개

이 문서에서는 버전 2.9(또는 이전)를 실행하는 Cisco Meeting Server 구축을 3.0(또는 이후)으로 업그레이드하는 문제 및 원활한 업그레이드 프로세스를 위해 이를 처리하는 방법에 대해 설명합니다.

Cisco CMS(Meeting Server) 3.0에는 WebRTC, 레코더, 스트림, 트렁크/로드 밸런서에 영향을 주는 XMPP의 제거, 예를 들어 새로운 webbridge3 추가와 같은 큰 변화가 있습니다. 이 문서는 2.9에서 3.0으로 마이그레이션할 때 보다 효과적으로 대비할 수 있도록 지원합니다.

이 문서에서는 업그레이드하기 전에 고려해야 할 주제만 다룹니다. 3.X에서 제공되는 모든 새로운 기능은 다루지 않습니다.

아래에 언급된 모든 내용은 다양한 문서에 설명되어 있습니다.  CMS 설치 및 구성 가이드 및 CMS 제품 릴리스 정보에 대한 추가 설명이 필요한 경우 제품 릴리스 정보를 읽고 프로그래밍 가이드 및 구축 설명서를 참조하는 것이 좋습니다.

사전 요구 사항

요구 사항

다음 주제에 대한 지식을 보유하고 있으면 유용합니다.

• CMS 관리
• CMS 업그레이드
• 인증서 생성 및 서명

사용되는 구성 요소

이 문서의 정보는 Cisco Meeting Server를 기반으로 합니다.

이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 네트워크가 작동 중인 경우 모든 명령의 잠재적인 영향을 이해해야 합니다.

배경 정보

이 문서는 CMS 2.9.x(또는 이전 버전) 구축이 이미 있을 경우, 단일 통합 또는 복원력이 있을 때, 그리고 CMS 3.0으로 업그레이드할 때 지침을 제공하기 위한 것입니다.  이 문서의 정보는 모든 CMS 모델과 관련이 있습니다.  

참고: X-Series는 CMS 3.0으로 업그레이드할 수 없습니다. X-Series 서버를 가능한 한 빨리 교체해야 합니다.

고려할 사항 요약

이러한 질문을 사용하여 자신의 상황에 해당하는 아래의 섹션으로 이동합니다.  각 고려 사항은 이 문서에 나와 있는 보다 자세한 설명 하이퍼링크를 가리킵니다.

라이센스

업그레이드 전에 서버에 PMP(Personal MultiParty)/SMP(Shared MultiParty) 라이센스가 충분히 있습니까?

3.0에서는 사용자가 로그인하지 않은 경우에도 PMP 라이센스가 할당됩니다. 예를 들어, LDAP를 통해 10000명의 사용자를 가져왔지만 100개의 PMP 라이센스만 있는 경우 3.0으로 업그레이드하면 규정 준수가 해제됩니다.  이 활용 사례에서는 userProfile이 설정되어 있고 값이 true인 hasLicense가 설정되어 있는지 확인하려면 system/profiles가 있는 테넌트를 반드시 확인해야 합니다.

API에서 userProfile을 확인하고 hasLicense=true set(PMP 라이센스 사용자를 의미)가 있는지 확인하는 방법은 이 섹션에서 자세히 다룹니다. 

현재 cms.lic 파일에 PMP/SMP 라이센스가 있습니까?

3.0부터 라이센스 동작이 변경되어 업그레이드를 수행하기 전에 PMP/SMP 라이센스가 충분한지 확인해야 합니다. 자세한 내용은 이 섹션에서 설명합니다.

CMM(Cisco Meeting Manager)이 구축되어 있습니까?

CMS 3.0에는 라이센스 처리 방식이 변경되었으므로 CMM 3.0이 필요합니다. 지난 90일 동안 90일 보고서에 라이센스 소비량이 있는지 확인할 수 있으므로 환경을 3.0으로 업그레이드하기 전에 CMM 2.9를 구축하는 것이 좋습니다. 자세한 내용은 이 섹션에서 설명합니다.

Smart Licensing이 있습니까?

CMS 3.0에는 라이센스 처리 방식이 변경되었으므로 CMM 3.0이 필요합니다. 따라서 CMM을 통해 Smart Licensing을 이미 사용하는 경우, 클러스터에 PMP 및 SMP 라이센스가 연결되어 있는지 확인합니다.

Webbridge(WebRTC 및 CMA 클라이언트)

CMS 2.9에서 WebRTC를 사용하십니까?

Webbridge는 CMS 3.0에서 크게 변경되었습니다.  webbridge2에서 webbridge3로의 마이그레이션 및 웹 앱 사용에 대한 지침은 이 섹션에 나와 있습니다.

사용자가 CMA 씩 클라이언트를 사용합니까?

이러한 클라이언트는 XMPP 기반이므로 XMPP 서버가 제거되었으므로 업그레이드 후에는 더 이상 이 클라이언트를 사용할 수 없습니다. 사용 사례에 해당되는 경우 이 섹션에서 자세한 내용을 확인할 수 있습니다.

WebRTC에서 채팅을 사용하십니까?

채팅 기능은 3.0에서 웹 앱에서 제거됩니다. CMS 3.2에서는 채팅이 다시 도입되지만 지속적이지는 않습니다.  이 섹션에서 이 기능에 대한 자세한 내용을 확인할 수 있습니다.

사용자가 WebRTC에서 디바이스로 지점 간 통화를 수행합니까?

CMS 3.0에서는 웹 앱 사용자가 더 이상 다른 장치로 직접 전화를 걸 수 없습니다. 이제 모임 공간에 참여해야 하며, 동일한 작업에서 수행할 참가자를 모임에 추가할 수 있는 권한이 있어야 합니다.  이 섹션에서 이 부품에 대한 자세한 내용을 확인할 수 있습니다.

사용자가 WebRTC에서 자신의 coSpaces를 생성합니까?

3.0에서는 웹 앱 사용자가 클라이언트에서 자신의 공간을 만들 수 있도록 API에서 coSpaceTemplate을 생성하고 사용자에게 할당해야 합니다. 이는 LDAP 가져오기 중에 수동 또는 자동일 수 있습니다.  CanCreateCoSpaces가 UserProfile에서 제거됩니다.  이 섹션에서 이 기능에 대한 자세한 내용을 확인할 수 있습니다.

웹 GUI 변경 사항

웹 관리 GUI에 webBridge 설정이 구성되어 있습니까?

webBridge 설정은 3.0의 GUI에서 제거되므로 API에서 webbridges를 구성하고 API에서 webBridgeProfiles를 적절하게 구성할 수 있도록 GUI에 현재 설정이 있는지 확인해야 합니다.  이 섹션에서 이 변경에 대한 자세한 내용을 확인할 수 있습니다.

웹 관리 GUI에 외부 설정이 구성되어 있습니까?

CMS 3.1의 GUI에서 외부 설정이 제거되었습니다.  CMS 3.0 또는 이전 웹 관리 GUI(Configuration —> General —> External Settings)에 Webbridge URL 또는 IVR이 구성된 경우 웹 페이지에서 이러한 URL이 제거되었으므로 이제 API에서 구성해야 합니다.  3.1로 업그레이드하기 전의 이전 설정은 API에 추가되지 않으므로 수동으로 수행해야 합니다.  이 섹션에서 이 변경에 대한 자세한 내용을 확인할 수 있습니다.

레코더/리스트림

현재 CMS 레코더 및/또는 스트리밍 장치를 사용하고 계십니까?

CMS 레코더 및 스트리밍 구성 요소는 이제 XMPP 기반 대신 SIP 기반입니다. 따라서 XMPP가 제거되므로 업그레이드 후 이를 조정해야 합니다. 이 섹션에서 이 변경에 대한 자세한 내용을 확인할 수 있습니다.

Cisco Expressway 고려 사항

Expressway를 사용하여 WebRTC를 프록시하는 경우 현재 Cisco Expressway 버전은 무엇입니까? 

CMS 3.0에는 Expressway 12.6 이상이 필요합니다.  이 섹션에서 이 WebRTC 프록시 기능에 대한 자세한 내용을 확인할 수 있습니다.

CMS 에지

현재 환경에 CMS 엣지가 있습니까?

CMS Edge는 CMS 3.1에 다시 도입되었으며 외부 연결을 위한 확장성이 뛰어납니다.  이 섹션에서 이 부품에 대한 자세한 내용을 확인할 수 있습니다.

CMS(Acano) X-시리즈

현재 환경에 x-series 서버가 있습니까? 

이러한 서버는 CMS 3.0으로 업그레이드할 수 없으며, 이러한 서버를 곧 교체해야 합니다(3.0으로 업그레이드하기 전에 가상 머신 또는 CMS 어플라이언스로 이동). 이 링크에서 이러한 서버에 대한 End-of-Life 공지를 확인할 수 있습니다.

SIP 에지

현재 환경에서 SIP Edge를 사용하고 있습니까?

CMS 3.0부터 Sip Edge는 완전히 사용되지 않습니다.  Cisco Expressway를 사용하여 CMS에 SIP 통화를 가져와야 합니다.  귀사에 대한 Expressway를 가져오는 방법은 Cisco 고객 담당자에게 문의하십시오.

추가 정보

라이센싱 - 업그레이드 전에 라이센스 확인

2.x 버전에서 3.0 이상으로 업그레이드할 경우 규정 준수 위반 라이센스 상태가 가장 큰 문제입니다. 이 섹션에서는 원활한 업그레이드를 위해 필요한 PMP/SMP 라이센스의 양을 결정하는 방법에 대해 설명합니다.

구축을 3.0으로 업그레이드하기 전에 CMM 2.9를 구축하고 Licenses(라이센스) 탭 아래에 90일 보고서를 확인하여 CMS 노드에서 현재 할당된 라이센스 금액에 라이센스 사용량이 남아 있는지 확인합니다.

기존 라이센스(cms.lic 파일이 CMS 노드에 로컬로 설치됨)를 사용하는 경우 CMS 라이센스 파일에서 각 CMS 노드의 개인 및 공유 라이센스(이미지에 따라 100/100)의 수량을 확인합니다(각 callBridge 노드에서 WinSCP를 통해 다운로드).

이미 Smart Licensing을 사용하는 경우 CMS 서버용 Cisco Software Smart 포털에 할당된 PMP/SMP 라이센스 수를 확인합니다.

90일 보고서(Zip 파일의 이름은 license-data.zip)를 열고 이름이 daily-peak.csv인 파일을 엽니다.

Excel에서 PMP 열을 Z에서 A로 정렬하여 높은 값을 맨 위로 가져온 다음 SMP 열에 대해 동일하게 수행합니다.  이 파일에 표시된 값이 CMS 라이센스 파일에서 사용 가능한 라이센스보다 낮습니까? "예"라고 답할 경우, 귀하는 완벽하고 완벽한 규정 준수를 보장합니다. 그렇지 않은 경우 섹션 1.7.4에서 더 많은 정보를 찾을 수 있는 CMS 구축 설명서의 그림 6절 1.7.3에 나와 있는 몇 가지 경고 및/또는 오류가 표시됩니다.

예를 들어 이미지에 따라 2.1667개의 SMP 라이센스가 사용되었으며 지난 90일 동안 피크 시간만큼 PMP 라이센스가 사용되지 않았습니다. cms.lic 파일은 라이센스 유형별로 100개의 유닛을 표시하므로 이 설정이 완전히 준수됩니다. 따라서 이 설정이 CMS 3.0으로 업그레이드될 때 라이센싱에 문제가 없습니다. 그러나 LDAP를 통해 10,000명의 사용자를 가져오는 경우 여전히 문제가 있을 수 있습니다. 그 때 PMP 라이센스는 100개밖에 없지만, 10000을 할당합니다(hasLicense가 True로 설정된 userProfile 사용). 이 경우 3.0으로 업그레이드하면 곧 규정을 준수하지 않습니다. 자세한 내용은 다음 섹션에서 확인하십시오.

업그레이드한 후 PMP 라이센스가 할당된 사용자 수 확인

hasLicense가 true인 userProfile을 가져오고 사용하는 모든 사용자는 CMS 3.0에서 PMP 라이센스가 자동으로 할당됩니다. 

API에서 보유 중인 userProfiles의 수를 확인하고 그 중 하나에 "hasLicense=true" 집합이 있는지 확인합니다.  그런 경우 해당 userProfiles가 할당된 위치를 확인해야 합니다. 

userProfiles는 다음 레벨에서 할당할 수 있습니다.

1. Ldap소스
2. 테넌트
3. 시스템/프로필

hasLicense=true인 할당된 userProfiles의 3개 위치를 모두 확인합니다.

1. Ldap소스/테넌트

테넌트 또는 userProfile을 사용하는 각 ldapSource에 대해 hasLicense 매개 변수가 True로 설정된 경우 해당 ldapSource를 사용하여 가져온 사용자에게 PMP 라이센스가 할당됩니다.  테넌트가 있는 경우 테넌트 ID를 클릭하여 사용자 프로필이 할당되었는지 확인한 다음 해당 userProfile이 'hasLicense=true'로 구성되었는지 확인해야 합니다.  테넌트가 없지만 userProfile 집합이 있는 경우 이를 클릭하여 'hasLicense=true'가 있는지 확인합니다.  어느 쪽이든 'hasLicense=true'인 경우 'api/v1/users'에 대한 GET을 수행하고 예를 들어 ldapSource에 연결된 ldapmapping에서 jidMapping에 사용되는 도메인에 대한 필터링을 수행하여 가져온 사용자 수를 확인할 수 있습니다.

참고: 이는 ActiveDirectory 매핑 및 사용자가 만든 필터로 이 항목을 확인해야 하는 다른 상황에서는 더욱 복잡할 수 있습니다.

1단계. ldapSource에서 매핑 ID를 찾습니다.

2단계. ldapMappings를 검색하여 jidMapping을 찾습니다.

3단계. api/v1/users에서 jidMapping에 사용되는 도메인을 검색합니다.

4단계. 각 ldapSource에서 찾은 사용자를 추가합니다.  가져온 LDAP 사용자에게 PMP 라이센스가 필요한 횟수입니다. 

2. 시스템/프로파일

userProfile이 시스템/프로필 수준에서 설정되고 그 userProfile에 "hasLicense=true"가 있는 경우 서버를 업그레이드할 때 CMS로 가져온 모든 사용자에게 PMP 라이센스가 할당됩니다.  10,000명의 사용자를 가져왔지만 100개의 PMP만 있는 경우 CMS 3.0으로 업그레이드할 때 규정을 준수하지 못하게 되며, 통화 시작 시 화면 메시지가 나타나고 오디오 프롬프트가 표시될 수 있습니다.  

시스템 레벨의 userProfile에서 사용자가 PMP를 가져오도록 표시하면 api/v1/users로 이동하여 총 사용자 수를 확인합니다.

이전에 ldap에서 모든 사용자를 가져온 적이 있지만 해당 목록에서 특정 하위 집합만 필요함을 인식한 경우 ldapSource에 더 나은 필터를 생성하여 PMP 라이센스를 할당할 사용자만 가져옵니다. ldapSource에서 필터를 수정한 다음 api/v1/ldapsync에서 새 LDAP 동기화를 수행합니다.  그러면 원하는 사용자만 가져오게 되고 이전 가져오기의 다른 모든 사용자가 제거됩니다. 

참고: 이 작업을 올바르게 수행하고 새 가져오기가 원치 않는 사용자만 제거하면 나머지 사용자 coSpace CallID와 암호는 변경되지 않지만, 오류가 발생하면 모든 callIds 및 암호가 변경될 수 있습니다.  이 문제가 우려되는 경우 데이터베이스 노드를 백업해야 합니다!

SMP 라이센스가 충분합니까?

CMM 90 Day Report(CMM 90 Day Report)에서 일일 피크 시간대를 볼 때, SMP 라이센스가 이미 충분합니까?  SMP 라이센스는 회의 소유자가 PMP 라이센스를 할당받지 않은 경우 사용됩니다(coSpace 소유자/임시 회의/TMS 예약 회의).  SMP를 의도적으로 사용하고 피크 시간을 충분히 감당할 수 있다면 이 모든 것은 괜찮습니다.  만약 여러분이 SMP의 90일 최고점을 확인하고 이것이 왜 소비되는지 확실하지 않다면, 여기 확인할 몇 가지 것들이 있습니다.

1. (CUCM에서 에스컬레이션된 대로) 임시 통화는 병합에 사용된 디바이스가 사용자 프로필을 통해 CMS에서 PMP 라이센스를 할당한 사용자와 연결되지 않은 경우 SMP 라이센스를 사용합니다.  CUCM은 모임을 에스컬레이트하는 사용자의 GUID를 제공합니다.  해당 GUID가 할당된 PMP 라이센스가 있는 가져온 Meeting Server LDAP 사용자에 해당하는 경우 해당 사용자의 라이센스가 사용됩니다.

2. coSpace 소유자가 PMP 라이센스를 할당받지 않은 경우, 해당 특정 coSpaces에 대한 통화는 SMP 라이센스를 사용합니다.

3. 회의가 TMS 버전 15.6 이상에서 예약된 경우 회의 소유자가 CMS로 전송되고, 사용자에게 PMP 라이센스가 할당되지 않은 경우 해당 미팅에서는 SMP 라이센스를 사용합니다.

CMM

CMS가 제대로 작동하려면 CMS 3.0과 마찬가지로 CMM 3.0이 필요합니다.  CMM은 CMS의 라이센스를 담당하므로 CMS를 3.0으로 업그레이드하려는 경우 CMM 서버가 있어야 합니다.  업그레이드하기 전에 라이센스 소비를 확인할 수 있도록 CMS 2.9에 있는 동안 CMM 2.9를 구축하는 것이 좋습니다.

CMM은 추가된 모든 callBridges for SMP and PMP license 및 callBridge 라이센스를 확인합니다.  클러스터 내의 다양한 디바이스 전체에서 가장 높은 번호를 사용합니다. 

예를 들어, CMS1에 PMP 20개와 SMP 라이센스 10개가 있고, CMS2에 기존 라이센스에서 PMP 40개와 SMP 라이센스 5개가 있는 경우, CMM에서는 40개의 PMP 및 SMP 라이센스를 사용할 수 있다고 보고합니다.

가져온 사용자보다 더 많은 PMP 라이센스가 있는 경우 PMP(또는 SMP) 라이센스와 관련된 문제가 없지만, 90일 피크 시간을 확인하고 사용 가능한 것보다 많이 사용한 것을 발견한 경우에도 CMS 3.0으로 업그레이드하고 CMM에서 90일 평가판 라이센스를 사용하여 라이센스로 항목을 정렬하거나 업그레이드 전에 조치를 취할 수 있습니다.

Webbridge(WebRTC 및 CMA 클라이언트)

CMS 3.0은 XMPP 서버 구성 요소를 제거하며, 이를 통해 webBridge 및 CMA 씩 클라이언트 사용 기능을 제거합니다.  WebBridge3는 이제 브라우저를 사용하여 웹 앱 사용자(이전의 WebRTC 사용자)를 회의에 연결하는 데 사용됩니다.  3.0으로 업그레이드할 때 webbridge3을 구성해야 합니다. 

참고: CMS 3.0으로 업그레이드한 후에는 CMA thick 클라이언트가 작동하지 않습니다!

이 비디오에서는 webbridge 3 인증서를 만드는 방법을 안내합니다.

https://video.cisco.com/video/6232772471001

3.0으로 업그레이드하기 전에 고객은 Webbridge3를 구성하는 방법을 계획해야 합니다. 여기서 가장 중요한 단계가 강조 표시됩니다.

1. webbridge3에는 키와 인증서 체인이 필요합니다.  인증서에 webbridge3를 실행할 SAN(Subject Alternative Name)/CN(Common Name)으로 모든 CMS 서버 FQDN 또는 IP 주소가 포함되어 있고 다음 중 하나가 충족되는 경우 이전 webbridge 인증서를 사용할 수 있습니다.

a. 인증서에 향상된 키 사용이 없습니다(클라이언트 또는 서버로 사용할 수 있음).

b. 인증서에 클라이언트 및 서버 인증이 모두 있습니다.  HTTPs 인증에는 서버 인증만 필요하지만 C2W 인증서에는 서버와 클라이언트가 모두 필요합니다.

2. "webbridge3 https" 인증서에 대한 새 인증서를 만들려면 공개적으로 서명하는 것이 좋습니다(웹 앱을 사용할 때 클라이언트에서 인증서 경고를 피하려면).  이 동일한 인증서를 "webbridge3 c2w cert"에 사용할 수 있으며, 인증서에는 SAN/CN에 webbridge3 서버의 FQDN이 있어야 합니다.

3. CallBridge는 webbridge3 c2w listen 명령에 구성된 포트를 사용하여 새 webbridge3과 통신해야 합니다. 449와 같이 사용 가능한 모든 포트일 수 있습니다.  사용자는 Callbridge가 이 포트의 webbridge3와 통신할 수 있는지 확인하고 필요한 경우 미리 방화벽을 변경해야 합니다.  "webbridge https"에서 수신 대기하는 것과 동일한 포트가 될 수 없습니다.

CMS를 3.0으로 업그레이드하기 전에 'backup snapshot <servername_date>'를 사용하여 백업을 수행한 다음 callbridge 노드의 webadmin 페이지에 로그인하여 모든 XMPP 설정 및 Webbridge 설정을 제거하는 것이 좋습니다.  그런 다음 서버의 MMP에 연결하고 SSH 연결을 통해 xmpp 및 webbridge가 있는 모든 코어 서버에서 다음을 수행합니다.

1. xmpp 비활성화
2. xmpp 재설정
3. xmpp 인증서 없음
4. xmpp 도메인 없음
5. webbridge 비활성화
6. webbridge 수신 없음
7. webbridge 인증서 없음
8. webbridge 트러스트 없음

3.0으로 업그레이드한 후, 전에 webbridge를 실행한 모든 서버에서 webbridge3을 구성하는 것으로 시작합니다.  이러한 서버를 가리키는 DNS 레코드가 이미 있으므로 이 작업을 수행해야 합니다. 따라서 사용자가 webbridge3로 전송될 경우 요청을 처리할 준비가 되어 있는지 확인해야 합니다.

Webbridge3 컨피그레이션(모든 SSH 연결)

1단계. webbridge3 http listening port를 구성합니다.

Webbridge3 https 수신 a:443

2단계. 브라우저 연결을 위한 webbridge3용 인증서를 구성합니다.  브라우저로 전송된 인증서이며, 공용 CA(Certificate Authority)에서 서명해야 하며 브라우저에서 연결을 신뢰하기 위해 사용하는 FQDN을 포함해야 합니다.

Webbridge3 https certs wb3.key wb3trust.cer(신뢰 체인 필요): 엔드 엔터티가 맨 위에 있고 중간 CA가 순서대로, RootCA로 끝나게 하는 신뢰 인증서를 만듭니다.

3단계. callBridge to webbridge(c2w) 연결을 수신하는 데 사용할 포트를 구성합니다.  webbridge3 https 수신 포트에 443이 사용되므로 이 컨피그레이션은 449와 같이 사용 가능한 다른 포트여야 합니다.

Webbridge3 c2w 수신 a:449

4. webbridge에서 c2w 트러스트에 대한 callbridge로 보낼 인증서를 구성합니다.

Webbridge3 c2w certs wb3.key wb3trust.cer

5. callBridge 인증서를 신뢰하는 데 사용할 트러스트 저장소 WB3을 구성합니다.  이는 callbridge CA 번들에 사용된 인증서와 동일해야 합니다(맨 위에 중간 인증서의 번들이 있어야 하며, 맨 끝에 루트 CA가 있고 그 뒤에 단일 캐리지 리턴이 와야 합니다).

Webbridge3 c2w 트러스트 rootca.cer

6. webbridge3 활성화

Webbridge3 활성화

CallBridge 컨피그레이션 변경(모든 SSH 연결)

1단계. webbridge3 c2w 인증서에 서명한 CA 인증서/번들로 callBridge 신뢰를 구성합니다.

Callbridge 트러스트 c2w rootca.cer

2단계. callBridge를 다시 시작하여 새 트러스트를 적용합니다.  이렇게 하면 이 특정 callBridge의 모든 통화가 삭제되므로 주의하여 사용합니다.

Callbridge 재시작

webBridge3에 연결하기 위한 callBridges의 API 컨피그레이션

1. API에서 POST를 사용하여 새 webBridge 객체를 생성하고 webbridge c2w 인터페이스 화이트리스트에 구성된 포트 및 FQDN을 사용하여 URL 값을 제공합니다(webbridge3 구성에서 위의 3단계).

c2w://webbridge.darmckin.local:449

이 시점에서 Webbridge3가 작동해야 하며, 스페이스를 게스트로 조인하거나 이전에 가져온 사용자가 있는 경우 해당 사용자는 로그인할 수 있어야 합니다.

웹 앱 사용자 공간 만들기 권한

사용자가 WebRTC에서 자신의 스페이스를 만들 수 있습니까?  CMS 3.0부터 웹 앱 사용자는 자신에게 할당된 공동 스페이스 템플릿이 없으면 자신의 coSpaces를 만들 수 없습니다.

coSpaceTemplate이 할당되어 있더라도 다른 사람이 다이얼할 수 있는 공간이 만들어지지 않습니다(URI, 통화 ID 또는 암호 없음). 그러나 coSpace에 'addParticipantAllowed'가 있는 callLegProfile이 있는 경우 스페이스에서 다이얼아웃할 수 있습니다.

새 스페이스로 호출하는 데 사용할 수 있는 다이얼 문자열을 사용하려면 coSpaceTemplate에 accessMethodTemplate 설정이 있어야 합니다(2.9 릴리스 정보 - https://www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Release_Notes/Version-2-9/Cisco-Meeting-Server-Release-Notes-2-9-6.pdf 참조).

API에서 coSpaceTemplate을 생성한 다음 accessMethodTemplate을 생성하고 ldapUserCoSpaceTemplateSources에 coSpace 템플릿을 할당하거나 api/v1/users의 사용자에게 coSpaceTemplate을 수동으로 할당할 수 있습니다.

여러 CoSpaceTemplates 및 accessMethodsTemplates를 만들고 할당할 수 있습니다.  자세한 내용은 CMS API 가이드(https://www.cisco.com/c/en/us/support/conferencing/meeting-server/products-programming-reference-guides-list.html)를 참조하십시오.

CoSpaceTemplate(API 컨피그레이션)

이름: coSpaceTemplate에 지정할 이름입니다.

설명: 필요한 경우 Brief Description(개요 설명).

통화 프로필:  White callProfile에서 이 템플릿으로 만든 스페이스를 사용하시겠습니까? 제공되지 않으면 시스템/프로필 레벨에서 설정된 항목을 사용합니다.

callleg프로필: 이 템플릿으로 만든 공백을 사용할 callegProfile을 선택하십시오.  제공되지 않으면 시스템/프로필 레벨에서 설정된 항목을 사용합니다.

다이얼 인 보안 프로필: 이 템플릿으로 만든 공백을 사용할 DialInSecurityProfile을 선택하십시오. 제공되지 않으면 시스템/프로필 레벨에서 설정된 항목을 사용합니다.

AccessMethodTemplate(API 구성)

이름: coSpaceTemplate에 지정할 이름입니다.

uriGenerator:  이 액세스 메서드 템플릿에 대한 URI 값을 생성하는 데 사용할 식입니다. 허용되는 문자 집합은 'a'에서 'z', 'A'에서 'Z', '0'에서 '9', '.', '-', '_' 및 '$'입니다. 비어 있지 않으면 '$' 문자를 하나만 포함해야 합니다.  예를 들어 $.space는 스페이스를 만들 때 사용자가 제공한 이름을 사용하고 ".space"를 추가합니다. "팀 회의"에는 url 'Team.Meeting.space@domain'이 있습니다.

통화 레그 프로필: 이 템플릿으로 만든 accessMethods를 어떤 callegProfile에서 사용하시겠습니까?  지정하지 않으면 설정된 CoSpaceTemplate 수준을 사용하며, 설정되지 않은 경우 시스템/프로필 수준에 있는 항목을 사용합니다.

generateUniqueCallId: 이 액세스 메서드에 대해 고유한 숫자 ID를 생성할지 여부를 지정합니다. 이 ID는 cospace에 대한 전역 ID를 재정의합니다.

다이얼 인 보안 프로필: 이 템플릿으로 만든 액세스 메서드를 어떤 dialInSecurityProfile에서 사용하시겠습니까? 지정하지 않으면 설정된 CoSpaceTemplate 수준을 사용하며, 설정되지 않은 경우 시스템/프로필 수준에 있는 항목을 사용합니다.

채팅 기능

CMS 3.0에서는 영구 채팅 기능을 제거했지만 CMS 3.2에서는 공간 내에서 비영구 채팅이 반환되었습니다.  채팅은 웹 앱 사용자가 사용할 수 있으며 어디에서도 저장되지 않습니다.  CMS 3.2가 설치되면 기본적으로 웹 앱 사용자는 모임 중에 서로 메시지를 보낼 수 있습니다.  이러한 메시지는 회의 중에만 사용할 수 있으며, 참가 후 교환된 메시지만 표시됩니다. 늦게 가입하고 뒤로 스크롤하여 이전 메시지를 볼 수 없습니다.

WebRTC 지점 간 통화

CMS 2.9.x에서 WebRTC 참가자는 클라이언트에서 다른 연락처로 직접 전화를 걸 수 있었습니다.  CMS 3.0부터는 더 이상 불가능합니다. 이제 사용자가 로그인하여 스페이스에 가입해야 합니다. 여기에서 callLegProfile(addParticipants 매개 변수가 True로 설정된 경우)에 사용 권한이 있으면 다른 연락처를 추가할 수 있습니다.  이로 인해 CMS는 참가자에게 전화를 걸어 CMS의 공간에서 회의를 하게 됩니다.

주목할 만한 WebBridge 설정 변경

CMS 3.0 및 3.1은 GUI에서 일부 webbridge 설정을 제거하거나 재배치했으며, 사용자에게 일관된 환경을 유지하기 위해 API에서 이러한 설정을 구성해야 합니다.  3.x에서는 api/v1/webBridges 및 api/v1/webBridgeProfiles를 사용합니다. 

3.0으로 업그레이드할 때 API에서 webbridge 및 webbridge 프로파일을 구성할 수 있도록 현재 구성한 내용을 확인합니다.

위의 3.0에서는 웹 브리지 설정이 GUI에서 제거된 다음 CMS 3.1에서는 외부 액세스 필드도 제거되었습니다.

GUI의 웹 브리지 설정

• 게스트 어카운트 클라이언트 URI - callBridge에서 webBridge를 찾기 위해 이 URI를 사용했습니다.  WebRTC를 위한 배포에 여러 개의 webBridges가 있는 경우 이 필드는 이미 비어 있어야 하며 callBridge가 연결해야 하는 각 webBridge에 대해 api/v1/webbridges에 고유한 URL이 있어야 합니다. 이 필드의 모든 내용을 삭제하고 API에 webBridges가 구성되어 있는지 확인하십시오.

• Guest Account Jid Domain - CMS 3.0에서는 더 이상 사용되지 않으므로 삭제할 수 있습니다.
• ID 및 암호를 통한 게스트 액세스 - CMS 3.0에서 제거되고 교체되지 않습니다.
• 하이퍼링크를 통한 게스트 액세스 - 이제 API의 webBridgeProfiles에서 "AllowSecrets"를 설정하여 구성할 수 있습니다.

CMS 3.0에서는 서버 필드가 api/v1/webBridges에서 제거되었습니다.

• resourceArchive - 이제 webbridgeProfiles에 있습니다.
• idEntryMode - 이제 더 이상 사용되지 않습니다.
• allowWeblinkAccess - 이제 webBridgeProfiles에서 allowSecrets로 실행됩니다.
• showSignin - 이제 webBridgeProfiles에서 userPortalEnabled로 표시됩니다.
• resolveCoSpaceCallIds- 이제 webbridgeProfiles에서 확인하십시오.
• resolveLyncConferenceIDs - 이제 webbridgeProfiles에서 확인할 수 있습니다.

웹 브리지 프로파일

• resourceArchive - 사용자 지정 배경을 사용하고 리소스 아카이브가 웹 서버에 저장되어 있는 경우 여기에 URL을 입력합니다.
• allowPasscodes - false인 경우 사용자는 모임에 게스트로 참가할 수 있는 옵션이 없습니다.  스페이스 정보 및 암호가 포함된 URL만 로그인하거나 사용할 수 있습니다.
• allowSecrets - false로 설정된 경우 사용자는 https://meet.company.com/meeting/040478?secret=gPDnucF8is4W1cS87_l.zw과 같은 URL을 사용하여 스페이스에 참여할 수 없습니다. 사용자는 https://meet.company.com를 사용하고 통화 ID/회의 ID/URI 및 PIN/패스코드가 구성된 경우 이를 입력해야 합니다.
• userPortalEnabled - false로 설정된 경우 웹 앱 포털 랜딩 페이지에 로그인 옵션이 표시되지 않습니다. 통화 ID/미팅 ID/URI 및 PIN/패스코드가 구성된 경우에만 필드가 표시됩니다.
• allowUnauthenticatedGuests - False로 설정하면 게스트가 모임 ID와 암호가 포함된 전체 URL을 사용해도 모임에 참가할 수 없습니다.  False이면 로그인할 수 있는 사용자만 모임에 참가할 수 있습니다.  예.  User2가 User1의 모임에 대해 URL을 사용하려고 합니다.  URL을 입력한 후 User2는 User1의 미팅을 계속 진행하려면 로그인해야 합니다.
• resolveCoSpaceCallIds - False로 설정된 경우 게스트는 URI 및 PIN/Passcode(사용 중인 경우)를 입력하여 모임에 참가할 수 있습니다.  통화 ID/회의 ID/숫자 ID는 허용되지 않습니다.
• resolveCoSpaceUri - 가능한 설정 3개: off, domainSuggestionDisabled 및 domainSuggestionEnabled를 선택합니다. 이 webBridge가 방문객이 공동 스페이스 미팅에 참여할 수 있도록 coSpace 및 coSpace accessMethod SIP URI를 수락하는지 여부.

- URI에서 'off' 조인으로 설정되면 비활성화됩니다.

- URI에서 'domainSuggestionDisabled' 조인으로 설정된 경우 이 webBridgeProfile을 사용하여 URI 도메인이 자동으로 완료되거나 웹 브리지에서 확인되지 않습니다.

- URI에 의한 'domainSuggestionEnabled' 조인으로 설정된 경우 이 webBridgeProfile을 사용하여 URI의 도메인을 자동으로 완료하고 웹 브리지에서 확인할 수 있습니다.

웹 GUI에서 외부 액세스 섹션이 제거됨

CMS 3.1에서는 웹 GUI에서 외부 액세스 섹션이 제거되었습니다.  업그레이드 전에 이러한 구성을 구성한 경우 webbridgeProfiles 아래의 API에서 다시 구성해야 합니다.

먼저 이전 섹션에서 설명한 대로 webbridgeProfile을 만들어야 합니다. webbridgeProfile을 만든 후에는 새로 생성된 webBridgeProfile 아래의 API에서 사용 가능한 링크를 통해 IVR 번호 및/또는 웹 브리지 URI를 생성할 수 있습니다.

webBridgeProfile당 최대 32개의 IVR 번호 또는 32개의 webbridgeAddresses를 생성할 수 있습니다.

녹음 또는 스트리밍

CMS 2.9.x 및 이전 버전의 레코더 및 스트리밍 구성 요소는 XMPP 클라이언트였으며 CMS 3.0에서는 SIP 기반입니다.  이제 API의 기본 레이아웃을 사용하여 녹음 및 스트리밍에 대한 레이아웃을 변경할 수 있습니다.  또한 이제 이름 레이블이 녹음/스트리밍 세션에 표시됩니다.  레코더/스트리밍 기능에 대한 자세한 내용은 CMS 3.0 릴리스 정보(https://www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Release_Notes/Version-3-0/Cisco-Meeting-Server-Release-Notes-3-0.pdf)을 참조하십시오.

2.9.x에서 레코더 또는 스트림이 구성된 경우 업그레이드 후에도 계속 작동하도록 MMP 및 API에서 설정을 재구성해야 합니다.

CMS를 3.0으로 업그레이드하기 전에 'backup snapshot <servername_date>'를 사용하여 백업을 수행한 다음 callbridge 노드의 webadmin 페이지에 로그인하여 모든 XMPP 설정을 제거하는 것이 좋습니다.  그런 다음 서버의 MMP에 연결하고 SSH 연결을 통한 xmpp가 있는 모든 코어 서버에서 다음을 수행합니다.

1. xmpp 비활성화
2. xmpp 재설정
3. xmpp 인증서 없음
4. xmpp 도메인 없음

레코더

MMP

이 그림에는 레코더가 구성되었을 때 CMS 2.9.1에 표시되는 컨피그레이션의 예와 3.0으로 업그레이드한 직후 어떻게 보는지를 보여줍니다.

업그레이드 후에는 다음 단계에 따라 레코더를 구성해야 합니다.

1단계. SIP 수신 대기 인터페이스를 구성합니다.

레코더 sip는 5060 5061을 수신합니다(SIP 레코더가 TCP 및 TLS에 대해 수신하도록 설정되는 인터페이스 및 포트, 정중하게 수신 TLS를 사용하지 않으려는 경우 '레코더 sip에서 5060 none(5060 없음 수신)'을 사용할 수 있습니다.

2단계. TLS 연결을 사용하는 경우 레코더가 사용하는 인증서를 구성합니다.

레코더 sip certs <key-file> <crt-file> [crt-bundle] (이러한 인증서가 없으면 tls 서비스가 레코더에서 시작되지 않습니다. 레코더는 crt-bundle을 사용하여 callBridge 인증서를 확인합니다.)

3단계. 통화 제한을 구성합니다.

recorder limit <0-500|none>(서버가 제공할 수 있는 동시 녹음 수 제한을 설정합니다. 이 테이블은 설명서에 있으며 레코더 제한은 서버의 리소스에 맞게 조정되어야 합니다.)

API

api/v1/callProfiles에서 sipRecorderUri를 구성해야 합니다. 녹음을 시작해야 할 때 callBridge에서 전화를 거는 URI입니다. 이 URI의 도메인을 아웃바운드 규칙 테이블에 추가하고 레코더(또는 통화 제어)를 사용할 SIP 프록시로 가리켜야 합니다.

이 그림에는 Configuration(컨피그레이션) > Outbound Calls(아웃바운드 통화)에 있는 아웃바운드 규칙의 레코더 구성 요소에 대한 직접 다이얼이 표시됩니다.

이 그림은 통화 제어(예: Cisco CUCM(Unified Communications Manager) 또는 Expressway)를 통해 레코더 구성 요소에 대한 통화를 보여줍니다.

참고: SIP TLS를 사용하도록 레코더를 구성했으며 통화가 실패할 경우 MMP에서 callBridge 노드를 확인하여 TLS SIP 확인이 활성화되었는지 확인합니다.  MMP 명령은 'tls sip'입니다.   레코더 인증서를 callBridge에서 신뢰하지 않으므로 통화가 실패할 수 있습니다.  'tls sip verify disable'을 사용하여 callBridge에서 이를 비활성화하여 테스트할 수 있습니다.

여러 레코더?

각 항목을 설명된 대로 구성하고 그에 따라 아웃바운드 규칙을 조정합니다.  직접-레코더 메서드를 사용하는 경우 기존 아웃바운드를 레코더 규칙으로 변경하여 "Continue(계속)" 동작으로 변경하고 우선 순위가 첫 번째보다 작은 이전 규칙 아래에 새 아웃바운드 규칙을 추가합니다.  첫 번째 레코더가 통화 제한에 도달하면 여기에서 488 Unconsiable을 다시 callBridge로 전송하고 callBridge는 다음 규칙으로 이동합니다.

레코더의 부하를 분산하려면 통화 제어를 사용하고 통화 제어 라우팅을 조정하여 여러 레코더에 전화를 걸 수 있도록 합니다.

스트리머

MMP

2.9.x에서 3.0으로 업그레이드한 후에는 스트림을 재구성해야 합니다.

1단계. SIP 수신 대기 인터페이스를 구성합니다.

streamer sip는 6000 6001을 수신합니다(SIP 스트리밍이 TCP 및 TLS에 대해 수신 대기하도록 설정된 인터페이스 및 포트, 정중하게 설정).  TLS를 사용하지 않으려면 'streamer sip listen a 6000 none'을 사용할 수 있습니다.)

2단계. TLS 연결을 사용하는 경우 스트리밍에서 사용하는 인증서를 구성합니다.

streamer sip certs <key-file> <crt-file> [crt-bundle](이러한 인증서가 없으면 tls 서비스가 스트리밍 장치에서 시작되지 않습니다. 스트림은 crt-bundle을 사용하여 callBridge 인증서를 확인합니다.)

3단계. 통화 제한을 구성합니다.

streamer limit <0-500|none> (서버가 제공할 수 있는 동시 스트림 수의 제한을 설정합니다. 이 표는 설명서에 나와 있으며 스트림 제한은 서버의 리소스에 맞게 조정되어야 합니다.)

API

api/v1/callProfiles에서 sipStreamUri를 구성해야 합니다. 스트리밍을 시작해야 할 때 callBridge에서 전화를 거는 URI입니다. 이 URI의 도메인을 아웃바운드 규칙 테이블에 추가하고 사용할 SIP 프록시로 스트림(또는 통화 제어)을 가리켜야 합니다.

이 그림에는 Configuration(컨피그레이션) > Outbound Calls(아웃바운드 통화)에 있는 아웃바운드 규칙의 스트리머 구성 요소에 대한 다이얼이 표시됩니다.

이 그림은 통화 제어(예: Cisco CUCM(Unified Communications Manager) 또는 Expressway)를 통해 레코더 구성 요소에 대한 통화를 보여줍니다.

참고: SIP TLS를 사용하도록 스트리버를 구성했으며 통화가 실패한 경우 MMP에서 callBridge 노드를 확인하여 TLS SIP 확인이 활성화되었는지 확인합니다.  MMP 명령은 'tls sip'입니다.   callBridge에서 스트리밍 인증서를 신뢰할 수 없으므로 호출이 실패할 수 있습니다.  'tls sip verify disable'을 사용하여 callBridge에서 이를 비활성화하여 테스트할 수 있습니다.

멀티스트림?

각 항목을 설명된 대로 구성하고 그에 따라 아웃바운드 규칙을 조정합니다.  다이렉트 투 스트리밍 방법을 사용하는 경우 기존 아웃바운드를 레코더 규칙으로 변경하여 "Continue(계속)" 동작으로 변경하고 첫 번째 방법보다 우선순위가 낮은 이전 규칙 아래에 새 아웃바운드 규칙을 추가합니다.  첫 번째 스트림이 통화 제한에 도달하면 여기에서 488 Unconsiable을 callBridge로 다시 전송하고 callBridge가 다음 규칙으로 이동합니다.

리본의 로드 밸런싱을 수행하려면 통화 제어를 사용하고 통화 제어 라우팅을 조정하여 여러 스트림에 전화를 걸 수 있도록 합니다.

Cisco Expressway 고려 사항

Cisco Expressway for Web Proxy를 사용하는 경우 CMS 업그레이드 전에 Expressway가 X12.6 이상 실행 중인지 확인해야 합니다. 웹 프록시가 작동하고 지원되려면 CMS 3.0이 필요합니다.

CMS 3.0과 함께 사용할 경우 Expressway보다 웹 앱 참가자의 용량이 증가했습니다.  대규모 OVA Expressway의 경우 150개의 풀 HD 통화(1080p30) 또는 200개의 기타 유형 통화(예: 720p30)가 필요한 기능이 필요합니다.  최대 6개의 노드(확장 시 4개, 리던던시 2개, 최대 600개의 풀 HD 통화 또는 800개의 기타 유형 통화)를 클러스터링하여 이 용량을 늘릴 수 있습니다.

CMS 에지

CMS Edge는 외부 웹 앱 세션용 Expressway보다 더 큰 용량을 제공하는 CMS 3.1에 다시 도입되었습니다. 두 가지 권장 구성이 있습니다.

소규모 에지 사양

4GB RAM, 4개의 vCPU, 1Gbps 네트워크 인터페이스

이 VM Edge 사양은 48 x 1080p, 96 x 720p, 192 x 480p 및 1000 오디오 통화인 단일 CMS1000 오디오 및 비디오 로드 용량을 충분히 수용할 수 있습니다.

구축의 경우 CMS1000당 1개의 소규모 에지 서버 또는 CMS2000당 4개의 소규모 에지 서버를 사용하는 것이 좋습니다.

대규모 에지 사양

8GB RAM, 16개의 vCPU, 10Gbps 네트워크 인터페이스

이 VM Edge 사양은 350 x 1080p, 700 x 720p, 1000 x 480p 및 3000x 오디오 통화인 단일 CMS 2000 오디오 및 비디오 용량을 수용할 수 있는 충분한 전력을 갖추고 있습니다.

구축의 경우 CMS2000당 1개의 대형 에지 서버 또는 4개의 CMS1000당 1개의 대형 에지 서버를 사용하는 것이 좋습니다.