Wireshark에서 음성 및 비디오 통화를 위한 패킷 손실 분석을 위한 RTP 스트림 분석

다운로드 옵션

PDF (1.2 MB)
다양한 디바이스에서 Adobe Reader로 보기
ePub (828.1 KB)
iPhone, iPad, Android, Sony Reader 또는 Windows Phone의 다양한 앱에서 보기
Mobi (Kindle) (936.4 KB)
Kindle 디바이스에서 보기 또는 다양한 디바이스의 Kindle 앱에서 보기

업데이트:2014년 7월 28일 (월)

문서 ID:117881

편견 없는 언어

본 제품에 대한 문서 세트는 편견 없는 언어를 사용하기 위해 노력합니다. 본 설명서 세트의 목적상, 편견 없는 언어는 나이, 장애, 성별, 인종 정체성, 민족 정체성, 성적 지향성, 사회 경제적 지위 및 교차성에 기초한 차별을 의미하지 않는 언어로 정의됩니다. 제품 소프트웨어의 사용자 인터페이스에서 하드코딩된 언어, RFP 설명서에 기초한 언어 또는 참조된 서드파티 제품에서 사용하는 언어로 인해 설명서에 예외가 있을 수 있습니다. 시스코에서 어떤 방식으로 포용적인 언어를 사용하고 있는지 자세히 알아보세요.

이 번역에 관하여

Cisco는 전 세계 사용자에게 다양한 언어로 지원 콘텐츠를 제공하기 위해 기계 번역 기술과 수작업 번역을 병행하여 이 문서를 번역했습니다. 아무리 품질이 높은 기계 번역이라도 전문 번역가의 번역 결과물만큼 정확하지는 않습니다. Cisco Systems, Inc.는 이 같은 번역에 대해 어떠한 책임도 지지 않으며 항상 원본 영문 문서(링크 제공됨)를 참조할 것을 권장합니다.

소개

이 문서에서는 Wireshark에서 음성 및 화상 통화를 위해 패킷 손실 분석을 위해 RTP(Real-Time Streaming) 스트림을 해독하는 방법에 대해 설명합니다.Wireshark 필터를 사용하여 통화의 소스 및 목적지에서 또는 근접한 동시 패킷 캡처를 분석할 수 있습니다.이는 네트워크 손실이 의심되는 경우 오디오 및 비디오 품질 문제를 해결해야 할 때 유용합니다.

문제

이 예에서는 다음 통화 흐름을 사용합니다.

IP phone A(중앙 사이트 A) > 2960 스위치 > 라우터 > WAN 라우터(중앙 사이트) > IPWAN > WAN 라우터(사이트 B) > 라우터 > 2960 > IP 전화 B

이 시나리오에서 발생하는 문제는 IP 전화 A에서 IP 전화 B로의 비디오 통화가 중앙 사이트 A에서 지사 사이트 B로 비디오 품질이 좋지 않아 중앙 사이트의 품질이 우수하지만 브랜치의 문제가 있다는 것입니다.

브랜치 IP 전화의 스트리밍 통계에서 수신자가 손실된 패킷을 확인합니다.

솔루션

나쁜 품질은 브랜치에서만 확인되며 중앙 사이트에서 좋은 이미지를 볼 수 있기 때문에 중앙 사이트에서 브랜치 사이트로 스트림이 네트워크를 통해 패킷을 손실하는 것처럼 보입니다.

IP addressing scheme
Central IP phone: 192.168.10.146
Central Gateway: 192.168.10.253
Central WAN router: 192.168.10.254
Branch WAN router: 192.168.206.210
Branch Gateway: 192.168.206.253
Branch IP phone: 192.168.207.231

패킷 캡처는 중앙 및 브랜치 WAN 라우터에서 수행되며 WAN은 이러한 패킷을 삭제합니다.중앙 IP 전화(192.168.10.146)에서 지사 IP 전화(192.168.207.231)으로 RTP 스트림에 초점을 맞춥니다. 이 스트림은 WAN이 스트림의 패킷을 중앙 WAN 라우터에서 브랜치 WAN 라우터로 삭제하는 경우 브랜치 WAN 라우터에서 패킷을 누락합니다. wireshark의 필터 옵션을 사용하여 문제를 격리합니다.

Wireshark에서 캡처를 엽니다.
ip.src==192.168.10.146 && ip.dst==192.168.207.231 필터를 사용합니다. 중앙 IP 전화에서 지사 IP 전화로의 모든 UDP 스트림을 필터링합니다.
브랜치 측 캡처에서만 분석을 수행하지만 중앙 캡처를 위해 이러한 단계를 수행해야 합니다.
이 스크린샷에서 UDP 스트림은 소스와 대상 IP 주소 간에 필터링되며 두 개의 UDP 스트림(UDP 포트 번호로 구별됨)을 포함합니다. 비디오 통화이므로 두 개의 스트림이 있습니다.오디오 및 비디오.이 예에서 두 스트림은 다음과 같습니다.
- 스트림 1:UDP 소스 포트:20560, 대상 포트:20800
- 스트림 2:UDP 소스 포트:20561, 대상 포트:20801
스트림 중 하나에서 패킷을 선택하고 패킷을 마우스 오른쪽 버튼으로 클릭합니다.
Decode As...를 선택하고 RTP를 입력합니다.
스트림을 RTP로 디코딩하려면 Accept 및 Ok를 클릭합니다.

