QoS 음성 문제 해결

다운로드 옵션

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

업데이트:2006년 2월 2일

문서 ID:20371

편견 없는 언어

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

이 번역에 관하여

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

소개

Packet Voice가 표준 PSTN(Public Switched Telephone Network) 텔레포니 서비스의 현실적인 대체품이 되려면 패킷 음성의 수신 품질이 기본 전화 서비스의 품질과 비교되어야 합니다. 이는 고품질의 음성 전송을 일관성 있게 의미합니다. 다른 실시간 애플리케이션과 마찬가지로 Packet Voice는 대역폭이 넓고 지연에 민감합니다. 음성 전송이 수신기에 알수(고르지 않음)되도록 하려면 음성 패킷을 삭제 또는 과도하게 지연시키거나 다양한 지연(지터라고도 함)을 겪을 수 없습니다. 이 문서에서는 음성 문제 해결에 도움이 되는 다양한 QoS(Quality of Service) 고려 사항에 대해 설명합니다. 음성 문제가 고르지 않은 주된 이유는 음성 패킷이 손실되고 지연되는 것입니다.

사전 요구 사항

요구 사항

이 문서의 독자는 다음 내용을 숙지해야 합니다.

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

사용되는 구성 요소

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

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

표기 규칙

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

음성 고르지 않은 원인

음성 품질이 낮은 것은 음성 패킷이 다양하게 지연되거나 네트워크에서 손실되기 때문입니다. 목적지에 도달하기 위해 음성 패킷이 지연되면 목적지 게이트웨이에 실시간 정보가 손실됩니다. 이 경우, 대상 게이트웨이는 누락된 패킷의 콘텐츠가 될 수 있는지 예측해야 합니다. 이 예측은 수신한 음성이 전송된 음성과 동일한 특성을 갖지 않게 합니다. 이것은 로봇처럼 들리는 수신 음성으로 이어집니다. 음성 패킷이 수신 게이트웨이의 예측 기능 이상으로 지연되면 게이트웨이는 실시간 간격을 비워 둡니다. 수신 끝의 그 공백을 메울 것이 없는 상태에서, 전송된 연설의 일부는 손실됩니다. 따라서 목소리가 고르지 않습니다. 음성 패킷이 매우 지연되지 않도록(그리고 그 이상, 가변적으로 지연되지 않음)하여 고르지 않은 음성 문제가 대부분 해결됩니다. VAD(Voice Activity Detection)는 음성 대화에 프런트엔드를 클리핑하는 기능을 추가할 때도 있습니다. 음성 통화 끊김(또는 클리핑)의 또 다른 원인입니다.

이 문서의 여러 섹션에서는 고르지 않은 음성 인스턴스를 최소화하는 방법을 보여줍니다. 이러한 조치 중 대부분은 음성 네트워크에서 최소 지터의 도입을 보장해야 합니다.

대역폭 요구 사항

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

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

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

이는 다음과 같습니다.

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

이는 다음과 같습니다.

헤더 압축은 IP RTP 헤더를 최대 4바이트로 줄이므로 28바이트입니다. 이렇게 하면 8kbps 코덱에서 11.2kbps가 생성됩니다(초당 50패킷).

자세한 내용은 Voice over IP - Per Call Bandwidth Consumption을 참조하십시오.

음성 트래픽 우선 순위

음성의 우선 순위를 지정하는 데 두 가지 중요한 구성 요소가 있습니다. 첫 번째는 흥미로운 음성 트래픽을 분류하고 표시하는 것입니다. 두 번째는 표시된 흥미로운 음성 트래픽의 우선 순위를 매깁니다. 이 두 하위 섹션에서는 음성을 분류, 표시 및 우선 순위를 지정하는 다양한 방법에 대해 설명합니다.

분류 및 표시

VoIP 패킷의 대역폭을 보장하려면 네트워크 디바이스가 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)를 참조하십시오.

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

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비트 0, 1, 2(DS5, DS4, DS3)는 우선 순위 비트입니다. 여기서,

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

000XXX00Bits 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 바이트의 가장 중요한 세 비트가 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

위의 예에서 다이얼 피어 음성 100 voip 명령과 일치하는 모든 VoIP 호출에는 EF(Citrated Forwarding) 비트 패턴 10110으로 설정된 모든 미디어 페이로드 패킷(음성 패킷)이 있습니다. 모든 신호 패킷은 AF 비트 패턴 011010으로 설정됩니다.

참고: ip qos dscp 명령은 Cisco IOS® Software 릴리스 12.2(2)T 이후로 지원됩니다. IP 우선 순위는 Cisco IOS Software Release 12.2T에서 더 이상 사용할 수 없습니다. 그러나 ip qos dscp 명령은 동일한 결과를 얻습니다. IP 우선 순위 5(101)는 IP DSCP 101000에 매핑됩니다. 자세한 내용은 QoS에 대한 VoIP 신호 처리 및 미디어 분류를 참조하십시오.

