패킷 음성 네트워크의 지터 이해(Cisco IOS 플랫폼)
목차
소개
이 문서에서는 지터 및 지터를 측정하고 보상하는 방법에 대해 설명합니다.
사전 요구 사항
요구 사항
이 문서의 독자는 다음 주제에 대해 알고 있어야 합니다.
-
기본 Cisco IOS® 음성 구성
-
QoS(Quality of Service)에 대한 기본적인 이해
사용되는 구성 요소
이 문서의 정보는 Cisco IOS 음성 게이트웨이 및 라우터에 적용됩니다.
이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다.이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다.현재 네트워크가 작동 중인 경우, 모든 명령어의 잠재적인 영향을 미리 숙지하시기 바랍니다.
표기 규칙
문서 규칙에 대한 자세한 내용은 Cisco 기술 팁 표기 규칙을 참조하십시오.
패킷 음성 네트워크의 지터
지터는 수신된 패킷의 지연 변동으로 정의됩니다.전송 측면에서는 패킷이 균일한 간격으로 떨어져 있는 연속 스트림에서 패킷이 전송됩니다.네트워크 혼잡, 잘못된 큐잉 또는 컨피그레이션 오류로 인해 이 안정된 스트림이 과부하게 되거나 각 패킷 간의 지연이 남아 있는 상수 대신 달라질 수 있습니다.
이 다이어그램은 패킷의 꾸준한 스트림이 처리되는 방법을 보여줍니다.
라우터가 VoIP(Voice over IP)용 RTP(Real-Time Protocol) 오디오 스트림을 수신하면 발생하는 지터를 보완해야 합니다.이 기능을 처리하는 메커니즘은 재생 지연 버퍼입니다.재생 지연 버퍼는 이러한 패킷을 버퍼링한 다음 이를 DSP(디지털 신호 프로세서)로 계속 재생하여 아날로그 오디오 스트림으로 변환해야 합니다.플레이아웃 지연 버퍼를 de-jitter 버퍼라고도 합니다.
이 다이어그램은 지터를 처리하는 방법을 보여줍니다.
지터가 너무 커서 패킷이 이 버퍼의 범위를 벗어나면 범위를 벗어난 패킷이 삭제되고 오디오에서 드롭아웃이 들립니다.패킷이 하나뿐인 손실인 경우 DSP는 오디오가 있어야 한다고 생각하는 내용을 보간하며 문제가 발생하지 않습니다.지터가 DSP에서 누락된 패킷을 보충하기 위해 할 수 있는 작업을 초과하면 오디오 문제가 발생합니다.
이 다이어그램은 과도한 지터를 처리하는 방법을 보여줍니다.
지터의 심각도 확인
과도한 지터의 존재를 Cisco IOS를 통해 확인하는 절차는 다음과 같습니다.
-
통화가 작동 및 활성화되고 지터가 의심되면 관련된 게이트웨이 중 하나에 텔넷합니다.
-
텔넷 세션을 통해 콘솔 메시지를 볼 수 있도록 터미널 모니터를 활성화합니다.
참고: 콘솔 포트에 연결된 경우에는 이 단계가 필요하지 않습니다.
-
show voice call summary 명령을 입력합니다.다음과 유사한 출력이 나타납니다.
PORT CODEC VAD VTSP STATE VPM STATE ============ ======== === ==================== ====================== 1/0/0 - - - FXSLS_ONHOOK 1/0/1 g729r8 y S_CONNECT FXSLS_CONNECT
지터가 발생하는 통화를 선택합니다.이 예에서는 1/0/1입니다.
-
이 특정 통화를 보려면 show voice call 명령을 입력합니다.
이 예에서는 show voice call 1/0/1입니다. 제공된 출력은 통화를 처리하는 DSP에서 가져오며 다음과 유사합니다.
1/0/1 vtsp level 0 state = S_CONNECT vpm level 1 state = FXSLS_CONNECT vpm level 0 state = S_UP MS-2621-3B# ***DSP VOICE VP_DELAY STATISTICS*** Clk Offset(ms): 0, Rx Delay Est(ms): 50 Rx Delay Lo Water Mark(ms): 50, Rx Delay Hi Water Mark(ms): 7 ***DSP VOICE VP_ERROR STATISTICS*** Predict Conceal(ms): 0, Interpolate Conceal(ms): 0 Silence Conceal(ms): 0, Retroact Mem Update(ms): 0 Buf Overflow Discard(ms): 0, Talkspurt Endpoint Detect Err: 0 ***DSP VOICE RX STATISTICS*** Rx Vox/Fax Pkts: 1187, Rx Signal Pkts: 0, Rx Comfort Pkts: 0 Rx Dur(ms): 150200, Rx Vox Dur(ms): 23740, Rx Fax Dur(ms): 0 Rx Non-seq Pkts: 0, Rx Bad Hdr Pkts: 0 Rx Early Pkts: 0, Rx Late Pkts: 0 ***DSP VOICE TX STATISTICS*** Tx Vox/Fax Pkts: 7129, Tx Sig Pkts: 0, Tx Comfort Pkts: 0 Tx Dur(ms): 150200, Tx Vox Dur(ms): 14259, Tx Fax Dur(ms): 0 ***DSP VOICE ERROR STATISTICS*** Rx Pkt Drops(Invalid Header): 0, Tx Pkt Drops(HPI SAM Overflow): 0 ***DSP LEVELS*** TDM Bus Levels(dBm0): Rx -54.5 from PBX/Phone, Tx -64.7 to PBX/Phone TDM ACOM Levels(dBm0): +2.0, TDM ERL Level(dBm0): +9.9 TDM Bgd Levels(dBm0): -49.4, with activity being voice -
출력에서 ***DSP VOICE VP_ERROR STATISTICS*** 섹션을 봅니다.
이 섹션에서는 몇 가지 매개변수를 살펴봅니다.주 하나는 보이는 Buf Overflow Discard(ms) 수입니다.이렇게 하면 재생 지연 버퍼(삭제됨)에 대해 범위를 벗어난 패킷이 계산됩니다. 지속적으로 증가하지 않는 한, 이 기능은 가치가 있을 수 있습니다.통화가 처음 시작될 때 오버플로우를 가져오는 것은 정상이지만 show voice call X/X/X 명령이 반복될 때 이 값은 증가해서는 안 됩니다.이 숫자는 과도한 지터의 직접적인 표시입니다.
기본적으로 이 버퍼는 현재 지터의 양에 따라 동적으로 조정되는 적응형 모드에서 실행됩니다(최대 한 점). de-jitter 버퍼의 동적 동작에 대한 기본값을 변경하도록 playout-delay 명령을 구성합니다.이 버퍼는 고정 모드에서도 설정할 수 있습니다.이렇게 하면 지터와 관련된 몇 가지 문제를 해결할 수 있습니다.자세한 내용은 VoIP에 대한 재생 지연 개선 사항을 참조하십시오.
지터의 원인은 무엇입니까?
지터는 일반적으로 IP 네트워크의 혼잡으로 인해 발생합니다.회로가 올바르게 프로비저닝되지 않은 경우 라우터 인터페이스 또는 사업자 또는 캐리어 네트워크에서 혼잡이 발생할 수 있습니다.
캡슐화 고려 사항
지터를 찾는 가장 쉽고 좋은 장소는 회로의 이 부분을 직접 제어할 수 있기 때문에 라우터 인터페이스입니다.지터의 소스를 추적하는 방법은 지터가 발생하는 링크의 캡슐화와 유형에 따라 크게 달라집니다.일반적으로 ATM 회로는 상수 셀 속도 때문에 올바르게 구성된 경우 지터가 발생하지 않습니다.따라서 레이턴시가 매우 일관됩니다.ATM 환경에서 지터가 보이면 ATM 컨피그레이션을 확인해야 합니다.ATM이 올바르게 작동하면(삭제된 셀 없음) 지터가 문제가 되지 않을 것으로 예상할 수 있습니다.PPP(Point-to-Point Protocol) 캡슐화에서는 거의 항상 직렬화 지연 때문에 지터가 발생합니다.이를 PPP 링크의 Link Fragmentation 및 Interleaving으로 쉽게 관리할 수 있습니다.PPP의 특성은 PPP 엔드포인트가 서로 직접 대화하면서 스위치 네트워크가 없다는 것을 의미합니다.따라서 네트워크 관리자가 관련된 모든 인터페이스를 제어할 수 있습니다.
프레임 릴레이 환경의 지터
프레임 릴레이 환경에서 지터를 찾으려면 세 가지 매개 변수를 지정해야 합니다.
이 구성과 관련된 샘플 컨피그레이션 및 정보는 QoS(Quality of Service)를 통해 VoIP over Frame Relay를 참조하십시오.
트래픽 셰이핑
라우터를 전달하는 트래픽을 통신사가 제공하는 실제 CIR(Committed Information Rate)로 셰이핑해야 합니다.Frame Relay(프레임 릴레이) 통계를 확인하고 통신업체에 문의하십시오.먼저 프레임 릴레이 통계를 살펴보십시오.show frame-relay pvc xx 명령을 사용합니다. 여기서 xx는 DLCI(Data-link connection identifier) 번호입니다.다음과 유사한 출력을 받아야 합니다.
PVC Statistics for interface Serial0/1 (Frame Relay DTE) DLCI = 16, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/1.1 input pkts 103611 output pkts 120054 in bytes 9909818 out bytes 10962348 dropped pkts 0 in FECN pkts 0 in BECN pkts 0 out FECN pkts 0 out BECN pkts 0 in DE pkts 0 out DE pkts 0 out bcast pkts 1366 out bcast bytes 448048 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec pvc create time 22:45:57, last time pvc status changed 22:45:57 Queueing strategy: weighted fair Current fair queue configuration: Discard Dynamic Reserved threshold queue count queue count 64 16 0 Output queue size 0/max total 600/drops 18303 fragment type end-to-end fragment size 1600 cir 20000 bc 1000 be 0 limit 125 interval 50 mincir 20000 byte increment 125 BECN response no IF_CONG no frags 103356 bytes 9807006 frags delayed 67241 bytes delayed 7127120 shaping active traffic shaping drops 18303
모든 필드에 대한 자세한 설명은 show frame-relay pvc 설명을 참조하십시오.
검색 대상
명령 출력에서 주의해야 하는 값은 프레임 네트워크에 혼잡이 있는지 여부를 표시하는 값입니다.이러한 값은 FECN(forward explicit congestion notification), BECN(backward explicit congestion notification) 및 DE(discard eligible) 매개변수입니다.Cisco에서 이러한 패킷을 전송하지 않으므로 입력 패킷만 고려해야 합니다.이러한 값 중 하나 이상이 증가하는 것을 볼 수 있습니다.이는 공급자가 사용하는 프레임 스위치의 유형과 구성에 따라 달라집니다.일반적으로 Frame Relay 트래픽 셰이핑이 있고 회로와 동일한 CIR에 대해 구성된 경우 이러한 값이 증가하면 안 됩니다.이러한 값이 증가하면서 회로의 실제 CIR과 일치하면 프레임 공급자의 네트워크에 있는 어떤 것이 제대로 구성되지 않습니다.
한 가지 좋은 예는 제로 CIR 회로를 구매하지만 버스트 값이 있는 경우입니다.일부 공급업체는 제로 CIR PVC(Permanent Virtual Circuit)를 판매합니다. 이는 데이터에 적합하지만 음성 품질에 문제가 있습니다.제로 CIR 회선의 명령 출력을 보면 DE 또는 FCN 패킷의 수가 입력 패킷 수와 같습니다.이 단계를 더 진행하기 위해, 캐리어가 128kbs로 프로비저닝하고 라우터의 CIR이 512kbs로 설정된 PVC가 있는 경우 이러한 카운터가 증가하여 속도가 더 느린 것을 볼 수 있습니다. 라우터 인터페이스로 들어오는 패킷만 살펴보고 이 속도는 PVC의 반대쪽 끝에 있는 라우터에 구성된 트래픽 셰이핑 매개변수에 의해 제어됩니다.반대로, 로컬 엔드에서 트래픽 셰이핑 매개변수가 구성되는 다른 라우터의 입력을 제어할 수 있습니다.
캐리어가 프로비저닝하는 PVC의 CIR을 초과하지 않는 것이 매우 중요합니다.문제 없이 이 CIR 아래에 있을 수 있습니다.그러나 초과되면 혼잡이 발생합니다.
이러한 혼잡을 확인할 수 있는 이유는 프레임 스위치의 특정 PVC에 대해 구성된 CIR이 해당 PVC에 대해 해당 스위치에서 트래픽을 전달하는 속도를 결정하기 때문입니다. 프레임 스위치에서 구성된 CIR이 수신한 실제 데이터 전송률에 의해 초과되면 버퍼된 패킷을 전달할 수 있을 때까지 CIR을 초과하는 프레임을 버퍼링해야 합니다.버퍼링된 패킷은 DE 비트 집합 또는 프레임 스위치에서 설정한 FCN 비트를 가져옵니다.
또한 항상 마찬가지로, 인터페이스 통계를 면밀하게 검토하고 모든 것이 물리적 레이어에서 제대로 작동하는지 확인하기 위해 삭제 또는 오류를 찾아봅니다.이렇게 하려면 show interface 명령을 사용합니다.
이러한 문제가 발생할 경우 지터와 관련된 방식이며, 일부 패킷은 프레임 네트워크에서 버퍼링해야 하며, 원격 라우터에 도달하는 데 더 긴 레이턴시가 발생합니다.그러나 혼잡이 없을 경우 일반적으로 예상되는 레이턴시 시간을 통과합니다.이렇게 하면 원격 라우터에서 수신된 패킷 간의 델타 시간 차이가 발생합니다.그래서 지터
조각화
조각화는 지터보다 직렬화 지연과 더 많이 연결됩니다.그러나, 특정한 조건하에서, 그것은 지터의 원인이 될 수 있습니다.패킷화된 음성을 수행할 때는 항상 프레임 릴레이 맵 클래스에서 프래그먼트화를 구성해야 합니다.이 매개변수의 컨피그레이션은 인터페이스에 두 가지 영향을 미칩니다.첫 번째 효과는 지정된 크기보다 큰 모든 패킷이 프래그먼트화된다는 것입니다.두 번째 효과는 덜 드러나지만 그만큼 중요합니다.프래그먼트화가 구성된 인터페이스를 보면 이 명령의 효과를 볼 수 있습니다.단편화가 없으면 show interface x 명령의 출력에 표시된 대기열 전략은 첫 번째 FIFO(first out) 큐잉이 사용 중임을 보여줍니다.Frame Relay 맵 클래스에 단편화가 적용되면 이 명령의 출력에서 큐 전략을 이중 FIFO로 표시합니다.이렇게 하면 인터페이스의 음성 트래픽에 사용되는 우선순위 대기열이 생성됩니다.프래그먼트화 값을 QoS 문서의 VoIP over Frame Relay의 Fragmentation 섹션에 권장되는 값으로 설정하는 것이 좋습니다.권장 값에서 지터 문제가 여전히 발생하는 경우 음성 품질이 허용될 때까지 조각화 값을 한 번에 하나씩 낮춥니다.
대기열 처리
이 유형의 환경에서는 일반적으로 VoIP 트래픽에 사용되는 두 가지 대기열 처리 방법이 있습니다.
한 가지 방법 또는 다른 방법을 사용해야 하며 둘 다 구성해서는 안 됩니다.문서에 따라 대기열 작업이 올바르게 표시되면 대기열 처리가 제대로 작동하고 문제가 다른 곳에 있음을 확인할 수 있습니다.큐잉은 일반적으로 지터의 원인이 아닙니다. 큐잉이 만든 지연 편차가 상대적으로 작기 때문입니다.그러나 VoIP 패킷이 올바르게 대기열에 추가되지 않고 동일한 회로에 데이터가 있는 경우 지터가 발생할 수 있습니다.
결론
지터는 음성 패킷의 패킷 레이턴시의 변수입니다.라우터 내의 DSP는 일부 지터를 보충할 수 있지만 과도한 지터에 의해 극복할 수 있습니다.이로 인해 음성 품질이 저하됩니다.지터의 원인은 패킷이 회로의 어느 곳에서 대기되거나 지연되며, 다른 패킷에 대한 지연 또는 큐잉이 없는 것입니다.이로 인해 레이턴시가 변합니다.지터는 라우터 컨피그레이션 오류와 캐리어 또는 공급자의 PVC 컨피그레이션 오류 모두로 인해 발생할 수 있습니다.
피드백