CMS와 CUCM 간의 보안 통신 활성화

소개

이 문서에서는 Cisco Meeting Server(CMS)와 Cisco Unified Communications Manager(CUCM) 간의 통신을 활성화하는 방법에 대해 설명합니다.

사전 요구 사항

요구 사항

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

• CMS 버전 3.8 이상
• CUCM 및 IM&P
• Jabber

사용되는 구성 요소

이 문서의 정보는 다음 소프트웨어 및 하드웨어 버전을 기반으로 합니다.

• CMS 버전 3.8
• CUCM 및 IM&P 14 SU (3)

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

배경 정보

이 문서에서는 Jabber/Web 앱 프레즌스 공유를 위해 CMS와 CUCM 간의 보안 통신을 설정하는 프로세스에 대해 간략하게 설명합니다. CMS에서 웹 앱 미팅을 진행하는 동안 Jabber 사용자의 업데이트 상태를 구성하고 트러블슈팅하는 자세한 단계를 설명합니다. Jabber 사용자가 Cisco Meeting Server 웹 앱 미팅에 참여하는 동안 프레즌스 상태를 업데이트하기 위해 Meeting Server를 구성할 수 있습니다.

구성

CMS와 CUCM/IMP 서버 간의 보안 통신 활성화

OS 관리 페이지에서 CUCM에 로그인하고 TOMCAT 인증서로 이동하여Security > Certificate Management 다운로드합니다.

CUCM Tomcat 인증서

OS 관리 페이지에서 Cisco Unified Presence Server(CUPS)에 로그인하고 CUPS 인증서로 Security > Certificate Management 이동하여 다운로드합니다.

Presence CUPS 인증서

Tomcat 및 Cup 인증서에 서명한 ROOT CA 인증서를 다운로드합니다.

Tomcat의 루트 인증서

CUPS용 루트 인증서

CUCM 인증서의 인증서 번들을 만듭니다. 번들 인증서는 서버 인증서를 맨 위에 놓고 중간 인증서(any)를 가운데에 두고 ROOT 인증서를 맨 아래에 두고 캐리지 리턴을 1개 추가하는 것을 의미합니다.

다음은 BUNDLE 인증서의 샘플입니다.

Tomcat 인증서 번들

CUPS 인증서의 인증서 번들을 생성합니다. 번들 인증서는 서버 인증서를 맨 위에 놓고 중간 인증서(any)를 가운데에 두고 ROOT 인증서를 맨 아래에 두고 캐리지 리턴을 1개 추가하는 것을 의미합니다.

CUPS 인증서 번들

이전에 생성한 번들 인증서를 WinSCP를 통해 CMS 서버에 푸시합니다.

CMS에 인증서 번들 복사

를 사용하여 Callbridge에 TOMCAT 번들 인증서를 callbridge ucm certs <cert-bundle> 할당합니다.

Callbride 인증서 신뢰

를 사용하여 Callbridge에 CUP 서버 번들 인증서를 callbridge imps certs <cert-bundle> 할당합니다.

인증서 번들이callbridge 할당되었는지 확인하려면 명령을 실행합니다.

Callbridge 트러스트 인증서 확인

CUCM Administrator로 CUCM에 로그인하고 로 이동하여 User Management > User Settings > Access Control Group Add New 을 클릭한 다음 Access Control Group(액세스 제어 그룹)을 생성합니다CUCM_AXL_Group.

AXL 그룹 생성

이전에 Standard  AXL API Access 생성한 액세스 제어 그룹에 역할을 할당합니다.

AXL 그룹에 API 액세스 할당

Application User(애플리케이션 사용자)로 User Management > Application User이동하여 을 클릭하고Add New 생성합니다AXLuser. 그런 다음 이전에 생성한 액세스 제어 그룹을 할당합니다.

사용자 생성 및 AXL 그룹 할당

CUP 사용자를 만들고 Third Party Application Users 및Admin-3rd Party API 두 가지 역할을 할당합니다.

CUP 사용자 생성