패킷 분류 및 표시를 위한 모듈식 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 바이트의 가장 중요한 세 비트가 101로 설정됩니다. ACL 100은 VoIP에서 사용하는 공통 UDP 포트와 일치합니다. 마찬가지로 ACL 101은 H.323 신호 트래픽(TCP(Transmission Control Protocol) 포트 1720)과 일치합니다. 다른 모든 트래픽은 IP 우선 순위 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를 구성하는 방법을 보여 줍니다. 자세한 내용은 대기 시간이 낮은 대기열을 참조하십시오.

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를 보장합니다. Class data2는 텔넷 트래픽(ACL 103에 표시된 TCP 포트 23)과 일치하고 32kbps를 보장합니다. 기본 클래스는 미분류 플로우에 나머지 대역폭의 동일한 공유를 제공하도록 구성됩니다. 이 정책을 "llq"라고 합니다. 총 대역폭이 256kbps인 Serial1/0의 발신 트래픽에 적용됩니다.

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

이 표에서는 다양한 소프트웨어 대기열 메커니즘과 각각의 이점 및 제한을 비교합니다.

소프트웨어 대기열 메커니즘	설명	혜택	제한 사항
FIFO(First-In-First-Out)	패킷이 도착하고 정확히 동일한 순서로 대기열을 유지합니다.	간단한 구성 및 신속한 운영	우선 순위 서비스 또는 대역폭이 보장되지 않습니다.¹
WFQ(Weighted Fair Queuing)	가중치를 사용하여 한 번에 서비스되는 패킷 수를 결정하는 별도의 큐로 이동하는 해싱 알고리즘. IP 우선 순위 및 DSCP 값을 설정하여 가중치를 정의합니다.	간단한 구성. 2Mbps 미만 링크의 기본값.	우선 순위 서비스 또는 대역폭이 보장되지 않습니다.¹
사용자 지정 대기열(CQ)	트래픽은 구성 가능한 대기열 제한이 있는 여러 대기열로 분류됩니다. 대기열 제한은 평균 패킷 크기, MTU(Maximum Transmission Unit) 및 할당할 대역폭 백분율을 기반으로 계산됩니다. 대기열 제한(바이트 수)은 각 대기열에 대해 대기열에서 제거됩니다. 따라서 할당된 대역폭을 통계적으로 제공합니다.	몇 년 동안 사용할 수 있습니다. 또한 서로 다른 대기열에 대략적인 대역폭을 할당할 수 있습니다.	우선 순위 서비스가 가능하지 않습니다. 대역폭 보장은 대략적인 것입니다. 대기열의 수가 제한되어 있습니다. 구성이 비교적 어렵습니다.¹
PQ(Priority Queuing)	트래픽은 높음, 중간, 보통 및 낮은 우선 순위 큐로 분류됩니다. 우선 순위가 높은 트래픽이 먼저 서비스되며, 그 뒤를 중간, 일반 및 낮은 우선 순위 트래픽이 옵니다.	몇 년 동안 사용할 수 있습니다. 우선 서비스를 제공합니다.	우선 순위가 높은 트래픽은 대역폭의 낮은 우선 순위 큐를 시작합니다. 대역폭 보장은 불가능합니다.²
클래스 기반 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(Priority Queue Class-Based Weighted Fair Queuing)라고 함	우선순위 큐가 있는 모듈형 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바이트(최저 속도는 128kbps로 160바이트 조각 크기가 필요한)인 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 크기를 변경하기 위한 인터페이스 수준 명령입니다. 큰 IP 패킷을 지정된 MTU 크기로 조각화하는 데 사용됩니다. LFI는 WFQ를 사용하여 프래그먼트 간에 실시간 패킷을 인터리빙합니다.	간단한 구성.	프래그먼트는 수신 애플리케이션에서만 리어셈블됩니다. 따라서 네트워크를 비효율적으로 사용합니다. DF(Do not Fragment) 비트가 설정되지 않은 IP 패킷만 조각화를 제대로 처리할 수 있습니다. 프로세서 집약도가 높습니다. 권장되지 않습니다.
MLPPP(Multilink Point-to-Point Protocol) LFI	포인트 투 포인트 직렬 링크에서 MLPPP를 먼저 구성한 다음 조각화 크기를 ms로 설정해야 합니다. 멀티링크 인터페이스에서도 인터리빙을 활성화해야 합니다.	패킷은 링크의 한쪽 끝에서 프래그먼트되고 다른 쪽 끝에서 리어셈블됩니다. 여러 링크를 결합하여 대형 가상 파이프로 작동할 수 있습니다.	PPP에 대해 구성된 링크에서만 사용할 수 있습니다. Cisco IOS Software Release 12.1(5)T 이상에서도 PPP over Frame Relay 또는 PPP over ATM용 솔루션이 지원됩니다.
프레임 릴레이 조각화(FRF.12)	Frame Relay PVC에서 frame-relay traffic-shaping 명령을 활성화하고 map-class 아래에 조각화 크기를 설정해야 합니다.	패킷은 PVC의 한쪽 끝에서 조각화되고 다른 쪽 끝에서 리어셈블됩니다.	frame-relay traffic-shaping 명령이 활성화된 프레임 릴레이 PVC에서만 사용할 수 있습니다.

