단방향 음성 문제 해결

소개

이 문서에서는 Cisco 게이트웨이와 관련된 IP 텔레포니 단방향 오디오 대화에서 발생할 수 있는 일반적인 문제에 대해 설명합니다. 

사전 요구 사항

요구 사항

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

• IP 텔레포니 네트워크 및 음성 네트워크에 대한 기본 지식 보유
• Cisco IOS^® 게이트웨이 및 라우터, Catalyst 스위치, DT-24+ 게이트웨이

사용되는 구성 요소

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

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

표기 규칙

문서 규칙에 대한 자세한 내용은 Cisco 기술 팁 표기 규칙을 참고하십시오.

문제

이 문서에서는 다음과 같은 문제에 대한 시나리오와 해결책을 제공합니다.

• Cisco IOS 음성 게이트웨이 또는 라우터를 통해 IP 스테이션에서 전화를 걸면 상대방 중 한 명만 오디오를 수신합니다(단방향 통신).

• 두 Cisco 게이트웨이 간에 유료 바이패스 통화가 설정되면 당사자 중 한 명만 오디오를 수신합니다(단방향 통신).

• VPN 3002 Hardware Client 뒤에 있는 IP 스테이션에서 전화를 걸면 상대방 중 한 명만 오디오를 수신합니다(단방향 통신).

솔루션

IP 텔레포니에서 단방향 오디오의 원인은 다양할 수 있지만, 문제의 근본 원인은 대개 IP 라우팅 문제입니다. 이 섹션에서는 현장에서 발견된 몇 가지 시나리오와 솔루션을 살펴봅니다.

Cisco IOS 게이트웨이 및 라우터에서 IP 라우팅이 활성화되었는지 확인합니다.

VG200과 같은 일부 Cisco IOS 게이트웨이는 기본적으로 IP 라우팅을 비활성화합니다. 이 기본 설정은 단방향 음성 문제로 이어집니다.

IP 라우팅을 활성화하려면 Cisco IOS 게이트웨이에서 다음 글로벌 컨피그레이션 명령을 실행합니다.

voice-ios-gwy(config)#ip routing

기본 IP 연결성 확인

항상 기본 IP 연결성을 먼저 확인합니다. RTP(Real-Time Transport Protocol) 스트림은 연결 없이(UDP를 통해 전송) 있으므로 트래픽이 한 방향으로는 정상적으로 이동할 수 있지만 반대 방향으로는 손실될 수 있습니다. 이 다이어그램은 이러한 상황이 발생할 수 있는 시나리오를 보여줍니다.

서브넷 A와 B는 둘 다 서브넷 X에 도달할 수 있습니다. 서브넷 X는 서브넷 A와 B에 도달할 수 있습니다. 이렇게 하면 엔드 스테이션(A 및 B)과 Cisco CallManager 간에 TCP 연결을 설정할 수 있습니다. 따라서 시그널링은 아무런 문제 없이 양쪽 종착역에 도달할 수 있고, 이는 A와 B 사이의 호 성립을 허용한다.

통화가 설정되면 오디오를 전달하는 RTP 스트림은 엔드 스테이션 간에 양방향으로 이동해야 합니다. 경우에 따라 서브넷 B는 서브넷 A에 연결할 수 있지만 서브넷 A는 서브넷 B에 연결할 수 없습니다. 따라서 A에서 B로의 오디오 스트림은 항상 손실됩니다.

이것은 기본적인 라우팅 문제입니다. 게이트웨이 B에서 전화기 A를 성공적으로 ping할 수 있는 단계로 이동하려면 IP 라우팅 문제 해결 방법을 사용합니다. ping은 양방향 검증입니다.

이 문서에서는 IP 라우팅 문제 해결에 대해서는 다루지 않습니다. 그러나 다음 단계는 다음과 같습니다.

• 기본 게이트웨이는 엔드 스테이션에 구성됩니다.

• 이러한 기본 게이트웨이의 IP 경로는 대상 네트워크로 연결됩니다.

이 목록에서는 다양한 Cisco IP Phone에서 기본 라우터 또는 게이트웨이 컨피그레이션을 확인하는 방법에 대해 설명합니다.

• Cisco IP Phone 7910 - Settings(설정)를 누르고 옵션 6을 선택한 다음 Default Router(기본 라우터) 필드가 나타날 때까지 볼륨을 낮춥니다.

