Expressway를 통해 CMS WebRTC 또는 Web App 프록시 구성

소개

이 문서에서는 Expressway를 통해 Cisco CMS(Meeting Server) WebRTC를 구성하고 문제를 해결하는 단계에 대해 설명합니다.

사전 요구 사항

요구 사항

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

• Expressway X12.6.1 이상(x12.6.1 이상에서는 Exp TURN 동작이 변경되어 CMS 2.9.2 이상에서만 작동함)
• CMS 서버 2.9.3 이상
• NAT(Network Address Translation)
• NAT 주변 릴레이를 사용하는 접근(TURN)
• NAT용 세션 접근 유틸리티(STUN)
• DNS(Domain Name System)

구성 사전 요구 사항:

• Expressway에서 기본 모바일 및 원격 액세스(MRA) 관련 설정(UC Traversal 영역, SSH 터널)을 이미 활성화하고 구성해야 합니다. MRA 가이드를 보려면 여기를 클릭하십시오.
• CMS에서 구성 및 활성화된 CMS 2.9.x - WebBridge(WB), XMPP 및 CallBridge는 컨피그레이션 가이드를 참조하십시오.
• Expressway-E에 설치된 TURN 옵션 키
• 공용 인터넷에서 Expressway-E의 공용 IP 주소로 방화벽에서 열린 TCP 포트 443
• 공용 인터넷에서 Expressway-E의 공용 IP 주소로 방화벽에서 열린 TCP 및 UDP 포트 3478(TURN 요청)
  • CMS API의 'turnservers'에 tcpPortNumberOverride가 3478로 설정된 경우에만 TCP 3478이 필요함
• CMS에서 Expressway-E의 프라이빗 IP 주소(Expressway-E에서 듀얼 NIC를 사용하는 경우)로 방화벽에서 열린 UDP 포트 3478(TURN 요청)
  • CMS 2.9.2 및 이전 버전에서는 Exp E에 바인딩 요청을 전송하는 반면 2.9.3은 할당 요청을 전송합니다.
• Expressway-E의 공용 연결 IP 주소로 확인할 수 있는 webbridge의 조인 URL에 대한 외부 DNS 레코드
• webbridge 서버의 IP 주소로 확인할 수 있는 조인 URL에 대한 내부 DNS 레코드
• X12.5.2 또는 이전 버전을 실행하는 경우 Expressway-E의 공용 IP 주소에 대해 외부 방화벽에서 NAT 리플렉션이 허용되는지 확인하려면 컨피그레이션의 예를 보려면 여기를 클릭하십시오.X12.5.3 현재 독립형 Expressway에는 더 이상 필요하지 않습니다.
• TURN443을 사용할 때는 외부 방화벽의 미디어용 UDP 포트 3478을 열어야 합니다

참고:Jabber 게스트 서비스에 사용되는 Expressway 쌍은 CMS WebRTC 프록시 서비스에 사용할 수 없습니다.

사용되는 구성 요소

이 문서는 특정 소프트웨어 및 하드웨어 버전으로 제한되지 않지만 최소 소프트웨어 버전 요구 사항을 충족해야 합니다.

• CMS API(Application Program Interface)
• 고속도로
• CMS 서버

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

배경 정보

Expressway 버전 X8.9.2에서 WebRTC 프록시 지원이 추가되었습니다. 이를 통해 오프프레미스 사용자가 Cisco Meeting Server 웹 브리지를 탐색할 수 있습니다.

외부 클라이언트 및 게스트는 지원되는 브라우저 이외의 소프트웨어 없이도 공간을 관리하거나 가입할 수 있습니다.지원되는 브라우저 목록을 보려면 여기를 클릭하십시오.

2021년 2월 5일부터 CMS 3.1.1에 지원되는 브라우저입니다.

구성

네트워크 다이어그램

이 이미지는 CMS WebRTC용 웹 프록시의 연결 흐름 예를 제공합니다.(Exp IP 포트 사용 컨피그레이션 가이드)

참고:X12.5.2 또는 이전 버전을 실행하는 경우 Expressway-E& public IP 주소에 대한 NAT 리플렉션을 허용하도록 외부 방화벽을 구성해야 합니다(방화벽은 일반적으로 소스 및 대상 IP 주소가 동일한 패킷을 신뢰하지 않음). X12.5.3 현재 독립형 Expressway에는 더 이상 필요하지 않습니다.

구성 단계

1단계. CMS WB를 Expressway-C에 통합

