QoS 음성 문제 해결

다운로드 옵션

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

업데이트:2006년 2월 2일

문서 ID:20371

편견 없는 언어

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

이 번역에 관하여

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

소개

패킷 음성이 표준 PSTN(Public Switched Telephone Network) 텔레포니 서비스를 실질적으로 대체하려면 수신된 패킷 음성의 품질이 기본 전화 서비스의 품질과 비슷해야 합니다. 즉, 지속적으로 고품질의 음성 전송이 이루어집니다. 다른 실시간 애플리케이션과 마찬가지로 Packet Voice는 대역폭이 넓고 지연에 민감합니다. 음성 전송이 수신기에 대해 명료하게(고르지 않게) 제공되려면 음성 패킷을 삭제하거나 과도하게 지연하거나 다양한 지연(지터라고 함)을 겪을 수 없습니다. 이 문서에서는 끊어진 음성 문제를 해결하는 데 도움이 되는 다양한 QoS(Quality of Service) 고려 사항에 대해 설명합니다. 끊어진 음성 문제의 주요 원인은 손실되고 지연된 음성 패킷입니다.

사전 요구 사항

요구 사항

이 문서의 독자는 다음 사항에 대해 잘 알고 있어야 합니다.

필요에 따라 VoIP, VoFR(Voice over Frame Relay) 또는 VoATM(Voice over ATM)의 기본 컨피그레이션
음성 우선 순위, 단편화, 여러 코덱 및 해당 대역폭 요구 사항에 대한 기본적인 이해.

사용되는 구성 요소

이 문서의 정보는 모든 Cisco 음성 게이트웨이 소프트웨어 및 하드웨어 버전에 적용됩니다.

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

표기 규칙

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

목소리가 울리는 원인

음성 품질이 저하되는 것은 음성 패킷이 네트워크에서 가변적으로 지연되거나 손실되기 때문입니다. 음성 패킷이 목적지에 도달하는 것이 지연되면 목적지 게이트웨이는 실시간 정보의 손실을 겪게 됩니다. 이 경우 대상 게이트웨이는 누락된 패킷의 내용이 무엇일 수 있는지 예측해야 합니다. 예측은 수신된 음성이 전송된 음성과 동일한 특성을 갖지 않도록 유도한다. 이것은 로봇처럼 들리는 수신된 목소리로 이어집니다. 음성 패킷이 수신 게이트웨이의 예측 능력 이상으로 지연되면 게이트웨이는 실시간 간격을 비워둡니다. 수신단에서 그 공백을 채울 것이 없으므로, 전송된 음성의 일부가 손실된다. 그 결과 목소리가 거칠어집니다. 불안정한 음성 문제의 대부분은 음성 패킷이 매우 지연되지 않는지(그리고 그 이상, 가변적으로 지연되지 않는지)를 확인함으로써 해결됩니다. VAD(Voice Activity Detection)는 음성 대화에 프런트엔드 클리핑을 추가하는 경우도 있습니다. 이는 목소리가 거칠거나 잘리는 또 다른 원인입니다.

이 문서의 다양한 섹션에서는 끊어진 음성의 인스턴스를 최소화하는 방법을 보여줍니다. 이러한 측정 방법의 대부분은 음성 네트워크에 최소 지터의 도입을 보장해야 합니다.

대역폭 요구 사항

지터를 최소화하기 위한 조치를 적용하기 전에 실시간 음성 트래픽을 지원할 수 있도록 충분한 네트워크 대역폭을 프로비저닝합니다. 예를 들어, 80kbps G.711 VoIP 통화(64kbps 페이로드 + 16kbps 헤더)는 패킷 중 최소 16kbps(20%)가 삭제되기 때문에 64kbps 링크에서는 불량하게 들립니다. 대역폭 요건은 압축에 사용되는 코덱에 따라 달라집니다. 코덱마다 다른 페이로드 및 헤더 요구 사항이 있습니다. VAD의 사용은 대역폭 요구 사항에도 영향을 줍니다. RTP(Real Time Protocol) 헤더 압축(cRTP)을 사용하는 경우 대역폭 요건을 더 낮출 수 있습니다.

예를 들어, G.729 코덱(기본 20바이트 페이로드)과 cRTP를 사용하는 음성 통화에 필요한 대역폭은 다음과 같습니다.

음성 페이로드 + 압축(RTP 헤더 + UDP(User Datagram Protocol) 헤더 + IP 헤더) + 레이어 2 헤더

이 값은 다음과 같습니다.

20바이트 + 압축(12바이트 + 8바이트 + 20바이트) + 4바이트

다음과 같습니다.

28바이트. 헤더 압축이 IP RTP 헤더를 최대 4바이트로 줄이기 때문입니다. 이는 8kbps 코덱 속도로 11.2kbps를 산출합니다(초당 50패킷).

자세한 내용은 VoIP(Voice over IP) - 통화별 대역폭 소비를 참조하십시오.

음성 트래픽 우선 순위

목소리의 우선순위를 정하는 데에는 두 가지 중요한 요소가 있습니다. 첫 번째는 흥미로운 음성 트래픽을 분류하고 표시하는 것입니다. 두 번째는 눈에 띄는 흥미로운 음성 트래픽의 우선순위를 정하는 것입니다. 여기의 두 하위 섹션에서는 음성을 분류하고, 표시하고, 우선 순위를 지정하는 다양한 접근 방식에 대해 설명합니다.

분류 및 마킹

VoIP 패킷의 대역폭을 보장하려면 네트워크 디바이스가 해당 디바이스를 통과하는 모든 IP 트래픽에서 패킷을 식별할 수 있어야 합니다. 네트워크 디바이스는 IP 헤더의 소스 및 목적지 IP 주소 또는 UDP 헤더의 소스 및 목적지 UDP 포트 번호를 사용하여 VoIP 패킷을 식별합니다. 이러한 식별 및 그룹화 프로세스를 분류라고 합니다. 모든 QoS를 제공하기 위한 기반입니다.

패킷 분류는 프로세서 집약적일 수 있습니다. 따라서 네트워크 엣지를 향해 가능한 한 멀리 떨어진 곳까지 분류가 이루어져야 합니다. 모든 홉은 여전히 패킷이 받아야 하는 처리 방법을 결정해야 하므로 네트워크 코어에서 더 간단하고 효율적인 분류 방법을 사용해야 합니다. 이와 같이 더 간단한 분류는 IP 헤더에서 ToS(Type of Service) 바이트를 표시하거나 설정하는 방법을 통해 이루어집니다. ToS 바이트의 가장 중요한 세 비트를 IP Precedence 비트라고 합니다. 현재 대부분의 애플리케이션 및 공급업체는 이 3비트를 설정하고 인식하는 기능을 지원합니다. DSCP(Differentiated Services Code Point)라고 하는 ToS 바이트의 최상위 6개 비트를 사용할 수 있도록 마킹이 진화하고 있습니다. RFC(Request for Comments)를 참조하십시오.