다음을 사용하여 CMS에서 CUCM 및 Cisco Unified Communications Manager IM & Presence Service(IMPS) 인증서에 대한 인증서 확인을 활성화합니다.

callbridge ucm verify <enable/disable>

callbridge imps verify <enable/disable>

Callbridge CUCM 및 CUPS 인증서 확인

명령을 실행하여 callbridge 확인합니다.

Callbrdge 명령 검사

이제 CMS에서 callbridge ucm add <hostname/IP> <axl_user> <presence_user>를 사용하여 이전에 생성한 CUCM FQDN(Fully Qualified Domain Name) 및 사용자 AXL 및 CUPS를 추가합니다.

axl_user = CUCM의 AXL 사용자

presence_user = 이전에 생성한 CUP 사용자

Callbridge에 CUCM 추가

이제 CMS가 다음과 같은 방법으로 CUCM 서비스를 신뢰하는지 확인합니다.

callbridge ucm <hostname/IP> axl_service status

callbridge ucm cucm14test.test.com axl_service status

Callbridge AXL 상태

callbridge imps <hostname/IP> <presence_user> presence_service status

wb3> callbridge imps impnew.test.com cisco presence_service status

Callbridge 프레즌스 상태

사용 가능한 서비스는 CUCM과 CMS가 AXL 및 프레즌스 서비스에 대해 서로 신뢰한다는 것을 의미합니다.

Webapp과 Jabber 클라이언트 간의 프레즌스 공유를 위한 CUCM 전용 컨피그레이션

CUCM에 LDAP가 구성되어 있어야 합니다.

LDAP 시스템:

CUCM LDAP 컨피그레이션 1

LDAP 디렉터리:

CUCM LDAP 컨피그레이션 2

LDAP 인증:

CUCM LDAP 컨피그레이션 1 CUCM LDAP 컨피그레이션 1 CUCM LDAP 컨피그레이션 1 CUCM LDAP 컨피그레이션 3

LDAP에서 Mail-ID가 구성된 CUCM으로 사용자를 가져옵니다.

CUCM의 사용자

CUCM 사용자가 CUPS 서버에서 업데이트됨:

CUPS 사용자

동일한 LDAP 디렉토리가 CMS에도 구성됩니다. 사용자 데이터베이스가 CMS에서 풀링되고 동기화됩니다.

CMS 사용자

이제 CMS가 CUCM을 신뢰할 수 있음을 이미 검증했으므로 프레즌스 테스트를 진행할 수 있습니다.

CMS에 컵 및 CUCM 추가

다음을 확인합니다.

동일한 사용자(동일한 LDAP에서 동기화됨)로 두 클라이언트에 서명됨:

Jabber 및 webapp에서 사용자 로그인

두 클라이언트가 동일한 사용자 test@test.com에 로그인했습니다.

통화 전 Jabber 및 Webapp 프레즌스

Webapp에서 통화에 참가할 때 프레즌스 상태가 변경됩니다.

Jabber 사용자가 웹 앱에 로그인하고 미팅에 참여하면 Meeting Server는 Jabber 상태를 'In a meeting, In a call'로 업데이트하고 사용자가 회의를 종료한 후 이전 상태로 되돌립니다. 예를 들어, Jabber의 사용자 상태가 'Available(사용 가능)'로 표시되면 웹 앱 미팅에 있을 때 'In a meeting, In a call(미팅 중, 통화 중)'로 업데이트됩니다. 사용자가 미팅에서 나가면 Jabber 상태가 다시 'Available(사용 가능)'로 설정됩니다. Jabber 사용자가 웹 앱 미팅에 참가하는 동안 다른 미팅/통화에 있는 경우 Meeting Server는 Jabber 상태를 업데이트하지 않습니다. Jabber 사용자가 웹 앱 미팅에 참가하기 전에 상태를 'DND - Do not disturb'로 설정한 경우 Meeting Server는 Jabber 상태를 업데이트하지 않습니다. 사용자가 웹 앱 회의 중에 언제든지 수동으로 Jabber 상태를 업데이트할 경우 Meeting Server는 수동으로 업데이트된 사용자 상태를 재정의하지 않습니다.