목차

소개

사전 요구 사항

요구 사항

사용되는 구성 요소

기존 CMS 회의에 참가자를 추가하는 방법

구성

다음을 확인합니다.

문제 해결

관련 정보

소개

이 문서에서는 로드 밸런싱이 활성화된 클러스터형 CMS를 구축할 때 기존 CMS 회의에 참가자를 추가하는 방법에 대해 설명합니다.

사전 요구 사항

요구 사항

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

- CMS 로드 밸런싱(Cisco Meeting Server)

- CUCM 임시 회의(Cisco Unified Communications Manager)

이 문서에서는 CB(클러스터링된 Callbridges)에 대해 로드 밸런싱이 이미 구성되어 있으며 이러한 CMS 서버에 대한 직접 통화(기존 CMS 공간으로 직접 통화)를 위해 작업하고 있다고 가정합니다. 이는 이러한 요구 사항이 이미 구성되어 있음을 의미합니다.

- 임시 회의에 사용할 모든 CMS 서버가 CUCM > Media Resources(미디어 리소스) > Conference Bridge(컨퍼런스 브리지)에 추가되고 등록됨

- MRG(미디어 리소스 그룹)가 포함된 MRGL(미디어 리소스 그룹)이 생성되고 CMS 서버만 있으며 MRGL의 첫 번째 그룹입니다.

- 경로 그룹이 포함된 경로 목록이 생성되고 CMS 서버가 있고 선택한 배포 알고리즘이 순환입니다

사용되는 구성 요소

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

- CMS 2.9.1

- CUCM 12.5.1

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

기존 CMS 회의에 참가자를 추가하는 방법

참고:기존 CMS 회의에 참가자를 추가하는 주요 방법에는 세 가지가 있습니다.API를 통해 참가자를 추가하고, Active Control을 통해 참가자를 추가하고, Active Control 없이 참가자를 추가합니다.

1. API를 통해 참가자를 추가합니다.

이 메서드를 사용하려면 Callbridge 그룹에서 LoadbalanceOutgoingCalls를 활성화해야 합니다.

이 방법을 사용하여 참가자를 추가하려면 API POST 요청을/calls/<active-call-id>/participants/로 수행해야 합니다.POST 요청은 이 POST 요청의 일부인 remoteParty 매개변수의 값으로 전화회의에 추가되는 참가자의 participantID를 포함해야 합니다.

이 POST 요청은 CMS가 추가되는 참가자에게 발신 통화를 하도록 지시합니다.Callbridge 그룹의 LoadbalanceOutgoingCalls가 활성화되고 CMS가 로드 제한에 도달한 경우 클러스터에서 사용 가능한 CMS 서버를 찾아 참가자에게 발신 통화를 추가하고 두 서버 간에 분산 통화가 생성됩니다.이는 CMM에서 참가자를 CMS 회의에 추가하는 방법과 동일합니다.

2. Active Control을 통해 참가자를 추가합니다.

Active Control 참가자를 추가하려면 먼저 CMS 서버와 참가자를 추가하는 사용자 간에 Active Control을 협상해야 합니다.

CUCM을 CMS와 연결하는 SIP 트렁크에 구성된 SIP 트렁크 프로파일에서 Active Control을 활성화하여 매개변수 Allow IX application media(IX 애플리케이션 미디어 허용)를 활성화하고 TelePresence Conferencing용 표준 SIP 프로파일은 기본적으로 활성화되어 있습니다.또한 Callbridge 그룹의 LoadbalanceOutgoingCalls를 활성화해야 합니다.

참가자가 기존 CMS 회의에 Active Control을 통해 추가되면 (활성 제어 메시지를 통해) 사용자가 새 참가자에게 발신 통화를 하도록 지시합니다.CMS1에 구성된 로드 제한 값에 도달하고 사용자가 활성 제어권을 가진 새 참가자를 추가하려고 하면 CMS1에는 다음 오류 메시지가 표시됩니다(최대 CMS 버전 2.9.1).

add participant "<participant-uri>" request failed: call bridge unavailable

이는 참가자가 임시 회의에 추가되거나 활성 제어를 통해 기존 CMS 공간에 추가된 두 활용 사례 모두에 적용됩니다.

이는 악의적인 행동이며 결함 아래 추적됩니다. CSCvu72374

3. Active Control 없이 참가자를 추가합니다.

활성 제어를 사용하지 않고 참가자를 추가하면(따라서 SIP 프로파일에서 Allow IX application media not enabled on the SIP Profile), CUCM은 작업을 시작하는 사용자와 새 참가자 간에 전화를 겁니다.그런 다음 사용자가 새 참가자를 전화회의에 참가할 준비가 되면 CUCM은 CMS1에서 실행되는 임시 전화회의로 발신 전화를 겁니다. CMS1에서 로드 제한에 도달하면 참가자를 추가할 수 없으며 CMS1에 이 오류 메시지가 표시됩니다(예: 통화 번호 55입니다).

call 55: ending; local teardown, system participant limit reached - not connected after 0:00

