Expressway를 통한 비즈니스 및 비즈니스 통화의 가장 일반적인 문제 해결

소개

이 문서에서는 B2B(Business to Business) 구축에서 가장 일반적인 문제에 대해 설명합니다.Expressway를 통해 B2B 통화를 해결하는 방법.

사전 요구 사항

요구 사항

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

• Expressway-C(Exp-C)
• Expressway-E
• Cisco CUCM(Unified Call Manager)
• Telepresence Video Communication Server-C(VCS-C)

사용되는 구성 요소

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

• Expressway C 및 E X8.1.1 이상
• CUCM(Unified Communications Manager) 10.0 이상

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

 일반적인 문제

 1. 오류 "//SIP/SIPcp/wait_SdlReadRsp:큰 메시지를 무시합니다.최대 5000바이트만 허용합니다.연결을 다시 설정하는 중입니다."

VCS에 등록된 TelePresence 엔드포인트의 통화, SIP(Session Initiation Protocol) 트렁크에서 CUCM으로 인바운드, "//SIP/SIPcp/wait_SdlReadRsp:큰 메시지를 무시합니다.최대 5000바이트만 허용합니다.연결을 다시 설정하는 중입니다."

Expressway-C/VCS-C의 통화 라우팅 컨피그레이션이 올바르고 통화가 CUCM으로 전송됩니다.SIP Invite 메시지는 CUCM으로 전송되지만 SDL 로그에는 SIP 메시지가 없습니다.이 오류는 SDL 로그에서 확인할 수 있습니다.

"|AppInfo |SIPTcp - xxx.xxx.xxx.xxx:[27469]의 큰 메시지를 무시합니다.최대 5000바이트만 허용합니다.연결을 다시 설정하는 중입니다."

CUCM 8.6에서 CUCM 9.X가 11000으로 변경된 후 SIP Max Incoming Message Size의 기본값은 5000입니다. 그러나 8 이하에서 버전 9 또는 10으로 업그레이드하면 이전 버전의 소프트웨어(5000)에서 기본값이 유지됩니다. 

솔루션

이 문제는 버그 CSCts00642와 관련이 있습니다.

CUCM Advanced Service Parameter SIP Max Incoming Message Size(CUCM 고급 서비스 매개변수 SIP 최대 수신 메시지 크기)를 기본값인 5000에서 이러한 통화 유형에 적합한 크기로 늘립니다.11000은 대부분의 예상 고객 시나리오에 적합한 가치인 것으로 보입니다.

CUCM Administration(CUCM 관리) 페이지에서 Service Parameters(서비스 매개변수)로 이동하고 CUCM 서버 및 CallManager Service를 선택합니다.

Advanced(고급) 옵션을 선택하고 SIP Max Incoming Message Size(SIP 최대 수신 메시지 크기)를 검색합니다.

2. 다른 통화 서버가 통화를 전송하는 경우 미디어 스트림이 중지됩니다.

이는 MRA(Mobile and Remote Access) 및 B2B 통화에서 발생할 수 있습니다.

통화가 전송된 후 단방향 또는 윙윙거리는 노이즈(암호화된 오디오로 캡처를 재생하려고 할 때 동일한 노이즈)가 발생하지 않습니다.이는 전송된 엔드포인트에서 지원하지 않는 통화 설정에서 암호화 제품군을 선택했기 때문에 발생합니다. 

통화 전송 전후의 SIP 협상을 비교할 수 있습니다. VCS 또는 CUCM 로그의 첫 번째 협상에서 VCS의 200 OK 메시지:

m=audio 54582 RTP/SAVP 9 96 97 0 8 18 101
a=rtpmap:9 G722/8000
a=rtpmap:96 G7221/16000
a=fmtp:96 bitrate=32000
a=rtpmap:97 G7221/16000
a=fmtp:97 bitrate=24000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:ckXijkT3CcVY+xlOf3ozX/TjHPz05OzEdY49rAHA|2^48
a=sendrecv
a=rtcp:54583 IN IP4 10.1.201.7
m=video 54658 RTP/SAVP 96 97
b=TIAS:4000000
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42e01e;max-fs=1621;packetization-mode=1;max-rcmd-nalu-size=32000;level-asymmetry-allowed=1
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=42e01e;max-fs=1621;packetization-mode=0;level-asymmetry-allowed=1
a=rtcp-fb:* nack pli
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:S8BJvGB/2l6F7XP8izXxId443Xd9f27oUI/4gxSt|2^48

 

암호화 회선은 첫 번째 통화에서 수락되지만 두 번째 통화에서 ACK 메시지가 암호화 회선을 제거하는 것을 확인할 수 있습니다.