Differentiated Services(DiffServ)는 ToS 필드를 기반으로 하는 상대적 우선순위가 있는 중간 시스템에서 트래픽을 처리하는 새로운 모델입니다. RFC 2474 및 RFC 2475에 정의된 DiffServ 표준은 RFC 791에서 설명하는 패킷 우선순위를 정의하기 위한 원래 사양을 대체합니다. DiffServ는 우선순위 표시를 위해 IP 패킷의 비트를 재할당하여 정의 가능한 우선순위 레벨의 수를 늘립니다. DiffServ 아키텍처는 DiffServ 필드를 정의합니다. IP V4의 ToS 바이트를 대체하여 패킷 분류 및 측정, 마킹, 셰이핑, 폴리싱 등의 트래픽 조절 기능에 대한 PHB(Per-Hop Behavior) 결정을 내립니다. 앞서 언급한 RFC 외에도 RFC 2597은 AF(Assured Forwarding) 클래스를 정의합니다. DSCP 필드의 분석입니다. DSCP에 대한 자세한 내용은 DSCP를 사용하여 서비스 품질 정책 구현을 참조하십시오.

ToS 바이트 - P2 P1 P0 T3 T2 T1 T0 CU

IP 우선 순위: 3비트(P2-P0), ToS: 4비트(T3-T0), CU: 1비트

DiffServ 필드 - DS5 DS4 DS3 DS2 DS1 DS0 ECN ECN

DSCP: 6비트(DS5-DS0), ECN: 2비트

XXX00000 Bits 0, 1, 2(DS5, DS4, DS3)는 우선 순위 비트입니다.

111 = 네트워크 제어 = 우선순위 7
110 = 인터네트워크 제어 = 우선순위 6
101 = 비평가/ECP = 우선 순위 5
100 = 플래시 재정의 = 우선순위 4
011 = 플래시 = 우선 순위 3
010 = 우선순위 2
001 = 우선순위 = 우선순위 1
000 = 루틴 = 우선순위 0

000XXX00 비트 3, 4, 5(DS2, DS1, DS0)는 지연, 처리량 및 신뢰성 비트입니다.

비트 3 = 지연 [D] (0 = 보통; 1 = 낮음)
비트 4 = 처리량 [T] (0 = 일반; 1 = 높음)
비트 5 = 안정성 [R] (0 = 일반; 1 = 높음)

000000XX비트 6, 7: ECN

이 두 섹션에서는 분류와 마킹이 수행되는 두 가지 방법에 대해 설명합니다.

음성 다이얼 피어를 사용하여 패킷 분류 및 표시

Cisco VoIP 게이트웨이에서는 일반적으로 음성 다이얼 피어를 사용하여 VoIP 패킷을 분류하고 IP 우선순위 비트를 표시합니다. 이 컨피그레이션에서는 IP 우선 순위 비트를 표시하는 방법을 보여줍니다.

dial-peer voice 100 voip
destination-pattern 100
session target ipv4:10.10.10.2
ip precedence 5

위의 예에서 dial-peer voice 100 voip 명령과 일치하는 모든 VoIP 통화의 모든 음성 페이로드 패킷은 IP Precedence 5로 설정됩니다. 즉, IP ToS 바이트의 최상위 비트 3개가 101로 설정됩니다.

dial-peer voice 100 voip
destination-pattern 100
session target ipv4:10.10.10.2
ip qos dscp ef media
ip qos dscp af31 signaling

위의 예에서 dial-peer voice 100 voip 명령과 일치하는 모든 VoIP 통화에는 모든 미디어 페이로드 패킷(음성 패킷)이 EF(Expedited Forwarding) 비트 패턴 101110으로 설정되어 있습니다. 모든 신호 패킷은 AF 비트 패턴 011010으로 설정됩니다.

참고: ip qos dscp 명령은 Cisco IOS® 소프트웨어 릴리스 12.2(2)T부터 지원됩니다. IP 우선 순위는 Cisco IOS Software 릴리스 12.2T에서 더 이상 사용할 수 없습니다. 그러나 ip qos dscp 명령도 마찬가지입니다. IP 우선 순위 5(101)는 IP DSCP 101000에 매핑됩니다. 자세한 내용은 QoS를 위해 VoIP 신호 및 DSCP를 사용하는 미디어 분류를 참조하십시오.

패킷 분류 및 표시를 위한 모듈형 QoS CLI

권장하는 분류 및 마킹 방법은 모듈형 QoS CLI입니다. 이는 분류와 정책을 분리하는 템플릿 기반 컨피그레이션 방법입니다. 이렇게 하면 여러 클래스에 대해 여러 QoS 기능을 함께 구성할 수 있습니다. 다양한 일치 기준에 따라 트래픽을 분류하려면 class-map 명령을 사용하고 각 클래스에 어떤 작업이 필요한지 결정하려면 policy-map 명령을 사용합니다. service-policy 명령을 실행하여 인터페이스의 수신 또는 발신 트래픽에 정책을 적용합니다. 이 컨피그레이션 예에서는 모듈형 QoS CLI를 사용하여 패킷을 분류하고 표시하는 방법을 보여 줍니다.

access-list 100 permit udp any any range 16384 32767
access-list 101 permit tcp any any eq 1720
!
class-map match-all voip
match access-group 100
class-map match-all control
match access-group 101
!
policy-map mqc
class voip
set ip precedence 5
class control
set ip precedence 5
class class-default
set ip precedence 0
!
interface Ethernet0/0
service-policy input mqc

이 컨피그레이션 예에서는 ACL(Access Control List) 100과 일치하는 모든 트래픽이 "class voip"로 분류되고 IP Precedence 5로 설정됩니다. 즉, IP ToS 바이트의 최상위 비트 3개가 101로 설정됩니다. ACL 100은 VoIP에서 사용되는 일반 UDP 포트와 일치합니다. 마찬가지로 ACL 101은 H.323 시그널링 트래픽(TCP(Transmission Control Protocol) 포트 1720)과 일치합니다. 다른 모든 트래픽은 IP Precedence 0으로 설정됩니다. 정책을 "mqc"라고 합니다. 이더넷 0/0의 수신 트래픽에 적용됩니다.

우선 순위 지정

네트워크의 모든 홉에서 포트/주소 정보 또는 ToS 바이트를 통해 VoIP 패킷을 분류하고 식별할 수 있게 되면 이러한 홉은 각 VoIP 패킷에 필요한 QoS를 제공합니다. 이 시점에서 특별 기술을 구성하여 우선 순위 큐잉을 제공하여 대용량 데이터 패킷이 음성 데이터 전송을 방해하지 않도록 합니다. 이는 일반적으로 혼잡 가능성이 높은 느린 WAN 링크에서 필요합니다. 모든 관심 트래픽이 QoS 요건에 따라 QoS 클래스에 배치되면 지능형 출력 대기 메커니즘을 통해 대역폭 보장 및 우선순위 서비스를 제공합니다. VoIP에 우선 순위 큐가 필요합니다.