VAD

정기적인 음성 대화는 몇 번의 침묵으로 구성됩니다. 일반적인 음성 대화는 40~50%의 침묵으로 구성됩니다. 음성 통화의 40%를 위해 네트워크를 통과하는 음성이 없으므로 VAD를 구축하여 일부 대역폭을 절약할 수 있습니다. VAD를 사용하면 게이트웨이가 음성 간극을 확인합니다. 이러한 간격을 편안한 소음(배경 소음)으로 대체합니다. 따라서 대역폭의 양이 저장됩니다. 그러나, 트레이드 오프가 있다. 코덱이 음성 활동을 탐지하고 그 다음에 침묵이 발생하기 전에 약간의 시간(밀리초 단위)이 있습니다. 이렇게 시간이 짧으면 수신한 음성이 프런트엔드로 클리핑됩니다. VAD는 매우 짧은 일시 중지 중에 활성화가 발생하지 않도록 하고 클리핑을 보완하기 위해 음성 정지 후 약 200ms의 기다렸다가 전송이 중단됩니다. 전송을 다시 시작하면 이전 5ms의 연설과 현재 음성이 포함됩니다. 주변 노이즈가 음성과 배경 노이즈를 구별하지 못하게 하면 VAD는 통화에서 자동으로 자신을 비활성화합니다. 그러나 대역폭이 문제가 아닌 경우 VAD를 끕니다.

VAD 매개변수 조정

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

음악 임계값

초기 임계값은 VAD가 활성화되어야 하는 시점을 좌우하는 것으로 결정됩니다. 이 예와 같이 음성 포트에서 music-threshold threshold_value 명령을 정의하여 제어합니다. 이 값의 범위는 -70데시벨(밀리와트 당)(dBm)에서 -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 명령을 구성하여 배경 잡음 및 편안함 노이즈의 구성 요소를 제어합니다. 음성 패킷 전송의 무음 감지 및 억제에 대한 지연 시간(밀리초)입니다. 대기 시간의 기본값은 250msec입니다. 즉, 250밀리초 이내에 편안함 소음이 발생합니다. 이 타이머의 범위는 250msec~65536msec입니다. 이에 대해 높은 값을 구성하면 훨씬 후에 편안한 소음이 발생합니다(배경 소음이 계속 재생됨). 65536msec에 대해 구성된 경우 편안한 소음이 꺼집니다. 이 타이머에 더 높은 값을 지정하면 배경 잡음과 편안한 노이즈 사이의 원활한 전환이 필요합니다. 음성 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(Committed Information Rate)은 64kbps, PVC 200은 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)를 통한 VoIP over Frame Relay(조각화, 트래픽 셰이핑, LLQ / IP RTP 우선순위)를 참조하십시오.

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 컨피그레이션 예