• Cisco IP Phone 7960/40 - Settings(설정)를 누르고 3 옵션을 선택한 다음 Default Router(기본 라우터) 필드가 나타날 때까지 아래로 스크롤합니다.

• Cisco IP Phone 2sp+/30vip - **#을 누른 다음 gtwy=가 나타날 때까지 #을 누릅니다.

올바른 미디어 종료 지점 컨피그레이션 확인

ICT(클러스터 간 트렁크)에 대해 트랜스코딩이 구성된 경우 MTP(Media Termination Point)가 트렁크와 연결된 미디어 리소스 그룹 및 미디어 리소스 그룹 목록에 구성되어 있는지 확인합니다. 필요하지 않을 때 MTP를 지정하거나 필요한 경우 MTP를 구성하지 못할 경우 ICT 컨피그레이션에 단방향 음성 문제가 발생하는 것으로 알려져 있습니다.

Cisco IOS 게이트웨이 및 라우터의 특정 IP 주소에 H.323 신호 바인딩

Cisco IOS 게이트웨이에 여러 활성 IP 인터페이스가 있는 경우 H.323 신호 처리 중 일부는 하나의 IP 주소에서 소싱될 수 있으며, 다른 부분은 다른 소스 주소를 참조할 수 있습니다. 이로 인해 다양한 종류의 문제가 발생할 수 있다. 이러한 문제 중 하나는 단방향 오디오입니다.

이 문제를 해결하려면 H.323 신호 처리를 특정 소스 주소에 바인딩할 수 있습니다. 소스 주소는 물리적 또는 가상 인터페이스(루프백)에 속할 수 있습니다. 인터페이스 컨피그레이션 모드에서 h323-gateway voip bind srcaddr ip-address 명령을 사용합니다. Cisco CallManager가 가리키는 IP 주소가 있는 인터페이스에서 이 명령을 구성합니다.

이 명령은 Cisco IOS Software 릴리스 12.1(2)T에서 도입되었습니다. 가상 인터페이스에 대해서는 H.323 지원을 참조하십시오.

Cisco IOS 게이트웨이의 MGCP 미디어 패킷 소스 인터페이스에 MGCP 신호 처리 바인딩

신호 및 미디어 패킷에 대한 소스 인터페이스가 지정되지 않은 경우 MGCP(Media Gateway Control Protocol) 게이트웨이에서 단방향 음성이 발생할 수 있습니다. mgcp bind media source-interface interface-id를 실행하면 MGCP 미디어를 소스 인터페이스에 바인딩할 수 있습니다 명령 및 mgcp bind control source-interface interface-id 명령을 실행합니다. 명령을 실행한 후 Cisco CallManager에서 MGCP 게이트웨이를 재설정합니다.

mgcp bind 명령이 활성화되지 않은 경우에도 IP 레이어는 최상의 로컬 주소를 제공합니다.

mgcp bind 명령에 대한 지침은 다음과 같습니다.

• 게이트웨이에 활성 MGCP 호출이 있는 경우 제어 및 미디어 모두에 대해 mgcp bind 명령이 거부됩니다.

• bind 인터페이스가 up 상태가 아니면 명령이 수락되지만 인터페이스가 up 상태가 될 때까지 적용되지 않습니다.

• IP 주소가 바인드 인터페이스에 할당되지 않은 경우 mgcp bind 명령은 허용되지만 유효한 IP 주소가 할당된 후에만 적용됩니다. 이 시간 동안 MGCP 호출이 실행 중이면 mgcp bind 명령이 거부됩니다.

• 바인딩된 인터페이스가 수동으로 종료되었거나 운영 실패로 인해 다운되면 해당 인터페이스에서 바인딩 활동이 비활성화됩니다.

• MGC(Media Gateway Controller)에서 바인딩이 구성되지 않은 경우 MGCP 제어 및 미디어를 소싱하는 데 사용되는 IP 주소가 사용 가능한 최상의 IP 주소입니다.

Telco 또는 Switch에서 응답 감독을 올바르게 보내고 받는지 확인

Telco 또는 스위치에 연결된 Cisco IOS 게이트웨이가 있는 경우, Telco 또는 스위치 뒤에 있는 수신 장치가 통화에 응답할 때 응답 관리 기능이 올바르게 전송되는지 확인합니다. 응답 감리를 수신하지 못하면 Cisco IOS 게이트웨이가 오디오 경로를 앞으로 잘라내지 못합니다(열기). 이 실패로 인해 단방향 음성이 발생합니다. 해결 방법은 voice rtp send-recv on 명령을 실행하는 것입니다.