m=audio 24826 RTP/AVP 0
c=IN IP4 10.1.231.30
a=ptime:20
a=rtpmap:0 PCMU/8000
m=video 0 RTP/AVP 126
c=IN IP4 10.1.98.80
b=TIAS:448000
a=label:11
a=rtpmap:126 H264/90000
a=fmtp:126 profile-level-id=42E01F;packetization-mode=1;max-fs=3601;max-rcmd-nalu-size=32000;level-asymmetry-allowed=1
a=content:main

VCS는 통화가 전송된 엔드포인트가 암호화를 지원하지 않는 경우에도 처음부터 협상된 암호화 라인을 사용하려고 시도합니다. 

솔루션

이 문제는 버그 CSCuv11790과 관련이 있습니다.

이 문제를 해결하려면 VCS/Expressway를 x8.6.1으로 업그레이드하십시오.

3. CUCM에 구성되지 않은 최상위 도메인

Top Level 도메인 Enterprise Parameter가 설정되지 않은 경우 CUCM에서 인바운드 통화를 자체 도메인으로 라우팅하고 SIP Route Patterns가 사용됩니다.이 경우 통화가 Exp-C로 다시 전송될 가능성이 높거나 "404 Not Found 오류"로 실패할 수 있으므로 루프가 발생할 수 있습니다. 

솔루션

CUCM Administration(CUCM 관리) 페이지에서 System(시스템) > Enterprise Parameters(엔터프라이즈 매개변수)로 이동하여 이 설정을 변경합니다.

4. CUCM 인증서에 클라이언트 인증 특성이 적용되어야 합니다.

Exp-C와 CUCM(TLS Verify On) 간에 보안 연결이 설정되면 SSL 핸드셰이크는 통화 방향에 따라 달라지는 특정 통화 서버에 의해 시작됩니다.즉, 두 서버 모두 인증서에 클라이언트 및 서버 인증이 있어야 합니다.특성이 없는 경우 VCS/Expressway 로그에 이 오류가 표시됩니다.

Line 190: 2015-05-07T07:34:01-04:00 XXXXXXXXXXXXXXXX tvcs: UTCTime="2015-05-07 11:34:01,060" Module="network.tcp" Level="DEBUG": Src-ip="10.50.47.16" Src-port="45215" Dst-ip="10.50.47.51" Dst-port="5061" Detail="TCP Connecting"
Line 239: 2015-05-07T07:34:01-04:00 XXXXXXXXXXXXXXXX tvcs: UTCTime="2015-05-07 11:34:01,071" Module="network.tcp" Level="DEBUG": Src-ip="10.50.47.16" Src-port="45215" Dst-ip="10.50.47.51" Dst-port="5061" Detail="TCP Connection Established"
Line 249: 2015-05-07T07:34:01-04:00 XXXXXXXXXXXXXXXX tvcs: UTCTime="2015-05-07 11:34:01,081" Module="network.tcp" Level="DEBUG": Src-ip="10.50.47.16" Src-port="45215" Dst-ip="10.50.47.51" Dst-port="5061" Detail="TCP Connection Closed" Reason="no certificate returned"

솔루션

웹 클라이언트 및 서버 특성을 모두 사용하여 템플릿을 구성하는 방법에 대한 자세한 내용은 VCS 인증서 가이드를 참조하십시오.

http://www.cisco.com/c/dam/en/us/td/docs/telepresence/infrastructure/vcs/config_guide/X8-7/Cisco-VCS-Certificate-Creation-and-Use-Deployment-Guide-X8-7.pdf

5. 연동 문제

VCS/Expressway 버전 X8.6.x에 Interworking 프로세스에 문제가 있었습니다.

문제와 관련된 버그:

VCS/Expressway에서 거부된 비디오 m 라인에 대한 진단 로그를 확인하는 경우 CSCuw85626 결함을 감지할 수 있습니다. 

이 오류 메시지는 H323 흐름의 TCS 부분에 있는 미디어 라인을 협상할 때 표시됩니다. 

미디어라인 인덱스:1

거부:참, 방향:SDP_MEDIA_DIR_SENDRECV

유형:비디오 / SDP_MF_AU_VID

결함 CSCuw85715는 유사하지만 이 경우 VCS/Expressway 로그는 dataTypeNotSupported로 원인을 지정합니다.

2015-10-29T09:49:00+04:00 XXXXXXXXXXXXXXXX tvcs: UTCTime="2015-10-29 05:49:00,197" Module="network.h323" Level="INFO": Action="Sent" Dst-ip="XXXXXXXXXXXXXXXX" Dst-port="49162"
Detail="Sending H.245 OpenLogicalChannelRejResponse "
2015-10-29T09:49:00+04:00 XXXXXXXXXXXXXXXX tvcs: UTCTime="2015-10-29 05:49:00,197" Module="network.h323" Level="DEBUG": Dst-ip="XXXXXXXXXXXXXXXX" Dst-port="49162"
Sending H.245 PDU:
value MultimediaSystemControlMessage ::= response : openLogicalChannelReject :
{
forwardLogicalChannelNumber 3,
cause dataTypeNotSupported : NULL
}