이 예에서는(컨피그레이션의 관련 섹션만 포함) Point-to-point 분수 T1 컨트롤러(12개의 채널이 있는)에 대해 QoS를 구성해야 한다고 가정합니다. 지정된 시간에 최대 4개의 동시 음성 통화가 존재합니다. 컨피그레이션 작업에는 PPP 캡슐화를 사용하여 이 직렬 인터페이스를 구성하고, 멀티링크 그룹의 일부로 만들고, 동일한 멀티링크 그룹에 속하는 멀티링크 인터페이스를 만들고, 멀티링크 인터페이스에서 모든 QoS를 구성하는 작업이 포함됩니다. PPP를 통한 VoIP 구성에 대한 자세한 내용은 QoS(Quality of Service)를 통한 VoIP over PPP 링크(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가 활성화된 경우 편안한 소음이 재생됩니다.

재생 제어 기능은 손실된 패킷, 중복된 패킷, 손상된 패킷 및 시퀀스되지 않은 패킷의 이벤트를 처리하는 것입니다. 이러한 이벤트는 지터가 있는 음성 패킷을 정렬하거나, 편안한 노이즈를 재생하거나(VAD가 구성된 경우), 호스트에 대해 재생될 듀얼 톤 DTMF(다중 주파수) 신호음을 재생성하는 시간으로 처리됩니다.

음성 패킷의 은닉 작업은 예측 은닉 또는 무음 은닉 방식으로 수행됩니다. 예측 은이전 패킷과 다음 패킷(사용 가능한 경우)을 기반으로 합니다. 비트 전송률이 낮은 코덱에서 가장 적합합니다(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

음성 통화 표시 <포트 번호>

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

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

이 출력에서 Rx 지연 테스트(ms)의 값은 71입니다. 현재 지터 버퍼 값입니다. 상위 워터마크 및 하위 워터마크의 값이 여기에 대해 추론됩니다. 상위 워터마크의 평균 초기 값은 70ms이고, 하위 워터마크의 경우 60msec입니다. 초기 값이 설정되면 게이트웨이는 받은 초기 패킷 또는 지연 패킷을 추적합니다. 여기 출력에서 볼 수 있듯이, 예측 은폐 물체는 250ms에 가깝고, 침묵 은폐 물체는 30ms입니다. 무음 은폐 기능은 예측 은폐 시나리오의 더 나쁜 시나리오이기 때문에 예측 은폐 시 항상 더 높은 값이 있습니다. 모든 예측 은에서 삭제될 때마다 버퍼 오버플로 버스트가 증가합니다.

버퍼 버림을 볼 때 반드시 높은 수위 표시의 증가를 볼 필요는 없습니다. 하이 워터마크는 지터 버퍼의 상한값입니다. 트렌드가 관찰된 경우에만 변경됩니다. 즉, 지연 패킷의 연속 플로우가 있어야 합니다. 따라서 지터 버퍼가 증가합니다. 여기 출력에서 이러한 추세가 나타나고 있습니다. 따라서 높은 수위는 70msec에서 161msec로 증가합니다. 이 값이 변경되지 않은 경우(그리고 여전히 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 Pkts가 많으므로 이 라우터에 연결된 전화기가 대부분 조용합니다. 동시에, 당신은 제로 Rx Comfort Pkts를 가지고 있는데, 그것은 다른 쪽 끝은 계속 말하고 있다는 것을 의미합니다.

위의 출력을 이전 명령 출력과 비교합니다. Rx Late Pkts(14개에서 26개로 증가) 수가 있습니다. 그러나 상위 워터마크 값은 증가하지 않습니다. 이는 12개의 패킷이 산발적으로 지연됨을 나타냅니다. Buffer Overflow Discard(버퍼 오버플로 폐기)가 910밀리초로 증가합니다. 하지만, 관찰된 추세가 없기 때문에, 높은 수위는 증가하지 않습니다.

여기 출력에는 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 지침은 음성 품질 문제가 불안정하거나 악화되는 문제를 처리합니다. 재생 지연 버퍼의 구성은 네트워크에서 부적절한 QoS 구현을 위한 해결 방법입니다. 이를 Stop-gap 수정이나 네트워크에 도입된 지터 문제를 해결하고 해결할 수 있는 도구로만 사용하십시오.

재생 지연 모드

지터 버퍼는 고정 모드 또는 적응 모드에 대해 구성됩니다. 적응형 모드에서 게이트웨이를 사용하면 지터 버퍼의 최소값, 최대값 및 명목상 값을 구성할 수 있습니다. 지터 버퍼는 패킷이 명목상 값 범위 내에 도착할 것으로 예상합니다. 명목상 값은 최소값보다 크거나 같고 최대값과 같거나 작아야 합니다. 버퍼가 구성된 최대값까지 확장됩니다. 최대 1700msec까지 확장할 수 있습니다. 높은 가치 구성의 한 가지 문제는 엔드 투 엔드 지연을 도입하는 것입니다. 네트워크에서 원치 않는 지연이 발생하지 않도록 최대 재생 지연 시간 값을 선택합니다. 이 출력은 적응형 모드에 대해 구성된 지터 버퍼의 예입니다.

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
!

고정 모드에서 게이트웨이는 명목상 값으로 구성된 값을 확인합니다. 재생 지연에 대한 최소값과 최대값을 구성할 수 있지만 고정 모드에 대해 구성된 경우 무시됩니다. 고정 모드에서 상위 워터마크 값 또는 하위 워터마크 값은 항상 일정하게 유지됩니다. 명목상 값을 기반으로 하며 Rx 지연 시간(ms) 값을 기반으로 합니다. 따라서 고정 모드에서는 값을 200msec로 구성할 수 있습니다. 그러나 예상 수신 지연이 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 Enhancements for Voice over IP를 참조하십시오.