참고: 효과적으로 VoIP에 높은 우선순위를 부여하는 모든 대기 메커니즘을 사용합니다. 그러나 LLQ(Low Latency Queuing)는 유연하고 구성하기 쉬우므로 사용하는 것이 좋습니다.

LLQ는 모듈형 QoS CLI 컨피그레이션 방법을 사용하여 특정 클래스에 우선 순위를 부여하고 다른 클래스에 보장된 최소 대역폭을 제공합니다. 혼잡 기간 중에는 우선순위 트래픽이 사용 가능한 대역폭을 모두 사용하지 않도록 구성된 속도로 우선순위 큐가 폴리싱됩니다. 우선순위 트래픽이 대역폭을 독점하면 다른 클래스에 대한 대역폭 보장이 충족되지 않습니다. LLQ를 올바르게 프로비저닝하는 경우 우선순위 큐로 이동하는 트래픽은 구성된 속도를 초과하지 않아야 합니다.

또한 LLQ를 사용하면 특정 클래스 대기열에 대기 중인 패킷이 너무 많은 경우 라우터에서 패킷을 삭제해야 하는 시점을 확인하기 위해 대기열 깊이를 지정할 수 있습니다. 구성된 클래스에 의해 분류되지 않은 모든 트래픽의 처리를 결정하는 데 사용되는 class-default 명령도 있습니다. class-default는 fair-queue 명령으로 구성됩니다. 이는 분류되지 않은 각 플로우에 나머지 대역폭의 대략 동일한 점유율이 제공됨을 의미한다.

이 예에서는 LLQ를 구성하는 방법을 보여 줍니다. 자세한 내용은 Low Latency Queuing을 참조하십시오.

access-list 100 permit udp any any range 16384 32000
access-list 101 permit tcp any any eq 1720
access-list 102 permit tcp any any eq 80
access-list 103 permit tcp any any eq 23
!
class-map match-all voip
match access-group 100
class-map match-all voip-control
natch access-group 101
class-map match-all data1
match access-group 102
class-map match-all data2
match access-group 103
!
policy-map llq
class voip
priority 32
class voip-control
bandwidth 8
class data1
bandwidth 64
class data2
bandwidth 32
class class-default
fair-queue
!
interface Serial1/0
bandwidth 256
service-policy output llq

이 예에서 ACL 100과 일치하는 모든 트래픽은 "class voip"(음성 트래픽을 의미)로 분류됩니다. 최대 32kbps까지 높은 우선 순위가 부여됩니다. ACL 100은 VoIP에서 사용하는 공통 UDP 포트와 일치합니다. Access-list 101은 H.323 시그널링 트래픽(TCP 포트 1720)과 일치합니다. 클래스 data1은 웹 트래픽(액세스 목록 102에 표시된 TCP 포트 80)과 일치하며 64kbps를 보장합니다. 클래스 data2는 텔넷 트래픽(ACL 103에 표시된 TCP 포트 23)과 일치하며 32kbps를 보장합니다. 기본 클래스는 분류되지 않은 플로우에 나머지 대역폭의 동일한 점유율을 제공하도록 구성됩니다. 정책을 "llq"라고 합니다. 총 대역폭이 256kbps인 Serial1/0의 발신 트래픽에 적용됩니다.

참고: 기본적으로 모든 클래스에 대해 보장되는 총 대역폭 및 우선 순위 대역폭은 인터페이스 대역폭의 75% 미만이어야 합니다. max-reserved bandwidth interface 명령을 실행하여 이 백분율을 수정합니다.

이 표에서는 서로 다른 소프트웨어 대기 메커니즘을 각각의 이점 및 한계와 비교합니다.