자세한 내용은 Cisco IOS 게이트웨이 및 라우터에서 Cut Through Two-Way Audio Early with the voice rtp send-recv Command를 참조하십시오.

Cisco IOS 게이트웨이 및 라우터에서 voice rtp send-recv 명령을 사용하여 양방향 오디오 조기 통과

음성 경로는 RTP 스트림이 시작될 때 역방향 설정되어 있습니다. 전달 오디오 경로는 Cisco IOS 게이트웨이가 원격 끝으로부터 연결 메시지를 수신할 때까지 차단되지 않습니다.

경우에 따라서는 RTP 채널이 열리자마자 연결 메시지를 수신하기 전인 양방향 오디오 경로를 설정해야 합니다. 이를 위해 voice rtp send-recv 전역 환경 설정 명령을 실행합니다.

Cisco IOS 게이트웨이 및 라우터에서 링크별로 cRTP 설정 확인

이 문제는 둘 이상의 Cisco IOS 라우터 또는 게이트웨이가 음성 경로에 포함되고 압축된 RTP(cRTP)가 사용되는 톨-바이패스와 같은 시나리오에 적용됩니다. cRTP 또는 RTP 헤더 압축은 대역폭을 되찾기 위해 VoIP 패킷 헤더를 더 작게 만드는 방법입니다. cRTP는 VoIP 패킷에서 40바이트 IP, UDP(사용자 데이터그램 프로토콜) 또는 RTP 헤더를 가져와 패킷당 2~4바이트로 압축합니다. 이 압축은 cRTP를 사용하는 G.729 인코딩 통화에 대해 약 12kbps의 대역폭을 제공합니다. cRTP에 대한 자세한 내용은 VoIP(Voice Over IP) - 통화당 대역폭 소비를 참조하십시오.

cRTP는 각 홉에서 압축 해제 및 재압축을 통해 홉별로 수행됩니다. 각 패킷 헤더에서 라우팅을 검사해야 합니다. 따라서 IP 링크의 양쪽에서 cRTP를 활성화해야 합니다.

또한 cRTP가 링크의 양쪽 끝에서 예상대로 작동하는지 확인하는 것이 중요합니다. Cisco IOS Software 릴리스 레벨은 스위칭 경로 및 동시 cRTP 지원 측면에서 다양합니다.

요약하면, 이력은 다음과 같습니다.

• Cisco IOS Software Release 12.0(5)T 이전의 Cisco IOS Software 릴리스에서는 cRTP가 프로세스 스위칭됩니다.

• Cisco IOS Software Release 12.0(7)T 및 Cisco IOS Software Release 12.1(1)T에서는 cRTP에 대한 고속 및 Cisco CEF(Express Forwarding) 스위칭 지원이 도입되었습니다.

• Cisco IOS Software Release 12.1(2)T에서는 알고리즘 성능 개선이 도입되었습니다.

Cisco IOS Software 플랫폼(Cisco IOS Software 릴리스 12.1)에서 cRTP를 실행하는 경우 Cisco 버그 ID CSCds08210이 Cisco IOS Software 릴리스에 영향을 미치지 않는지 확인합니다. 이 버그의 증상은 RTP 헤더 압축을 설정한 상태에서 VoIP 및 Fax over IP가 작동하지 않는 것입니다.

등록된 Cisco 사용자만 내부 Cisco 버그 정보 및 툴에 액세스할 수 있습니다.

Cisco IOS Gateway의 Clocking 컨피그레이션 확인

show controller {e1에서 E1 또는 T1 인터페이스에 클럭 슬립이 있음을 발견한 경우 | t1} 명령입니다. 음성 게이트웨이의 클럭킹 컨피그레이션이 일치하지 않을 수 있습니다. 음성 지원 Cisco IOS 기반 플랫폼의 Clocking Configurations를 참조하고 음성 게이트웨이의 Clocking 컨피그레이션이 올바른지 확인합니다.

Cisco IOS 게이트웨이 및 라우터의 NAT에 대한 최소 소프트웨어 레벨 확인

NAT(Network Address Translation)를 사용하는 경우 최소 소프트웨어 수준 요구 사항을 충족해야 합니다. 이전 버전의 NAT는 Skinny 프로토콜 변환을 지원하지 않습니다. 이러한 이전 버전에서는 단방향 음성 문제가 발생합니다.