이 오류 메시지는 CMS 서버가 수신 통화를 수신하고 최대 로드 제한에 도달한 후에 인쇄하는 일반적인 오류 메시지입니다.그런 다음 CUCM 또는 VCS(Call Control Server)는 클러스터의 다른 멤버에 대한 통화 라우팅을 계속합니다.그러나 임시 전화회의의 경우 이 작업은 작동하지 않으며 CUCM에 임시 전화회의를 위한 경로 목록이 없으므로 가능하지 않습니다.

구성

이 문서에서는 기존 전화회의에 참가자를 추가하는 세 번째 방법을 사용하는 데 필요한 컨피그레이션 단계를 제공합니다(Active Control 없이 참가자 추가).

이 문서에서 구성 단계를 통해 다루는 동작은 다음과 같습니다.

1. 사용자가 임시 회의를 생성하고, CMS1 서버가 이를 호스팅하고 있습니다.

2. 임시회의 수립 후, 점진적으로 CMS1이 구성된 로딩 한도(API를 통해/시스템/구성/클러스터에서 구성)

3. 사용자가 진행 중인 임시 회의에 새 참가자를 추가하려고 하지만 새 사용자가 전화회의에 연결되지 않습니다.

참고:이 컨피그레이션 절차에서는 사용자가 임시 회의를 호스팅하는 CMS 서버가 로드 제한에 도달했더라도 기존 CMS 임시 회의에 참가자를 추가할 수 있으며, 활성 제어 결함이 해결될 때까지 이 컨피그레이션을 사용할 수 있습니다.Active Control은 해당 Ad-Hoc 전화회의에서 비활성화됩니다.

1단계.  Trunk1용 새 SIP 트렁크 보안 프로파일 생성

- System(시스템) > Security(보안)로 > SIP 트렁크 보안 프로파일

- 새로 추가 선택

- 5040에서 Name을 Trunk1 비 보안 수신으로 설정합니다.

- 디바이스 보안 모드를 비보안으로 설정

- 수신 포트를 5040으로 설정합니다.

- 저장 선택

트렁크1 SIP 보안 프로파일

2단계.  Trunk2용 새 SIP 트렁크 보안 프로파일 생성

- System(시스템)> Security(보안)로 > SIP 트렁크 보안 프로파일

- 새로 추가 선택

- 5041에서 Name을 Trunk2 비보안 수신으로 설정합니다.

- 디바이스 보안 모드를 비보안으로 설정

- Incoming Port(수신 포트)를 5041로 설정합니다.

- 저장 선택

트렁크2 SIP 보안 프로파일

3단계.  새 SIP 정규화 스크립트 만들기

- Device(디바이스) > Device settings(디바이스 설정)> 로 이동합니다. SIP 정규화 스크립트

- 새로 추가 선택

- 이름을 remove_conference_from_call_info_header로 설정합니다.

- 콘텐츠에서 이 스크립트 사용

M = {}

function M.outbound_INVITE(msg)

msg:removeHeaderValue("Call-Info", "<urn:x-cisco-remotecc:conference>")

end

return M

- 저장 선택

4단계.  새 SIP 프로필 만들기

- Device(디바이스) > Device settings(디바이스 설정) > SIP 프로필

- TelePresence Conferencing용 표준 SIP 프로필 선택 및 복사

- Name(이름)을 No active control telepresence conferencing(활성 제어 텔레프레젠스 회의 없음)으로 설정합니다.

- 페이지 하단의 iX 애플리케이션 미디어 허용 확인란 선택을 취소합니다

- 저장 선택

5단계.  새 파티션 만들기

- Call routing(통화 라우팅) > Class of Control(제어 클래스) > 파티션

- 새로 추가 선택

- Name을 cms_adhoc_numbers로 설정합니다.

- 저장 선택

6단계.  새 CSS(Calling Search Space)를 만듭니다.

- 다음으로 이동 통화 라우팅 > 제어 클래스 > 발신 검색 공간

- 새로 추가 선택

- Name을 CMS_adhoc_numbers로 설정합니다.

- 5단계에서 생성한 파티션을 추가합니다. cms_adhoc_numbers

- 저장 선택

발신 검색 공간 구성

7단계.  새 SIP 트렁크, Trunk1을 생성합니다.

- Device(디바이스) > Trunk(트렁크)로 이동합니다.

- 새로 추가 선택

- 트렁크 유형에 대해 SIP 트렁크 선택

- 다음 선택

- 이 값을 입력하고 저장

장치 이름

SIP 트렁크의 이름, Trunk1 입력

모든 활성 Unified CM 노드에서 실행

선택

대상 주소

CUCM 서버 자체의 IP를 입력합니다(예: 10.48.36.50).

대상 포트

Trunk2가 수신 대기하는 포트 입력, 5041

SIP 트렁크 보안 프로파일

5040에서 1단계, Trunk1 비보안 수신에서 생성된 프로파일을 선택합니다.

SIP 프로파일

4단계에서 생성한 프로필 선택, No active control telepresence conferencing