소프트웨어 큐잉 메커니즘	설명	혜택	제한 사항
선입선출(FIFO)	패킷은 정확히 동일한 순서로 대기열에 도착하고 대기열에서 나갑니다.	간단한 구성과 빠른 운영.	우선 순위 서비스 또는 대역폭 보장을 할 수 없습니다.¹
WFQ(Weighted Fair Queuing)	한 번에 서비스되는 패킷 수를 결정하는 데 가중치가 사용되는 별도의 대기열로 이동하는 해싱 알고리즘입니다. IP Precedence 및 DSCP 값을 설정하여 가중치를 정의합니다.	간단한 구성. 2Mbps 미만의 링크에서는 기본값입니다.	우선 순위 서비스 또는 대역폭 보장을 할 수 없습니다.¹
CQ(Custom Queuing)	트래픽은 구성 가능한 대기열 제한이 있는 여러 대기열로 분류됩니다. 대기열 제한은 평균 패킷 크기, MTU(Maximum Transmission Unit) 및 할당될 대역폭의 백분율을 기반으로 계산됩니다. 대기열 제한(바이트 수)은 각 대기열에 대해 디큐잉됩니다. 따라서 통계적으로 할당된 대역폭을 제공합니다.	몇 년 전부터 사용 가능했습니다. 서로 다른 대기열에 대해 대략적인 대역폭 할당이 가능합니다.	우선 순위 서비스를 사용할 수 없습니다. 대역폭 보장 수준은 대략적입니다. 대기열의 수가 제한되어 있습니다. 구성이 상대적으로 어렵습니다.¹
PQ(우선 순위 큐잉)	트래픽은 우선 순위가 높은 대기열, 중간 대기열, 보통 대기열 및 낮은 대기열로 분류됩니다. 우선 순위가 높은 트래픽이 먼저 서비스되고, 그 다음으로 보통, 보통, 낮은 트래픽이 서비스됩니다.	몇 년 전부터 사용 가능했습니다. 우선 서비스를 제공합니다.	우선순위가 높은 트래픽은 우선순위가 낮은 대역폭의 대기열을 빼앗습니다. 대역폭 보장은 불가능합니다.²
클래스 기반 CBWFQ(Weighted Fair Queuing)	모듈식 QoS CLI를 사용하여 트래픽을 분류합니다. 분류된 트래픽은 예약된 대역폭 대기열 또는 기본 예약되지 않은 대기열에 배치됩니다. 스케줄러는 대역폭을 보장하기 위해 가중치를 기반으로 대기열을 서비스합니다.	우선순위 큐가 없다는 점을 제외하면 LLQ와 유사합니다. 간단한 구성 및 대역폭 보장 기능	우선 순위 서비스를 사용할 수 없습니다.³
PQ-WFQ(Priority Queue Weighted Fair Queuing)(IP RTP Priority라고도 함)	단일 인터페이스 명령은 지정된 범위 내의 짝수 포트 번호로 향하는 모든 UDP 패킷에 우선 순위 서비스를 제공하는 데 사용됩니다.	간단한 단일 명령 컨피그레이션입니다. RTP 패킷에 대한 우선 순위 서비스를 제공합니다.	다른 모든 트래픽은 WFQ로 처리됩니다. RTCP(Real-Time Conferencing Protocol) 트래픽은 우선순위가 지정되지 않습니다. 보장된 대역폭 기능이 없습니다.⁴
LLQ(이전의 우선순위 대기열 클래스 기반 가중 공정 대기열(PQCBWFQ)	우선순위 큐가 있는 모듈형 QoS CLI를 사용하여 트래픽을 분류합니다. 분류된 트래픽은 우선 순위 대기열, 예약된 대역폭 대기열 또는 기본 예약되지 않은 대기열에 배치됩니다. 스케줄러는 우선 순위 트래픽이 먼저 전송되고(혼잡 중 특정 폴리싱된 제한까지) 대역폭 보증이 충족되도록 가중치를 기반으로 대기열을 서비스합니다.	간단한 구성. 여러 트래픽 클래스에 우선 순위를 부여하고 우선 순위 대역폭 사용률에 대한 상한을 부여하는 기능. 대역폭 보장 클래스와 기본 클래스를 구성할 수도 있습니다.	아직 여러 수준의 우선 순위를 제공하는 메커니즘이 없으므로 모든 우선 순위 트래픽은 동일한 우선 순위 큐를 통해 전송됩니다. 별도의 우선 순위 클래스는 혼잡 중에 별도의 우선 순위 대역폭 경계를 가질 수 있습니다. 그러나 애플리케이션 간에 우선순위 큐를 공유하면 잠재적으로 지터가 발생할 수 있습니다.⁴

음성에 적합하지 않습니다.
음성이 보장되는 대역폭이 필요합니다.
처리하려면 지연 시간이 필요합니다.
목소리 듣기에 충분합니다.

직렬화 지연

큐잉이 최상으로 작동하고 음성 트래픽의 우선 순위를 정하는 경우에도 우선 순위 큐가 비어 있고 다른 클래스의 패킷이 서비스되는 경우가 있습니다. 보장된 대역폭 클래스의 패킷은 구성된 가중치를 기반으로 서비스되어야 합니다. 이러한 패킷이 서비스되는 동안 우선 순위 음성 패킷이 출력 대기열에 도착하면 음성 패킷이 전송되기까지 상당한 시간을 대기할 수 있습니다. 음성 패킷은 더 큰 데이터 패킷 뒤에 대기해야 할 때 직렬화 지연이 발생합니다.

직렬화 지연은 음성 패킷에 대해 최악의 형태의 지터를 유발할 수 있다. 음성 패킷이 느린 링크에서 1500바이트만큼 큰 데이터 패킷 뒤에 대기해야 할 경우, 이는 엄청난 지연으로 이어집니다. 다음 예에 표시된 것처럼 데이터 패킷이 80바이트이면 직렬화 지연이 크게 달라집니다.

1500바이트 패킷 = 1500*8/64000 = 187.5ms로 인한 64kbps 링크의 직렬화 지연.
80바이트 패킷 = 80*8/64000 = 10ms로 인한 64kbps 링크의 직렬화 지연.

따라서 음성 패킷이 64kbps 링크의 단일 1500바이트 패킷 뒤에 머물러 있는 경우 전송되기 전에 최대 187.5ms까지 기다려야 합니다. 반면 다른 음성 패킷은 대상 게이트웨이에서 10ms만 기다려야 합니다. 이로 인해 패킷 간 지연의 분산으로 인해 발생하는 큰 지터가 발생합니다. 원래 게이트웨이에서 음성 패킷은 일반적으로 20ms마다 전송됩니다. 엔드 투 엔드 지연 예산이 150ms이고 엄격한 지터 요구 사항이 있는 경우 180ms를 초과하는 간격은 허용되지 않습니다.

하나의 전송 유닛의 크기가 10ms 미만이 되도록 하는 프래그먼트화의 메커니즘을 도입한다. 10ms 이상의 직렬화 지연이 있는 패킷은 10ms 청크로 프래그먼트화해야 합니다. 10ms 청크 또는 프래그먼트는 링크를 통해 10ms 단위로 전송된 바이트 수입니다. 다음 예제와 같이 링크 속도를 사용하여 크기를 계산합니다.

조각화 크기 = (0.01초 * 64,000bps) / (8비트/바이트) = 80바이트

64kbps 링크를 통해 80바이트 패킷 또는 프래그먼트를 전송하는 데 10ms가 소요됩니다.

단일 물리적 인터페이스에 여러 ATM 또는 PVC(Frame Relay Permanent Virtual Circuits)가 있는 경우 사용 가능한 대역폭이 가장 낮은 PVC를 기준으로 프래그먼트화 값(모든 PVC에 있음)을 구성합니다. 예를 들어, 보장된 대역폭이 512kbps, 128kbps 및 256kbps인 3개의 PVC가 있는 경우 프래그먼트 크기가 160바이트(160바이트 프래그먼트 크기가 필요한 최저 속도가 128kbps)인 3개의 PVC를 모두 구성합니다. 이러한 값은 서로 다른 링크 속도에 권장됩니다.

Link Speed (kbps)         Fragmentation Size (bytes) 
56                                  70 
64                                  80 
128                                 160 
256                                 320 
512                                 640 
768                                 960 
1024                                1280 
1536                                1920

참고: 프래그먼트 크기가 링크 MTU 크기보다 큰 경우 프래그먼트화가 필요하지 않습니다. 예를 들어, 1500바이트 MTU가 있는 T1 링크의 경우 프래그먼트 크기는 1920바이트입니다. 따라서 프래그먼트화가 필요하지 않습니다. 패킷 조각화 크기는 VoIP 패킷 크기보다 작으면 안 됩니다. VoIP 패킷을 프래그먼트화하지 마십시오. 이러한 패킷을 프래그먼트화하면 수많은 통화 설정 및 품질 문제가 발생합니다.

현재 3가지 링크 프래그먼트화 및 인터리빙 메커니즘이 사용 가능합니다. 패킷 네트워크에 도입된 다양한 지연에 대한 자세한 내용은 패킷 음성 네트워크의 지연 이해를 참조하십시오. 다음 표에는 이러한 솔루션의 혜택과 제한 사항이 나와 있습니다.

LFI(Link Fragmentation and Interleaving) 메커니즘	설명	혜택	제한 사항
WFQ를 사용한 MTU 프래그먼트화	MTU 크기 또는 IP MTU 크기를 변경하는 인터페이스 레벨 명령입니다. 지정된 MTU 크기에 대해 큰 IP 패킷을 조각화하는 데 사용됩니다. LFI는 WFQ를 사용하여 프래그먼트 간에 실시간 패킷을 인터리브합니다.	간단한 구성.	프래그먼트는 수신 애플리케이션에 의해서만 리어셈블됩니다. 따라서 네트워크를 비효율적으로 사용할 수 있습니다. DF(Do not Fragment) 비트가 설정되지 않은 IP 패킷만 프래그먼트화를 잘 처리할 수 있습니다. 고도의 프로세서 집약적 권장하지 않습니다.
MLPPP(Multilink Point-to-Point Protocol) LFI	포인트-투-포인트 직렬 링크에서 MLPPP를 먼저 구성한 다음 프래그먼트화 크기를 ms 단위로 설정해야 합니다. 멀티링크 인터페이스에서도 인터리빙이 활성화되어야 합니다.	패킷은 링크의 한쪽 끝에서 프래그먼트화되고 다른 쪽에서 재조합됩니다. 여러 개의 링크를 결합하여 대형 가상 파이프로 작동할 수 있습니다.	PPP에 대해 구성된 링크에서만 사용할 수 있습니다. PPP over Frame Relay 또는 PPP over ATM용 솔루션은 Cisco IOS Software Release 12.1(5)T 이상에서도 지원됩니다.
프레임 릴레이 프래그먼트화(FRF.12)	Frame Relay PVC에서 frame-relay traffic-shaping 명령을 활성화하고 map-class 아래에 프래그먼트화 크기를 설정해야 합니다.	패킷은 PVC의 한쪽 끝에서 프래그먼트화되며 다른 쪽에서 리어셈블됩니다.	Frame-relay traffic-shaping 명령이 활성화된 Frame Relay PVC에서만 사용할 수 있습니다.

바드

규칙적인 음성 대화는 몇 번의 침묵의 순간으로 이루어져 있다. 일반적인 음성 대화는 40~50%의 침묵으로 구성되어 있다. 음성 통화의 40%를 위해 네트워크를 통과하는 음성이 없기 때문에 VAD를 구축하면 일부 대역폭을 절약할 수 있습니다. VAD를 사용하면 게이트웨이에서 음성 메시지의 차이를 찾습니다. 그것은 편안한 소음 (배경 소음)으로 그 틈을 대체. 따라서, 대역폭의 양을 절약할 수 있다. 하지만, 절충점이 있다. 코덱에서 음성 활동을 탐지하고 그 뒤에 무음 기간이 올 때까지 시간이 짧습니다(밀리초 단위). 이렇게 시간이 짧으면 수신된 음성의 프런트엔드가 클리핑됩니다. 매우 짧은 일시 중지 동안 활성화를 피하고 클리핑을 보상하기 위해 VAD는 음성 중지 후 약 200ms를 기다린 후 전송을 중지합니다. 전송을 다시 시작할 때, 현재 스피치와 함께 이전의 5 ms 스피치를 포함한다. 주변 노이즈로 인해 음성과 배경 노이즈를 구분하지 못하는 경우 VAD는 통화에서 자동으로 비활성화됩니다. 그러나 대역폭이 문제가 되지 않으면 VAD를 끕니다.

VAD 매개변수 조정

VAD의 기능을 지시하는 두 가지 매개변수가 있습니다. 다음은 music-threshold 및 voice vad-time 명령입니다.

음악 임계값

VAD를 활성화해야 하는 시점을 제어하는 초기 임계값이 결정됩니다. 이 예에서는 표시된 것처럼 음성 포트에서 music-threshold threshold_value 명령을 정의하여 이 명령을 제어합니다. 이 값의 범위는 dBm(밀리와트 당 -70데시벨)에서 -30dBm까지입니다. 이 옵션의 기본값은 -38dBm입니다. 값을 낮게 구성하면(-70dBm으로) VAD가 훨씬 낮은 신호 강도로 활성화됩니다(볼륨이 매우 낮게 떨어져야 침묵으로 간주됨). 더 높은 값(-30dBm에 가까움)을 구성하면 음성 신호 강도가 조금만 떨어져도 VAD가 활성화됩니다. 또한 컴포트 노이즈 패킷을 더 자주 재생하도록 재생 시간을 단축합니다. 그러나 이로 인해 오디오의 사소한 클리핑이 발생하는 경우도 있습니다.

3640-6#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
3640-6(config)#voice-port 3/0/0
3640-6(config-voiceport)#music-threshold ?
WORD Enter a number b/w (-70 to -30)
3640-6(config-voiceport)#music-threshold -50
3640-6(config-voiceport)#end
3640-6#
3640-6#show run | be voice-portvoice-port 3/0/0 music-threshold -50

음성 vad 시간

VAD가 활성화되면 이 예에 표시된 것처럼 전역 컨피그레이션 아래에서 voice vad-time timer_value 명령을 구성하여 백그라운드 노이즈 및 컴포트 노이즈의 구성 요소를 제어합니다. 음성 패킷 전송의 무음 감지 및 억제에 대한 지연 시간(밀리초)입니다. 보류 시간의 기본값은 250 msec입니다. 이는 250 msec 이내에 컴포트 노이즈가 시작됨을 의미한다. 이 타이머의 범위는 250 msec~65536 msec입니다. 이에 대해 높은 값이 구성되면, 컴포트 노이즈는 훨씬 나중에 재생된다(배경 노이즈는 계속 재생된다). 65536 msec 동안 구성되면 컴포트 노이즈는 꺼집니다. 이 타이머에 대한 더 높은 값은 배경 노이즈와 컴포트 노이즈 사이의 더 원활한 전이를 위해 요망된다. voice vad-time 명령을 높은 수준으로 구성하는 단점은 원하는 30~35% 대역폭 절감을 달성하지 못한다는 것입니다.

3640-6#
3640-6#
3640-6#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
3640-6(config)#voice vad-time ?
<250-65536> milliseconds
3640-6(config)#voice vad-time 750
3640-6(config)#end
3640-6#
3640-6#
3640-6#
3640-6#show run | be vad-time voice vad-time 750

QoS의 일반적인 컨피그레이션 예

VoIP 통화를 설정하는 일반적인 시나리오는 프레임 릴레이 링크 또는 PPP 링크를 통해 이루어집니다. 다음은 이러한 시나리오의 컨피그레이션 예입니다.

VoIPoFR - QoS 컨피그레이션 예

(컨피그레이션의 관련 섹션만 포함된) 이 예에서는 프레임 릴레이 회로 속도가 256kbps라고 가정합니다. PVC 100의 CIR(Guaranteed Information Rate)은 64kbps이고 PVC 200의 CIR은 192kbps입니다. PVC(100)는 데이터와 음성을 모두 운반하는 데 사용된다. PVC 200은 데이터를 전달하기 위해서만 사용됩니다. 최대 4개의 동시 음성 통화가 지정된 시간에 존재합니다. 가장 낮은 대역폭-음성-PVC(음성을 전달하는 PVC)의 CIR을 기반으로 두 PVC에 대한 프래그먼트화를 구성합니다. 이 문서의 예를 바탕으로, 조각화 크기는 PVC 100의 CIR(64kbps)을 기준으로 결정됩니다. Serialization Delay 섹션의 표에 표시된 것처럼 64kbps 링크의 경우 80바이트의 프래그먼트화 크기가 필요합니다. PVC 200에 대해 동일한 프래그먼트화 크기를 구성해야 합니다.

VoIP over Frame Relay의 컨피그레이션에 대한 자세한 내용은 QoS(Quality of Service)(프래그먼트화, 트래픽 셰이핑, LLQ/IP RTP 우선 순위)가 포함된 VoIP over Frame Relay를 참조하십시오.

3660-1#show run
Building configuration...
!
class-map match-any voip
match ip rtp 16384 16383
match ip dscp 26 46
class-map match-all voip-control
match access-group 101
!
!
policy-map VoIPoFR
class voip
priority 48
class voip-control
bandwidth 8
class class-default
fair-queue
!
voice call send-alert
voice rtp send-recv
!
!
interface Serial4/0:0
bandwidth 256
no ip address
encapsulation frame-relay
frame-relay traffic-shaping
!
interface Serial4/0:0.1 point-to-point
bandwidth 64
ip address 10.10.10.10 255.255.255.0
frame-relay ip rtp header-compression
frame-relay interface-dlci 100
 class voice
!
interface Serial4/0:0.2 point-to-point
bandwidth 192
ip address 20.20.20.20 255.255.255.0
frame-relay interface-dlci 200
class data
!
map-class frame-relay data
frame-relay fragment 80
frame-relay adaptive-shaping becn
frame-relay cir 256000
frame-relay bc 32000
frame-relay be 0
frame-relay mincir 192000
frame-relay fair-queue
!
map-class frame-relay voice
frame-relay fragment 80
no frame-relay adaptive-shaping
frame-relay cir 64000
frame-relay bc 640
frame-relay be 0
frame-relay mincir 64000
service-policy output VoIPoFR
!
!
access-list 101 permit tcp any any eq 1720
!
!
voice-port 3/1/0
!
voice-port 3/1/1
!
!
dial-peer voice 10 voip
incoming called-number .
destination-pattern 1408.......
session target ipv4:10.10.10.11
dtmf-relay h245-signal h245-alphanumeric
no vad
!
dial-peer voice 20 pots
destination-pattern 1234
port 3/1/0
!
dial-peer voice 21 pots
destination-pattern 5678
port 3/1/1

VoIP Over PPP - QoS 컨피그레이션 예

(컨피그레이션의 관련 섹션만 포함된) 이 예에서는 포인트-투-포인트 분수 T1 컨트롤러(12개 채널)에 대해 QoS를 구성해야 한다고 가정합니다. 최대 4개의 동시 음성 통화가 지정된 시간에 존재합니다. 컨피그레이션 작업에는 PPP 캡슐화를 사용하여 이 직렬 인터페이스를 구성하고, 이를 멀티링크 그룹에 포함시키고, 멀티링크 인터페이스(동일한 멀티링크 그룹에 속함)를 생성하고, 멀티링크 인터페이스에서 모든 QoS를 구성하는 작업이 포함됩니다. PPP를 통한 VoIP 컨피그레이션에 대한 자세한 내용은 QoS(Quality of Service) 링크(LLQ/IP RTP Priority, LFI, cRTP)를 참조하십시오.

3660-1#show run
Building configuration...
!
class-map match-any voip
match ip rtp 16384 16383
match ip dscp 26 46
class-map match-all voip-control
match access-group 101
!
!
policy-map VoIPoPPP
class voip
priority 48
class voip-control
bandwidth 8
class class-default
fair-queue
!
voice call send-alert
voice rtp send-recv
!
!
interface Multilink7
bandwidth 768
ip address 10.10.10.10 255.255.255.0
ip tcp header-compression iphc-format
service-policy output VoIPoPPP
no cdp enable
ppp multilink
ppp multilink fragment-delay 10
ppp multilink interleave
multilink-group 7
ip rtp header-compression iphc-format
!
!
interface Serial4/0:0
bandwidth 768
no ip address
encapsulation ppp
no fair-queue
ppp multilink
multilink-group 7
!
!
access-list 101 permit tcp any any eq 1720
!
voice-port 3/1/0
!
voice-port 3/1/1
!
!
dial-peer voice 10 voip
incoming called-number .
destination-pattern 1408.......
session target ipv4:10.10.10.11
dtmf-relay h245-signal h245-alphanumeric
no vad
!
dial-peer voice 20 pots
destination-pattern 1234
port 3/1/0
!
dial-peer voice 21 pots
destination-pattern 5678
port 3/1/1
!

지터 및 재생 메커니즘

수신된 음성 패킷에서 추가적인 지연 및 지터에 기여하는, 네트워크에는 항상 제어되지 않는 일부 엔티티가 있습니다. 종료 게이트웨이의 지터 버퍼를 수정하면 음성 네트워크에서 제어되지 않은 지터가 해결됩니다.

재생 메커니즘

지터 버퍼는 시간 버퍼입니다. 종료 게이트웨이가 플레이아웃 메커니즘을 더 효과적으로 만들기 위해 제공합니다. 다음은 재생 메커니즘의 기능 다이어그램입니다.

재생 제어는 음성 패킷을 수신하면 RTP 타임스탬프를 분석합니다. 음성 패킷이 지터 버퍼의 보유 용량을 초과하여 지연되면 패킷이 즉시 삭제됩니다. 패킷이 버퍼링 기능 내에 있으면 지터 버퍼에 배치됩니다. 지터 버퍼에서 이 패킷의 위치는 해당 패킷에 대해 계산된 RTP 타임스탬프에 따라 달라집니다. 사용 가능한 음성 패킷이 없는 경우 재생 제어는 해당 패킷을 숨기려고 시도합니다(누락된 패킷을 예측함). VAD가 활성화된 경우 컴포트 노이즈가 재생됩니다.

재생 제어의 책임은 손실 패킷, 중복 패킷, 손상된 패킷, 무순서 패킷의 이벤트를 처리하는 것입니다. 이러한 이벤트는 jitted 음성 패킷을 시간 정렬하거나, comfort noise(VAD가 구성된 경우)를 재생하거나, 호스트에 재생하기 위해 DTMF(dual tone multifrequency) 톤을 재생성하는 방식으로 처리됩니다.

음성 패킷의 은닉은 예측 은닉 또는 침묵 은닉에 의해 이루어진다. 예측 은닉은 이전 패킷과 다음 패킷(사용 가능한 경우)을 기반으로 합니다. 낮은 비트 전송률 코덱(5kbps에서 16kbps)으로 가장 적합합니다. 높은 비트 전송률 코덱(32kbps에서 64kbps)에 대한 음성 패킷이 손실되면 예측 은폐가 저하될 수 있습니다. 예측 은닉은 지연이 적거나 패킷 손실 수가 적을 때 시작됩니다. 너무 많은 예측 은폐는 로봇 음질로 이어질 수 있습니다. 침묵의 은폐는 최악의 예측 은폐이다. 예측할 수 있는 정보가 없을 때 작동합니다. 그것은 단순히 배경 은폐이다. 지연이 많고 패킷 손실 수가 많을 때 시작됩니다. 지나친 침묵은 음질의 저하를 초래한다. 예측 은폐는 30초 동안 좋으며, 그 후에 침묵 은폐가 작용한다.

지터 버퍼

지터 버퍼는 하이 워터마크와 로우 워터마크에 의하여 한정된다. 상위 워터마크는 패킷이 정시 플레이아웃을 위해 도착할 것으로 예상되는 최대 시간 제한입니다. 상위 워터마크 이후에 도착한 패킷은 지연 패킷 또는 손실 패킷으로 표시됩니다. 로우 워터마크는 패킷이 정시 플레이아웃을 위해 도착할 것으로 예상되는 최소 시간입니다. 최저 수위 표시 전에 도착하는 패킷은 조기 패킷으로 간주됩니다(적시에 재생할 수 있음).

종료 게이트웨이가 지연 패킷의 도달 증가분을 계속 확인하는 경우 상위 워터마크를 높입니다. 고수위 표시에 대한 이 값은 통화 기간 동안 동일하게 유지됩니다. 이는 컨피그레이션에 정의된 최대값까지 증가합니다. 유사한 방식으로, 종료 게이트웨이는 수신된 조기 패킷의 수를 관찰한다. 이러한 패킷이 게이트웨이의 빈도를 높이기 시작하면 최저 수위가 낮아집니다. 이 값은 통화 기간 동안 동일하게 유지됩니다. 이러한 지터 버퍼 모드를 "적응형 모드"라고 하며, 여기서 종료 게이트웨이는 트래픽 패턴에 기초하여 지터 버퍼를 적응시킨다. 다른 모드는 "고정 모드"입니다. 고정 모드에서, 로우 워터 마크 및 하이 워터 마크에 대한 하나의 초기 값이 존재한다. 이 값은 예상 수신 지연을 기반으로 합니다(이 문서의 show voice call <port-number> 섹션 참조).

지터 버퍼에 대한 자세한 내용은 패킷 음성 네트워크의 지터 이해(Cisco IOS 플랫폼)를 참조하십시오.

지연 및 지터 확인

이 섹션에서는 네트워크의 지터를 식별하는 방법에 대해 설명합니다.

통화 활성 음성 표시

show call active voice brief 명령은 진행 중인 대화에 대한 많은 정보를 제공합니다. 이 출력은 이 명령을 통해 학습된 몇 가지 중요한 점을 표시합니다.

11E4 : 2170927hs.1 +600 pid:10 Answer 1000 active
dur 00:08:43 tx:26157/522967 rx:7044/139565
Tele 3/0/0:9: tx:151310/755/0ms g729r8 noise:-62 acom:0 i/0:-56/-48 dBm
11E4 : 2171198hs.1 +329 pid:20 Originate 2000 active
dur 00:08:43 tx:7044/139565 rx:26165/523127
IP 30.30.30.29:18682 rtt:51ms pl:148590/290ms lost:0/0/15 delay:65/60/132ms g729r8

show call active voice brief 명령 출력에서 텔레포니 레그(rx:7044)에 수신된 것이 IP 레그(tx:7044)로 전송되는 것을 확인할 수 있습니다. IP 레그(26165)에서 수신되어 텔레포니 레그(26157)로 전달되는 패킷의 경우에도 마찬가지입니다. IP 레그에서 수신된 패킷 수와 텔레포니 레그에서 전송된 패킷 수의 차이는 제시간에 도착하지 않는 늦은 패킷의 원인이 됩니다.

show call active voice 명령("brief" 키워드 없음)의 이 출력은 지터를 직접 식별하는 매개 변수에 대한 추가 세부 정보를 가리킵니다.

GapFillWithSilence=850 ms
GapFillWithPrediction=9230 ms
GapFillWithInterpolation=0 ms
GapFillWithRedundancy=0 ms

음성 통화 표시 <port-number>

show voice call port-number 명령은 유용한 정보를 제공합니다. 게이트웨이에서 위로되거나 게이트웨이로 텔넷된 경우 exec 레벨에서 terminal monitor 명령을 실행했는지 확인합니다.

참고: 이 명령은 AS5x00/AS5x50 플랫폼에서는 사용할 수 없습니다.

이 출력에서 Rx Delay Est(ms)의 값은 71입니다. 현재 지터 버퍼 값입니다. 이에 대하여 상위 워터마크 및 하위 워터마크의 값을 도출한다. 높은 물 마크의 평균 초기값은 70 msec인 반면, 낮은 물 마크의 초기값은 60 msec이다. 초기 값이 설정되면 게이트웨이는 수신된 모든 초기 패킷 또는 지연 패킷을 추적합니다. 여기 출력에서 보이는 바와 같이, 예측 은닉 드랍은 250 ms에 가까운 반면, 침묵 은닉은 30 ms이다. 침묵 은닉은 예측 은닉의 더 나쁜 시나리오일 뿐이기 때문에 예측 은닉에는 항상 더 높은 값이 있다. 모든 Prediction 은닉 삭제에 대해 버퍼 오버플로 삭제가 증가합니다.

버퍼 폐기가 나타난다고 해서 반드시 높은 수위가 상승한다는 의미는 아닙니다. 상위 워터마크는 지터 버퍼의 상한입니다. 추세가 관찰될 경우에만 변경됩니다. 즉, 지연 패킷의 연속적인 흐름이 있어야 합니다. 이는 지터 버퍼의 증가를 초래한다. 여기 출력에는 그런 경향이 있습니다. 따라서, 하이 워터마크는 70 msec에서 161 msec로 증가하였다. 이 값이 변경되지 않은 경우(그리고 아직 14개의 지연 패킷이 표시되는 경우), 이는 이러한 패킷이 산발적인 지연 패킷이어서 추세를 형성하지 않음을 의미합니다.

show call active voice 명령 출력에서 손실된 패킷을 확인합니다. 손실된 모든 패킷에 대해 시퀀스가 잘못된 두 패킷이 표시됩니다. Rx Non-Seq Pkts 출력에 표시됩니다. 양의 값이 아니기 때문에 패킷 손실도 발생하지 않았다는 결론을 내린다.

3640-6# ***DSP VOICE TX STATISTICS***
Tx Vox/Fax Pkts: 195, Tx Sig Pkts: 0, Tx Comfort Pkts: 10
Tx Dur(ms): 192070, Tx Vox Dur(ms): 388, Tx Fax Dur(ms): 0
***DSP VOICE RX STATISTICS***
Rx Vox/Fax Pkts: 9604, Rx Signal Pkts: 0, Rx Comfort Pkts: 0
Rx Dur(ms): 192070, Rx Vox Dur(ms): 191560, Rx Fax Dur(ms): 0
Rx Non-seq Pkts: 0, Rx Bad Hdr Pkts: 0
Rx Early Pkts: 0, Rx Late Pkts: 14
***DSP VOICE VP_DELAY STATISTICS***
Clk Offset(ms): 0, Rx Delay Est(ms): 71
Rx Delay Lo Water Mark(ms): 60, Rx Delay Hi Water Mark(ms): 161
***DSP VOICE VP_ERROR STATISTICS***
Predict Conceal(ms): 250, Interpolate Conceal(ms): 0
Silence Conceal(ms): 30, Retroact Mem Update(ms): 0
Buf Overflow Discard(ms): 500, Talkspurt Endpoint Detect Err: 0
***DSP LEVELS***
TDM Bus Levels(dBm0): Rx -49.9 from PBX/Phone, Tx -41.7 to PBX/Phone
TDM ACOM Levels(dBm0): +2.0, TDM ERL Level(dBm0): +11.1
TDM Bgd Levels(dBm0): -58.9, with activity being voice
***DSP VOICE ERROR STATISTICS***
Rx Pkt Drops(Invalid Header): 0, Tx Pkt Drops(HPI SAM Overflow): 0

Tx Comfort Pkts 및 Rx Comfort Pkts를 확인합니다. 이 예제 출력에서 알 수 있듯이, Tx Comfort Pkt가 많으므로 이 라우터에 연결된 전화기가 대부분 조용히 유지된다는 결론이 내려집니다. 동시에 Rx Comfort Pkts가 0입니다. 즉, 반대편이 계속 말합니다.

여기 출력을 이전 명령 출력과 비교합니다. Rx 지연 패킷 수가 14개에서 26개로 증가했습니다. 그러나 상위 워터마크 값에는 증분이 없습니다. 이는 12개의 패킷이 산발적으로 지연되고 있음을 나타냅니다. Buffer Overflow discard(버퍼 오버플로 폐기)가 910msec로 증가합니다. 다만, 관찰되는 경향성이 없기 때문에 고수위가 높아지지 않는다.

여기 출력에는 Rx Early Pkts가 있습니다. 3. 패킷이 예상보다 훨씬 먼저 도착함을 의미합니다. 여기 출력에서 알 수 있듯이, 지터 버퍼는 로우 워터마크를 60에서 51로 줄임으로써 더 이상 초기 패킷을 수용하도록 자체 확장되었습니다.

3640-6# ***DSP VOICE TX STATISTICS***
Tx Vox/Fax Pkts: 209, Tx Sig Pkts: 0, Tx Comfort Pkts: 11
Tx Dur(ms): 337420, Tx Vox Dur(ms): 416, Tx Fax Dur(ms): 0
***DSP VOICE RX STATISTICS***
Rx Vox/Fax Pkts: 16843, Rx Signal Pkts: 0, Rx Comfort Pkts: 1
Rx Dur(ms): 337420, Rx Vox Dur(ms): 335920, Rx Fax Dur(ms): 0
Rx Non-seq Pkts: 0, Rx Bad Hdr Pkts: 0
Rx Early Pkts: 3, Rx Late Pkts: 26
***DSP VOICE VP_DELAY STATISTICS***
Clk Offset(ms): 0, Rx Delay Est(ms): 72
Rx Delay Lo Water Mark(ms): 51, Rx Delay Hi Water Mark(ms): 161
***DSP VOICE VP_ERROR STATISTICS***
Predict Conceal(ms): 510, Interpolate Conceal(ms): 0
Silence Conceal(ms): 70, Retroact Mem Update(ms): 0
Buf Overflow Discard(ms): 910, Talkspurt Endpoint Detect Err: 0
***DSP LEVELS***
TDM Bus Levels(dBm0): Rx -51.5 from PBX/Phone, Tx -44.1 to PBX/Phone
TDM ACOM Levels(dBm0): +2.0, TDM ERL Level(dBm0): +11.9
TDM Bgd Levels(dBm0): -61.3, with activity being voice
***DSP VOICE ERROR STATISTICS***
Rx Pkt Drops(Invalid Header): 0, Tx Pkt Drops(HPI SAM Overflow): 0

게이트웨이의 지터 버퍼 구성

이 문서에서 다루는 QoS 지침은 불안정하거나 악화된 음성 품질 문제를 처리합니다. Playout-delay buffer 컨피그레이션은 네트워크에서 부적절한 QoS 구현을 위한 해결 방법입니다. 이 옵션은 네트워크에 도입된 지터 문제를 해결하고 좁히기 위한 도구로만 사용해야 합니다.

재생 지연 모드

지터 버퍼는 고정 모드 또는 적응형 모드에 대해 구성된다. 적응형 모드에서는 게이트웨이에서 지터 버퍼의 최소값, 최대값 및 공칭 값을 구성할 수 있습니다. 지터 버퍼에서는 패킷이 공칭 값 범위 내에 도착해야 합니다. 명목상 값은 최소 이상 및 최대 이하여야 합니다. 구성된 최대값까지 버퍼가 확장됩니다. 최대 1700 msec까지 확장할 수 있습니다. 높은 최대값을 구성하는 데 있어 한 가지 문제는 엔드 투 엔드 지연의 도입입니다. 네트워크에서 원치 않는 지연을 초래하지 않도록 최대 playout-delay 값을 선택합니다. 이 출력은 적응형 모드에 대해 구성된 지터 버퍼의 예입니다.

3640-6#
3640-6#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
3640-6(config)#voice-port 3/0/0
3640-6(config-voiceport)#playout-delay mode adaptive
3640-6(config-voiceport)#playout-delay maximum 400
3640-6(config-voiceport)#playout-delay nominal 70
3640-6(config-voiceport)#playout-delay minimum low
3640-6(config-voiceport)#^Z
3640-6#
3640-6#
3640-6#show run | begin 3/0/0
voice-port 3/0/0
playout-delay maximum 400
playout-delay nominal 70
playout-delay minimum low
playout-delay mode adaptive
!

고정 모드에서 게이트웨이는 구성된 값을 nominal로 확인합니다. 이 옵션을 사용하면 playout-delay의 최소값과 최대값을 구성할 수 있지만 고정 모드로 구성하면 무시됩니다. 고정 모드에 있을 때, 높은 물 마크 값 또는 낮은 물 마크 값은 항상 일정하게 유지된다. 이는 명목상 값 및 Rx Delay Est(ms) 값을 기반으로 합니다. 따라서 고정 모드에서 값을 200 msec로 구성할 수 있습니다. 그러나 예상 수신 지연이 100ms에 가까운 경우, 즉 통화 전체 기간에 대해 최고 수위 표시 및 최저 수위 표시가 설정됩니다.

3640-6#
3640-6#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
3640-6(config)#voice-port 3/0/0
3640-6(config-voiceport)#playout-delay mode fixed
3640-6(config-voiceport)#playout-delay nominal 70
3640-6(config-voiceport)#^Z
3640-6#
3640-6#
3640-6#show run | begin 3/0/0
voice-port 3/0/0
playout-delay mode fixed
playout-delay nominal 70
!

Playout-delay 컨피그레이션에 대한 자세한 내용은 Voice over IP용 Playout Delay Enhancements를 참조하십시오.