솔루션

X8.7 이상으로 업그레이드하십시오.

  

6. CUCM에서 받은 ACK 메시지가 VCS-E/Expressway-E로 전송되지 않습니다.

이는 일반적으로 구성된 접근 영역이 VCS Expressway/Expressway-E의 올바른 IP 주소를 가리키지 않는 경우에 나타납니다.

단일 NIC 구축(Expressway/Edge에서)에서 Control/Core의 traversal 클라이언트 영역은 통과 서버의 공용 IP 주소를 가리켜야 합니다.

이중 NIC 구축에서 통과 클라이언트는 통과 서버의 내부 IP 주소(내부 NIC는 일반적으로 LAN1이지만 LAN2일 수 있음)를 가리켜야 합니다.내부 LAN의 내부 IP 주소입니다.

솔루션

다른 네트워크 구축에 대한 자세한 내용과 다이어그램은 Cisco VCS Expressway 및 VCS Control - Basic Configuration의 부록 4를 참조하십시오. 

7. CUCM은 인바운드 통화에 대한 TCP 세션을 삭제합니다.

VCS 제어/Expressway Core에서 통화가 전달되면 CUCM은 TCP 세션을 삭제하여 이를 거부할 수 있습니다.

 이는 인접 영역과 sip 트렁크 보안 프로파일 간의 포트가 일치하지 않거나 5060/5061로 구성된 경우에 발생할 수 있습니다.

MRA는 인라인 통신을 사용하는 반면 B2B 통화는 트렁크 통신을 사용하며, CUCM에는 인라인 및 트렁크 통신이 동일한 포트를 통과하도록 허용하지 않는 제한이 있습니다.MRA는 대부분 자동으로 구성되므로 B2B 구축에서는 다른 포트를 사용해야 합니다.

솔루션

이를 위해 VCS-C/Expressway-C에서 CUCM에 대해 네이버 영역에 구성된 목적지 포트는 5060/5061과 달라야 하며, 일반적으로 5065가 사용되지만 다른 포트를 사용할 수 있는 경우 구성된 포트가 CUCM의 이 서버에 할당된 sip 트렁크 보안 프로필에 구성된 포트와 일치해야 합니다.

CUCM Administration(CUCM 관리) 페이지에서 Device(디바이스) > Trunk(트렁크)로 이동합니다.

포트 5065를 사용하는 SIP 트렁크 보안 프로파일 

SIP 트렁크 대상 포트는 이미지에 표시된 대로 5060/5061이 될 수 있습니다.

VCS/Expressway 네이버 영역의 SIP 포트는 이미지에 표시된 대로 SIP 트렁크 보안 프로파일에 구성된 포트와 일치해야 합니다.

Expressway Administration(Expressway 관리) 페이지에서 Configuration(컨피그레이션) > Protocols(프로토콜) > SIP로 이동합니다.

VCS는 이 제한을 가지고 있지 않거나 이 시나리오에 적용되지 않습니다. 즉, SIP 트렁크 자체를 5060/5061로 구성할 수 있습니다.

8. VCS가 FQDN을 올바르게 확인할 수 없거나 SRV 레코드를 쿼리하지 못했습니다.

CUCM에서 시작된 B2B 통화의 경우 CUCM에서 통화를 처리하고 라우팅하는 방식의 특성으로 인해 문제가 발생할 수 있습니다.

CUCM 전달이 VCS 서버로 전화를 걸 때 CUCM은 전화를 건 URI의 끝에 <:5060 또는 <:5061(구성에 따라 다름)을 추가하는 경향이 있습니다(예: test@lab.local >> test@lab.local:5060). VCS는 Expressway에 도달하여 DNS 영역을 향해 검색 규칙에 도달하면 SRV 레코드를 쿼리하지 않고 A 또는 AAAA 레코드만 쿼리합니다.VCS/Expressway의 진단 로그에서 이를 확인할 수 있습니다. 

솔루션

이 문제를 해결하려면 DNS 영역에 도달하기 전에 엔드(두 서버 중 어느 서버에서도 중요하지 않음)에 있는 포트를 제거하는 변환을 생성하기만 하면 됩니다.

Expressway 관리 페이지에서 탐색 구성 > 다이얼 플랜 > 변환 y 구성 > 다이얼 플랜 > 변환으로

 변형 예: 

어떤 이유로 변형을 생성할 수 없는 경우 검색 규칙을 통해 변환을 수행할 수도 있지만 변형을 통해 변환하는 것이 좋습니다.

Expressway 관리 페이지에서 Configuration(구성) > Dial Plan(다이얼 플랜) > Transforms y Configuration(컨피그레이션) > Dial Plan(다이얼 플랜) > Search Rules(검색 규칙)로 이동합니다.

관련 정보

• Cisco VCS Expressway 및 VCS Control - 기본 구성

• Cisco VCS 인증서 생성 및 사용