a.Configuration(구성) > Unified Communication(통합 커뮤니케이션) > Cisco Meeting Server(Cisco Meeting Server)로 이동합니다.

b.Meeting Server 웹 프록시를 사용하도록 설정합니다.

c. Guest 계정 클라이언트 URI 필드에 Join URL을 입력합니다.

d.저장을 클릭합니다.

e.Expressway-E 서버 인증서에 CMS Join URL을 SAN(Subject Alternative Name)으로 추가합니다. Cisco VCS Certificate Creation and Use Deployment Guide를 참조하십시오.

2단계. Expressway-E에서 TURN을 활성화하고 로컬 인증 데이터베이스에 인증 자격 증명을 추가합니다.

a.Configuration(컨피그레이션) > Traversal(접근) > TURN으로 이동합니다.

b.TURN 서비스(끄기)를 설정

c. 로컬 데이터베이스에서 TURN 클라이언트 자격 증명 구성을 선택하고 자격 증명(사용자 이름 및 비밀번호)을 추가합니다.

참고:Expressway-E의 클러스터가 있고 모두 TURN 서버로 사용될 경우 모든 노드에서 이 클러스터를 활성화해야 합니다.API를 통해 두 개의 개별 turnServer 인스턴스를 구성하고 클러스터의 각 Expressway-E 서버를 가리키도록 해야 합니다(단계 4에 표시된 컨피그레이션 프로세스에 따라). 이는 하나의 Expressway-E 서버에 대한 프로세스를 보여줍니다.두 번째 turnServer의 컨피그레이션은 서로 유사하며, 해당 IP 주소를 사용하고 다른 Expressway-E 서버에 대한 자격 증명을 활성화하기만 하면 됩니다.

참고:TCP/HTTPS 트래픽에 대해 고속도로 앞에 있는 네트워크 로드 밸런서를 사용할 수 있지만 TURN 미디어는 클라이언트에서 TURN 서버로 공용 IP로 이동해야 합니다.  TURN 미디어는 네트워크 로드 밸런서를 통과해서는 안 됩니다.

3단계. Expressway-E의 관리 포트를 변경합니다.

webtc 연결이 TCP 443에서 시작되므로 이 단계는 필수입니다. 그러나 Exp 12.7에서는 443에 사용할 수 있는 새로운 DMI(Dedicated Management Interface)를 도입했습니다.

a.System(시스템) > Administration(관리)으로 이동합니다.

b.웹 서버 컨피그레이션에서 웹 관리자 포트를 드롭다운 옵션에서 445로 변경한 다음 저장을 클릭합니다.

c. WebRTC 프록시 서비스에 사용되는 모든 Expressway-E에서 3a~3b 단계를 반복합니다.

참고:WebRTC 클라이언트는 443을 사용하므로 관리 포트를 변경할 것을 권장합니다. WebRTC 브라우저가 포트 80에 액세스하려고 하면 Expressway-E는 연결을 443으로 리디렉션합니다.

4단계. 미디어 NAT 통과를 위한 TURN 서버로 Expressway-E를 CMS 서버에 추가합니다.

CMS 2.9.x 이후 단계에서 Configuration(컨피그레이션) —> API(API) 메뉴를 사용하여 턴서버를 추가합니다.

• 서버 주소:(Expressway의 프라이빗 IP 주소)
• 클라이언트 주소:(Expressway의 공용 IP 주소)
• 유형:(고속도로)
• 사용자 이름:(2c단계에서 구성된 대로)
• 암호:(2c단계에서 구성된 대로)
• tcpPortNumberOverride:3478

d.TURN에 사용할 모든 Expressway-E 서버에 대해 4c 단계를 반복합니다.

이 이미지는 구성 단계의 예를 제공합니다.

다음을 확인합니다.

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

1단계. Expressway-C에서 WB가 올바르게 통합되었는지 확인합니다.

a.Configuration(컨피그레이션) > Unified Communication(통합 커뮤니케이션) > Cisco Meeting Server(Cisco Meeting Server)로 이동하고 WB의 IP 주소를 확인해야 합니다.

b.Configuration(컨피그레이션) > Unified Communication(통합 커뮤니케이션) > HTTP allow list(HTTP 허용 목록) > Automatically added rules(자동으로 추가된 규칙)로 이동하여 이 규칙이 규칙에 추가되었는지 확인합니다.

