소개

이 문서에서는 Cisco CallManager에 등록된 Tandberg Codec(TC) 엔드포인트에서 발생하는 몇 가지 일반적인 통화 실패 문제 및 제안 솔루션에 대해 설명합니다.

사전 요구 사항

요구 사항

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

H.323 디버그 로그를 캡처하는 방법

참고: SSH(Secure Socket Host) 세션 출력이 캡처되었는지 확인합니다.

SSH를 코덱에 입력하고 다음 명령을 입력합니다.
- 로그 ctx H.323패킷 디버그 9
- log output on(모든 로그가 SSH 세션 터미널 세션 화면으로 출력됩니다.)
통화를 시작하고 문제를 다시 만듭니다.
log output off를 입력하고 ctx H.323Packet debug off 명령을 기록합니다.

SIP(Session Initiation Protocol) 디버그 로그를 캡처하는 방법

참고: SSH 세션 출력이 캡처되었는지 확인합니다.

SSH를 코덱에 입력하고 다음 명령을 입력합니다.
- 로그 ctx SIPPacket 디버그 9
- log output on(모든 로그가 SSH 세션 터미널 세션 화면으로 출력됩니다.)
통화를 시작하고 문제를 다시 만듭니다.
log output off를 입력하고 ctx SIPPacket debug off 명령을 기록합니다.

TC 엔드포인트에서 패킷 캡처/엔드포인트 로그를 수집하는 방법

웹 GUI에서 Diagnostics > Log files를 선택하고 전체 패킷 캡처를 사용하여 확장 로깅을 활성화합니다.
통화를 시작하고 문제를 다시 만듭니다. 패킷 캡처는 3분 동안만 활성화할 수 있습니다.
웹 GUI에서 Diagnostics > Log files를 선택하고 전체 로그 아카이브 및 패킷 캡처를 다운로드합니다.

기타 정보 필요

관련된 모든 디바이스와 통화 흐름 완료
발신 및 발신 번호
문제가 발생한 날짜 및 시간

사용되는 구성 요소

이 문서는 특정 소프트웨어 및 하드웨어 버전으로 한정되지 않습니다.

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

문제/장애: CallManager의 CSS(Call Search Space)/파티션 문제로 인한 통화 실패

CUCM의 CSS/파티션 문제로 인해 Cisco CUCM(Unified Communications Manager)에 등록된 두 엔드포인트 간의 통화가 실패할 수 있습니다.

발신 엔드포인트 SIP 로그를 캡처합니다. 이 "404 Not Found" 메시지는 CUCM에서 오는 엔드포인트 SIP 로그에 나타납니다.

 |SIP/2.0 404 Not Found
 Via: SIP/2.0/TCP 172.16.2.55:5060;branch=z9hG4bK26e12a6fbed832;received=172.16.2.55
 Call-ID: 77fec00-564180a1-1eec8b-370210ac@172.16.2.55
 CSeq: 101 INVITE
 From: <sip:1502@172.16.2.55>;tag=158127671
 To: <sip:4659@172.16.2.53>;tag=654ba920aeef9e74
 User-Agent: Cisco-CUCM10.5
 Content-Length: 0

솔루션

발신 엔드포인트의 CSS 및 수신 엔드포인트의 파티션을 확인하려면 다음 단계를 완료하십시오. 발신 엔드포인트의 CSS에 발신된 엔드포인트의 파티션이 있는지 확인합니다.

엔드포인트의 디바이스 및 라인 레벨에서 CSS를 할당할 수 있습니다.

Device(디바이스) > Phone(전화기)을 선택하고 엔드포인트를 선택하고 회선을 클릭한 다음 회선 레벨에서 Calling Search Space(CSS)를 선택합니다. 이 예에서는 라인 레벨에서 CSS가 구성되지 않습니다. 그러나 디렉토리 번호 레벨에 CSS가 있는 경우 CSS 중 하나는 호출된 번호의 일부를 가져야 합니다.
전화기 레벨에 지정된 CSS를 확인합니다. Device(디바이스) > Phone(전화기)을 선택하고 문제의 발신 끝점을 선택합니다.
수신한 번호의 파티션을 확인합니다. Device(디바이스) > Phone(전화기)을 선택하고 전화를 건 디바이스를 선택하고 회선을 클릭한 다음 Route Partion(경로 파티션)을 선택합니다.
두 엔드포인트에서 파티션 및 CSS를 확인한 후, 발신 디바이스의 CSS에 호출된 디바이스의 파티션이 있는지 확인합니다.
그렇지 않은 경우 "404 Not Found" 오류의 원인이 될 수 있습니다.