Cisco IOS 게이트웨이가 skinny 및 H.323 버전 2와 NAT를 동시에 지원하려면 Cisco IOS Software Release 12.1(5)T 이상을 실행해야 합니다. 자세한 내용은 Cisco CallManager에 대한 IP Phone의 NAT 지원을 참조하십시오.

PIX 방화벽에서 NAT와 skinny를 동시에 사용하기 위해 필요한 최소 소프트웨어 레벨은 6.0입니다. 자세한 내용은 Cisco PIX Firewall 버전 6.0을 참조하십시오.

AS5350 및 AS5400에서 voice-fastpath 비활성화

Cisco IOS Software 명령 voice-fastpath enable은 AS5350 및 AS5400에 대한 숨겨진 글로벌 컨피그레이션 명령입니다. 이 명령은 기본적으로 활성화되어 있습니다. 비활성화하려면 no voice-fastpath enable global configuration 명령을 실행합니다.

이 명령이 활성화되면 특정 통화에 대해 열린 논리 채널에 대한 IP 주소 및 UDP 포트 번호 정보를 캐시합니다. 이 명령은 RTP 스트림이 애플리케이션 레이어에 도달하는 것을 방지합니다. 대신 패킷은 하위 레이어에서 전달됩니다. 이렇게 하면 통화량이 많은 시나리오에서 CPU 사용률을 약간 줄이는 데 도움이 됩니다.

보류 또는 전송과 같은 보조 서비스를 사용할 경우 voice-fastpath 명령을 사용하면 라우터가 오디오를 캐시된 IP 주소 및 UDP 포트로 스트리밍합니다. 보류 중인 통화가 다시 시작되거나 전송이 완료된 후에 생성된 새 논리 채널 정보는 무시됩니다. 이 문제를 해결하려면 트래픽이 애플리케이션 레이어로 지속적으로 이동해야 하므로 논리 채널의 재정의가 고려되고 오디오가 새 IP 주소 및 UDP 포트 쌍으로 스트리밍됩니다. 따라서 보조 서비스를 지원하기 위해 voice-fastpath를 비활성화해야 합니다.

SoftPhone으로 VPN IP 주소 구성

Cisco IP SoftPhone을 사용하면 PC가 Cisco IP Phone 7900 Series 전화기처럼 작동할 수 있습니다. VPN(Virtual Private Network)을 통해 회사 네트워크에 다시 연결하는 원격 사용자는 단방향 음성 문제를 방지하기 위해 몇 가지 추가 설정을 구성해야 합니다. 미디어 스트림은 연결의 엔드포인트를 알아야 하기 때문입니다.

해결책은 네트워크 오디오 설정에서 네트워크 어댑터의 IP 주소 대신 VPN IP 주소를 구성하는 것입니다. 자세한 내용은 How to Use Cisco IP SoftPhone over VPN을 참조하십시오.

네트워크 확장 모드에서 작동하도록 VPN 3002 구성

Cisco VPN 3002 하드웨어 클라이언트는 클라이언트 모드와 NEM(Network Extension Mode)의 두 가지 모드로 작동할 수 있습니다. 클라이언트 모드에서 Cisco VPN 3002 클라이언트 뒤에 있는 모든 호스트는 VPN 3002 클라이언트의 외부 IP 주소로 변환된 포트 주소입니다. H.323은 PAT(포트 주소 변환)와 함께 작동하지 않으며 IP 전화가 VPN 3002 클라이언트 뒤에 있는 경우 단방향 오디오가 발생합니다. VPN 3002가 NEM에서 작동하는 경우 원격 네트워크는 NAT 기반 또는 PAT 기반 IP 주소가 아닌 실제 IP 주소를 통해 서로를 볼 수 있습니다. VPN 3002가 NEM에서 작동하도록 구성된 경우 H.323이 작동할 수 있습니다. 즉, VPN 3002 클라이언트 뒤에 있는 IP 전화는 VPN 3002가 NEM에서 작동하는 경우에만 작동할 수 있습니다. 따라서 VPN 3002 클라이언트의 단방향 음성 문제를 방지하려면 NEM을 사용하도록 VPN 3002 클라이언트를 구성합니다.

NEM을 사용하도록 Cisco VPN 3002 Hardware Client를 구성하려면 Configuration(컨피그레이션) > Quick(빠른) > PAT(PAT)를 선택하고 PAT 창에서 No(아니요), use Network Extension mode(네트워크 확장 모드 사용)를 클릭합니다.