Meeting Server web bridges 	https 	443 	Prefix 	/ 	GET, POST, PUT, HEAD, DELETE
Meeting Server web bridges 	wss 	443 	Prefix 	/ 	GET, POST, PUT, HEAD, DELETE

참고:규칙은 WB에 대한 HTTPS 트래픽의 프록시를 허용하기 위한 것뿐, 통합 커뮤니케이션에 반드시 필요한 것은 아니기 때문에 검색된 노드에서 WB를 찾지 못할 것으로 예상됩니다.

c. WB FQDN에 대한 SSH(Secure Shell) 터널이 Expressway-C에서 Expressway-E로 구축되었으며 활성화되어 있는지 확인합니다.Status(상태) > Unified Communications > Unified Communications SSH tunnels(Unified Communications SSH 터널) 상태로 이동하고 WB의 FQDN을 확인해야 하며 대상은 Expressway-E여야 합니다.

2단계. TURN 서버가 CMS 서버에 추가되었는지 확인합니다.

CMS API 메뉴에서 턴서버를 찾아 각 서버를 클릭합니다.각 객체 내에 상태를 확인할 수 있는 링크가 있습니다.

출력에 TURN 서버와 연결된 RTT(Round-Trip Time)를 포함하는 정보가 표시됩니다.이 정보는 사용할 최상의 TURN 서버의 CB 선택에 중요합니다.

3단계. 진행 중인 통화 중에 TURN 릴레이 사용 확인

WebRTC 클라이언트를 사용하여 라이브 통화를 할 때 Expressway에서 TURN 미디어 릴레이 상태를 볼 수 있습니다.Status(상태) > TURN relay usage(TURN 릴레이 사용)로 이동한 다음 보기를 선택합니다.

문제 해결

유용한 툴:

• 브라우저에서 HAR 파일(Chrome 또는 Firefox에서 HAR 파일을 생성하는 방법)
• 브라우저에서 WebRTC 내부 휴지통 - chrome://webrtc-internals 또는 edge://webrtc-internals - 조인이 시도되는 즉시 덤프 만들기
• 브라우저 콘솔 로그도 유용할 수 있습니다.
• 클라이언트, Exp E, Exp C 및 CMS에서 Wireshark 캡처
• Exp E network.http.traficserver 디버그는 웹 소켓 문제 해결을 지원합니다.

외부 WebRTC 클라이언트가 연결되지만 미디어가 연결되지 않음(ICE 오류로 인해)

이 시나리오에서 RTC 클라이언트는 통화 ID를 jalero.space로 확인할 수 있지만 이름을 입력하고 가입 통화를 선택하면 다음 이미지에 표시된 대로 클라이언트가 연결을 표시합니다.

약 30초 후에 초기 WB 페이지로 리디렉션됩니다.

문제를 해결하려면 다음 단계를 완료하십시오.

• 통화를 시도할 때 RTC 클라이언트에서 wireshark를 시작하고 오류가 발생하면 캡처를 중지합니다.
• 문제가 발생한 후 CMS 이벤트 로그를 확인합니다.

CMS WebAdmin에서 Logs(로그) > Event logs(이벤트 로그)로 이동합니다.

• Wireshark 추적을 stun으로 필터링합니다.다음 예를 참조하십시오.

Wireshark 추적에서 클라이언트가 구성된 자격 증명으로 할당 요청을 포트 3478의 Expressway-E TURN 서버에 전송하는 것을 확인할 수 있습니다.

1329    2017-04-15 10:26:42.108282    10.55.157.229    10.48.36.248    STUN    186 
   Allocate Request UDP user: expturncreds realm: TANDBERG with nonce

서버가 할당 오류로 응답합니다.

1363    2017-04-15 10:26:42.214119    10.48.36.248    10.55.157.229    STUN    254
    Allocate Error Response user: expturncreds with nonce realm: TANDBERG UDP error-code: 431
 (*Unknown error code*) Integrity Check Failure

또는

3965    2017-04-15 10:34:54.277477    10.48.36.248    10.55.157.229    STUN    218
    Allocate Error Response user: expturncreds with nonce realm: TANDBERG UDP error-code: 401
 (Unauthorized) Unauthorized

CMS 로그에 다음 로그 메시지가 표시됩니다.

2017-04-15	10:34:56.536	Warning	call 7: ICE failure 4 (unauthorized - check credentials)

해결책:

CMS에 구성된 TURN 자격 증명을 확인하고 Expressway-E 로컬 인증 데이터베이스에 구성된 것과 일치하는지 확인합니다.