문제/장애: 15분 후(또는 특정 시간 이후) SIP 통화 삭제

일반적으로 특정 시간 간격의 통화 삭제는 방화벽, 라우터 등에 구성된 SIP 타이머 또는 TCP 시간 초과로 인해 발생합니다.

솔루션

통화가 정확히 15분 내에 연결이 끊길 때 나타나는 일반적인 문제는 네트워크에 구성된 TCP 시간 초과(방화벽, 라우터)가 SIP 세션 만료 타이머보다 적다는 것입니다. CallManager에서 기본적으로 SIP Session Expire Timer(SIP 세션 만료 타이머)는 1800초로 설정됩니다.

이를 확인하려면 Cisco Unified CM Administration(Cisco Unified CM 관리) > System(시스템) > Service Parameters(서비스 매개변수) > Cisco Call Manager Service(Cisco Call Manager 서비스) > Look for - SIP Session Expires Timer(SIP 세션 만료 타이머)를 선택합니다.

CUCM에 등록된 모든 엔드포인트는 이 타이머를 사용합니다. 엔드포인트가 다른 원격 엔드포인트와 통화 중일 때 당사자 중 하나가 세션을 새로 고치고 다시 초대하거나 업데이트를 보내야 합니다. 이 새로 고침은 세션 만료 타이머의 절반 전에 전송해야 합니다(1800/2 = 900초 = 15분). 수신된 새로 고침 메시지가 없으면 통화가 끊어집니다.

초기 INVITE에서 세션 타이머를 확인합니다. 이 시간이 만료되기 전에 새로 고침(INVITE/UPDATE)을 받아야 합니다.

|INVITE sip:+1234@10.108.64.22:5060;transport=tcp SIP/2.0
 Via: SIP/2.0/TCP 10.110.68.38:5060;branch=z9hG4bK00eed555
 Call-ID: dbfe0000-4491f669-9fd00-16406c0a@10.108.64.22
 CSeq: 1 INVITE
 Contact: <sip:30048@example.com;gr=urn:uuid:f7a3a098-ead8-5512-85ef-26ae544d6547
   >;isfocus;x-cisco-tip
 From: "TP Conference 30048 - Test" <sip:30048@10.110.68.6>;tag=86251172C3B60000
 To: <sip:1234@10.108.64.22>;tag=25983910~226bf657-9d6c-4ad9-98a2-cf842fe1d733-52629917
 Max-Forwards: 70
 Route: <sip:proxy-call-id=53a00ced-68e1-4ecd-872b-1edbb9abc75b
 @10.110.68.6:5060;transport=tcp;lr>
 Route: <sip:proxy-call-id=53a00ced-68e1-4ecd-872b-1edbb9abc75b
 @10.110.68.6:5060;transport=tcp;lr>
 Allow: INVITE,ACK,CANCEL,OPTIONS,UPDATE,INFO,SUBSCRIBE,NOTIFY,BYE
 User-Agent: TANDBERG/518 (TC6.2.0.20b1616)
 Supported: timer,outbound,record-aware,X-cisco-callinfo
 Session-Expires: 1800;refresher=uac

초기 User Agent Client /User Agent Server(UAC/UAS) 협상에 따라 엔드포인트 중 하나가 Re-INVITE를 전송할 때 세션을 새로 고칩니다. 리프레셔가 UAC인 경우 통화 개시자는 세션을 새로 고칠 책임이 있습니다. 리프레셔가 UAS인 경우 서버는 세션을 새로 고쳐야 합니다. 두 엔드포인트에서 SIP 디버그 로그를 수집하고 다음 항목을 확인합니다.

예: 당사자 A에서 CUCM에서 파티 B로 통화했습니다. 리프레셔가 당사자 A의 UAC와 당사자 B의 UAS인 경우:

파티 A는 CUCM에 re-INVITE/UPDATE를 보내야 합니다.
CUCM은 파티 B에 다시 초대/업데이트를 보내야 합니다.
파티 B는 다시 초대 메시지를 수신하고 200 OK로 해당 메시지에 응답합니다.
CUCM은 당사자 A에 200OK를 보내야 합니다.

한 엔드포인트가 CUCM에 REINVITE 메시지를 보낼 경우 CUCM은 상대방에게 다시 초대합니다. 그러나 원격 측에서 수신하지 못한 경우 그 사이에 있는 일부 네트워크 디바이스 때문일 수 있습니다. SIP 검사 또는 네트워크 설정으로 인해 다시 INVITE/응답이 측면 중 하나에 도달하지 않을 가능성이 높습니다.

엔드포인트에서 다시 초대 를 시작하지 않으면 엔드포인트에 문제가 있을 수 있습니다. 자세한 내용은 Cisco TAC(Technical Assurance Center)를 참조하십시오.

문제/장애: 특정 시간 이후 H.323 통화 삭제

SIP와 마찬가지로, H.323 통화는 일반적으로 네트워크 또는 방화벽 시간 제한 컨피그레이션으로 인해 특정 시간 간격에 통화가 중단됩니다.

솔루션

H.323 통화에서 RTDR(Round Trip Delay Request) 메시지는 시퀀스 번호와 함께 엔드포인트 간 30초마다 전송됩니다. 각 요청에 대해 응답이 필요합니다.

Cisco 엔드포인트는 H.245 멀티미디어 시스템 제어 메시지의 일부인 RTDR/왕복 지연 응답 메시지를 사용합니다. 그러면 활성 통화 관리에 사용되는 통화 중에 H.245 TCP 세션이 활성 상태로 유지됩니다. 엔드포인트가 초기에 RTDR에 대한 응답을 수신하고 통화 중에 응답이 수신되지 않으면 엔드포인트는 통화를 종료합니다.

이 시나리오에서는 문제를 격리하기 위해 H.323 디버그 로그 및 엔드포인트 로그를 수집합니다. H.323 디버그 로그에서 RTDR 요청 및 응답 메시지를 확인하고 삭제되었는지 확인합니다.