하나의 스트림이 RTP로 디코딩되고 다른 스트림은 ecoded UDP로 디코딩됩니다.
인코딩되지 않은 스트림에서 패킷을 선택하고 이를 RTP로 디코딩합니다.이렇게 하면 오디오 및 비디오 스트림이 모두 RTP로 디코딩됩니다.

참고: 오디오 스트림은 G.722 코덱의 형식이며 Dynamic-RTP-97 페이로드 유형은 비디오 RTP 스트림을 나타냅니다.

문제는 이제 비디오 품질에만 있습니다.비디오 RTP 스트림에 집중하고 이 스트림에 대한 UDP 포트 번호를 사용하여 다른 스트림을 필터링합니다.
Wireshark 유틸리티의 아래쪽 창에 UDP 포트 정보를 표시하는 패킷 중 하나를 선택하여 포트 번호를 확인합니다.이전 스크린샷에서 비디오 스트림의 패킷 중 하나가 선택되고 아래쪽 창에 Src Port(20568) 및 Dst port(20808) 정보가 표시됩니다.

팁:이 필터를 사용합니다. (ip.src==192.168.10.146 && ip.dst==192.168.207.231) && (udp.port eq 20568 및 udp.port eq 20808) 이 스크린샷에는 비디오 RTP 스트림만 표시됩니다.

참고:이 스트림의 첫 번째 및 마지막 RTP 시퀀스 번호를 기록합니다.

첫 번째 RTP 시퀀스 번호는 45514이고, 마지막은 필터링된 출력 비디오 RTP 스트림에 대한 50449입니다.
첫 번째 및 마지막 RTP 시퀀스 번호 패킷이 두 캡처 모두에 있는지 확인합니다(예: 중앙 및 분기 캡처). 스트림의 SSRC는 두 캡처 모두에서 동일해야 합니다.
첫 번째와 마지막 RTP 스트림 사이의 패킷만 매칭하도록 필터를 구체화합니다.

시퀀스 번호는 캡처가 동시에 수행되지 않고 두 캡처가 약간 지연되는 경우 스트림을 구체화하는 데 사용됩니다.

참고:브랜치 사이트에서 45514 이후 일부 시퀀스 번호를 시작할 수 있습니다.
시작 및 종료 시퀀스 번호를 선택합니다.이러한 패킷은 시작 및 종료 RTP 시퀀스 번호 사이에 있는 패킷만 표시하도록 필터를 캡처 및 구체화하는 데 모두 존재합니다.이에 대한 필터는 다음과 같습니다.
```
(ip.src==192.168.10.146 && ip.dst==192.168.207.231) && (udp.port eq 20568 
 and udp.port eq 20808) && ( rtp.seq>=44514 && rtp.seq<=50449 )
```
캡처를 동시에 수행하면 두 캡처의 시작 또는 끝에서 누락된 패킷이 없습니다.캡처 중 하나에 시작/끝에 몇 개의 패킷이 포함되지 않은 경우 두 패킷에서 누락되는 캡처의 첫 번째 시퀀스 번호 또는 마지막 시퀀스 번호를 사용하여 두 캡처 모두에 대한 필터를 세분화합니다.동일한 시퀀스 번호(RTP 시퀀스 번호 범위) 사이의 두 지점에서 캡처된 패킷을 확인합니다.

필터를 적용하면 중앙 사이트 및 브랜치 사이트에 다음 항목이 표시됩니다.

중앙 사이트:

브랜치 사이트:

두 캡처 모두에서 Wireshark 유틸리티의 아래쪽 창에서 필터링된 패킷 수를 확인합니다.Displayed count는 원하는 필터 기준과 일치하는 패킷 수를 나타냅니다.

중앙 사이트에는 시작(45514)과 끝(50449) RTP 시퀀스 번호 사이에 원하는 필터 기준과 일치하는 4,936개의 패킷이 있지만 브랜치 사이트에는 4,737개의 패킷만 있습니다.이것은 199개의 패킷이 손실되었음을 나타냅니다. 이 199개의 패킷은 이 문서의 시작 부분에 표시된 브랜치 측 IP 전화의 스트리밍 통계에서 본 199의 "Rcvr Lost Pkts" 수와 일치합니다.

이렇게 하면 모든 Rcvr Lost Packets가 실제로 WAN에서 손실된 네트워크 손실임을 확인할 수 있습니다.이는 네트워크에서 패킷 손실 지점이 격리되는 반면 오디오/비디오 품질 문제는 의심되는 네트워크 삭제와 관련된 것입니다.