자세한 내용은 네트워크 확장 모드에서 EzVPN을 사용하여 Cisco VPN 3002 하드웨어 클라이언트를 Cisco IOS 라우터로 구성을 참조하십시오

추가 정보: 단방향 오디오 확인

패킷 흐름을 확인하기 위해 사용할 수 있는 두 가지 유용한 명령은 debug cch323 rtp 명령과 debug voip rtp 명령입니다. debug cch323 rtp 명령은 라우터가 전송하고(X) 수신한(R) 패킷을 표시합니다. 대문자 문자는 전송 또는 수신이 성공했음을 나타냅니다. 소문자는 삭제된 패킷을 나타냅니다.

voice-ios-gwy#debug cch323 rtp

RTP packet tracing is enabled
voice-ios-gwy#
voice-ios-gwy#
voice-ios-gwy#
voice-ios-gwy#
voice-ios-gwy#

!--- This is an unanswered outgoing call. !--- Notice that the voice path only cuts through in the forward direction and 
!--- that packets are dropped. Indeed, received packets are traffic from the !--- IP phone to the PSTN phone. These are dropped until the call is answered. 
Mar 3 23:46:23.690: ****** cut through in FORWARD direction *****
XXXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXr
XrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXr
XrXrXXrrrrrrrrrrrrrrrr
voice-ios-gwy#
voice-ios-gwy#

!--- This is an example of an answered call:

voice-ios-gwy#
voice-ios-gwy#
*Mar 3 23:53:26.570: ****** cut through in FORWARD direction *****
XXXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXr
XrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXr
XXrrrrrXrXrXrXrXrXrXrXrXrXrXrXrrXXrrXrXrXrXrXrXXXXXXXXXXXXXXXXrXXXXXXXXrXrXrXXrrXr
XrXrXrXrXrXrXrXrXXrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr

!--- At this point, the remote end picks up the phone.

*Mar 3 23:53:30.378: ****** cut through in BOTH direction *****
XRXRXRXRXRXRXRXRXXRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRXRXRXRXRXRXRXR
XRXRXRXRXRXRXRXRXRXRXRXRXRXRXXRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRXRXRXRXRXR
XXRRXRXRXXRRXRXRXRXRXXRXRXRXRXRXRRXRXXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXR
XRXRXRXRXRXRXRXRXRXRXRXRXRXRXRRRRRRRRRRRRRRRRRRRRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXR
XRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXXRRRRRRRRRRRRRRRRRRRRRRRRRRRRXRXRXRXRXRXRXRXRXRXR
XRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRRXXRXRXRXRXRXRRXRXRXRXRXRXRXRXR
XRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXXRRRRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXR
XXRRRRRRRRRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXR
XRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXR
XRXRXRXRXRXRXRXRXRXRXRXRXXRRRXR

!--- This is the end of the conversation.

voice-ios-gwy#debug voip rtp

--------cut through in BOTH direction-------------------