이 예제 출력에서 엔드포인트는 원격 엔드포인트에 RTDR 요청을 전송하며 원격 엔드포인트에서 응답을 받지 않습니다. 따라서 통화의 연결이 끊깁니다.

 014-09-23T21:37:01+10:00 corevcs1 tvcs: UTCTime="2014-09-23 11:37:01,
 711"Module="network.H.323" Level="DEBUG":  Dst-ip="10.0.20.11"  
 Dst-port="11012" Sending H.245 PDU: value MultimediaSystemControlMessage
 ::= request : roundTripDelayRequest : {   sequenceNumber 120

요청 및 응답은 sequenceNumbers로 추적할 수 있습니다.

엔드포인트 로그의 다음 예는 연결 끊기의 원인을 보여줍니다.

2977610.83 H.323Call I: H.323_call_handler::handleDiscInd(p=349, s=1) 
Received disconnectindication (Cause: 12:18, H.323 cause: 3:18)- 
NetworkRejected Q85012977610.84 MC I: RemoteParticipant::
reevalRefMode(p=349,ch=2) set ref [Video (2): vid-off0x0@0.0  0k ] 
q= auto, t60=600012977610.84 ModesController I: ModesController::
resetRateLimit(ch=2)12977610.84 MC I: RemoteParticipant::modeChanged
(p=349, ch=2): ModesController wants torun mode: Video (2): vid-off 0x0@0.0  0k

문제/장애: 미디어 리소스 할당 실패로 인한 통화 실패

영상 통화의 경우 미디어 리소스 할당 실패로 인해 실패한 통화가 표시됩니다. 예를 들어, 발신 및 호출된 엔드포인트가 공통 코덱을 지원하지 않으면 트랜스코더가 필요합니다. DTMF(Dual Tone Multi Frequency)가 일치하지 않으면 통화 관리자에서 MTP(Media Termination Point)가 필요합니다.

솔루션

비디오 트랜스코딩의 경우 PVDM2의 트랜스코더가 비디오를 지원하지 않으므로 PVDM3(Packet Voice Digital Module) DSP(Digital Signal Processor) 트랜스코더가 필요합니다. 트랜스코더/MTP를 사용할 수 없는 경우 엔드포인트로 503 Service unavailable 메시지가 전송됩니다.

SIP/2.0 503 Service UnavailableVia: SIP/2.0/TCP 10.101.15.13:
5060;branch=z9hG4bK954956da2012413dfb6ef80d6bc9e373.1;rportFrom:
 <sip:3550@10.102.254.4>;tag=47c4717d0db85e1aTo:
 <sip:1281@10.102.254.4>;tag=176803~66dd1c7a-eac9-42af-a69b-
18da1695a800-31478649Date: 
Wed, 19 Feb 2014 16:10:05 GMTCall-ID: 
c05df2acedcafd063eb5cf947ebc1efcCSeq: 100 INVITEAllow-Events: 
presenceReason: Q.850;cause=47Content-Length: 0

이 문제를 해결하려면 MRG/MRGL(Media Resource Group/Media Resource Group List) 컨피그레이션을 확인하고 비디오 트랜스코더/MTP를 사용할 수 있는지 확인합니다. MRGL은 전화기 레벨 또는 디바이스 풀 레벨에서 디바이스에 할당할 수 있습니다.

CallManger에서 Device > Phone을 선택하고 문제가 있는 디바이스를 선택하고 Device Pool(디바이스 풀)과 MRGL 설정을 확인합니다.
전화기의 MRGL 설정이 None인 경우 Device pool 설정을 확인하여 트랜스코더가 있는지 확인해야 합니다.
System(시스템) > Device Pool(디바이스 풀)을 선택하고 디바이스에 할당된 디바이스 풀을 선택합니다.
Media Resources(미디어 리소스) > Media Resource Group List(미디어 리소스 그룹 목록)를 선택하고 전화기 레벨/디바이스 풀 레벨에서 지정된 MRGL을 선택하고 MRG를 선택합니다.
MRG에 유의하고 Media Resources(미디어 리소스) > Media Resource Group(미디어 리소스 그룹)을 선택하고 표시된 MRG를 선택합니다. PVDM3 하드웨어 트랜스코더/MTP가 추가되었는지 확인합니다.

문제/장애: 대역폭이 부족하여 통화 실패

CUCM의 디바이스의 Region/Location에서 대역폭 컨피그레이션이 부족하여 통화가 끊기는 경우가 종종 있습니다. 해당 지역이 엔드포인트에서 지원할 수 없는 낮은 대역폭으로 설정된 경우 CallManager는 SIP 미디어 협상이 발생한 후 "대역폭이 부족합니다" 또는 "대역폭이 충분하지 않음"을 의미하는 125와 함께 "488 Not Acceptable Media"를 전송합니다.

설명된 대로 엔드포인트에서 SIP 로그를 캡처하고 다음 메시지를 찾아야 합니다.

1459.81 SipPacket I: PacketDump: Proto: SIP, Direction: Incoming, Name: 488 
Not Acceptable Media, CSeq: 100 INVITE, RemoteAddress: 10.106.85.219:5060, 
CallId: 207b6ddb148ddf900ae2e2f844115837, Time: 1459811
	1459.81 SipPacket   SIP/2.0 488 Not Acceptable Media
	1459.81 SipPacket   Via: SIP/2.0/TCP 10.106.85.231:56280;
branch=z9hG4bK64e2eb4a1a3afd5f956a1547eb1c05ad.1;rport
	1459.82 SipPacket   Call-ID: 207b6ddb148ddf900ae2e2f844115837
	1459.82 SipPacket   CSeq: 100 INVITE
	1459.82 SipPacket   From: <sip:4657@example.com>;tag=2d98ee2065ba492d
	1459.82 SipPacket   To: <sip:1112@10.106.85.219>;
tag=10543~8c84fc84-78bb-de4d-3ac7-da2a9cab63d5-19683975
	1459.83 SipPacket   Server: Cisco-CUCM10.5
	1459.83 SipPacket   Date: Sun, 07 May 2015 14:36:41 GMT
	1459.83 SipPacket   Allow-Events: presence
	1459.83 SipPacket   Warning: 370 10.106.85.219 "Insufficient Bandwidth"
	1459.83 SipPacket   Reason: Q.850 ;cause=125
	1459.83 SipPacket   Content-Length: 0
	1459.83 SipPacket   
	1459.83 SipStack I: SipDialog(ui=3,s=9) sendInviteRejToStack (488:Not Acceptable Media)
	1459.84 SipCall I: sip_call_handler::handleSIPMCallRej(3/9/-1): Call rejected
 (cause: Not Acceptable Media)
	1459.84 MainEvents I: CallDisconnectRequested(p=3) remoteURI='sip:1112@10.106.85.219'
 cause=[normal('') 'LocalDisconnect']
	1459.84 MainEvents I: ParticipantLeftConference(c=2,p=3)
	1459.85 APPL_Media ERROR: AudioCtrlImpl::execute_disconnectInputOutput 
No mixer for (p=1,ch=61)
	1459.85 MainEvents I: CallDisconnected(p=3) remoteURI='sip:1112@10.106.85.219' 
causeToLocal=[disconnected('Not Acceptable Media') 'RemoteDisconnect'] 
causeToRemote=[normal('') 'LocalDisconnect']

솔루션

이 문제가 발생하는 경우 두 엔드포인트에 구성된 지역을 확인하고 두 엔드포인트 간의 Region 관계를 확인합니다.

Device(디바이스) > Phone(전화기)을 선택하고 두 디바이스를 모두 선택합니다. 디바이스에 할당된 디바이스 풀을 확인합니다.
Device Pool(디바이스 풀)을 확인한 후 CUCM에서 System(시스템) > Device Pool(디바이스 풀)을 선택하고 두 Device Pools(디바이스 풀)에 구성된 Region(영역)을 선택합니다.
시스템 > 지역 정보 > 지역을 선택하고 지역 관계를 선택합니다. 해당 지역의 오디오 비디오 대역폭을 확인하고 엔드포인트가 선택한 오디오/비디오 대역폭에서 작동할 수 있는지 확인합니다.

위 스크린샷에서는 한 엔드포인트가 "트렁크 영역"에 있고 다른 엔드포인트는 "로컬 엔드포인트 영역"에 있는 것으로 가정합니다.

또 다른 해결 방법은 비디오 통화 대역폭에 대한 대역폭이 부족한 경우 비디오 통화를 오디오 통화로 시도하는 것입니다. 다음 절차를 사용하여 확인 및 구성합니다.

Device(디바이스) > Phone(전화기)을 선택하고 문제가 있는 발신 디바이스를 선택합니다. 이 스크린샷의 매개변수가 선택되어 있는지 확인합니다. 선택하지 않은 경우 대역폭 문제가 발생할 경우 비디오 통화가 오디오로 다시 전송되도록 선택합니다.
이 문제는 CallManager의 위치 설정 때문에 발생할 수 있습니다.
전화기 레벨 또는 디바이스 풀 레벨에서 위치를 할당할 수 있습니다(전화기 레벨이 우선순위가 더 높음).
Phone Level 위치 설정을 확인하려면 Devices(디바이스) > Phones(전화기)를 선택하고 발신 및 호출된 엔드포인트의 위치를 확인합니다.
디바이스 풀 레벨에서 위치를 적용할 수도 있습니다. 따라서 먼저 두 엔드포인트의 디바이스 풀을 확인합니다.
System(시스템) > Device Pool(디바이스 풀)을 선택합니다. 디바이스 풀에서 발신 및 호출된 엔드포인트 모두에 할당된 위치를 확인합니다. 이 예에서는 디바이스 풀 레벨에서 할당된 위치가 없습니다. 전화 위치 컨피그레이션이 사용됩니다.
발신 및 호출된 엔드포인트 위치 간에 충분한 대역폭이 구성되었는지 확인합니다. 이 예에서는 한 엔드포인트가 로컬 엔드포인트 위치에 있고 다른 엔드포인트는 Hub_None 위치에 있고 오디오/비디오 및 화상형 통화의 대역폭이 모두 Unlimited로 구성됩니다.