이 문서에서는 Cisco 게이트웨이와 관련된 IP 텔레포니 단방향 오디오 대화에서 발생할 수 있는 몇 가지 일반적인 문제를 다룹니다. 이 문서에서 다루는 Cisco 게이트웨이는 Cisco IOS® 게이트웨이 및 라우터, Catalyst 스위치 및 DT-24+ 게이트웨이입니다.
이 문서는 IP 텔레포니 네트워크에 관여하고 음성 네트워크에 대한 기본적인 지식을 가진 직원을 대상으로 작성되었습니다.
이 문서는 특정 소프트웨어 또는 하드웨어 버전으로 제한되지 않습니다.
문서 규칙에 대한 자세한 내용은 Cisco 기술 팁 표기 규칙을 참고하십시오.
이 문서에서는 다음과 같은 문제에 대한 시나리오 및 솔루션을 제공합니다.
Cisco IOS 음성 게이트웨이 또는 라우터를 통해 IP 스테이션에서 전화 통화가 설정되면 당사자 중 한 명만 오디오(단방향 통신)를 수신합니다.
두 Cisco 게이트웨이 간에 통화 우회 통화가 설정되면 당사자 중 한 명만 오디오(단방향 통신)를 수신합니다.
VPN 3002 하드웨어 클라이언트 뒤에 있는 IP 스테이션에서 전화 통화가 설정되면 상대방 중 하나만 오디오(단방향 통신)를 수신합니다.
IP 텔레포니에서 단방향 오디오의 원인은 다양할 수 있지만 문제의 근본 원인은 일반적으로 IP 라우팅 문제입니다. 이 섹션에서는 현장에서 발견된 몇 가지 시나리오와 솔루션을 살펴봅니다.
VG200과 같은 일부 Cisco IOS 게이트웨이는 기본적으로 IP 라우팅을 비활성화합니다. 이 기본 설정은 단방향 음성 문제로 이어집니다.
참고: 더 진행하기 전에 라우터에서 IP 라우팅이 활성화되어 있는지 확인하십시오. 즉, 라우터에 no ip routing 전역 컨피그레이션 명령이 없는지 확인합니다.
IP 라우팅을 활성화하려면 Cisco IOS 게이트웨이에서 다음 전역 컨피그레이션 명령을 실행합니다.
voice-ios-gwy(config)#ip routing
항상 기본 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 전화에서 기본 라우터 또는 게이트웨이 구성을 확인하는 방법에 대해 설명합니다.
Cisco IP Phone 7910 - Settings(설정)를 누르고 옵션 6을 선택한 다음 Default Router(기본 라우터) 필드가 나타날 때까지 볼륨을 누릅니다.
Cisco IP Phone 7960/40 - Settings(설정)를 누르고 옵션 3을 선택한 다음 Default Router(기본 라우터) 필드가 나타날 때까지 아래로 스크롤합니다.
Cisco IP Phone 2sp+/30vip - **#을 누른 다음 gtwy=가 나타날 때까지 #을 누릅니다.
참고: Cisco IP SoftPhone 애플리케이션을 사용하고 상자에 둘 이상의 NIC(Network Interface Card)가 설치된 경우 해당 상자에 올바른 NIC가 있는지 확인합니다. 이 문제는 일반적으로 IP SoftPhone 소프트웨어 버전 1.1.x에서 발생합니다. 버전 1.2는 이 문제를 해결해야 합니다.
참고: Cisco DT-24+ 게이트웨이를 사용할 때 DHCP 범위를 확인하고 범위에 기본 게이트웨이(003 라우터) 옵션이 있는지 확인하십시오. 003 라우터 매개변수는 디바이스 및 PC의 Default Gateway 필드를 채웁니다. 범위 옵션 3에는 게이트웨이로 라우팅할 라우터 인터페이스의 IP 주소가 있어야 합니다.
트랜스코딩이 클러스터 간 트렁크(ICT)에 대해 구성된 경우 트렁크와 연결된 미디어 리소스 그룹 및 미디어 리소스 그룹 목록에 MTP(Media Termination Point)가 구성되어 있는지 확인합니다. 필요하지 않은 MTP를 지정하거나 필요한 경우 MTP를 구성하지 않으면 ICT 컨피그레이션에 단방향 음성 문제가 발생하는 것으로 알려져 있습니다.
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 Software Release 12.2(6)에 버그가 있으며, 이 솔루션에서 실제로 단방향 오디오 문제를 일으킬 수 있습니다. 자세한 내용은 Cisco 버그 ID CSCdw69681(등록된 고객만 해당)을 참조하십시오.
신호 및 미디어 패킷에 대한 소스 인터페이스가 지정되지 않은 경우 MGCP(Media Gateway Control Protocol) 게이트웨이에서 단방향 음성이 발생할 수 있습니다. mgcp bind media source-interface interface-id 명령을 실행한 다음 mgcp bind control source-interface interface-id 명령을 실행하면 MGCP 미디어를 소스 인터페이스에 바인딩할 수 있습니다. 명령을 실행한 후 Cisco CallManager에서 MGCP 게이트웨이를 재설정합니다.
mgcp bind 명령이 활성화되지 않은 경우 IP 레이어는 여전히 최상의 로컬 주소를 제공합니다.
mgcp bind 명령에 대한 지침은 다음과 같습니다.
게이트웨이에 활성 MGCP 호출이 있는 경우 제어 및 미디어 모두에 대해 mgcp bind 명령이 거부됩니다.
바인딩 인터페이스가 작동되지 않으면 명령이 수락되지만 인터페이스가 작동될 때까지 적용되지 않습니다.
IP 주소가 바인드 인터페이스에 할당되지 않은 경우 mgcp bind 명령은 허용되지만 유효한 IP 주소가 할당된 후에만 적용됩니다. 이 시간 동안 MGCP 호출이 작동하면 mgcp bind 명령이 거부됩니다.
바인딩된 인터페이스가 다운되면 인터페이스에서 수동으로 종료되거나 운영 실패로 인해 바인딩 활동이 해당 인터페이스에서 비활성화됩니다.
MGC(Media Gateway Controller)에 바인딩이 구성되지 않은 경우 소스 MGCP 제어 및 미디어에 사용되는 IP 주소가 가장 사용 가능한 IP 주소입니다.
Telco 또는 스위치에 연결되는 Cisco IOS 게이트웨이가 있는 경우 Telco 뒤에 있는 호출된 디바이스가 통화에 응답할 때 응답 감리가 올바르게 전송되는지 확인합니다. 응답 감리를 수신하지 못하면 Cisco IOS 게이트웨이가 오디오 경로를 정방향(앞으로)으로 잘라내지(열기)못합니다. 이 실패는 단방향 음성을 발생시킵니다. 해결 방법은 voice rtp send-recv on 명령을 실행합니다.
자세한 내용은 Cisco IOS Gateway and Routers에서 음성 rtp send-recv 명령을 사용하여 Cut Through Two-Way Audio Early를 참조하십시오.
음성 경로는 RTP 스트림의 시작 시 이전 방향으로 설정됩니다. Cisco IOS 게이트웨이가 원격 엔드로부터 연결 메시지를 수신할 때까지 전달 오디오 경로가 차단되지 않습니다.
경우에 따라 RTP 채널을 열자마자 연결 메시지를 수신하기 전에 양방향 오디오 경로를 설정해야 합니다. 이를 위해 voice rtp send-recv 전역 컨피그레이션 명령을 실행합니다.
이 문제는 음성 경로에 둘 이상의 Cisco IOS 라우터 또는 게이트웨이가 관련되어 있고 압축된 RTP(cRTP)가 사용되는 유료 우회 등의 시나리오에 적용됩니다. cRTP(RTP Header Compression)는 대역폭을 다시 얻기 위해 VoIP 패킷 헤더를 더 작게 만드는 방법입니다. cRTP는 VoIP 패킷에서 40바이트 IP, UDP(User Datagram Protocol) 또는 RTP 헤더를 가져와 패킷당 2~4바이트로 압축합니다. 이 압축은 cRTP를 사용하는 G.729 인코딩 통화에 대해 약 12kbps의 대역폭을 산출합니다. cRTP에 대한 자세한 내용은 Voice Over IP - Per Call Bandwidth Consumption을 참조하십시오.
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 Release 12.1)에서 cRTP를 실행하는 경우 Cisco 버그 ID CSCds08210(등록된 고객만 해당)이 Cisco IOS Software 릴리스에 영향을 주지 않는지 확인합니다. 이 버그의 증상은 VoIP 및 Fax over IP가 RTP 헤더 압축을 사용하는 데 실패했다는 것입니다.
show controller {e1에서 E1 또는 T1 인터페이스에 클럭 전이가 있는 경우 | t1} 명령이 음성 게이트웨이의 clocking 컨피그레이션이 일치하지 않을 수 있습니다. 음성 지원 IOS 기반 플랫폼의 잠금 구성을 참조하고 음성 게이트웨이의 잠금 구성이 올바른지 확인합니다.
NAT(Network Address Translation)를 사용하는 경우 최소 소프트웨어 수준 요구 사항을 충족해야 합니다. 이전 버전의 NAT는 Skinny 프로토콜 변환을 지원하지 않습니다. 이러한 이전 버전에서는 단방향 음성 문제가 발생합니다.
Cisco IOS 게이트웨이를 지원하려면 Cisco IOS Software Release 12.1(5)T 이상을 실행하고 NAT를 사용하는 H.323 버전 2를 동시에 지원해야 합니다. 자세한 내용은 Cisco CallManager에 IP Phone의 NAT-지원을 참조하십시오.
참고: Cisco CallManager가 기본 포트(2000)와 다른 skinny 시그널링에 TCP 포트를 사용하는 경우 NAT 라우터를 조정해야 합니다. ip nat service skinny tcp 포트 번호 전역 컨피그레이션 명령을 실행합니다.
PIX 방화벽에서 NAT를 동시에 사용하고 skinny를 사용하기 위해 필요한 최소 소프트웨어 레벨은 6.0입니다. 자세한 내용은 Cisco PIX Firewall Version 6.0을 참조하십시오.
참고: 이러한 소프트웨어 레벨은 전체 게이트키퍼 지원에 필요한 모든 RAS(Registration, Admission, and Status) 메시지를 지원하지 않습니다. 게이트키퍼 지원은 이 문서의 범위를 벗어납니다.
Cisco IOS Software 명령 voice-fastpath enable은 AS5350 및 AS5400에 대한 숨겨진 전역 구성 명령입니다. 이 명령은 기본적으로 활성화되어 있습니다. 비활성화하려면 no voice-fastpath enable 전역 컨피그레이션 명령을 실행합니다.
명령이 활성화되면 특정 통화에 대해 열린 논리적 채널에 대한 IP 주소 및 UDP 포트 번호 정보를 캐시합니다. 이 명령은 RTP 스트림이 애플리케이션 레이어에 도달하는 것을 방지합니다. 대신 패킷은 하위 레이어에서 전달됩니다. 이렇게 하면 통화량이 많은 시나리오에서 CPU 사용률을 줄일 수 있습니다.
보류 또는 전송과 같은 보조 서비스를 사용하는 경우 voice-fastpath 명령을 사용하면 라우터가 오디오를 캐시된 IP 주소 및 UDP 포트로 스트리밍합니다. 보류 통화가 재개되거나 전송이 완료된 후 생성된 새 논리적 채널 정보는 무시됩니다. 이 문제를 해결하려면 트래픽이 애플리케이션 레이어로 지속적으로 이동해야 논리적 채널의 재정의가 고려되고 오디오가 새 IP 주소 및 UDP 포트 쌍으로 스트리밍됩니다. 따라서 보조 서비스를 지원하려면 음성 빠른 경로를 비활성화해야 합니다.
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을 통한 Cisco IP SoftPhone 사용 방법)을 참조하십시오.
Cisco VPN 3002 Hardware Client는 다음 두 가지 모드에서 작동할 수 있습니다. 클라이언트 모드 및 네트워크 확장 모드(NEM). 클라이언트 모드에서 Cisco VPN 3002 클라이언트 뒤의 모든 호스트는 VPN 3002 클라이언트의 외부 IP 주소로 변환된 포트 주소입니다. H.323은 PAT(Port Address Translation)에서 작동하지 않으며 IP 전화기가 VPN 3002 클라이언트 뒤에 있을 때 단방향 오디오를 생성합니다. VPN 3002가 NEM에서 작동하는 경우 원격 네트워크는 NAT 기반 또는 PAT 기반 IP 주소가 아니라 실제 IP 주소를 통해 서로를 볼 수 있습니다. VPN 3002가 NEM에서 작동하도록 구성된 경우 H.323이 작동할 수 있습니다. 즉, VPN 3002 클라이언트 뒤에 있는 IP 전화는 NEM에서 VPN 3002가 작동하는 경우에만 작동할 수 있습니다. 따라서 VPN 3002 클라이언트에서 단방향 음성 문제를 방지하려면 NEM을 사용하도록 VPN 3002 클라이언트를 구성합니다.
NEM을 사용하도록 Cisco VPN 3002 하드웨어 클라이언트를 구성하려면 Configuration(컨피그레이션) > Quick(빠른) > PAT(PAT)를 선택하고 No(아니요)를 클릭하고 PAT 창에서 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.
참고: Cisco IOS Software 릴리스 12.2(11)T 이상에서는 debug cch323 rtp CLI(command-line interface) 명령이 debug voip rtp 명령으로 대체되었습니다.
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 capture 명령을 사용하여 통화가 발생할 때 포트가 열려 있고 사용되는지 확인할 수 있습니다. PIX 방화벽 전반의 VoIP 트래픽에 대한 자세한 내용은 PIX 방화벽을 사용하여 VoIP 트래픽 처리를 참조하십시오.
참고: 트러블슈팅에 필요한 캡처 파일을 생성한 후 capture 명령을 비활성화해야 합니다.
이 문제는 MTP가 필요한 발신 초기 SIP 통화 설정에서만 발생할 수 있습니다. 이 경우 발신 SIP INVITE 메시지에 SDP 제안이 포함됩니다. 이 문제는 다음 시나리오에서 발생할 수 있습니다.
SIP 트렁크에서 미디어 종료 지점이 필요한 발신 SIP 트렁크 통화 선택
IPv6 전용 엔드포인트와 IPv4 전용 엔드포인트 간 통화
MTP 리소스가 간헐적으로 유출될 수 있으며, 이로 인해 MTP 리소스가 필요한 SIP 호출이 실패할 수 있습니다. RTMT에서 사용 가능한 MTP 리소스가 0에 도달하고 MTP가 필요한 각 통화에 대해 MTP 할당 실패 카운트가 증가합니다. 초기 INVITE의 SDP 부분에 a=inactive가 잘못 포함됩니다.
문제를 해결하려면 다음 단계를 완료하십시오.
가능한 경우 SIP 트렁크 컨피그레이션에서 Media Termination Point Required(미디어 종료 지점 필요)를 선택 취소합니다.
Early Offer(조기 제안)가 필요한 경우 Early Offer(조기 제안)를 구성하지만 Media Termination Point Required(미디어 종료 지점 필요)를 선택하지 않은 상태로 둡니다.
IPv6 구축의 경우 IPv6 전용 엔드포인트 대신 듀얼 스택을 사용합니다.
참고: 이 내용은 Bug ID CSCtk77040(등록된 고객만 해당)에 설명되어 있습니다.
개정 | 게시 날짜 | 의견 |
---|---|---|
1.0 |
13-Oct-2008 |
최초 릴리스 |