*Mar 27 19:52:08.259: RTP(32886): fs rx d=10.48.79.181(20002),
pt=0, ts=4FFBF0, ssrc=8E5FC294
*Mar 27 19:52:08.275: RTP(247): fs tx d=10.48.79.181(20002),
pt=0, ts=5D00C8D9, ssrc=1F1E5093
*Mar 27 19:52:08.279: RTP(32887): fs rx d=10.48.79.181(20002),
pt=0, ts=4FFC90, ssrc=8E5FC294
*Mar 27 19:52:08.295: RTP(248): fs tx d=10.48.79.181(20002),
pt=0, ts=5D00C979, ssrc=1F1E5093
*Mar 27 19:52:08.299: RTP(32888): fs rx d=10.48.79.181(20002),
pt=0, ts=4FFD30, ssrc=8E5FC294
*Mar 27 19:52:08.315: RTP(249): fs tx d=10.48.79.181(20002),
pt=0, ts=5D00CA19, ssrc=1F1E5093
*Mar 27 19:52:08.319: RTP(32889): fs rx d=10.48.79.181(20002),
pt=0, ts=4FFDD0, ssrc=8E5FC294
*Mar 27 19:52:08.335: RTP(250): fs tx d=10.48.79.181(20002),
pt=0, ts=5D00CAB9, ssrc=1F1E5093
*Mar 27 19:52:08.339: RTP(32890): fs rx d=10.48.79.181(20002),
pt=0, ts=4FFE70, ssrc=8E5FC294
*Mar 27 19:52:08.355: RTP(251): fs tx d=10.48.79.181(20002),
pt=0, ts=5D00CB59, ssrc=1F1E5093
*Mar 27 19:52:08.359: RTP(32891): fs rx d=10.48.79.181(20002),
pt=0, ts=4FFF10, ssrc=8E5FC294
*Mar 27 19:52:08.375: RTP(252): fs tx d=10.48.79.181(20002),
pt=0, ts=5D00CBF9, ssrc=1F1E5093
*Mar 27 19:52:08.379: RTP(32892): fs rx d=10.48.79.181(20002),
pt=0, ts=4FFFB0, ssrc=8E5FC294
*Mar 27 19:52:08.395: RTP(253): fs tx d=10.48.79.181(20002),
pt=0, ts=5D00CC99, ssrc=1F1E5093
*Mar 27 19:52:08.399: RTP(32893): fs rx d=10.48.79.181(20002),
pt=0, ts=500050, ssrc=8E5FC294
*Mar 27 19:52:08.976: RTP(282): fs tx d=10.48.79.181(20002),
pt=0, ts=5D00DEB9, ssrc=1F1E5093
*Mar 27 19:52:08.980: RTP(32922): fs rx d=10.48.79.181(20002),
pt=0, ts=501270, ssrc=8E5FC294
*Mar 27 19:52:08.996: RTP(283): fs tx d=10.48.79.181(20002),
pt=0, ts=5D00DF59, ssrc=1F1E5093
*Mar 27 19:52:09.000: RTP(32923): fs rx d=10.48.79.181(20002),
pt=0, ts=501310, ssrc=8E5FC294
*Mar 27 19:52:09.016: RTP(284): fs tx d=10.48.79.181(20002),
pt=0, ts=5D00DFF9, ssrc=1F1E5093

PIX 방화벽을 통해 통화 트래픽 정보 수집

PIX 방화벽을 통해 통화 트래픽 정보를 수집하여 단방향 통화 문제를 해결할 수 있습니다. PIX capture 명령을 사용하여 포트가 열려 있는지 확인하고 통화가 발생할 때 사용할 수 있습니다. PIX 방화벽을 지나는 VoIP 트래픽에 대한 자세한 내용은 PIX 방화벽으로 VoIP 트래픽 처리를 참조하십시오.

Cisco Unified Communications Manager 단방향 오디오 문제

이 문제는 MTP가 필요한 발신 초기 SIP 통화 설정에서만 발생할 수 있습니다. 이 경우 발신 SIP INVITE 메시지에 SDP 제안이 포함될 수 있습니다. 이 문제는 다음 시나리오에서 발생할 수 있습니다.

• SIP 트렁크에서 Media Termination Point Required가 선택된 발신 SIP 트렁크 통화

• IPv6 전용 엔드포인트와 IPv4 전용 엔드포인트 간의 통화

솔루션

MTP 리소스가 간헐적으로 유출될 수 있으므로 MTP 리소스가 필요한 SIP 호출이 실패합니다. RTMT에서 사용 가능한 MTP 리소스가 0에 도달하고 MTP가 필요한 각 통화에 대한 MTP 할당 실패 횟수가 증가합니다. 초기 INVITE의 SDP 부분에 a=inactive가 잘못 포함될 수 있습니다.

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

1. 가능한 경우 SIP 트렁크 컨피그레이션에 필요한 미디어 종료 지점의 선택을 취소합니다.

2. Early Offer가 필요한 경우 Early Offer를 구성하되 Media Termination Point Required는 선택하지 않습니다.

3. IPv6 구축의 경우 IPv6 전용 엔드포인트가 아닌 듀얼 스택을 사용합니다.

관련 정보

• CallManager H.323: 호전환 또는 보류 후 단방향 음성 문제
• Cisco CallManager에 대한 IP Phone NAT 지원
• 가상 인터페이스에 대한 H.323 지원
• 네트워크 확장 모드에서 EzVPN을 사용하여 Cisco IOS 라우터에 Cisco VPN 3002 하드웨어 클라이언트 구성
• Cisco Unity with Cisco CallManager: One Way Audio
• Cisco Unity를 위한 듀얼 NIC 구성 및 문제 해결
• 음성 기술 지원
• 음성 및 통합 커뮤니케이션 제품 지원
• Cisco IP 텔레포니 문제 해결
• Cisco 기술 지원 및 다운로드