외부 WebRTC 클라이언트가 통화 참가 옵션을 가져오지 않음

Callbridge Status > General 페이지에 다음과 같이 표시됩니다.

2017-04-15	12:09:06.647	Web bridge connection to "webbridge.alero.aca" failed (DNS failure)
2017-04-15	12:10:11.634	Warning	web bridge link 2: name resolution for "webbridge.alero.aca" failed
2017-04-15	11:55:50.835	Info	failed to establish connection to web bridge link 2 (unknown error)

해결책:

• Callbridge에서 Webbridge FQDN에 대한 Join URL을 확인할 수 있는지 확인합니다(Callbridge는 Expressway-E의 IP 주소로 이를 확인하지 않아야 함).
• CLI(Command Line Interface)를 통해 Callbridge의 DNS 캐시를 dns flush 명령으로 플러시합니다.
• WB가 Callbridge 서버 인증서(발급자가 아님)를 신뢰하는지 확인합니다.

외부 WebRTC 클라이언트가 공동 공간에 연결할 때(미디어 로드 중) 중단된 다음 WB 초기 페이지로 리디렉션됩니다.

해결책:

• CMS가 CB 도메인의 내부 네트워크에서 _xmpp-client SRV 레코드를 확인하고 WebRTC 연결이 내부적으로 작동하는지 확인합니다.
• 클라이언트에서 Wireshark 캡처를 수집하고 외부 클라이언트와 연결을 시도하는 동안 Expressway-E에서 tcpdump를 비롯한 진단 로깅을 수집합니다.

Maintenance(유지 관리) > Diagnostics(진단) > Diagnostic logging(진단 로깅)으로 이동하고 Start new log(새 로그 시작)를 선택하기 전에 이 이미지에 표시된 대로 로깅 동안 tcpdump를 선택했는지 확인합니다.

참고:실패 통화를 다시 시작하기 전에 클라이언트 디바이스에서 Wireshark 캡처 및 Expressway-E의 로깅을 시작해야 합니다.실패한 통화가 재생되면 Expressway-E의 로깅 및 클라이언트의 캡처를 중지하고 다운로드합니다.

• Expressway-E에서 다운로드된 로그 번들의 압축을 풀고 공용 인터페이스에서 가져온 .pcap 파일을 엽니다.
• stun을 사용하여 두 패킷 캡처를 필터링합니다.
  • 그런 다음 외부 클라이언트에서 Expressway-E 공용 IP 주소로의 바인딩 요청을 찾아 마우스 오른쪽 버튼으로 클릭한 다음 Follow(따라하기) > UDP Stream(UDP 스트림)을 선택합니다.
  • 일반적으로 클라이언트의 바인딩 요청의 대상 포트는 24000-29999 범위에 있으며, 이는 Expressway-E의 TURN 릴레이 포트 범위입니다.
• 클라이언트 측에서 바인딩 요청에 대한 응답이 수신되지 않은 경우 요청이 도착하고 있는 경우 Expressway-E의 캡처를 확인합니다.
• 요청이 도착하고 Expressway-E가 클라이언트에 회신하는 경우 External FW에서 아웃바운드 UDP 트래픽을 허용하는지 확인합니다.
• 요청이 도착하지 않을 경우 FW를 확인하여 위의 포트 범위가 차단되지 않았는지 확인합니다.
• Expressway-E가 고정 NAT 모드가 활성화되고 X12.5.2 이전 버전인 듀얼 네트워크 인터페이스 컨트롤러(DUAL-NIC)와 함께 구축되어 있는 경우 외부 FW에서 NAT 리플렉션이 지원 및 구성되었는지 확인합니다.X12.5.3 현재 독립형 Expressway에는 더 이상 필요하지 않습니다.

외부 WebRTC 클라이언트가 공동 공간에 가입할 수 없으며 경고를 받습니다(연결할 수 없음 - 나중에 다시 시도).

이 시나리오에서는 RTC 클라이언트가 통화 ID를 jalero.space로 확인할 수 있지만 이름을 입력하고 가입 통화를 선택하면 연결할 수 없음 - 나중에 다시 시도라는 경고가 즉시 표시됩니다.

해결책:

내부 네트워크의 CMS가 항상 CB 도메인에 대한 _xmpp-client SRV 레코드를 확인할 수 있는지 확인합니다.

관련 정보

• VCS/Expressway IP 포트 사용 설명서
• 기술 지원 및 문서 − Cisco Systems