DTMF 신호 처리 방법

RFC 2833 선택

SIP 정규화 스크립트

3단계에서 생성한 스크립트, remove_conference_from_call_info_header를 선택합니다.

트렁크1 SIP 설정

8단계.  새 SIP 트렁크 Trunk2를 생성합니다.

- Device(디바이스) >Trunk(트렁크)로 이동합니다.

- 새로 추가 선택

- 트렁크 유형에 대해 SIP 트렁크 선택

- 다음 선택

- 이 값을 입력하고 저장

장치 이름

SIP 트렁크, 트렁크2의 이름을 입력합니다.

모든 활성 Unified CM 노드에서 실행

선택

발신 검색 공간

6단계에서 생성된 CSS, CMS_adhoc_numbers를 선택합니다.

대상 주소

CUCM 서버 자체의 IP 주소 또는 FQDN을 입력합니다(예: 10.48.36.50).

대상 포트

Trunk1이 수신 대기하는 포트 입력, 5040

SIP 트렁크 보안 프로파일

5041에서 2단계, Trunk2 비보안 수신에서 생성된 프로파일 선택

SIP 프로파일

4단계에서 생성한 프로필 선택, No active control telepresence conferencing

DTMF 신호 처리 방법

RFC 2833 선택

SIP 정규화 스크립트

기존 표준화 스크립트 cisco-meeting-server-interop 선택

Trunk2 SIP 설정

9단계.  새 경로 패턴 생성

- Call Routing(통화 라우팅) > Route/Hunt(경로/헌트)로 이동합니다. 경로 패턴

- 새로 추가 선택

- 설정 경로 패턴 를 클릭합니다.

- Route Partition을 5단계, cms_adhoc_numbers에서 생성한 파티션으로 설정합니다.

- 확인란 사용 긴급 우선 순위

- 통화 분류를 OnNet으로 변경

- 게이트웨이/경로 목록을 이미 구성된 CMS 경로 목록으로 설정합니다(앞서 Requirements 섹션에서 언급됨).

- 저장 선택

경로 패턴

CMS 로드 밸런싱 경로 목록

CMS 로드 밸런싱 경로 그룹

10단계.  CMS 임시 컨퍼런스 브리지 구성 수정

- 미디어 리소스로 이동 > 컨퍼런스 브리지

- 첫 번째 CMS 서버를 선택합니다.

- 변경 SIP 트렁크 Trunk1로 이동하며 7단계에서 생성된 SIP 트렁크

- 확인란 사용 SIP 트렁크 대상을 HTTPS 주소로 재정의

- Hostname /IP Address 필드에서 해당 서버의 Webadmin 인증서에도 존재해야 하는 특정 CMS 서버에 대한 CMS Webadmin FQDN을 설정합니다.

- 저장 선택

- 다른 모든 CMS 서버에서도 동일하게 수행하고, 모든 서버에서 Trunk1을 사용하도록 설정하지만, Hostname/IP Address(호스트 이름/IP 주소) 필드를 특정 CMS FQDN으로 변경합니다.

CMS1

CMS2

CMS3

11단계.  SIP 트렁크 트렁크1 및 트렁크2 재설정

- Device(디바이스) > Trunk(트렁크)로 이동합니다.

- Trunk 1 및 Trunk2 선택

- Reset(재설정)을 선택합니다.

- 둘 다 전체 서비스를 표시할 때까지 기다립니다.

12단계.  CMS 임시 서버 재설정

- Media resources(미디어 리소스) >Conference bridge(컨퍼런스 브리지)로 이동합니다.

- 모든 CMS 서버 선택

- Reset(재설정)을 선택합니다.

- 모든 서버가 등록됨으로 표시될 때까지 대기

다음을 확인합니다.

이 섹션을 사용하여 컨피그레이션이 제대로 작동하는지 확인합니다.

- 임시 회의를 생성하고 어떤 CMS 서버가 회의를 호스팅하는지 확인합니다.

임시 회의를 호스팅하는 CMS1

- 해당 CMS 서버에서 현재 미디어 처리 로드를 확인하고 API GET to/system/load를 사용합니다.

현재 미디어 로드

- 매개변수 로드 제한을 사용하여 POST를 /system/configuration/cluster에 전송하여 서버의 로드 제한을 미디어 처리 로드보다 낮은 값으로 설정합니다(예: 1000).

로드 제한 변경

- 모임에 새 참가자를 추가합니다.CMS1이 한계에 도달했으므로 참가자가 추가되고 CMS1과 다른 CMS 서버 간에 분산되어 생성됩니다.

분산 통화

문제 해결

현재 이 컨피그레이션에 사용할 수 있는 특정 문제 해결 정보가 없습니다.

로그 분석에 Collaboration Solutions Analysis 툴을 사용할 수 있습니다.

관련 정보

- Cisco Meeting Server의 로드 밸런싱 로직

- CMS 구성 설명서

- CMS API 및 MMP 프로그래밍 가이드

- CUCM 구성 설명서