이 문서에서는 VoIP 네트워크의 문제 해결 및 디버깅을 위한 기본 기술과 명령을 보여 줍니다. Cisco 라우터의 음성 통화 흐름 및 텔레포니 아키텍처에 대한 개요와 다음 단계에 제시된 단계별 VoIP 문제 해결 방식이 함께 제공됩니다.
참고: 이 문서에서는 Cisco VoIP 게이트웨이 및 게이트키퍼에서 사용되는 Cisco IOS® 아키텍처의 모든 패싯에 대해 설명하지 않습니다. 대신 사용할 수 있는 명령과 명령 출력에서 가장 유용할 수 있는 필드를 표시하도록 합니다.
주의: Cisco IOS 디버깅은 프로세서 집약적일 수 있습니다. 이 문서에 나열된 디버그를 사용할 때는 주의해야 합니다. 자세한 내용은 디버그 명령에 대한 중요 정보를 참조하십시오.
로그에서 타임스탬프를 사용하도록 설정한 상태로 디버그를 실행해야 합니다. 명령을 추가하여 타임스탬프를 활성화합니다. service timestamp debug datetime msec, service timestamp log datetime msec이 활성화 모드에 있습니다. 타임스탬프는 상태 변경 사이의 시간 간격을 결정하는 데 도움이 됩니다.
이 문서는 VoIP 네트워크의 설계 및 구축에 관여하는 네트워킹 담당자를 대상으로 합니다. 이 문서의 독자는 다음 주제에 대해 잘 알고 있어야 합니다.
VoIP 컨피그레이션
음성 QoS
이 문서는 특정 소프트웨어 및 하드웨어 버전으로 한정되지 않습니다. 그러나 표시된 출력은 Cisco IOS® Software Release 12.3(8)을 기반으로 합니다.
이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 라이브 네트워크에서 작업하는 경우, 사용하기 전에 모든 명령의 잠재적인 영향을 이해해야 합니다.
문서 규칙에 대한 자세한 내용은 Cisco 기술 팁 표기 규칙을 참조하십시오.
VoIP 문제 해결 또는 디버깅을 시작하기 전에 고려해야 할 중요한 요소는 VoIP 통화가 3개의 통화 레그로 구성된다는 것입니다. 이러한 통화 레그는 소스 POTS(Plain Old Telephone Systems), VoIP 및 대상 POTS입니다. 이 다이어그램에 나와 있습니다. 문제 해결 및 디버깅은 먼저 각 레그에 개별적으로 그리고 전체적으로 VoIP 통화에 주력해야 합니다.
다음 정의는 라우터 통화 흐름 다이어그램에 표시되는 기본 구성 요소의 기능에 대해 설명합니다.
Call Control API(Application Programming Interface) - 세 개의 클라이언트가 통화 제어 API를 사용합니다. 세 개의 클라이언트는 CLI, SNMP(Simple Network Management Protocol) 에이전트 및 세션 애플리케이션입니다. CCAPI라고도 하는 Call Control API의 주요 기능은 다음과 같습니다.
통화 레그 식별(예: 어떤 다이얼 피어가 통화 레그입니까? 어디서 나온 것입니까?)
통화를 받을 세션 응용 프로그램(예: 통화를 처리하는 사용자)을 결정합니다.
패킷 처리기를 호출합니다.
통화 레그를 함께 컨퍼런스.
통화 통계를 기록하기 시작합니다.
Session Application and Dial Plan Mapper(세션 애플리케이션 및 다이얼 플랜 매퍼) - 세션 애플리케이션은 다이얼 플랜 매퍼를 사용하여 번호를 다이얼 피어(로컬 POTS 또는 원격 VoIP)에 매핑합니다. 다이얼 플랜 매퍼는 다이얼 피어 테이블을 사용하여 활성 다이얼 피어를 찾습니다.
텔레포니 및 VoIP SPI(Service Provider Interface) - 텔레포니 SPI가 POTS와 통신합니다(아날로그: fxs, fxo, e&m 디지털: isdn, qsig, e&m 등) 다이얼 피어 VoIP SPI는 VoIP 피어에 대한 특정 인터페이스입니다. 텔레포니/DSP 드라이버는 텔레포니 SPI에 서비스를 제공하고 VoIP SPI는 세션 프로토콜을 사용합니다.
이 다이어그램은 Cisco 라우터 텔레포니 구성 요소의 아키텍처와 이들이 상호 작용하는 방식을 보여줍니다.
이 목록에서는 기본 다이어그램 구성 요소의 함수 및 정의를 설명합니다.
CCAPI(Call Control Application Programming Interface) - 통화 레그를 설정, 종료 및 브리징하는 소프트웨어 엔티티입니다.
VTSP(Voice Telephony Service Provider) - 통화 제어 API에서 요청을 처리하고 DSP(디지털 신호 프로세서) 또는 VPM에 대한 적절한 요청을 생성하는 IOS 프로세스입니다.
VPM(Voice Processor Module)—VPM은 SSM(Telephony Ports Signaling State Machine), DSP Resource Manager 및 VTSP 간의 신호 처리 및 조정 작업을 담당합니다.
DSP Resource Manager—DSPRM은 VTSP가 DSP에서 메시지를 보내고 받을 수 있는 인터페이스를 제공합니다.
Packet Handler(패킷 처리기) - 패킷 처리기가 DSP와 Peer Call(피어 통화) 레그 간에 패킷을 전달합니다.
통화 피어 - 통화 피어가 반대 통화 레그입니다. 이는 다른 POTS(Telephony Voice Connection), VoFR, VoATM 또는 VoIP 연결이 될 수 있습니다.
디지털 및 아날로그 신호 확인을 위한 목표는 다음과 같습니다.
올바른 온후크 및 오프후크 아날로그 또는 디지털 신호 수신 여부를 확인합니다.
라우터와 스위치(CO 또는 PBX)에 올바른 E&M, FXO 및 FXS 신호 처리가 구성되었는지 확인합니다.
DSP가 숫자 수집 모드에 있는지 확인합니다.
이 섹션에 설명된 명령을 사용하여 신호 처리를 확인할 수 있습니다.
show controllers t1 [slot/port]—이 명령을 먼저 사용합니다. 라우터와 스위치(CO 또는 PBX) 간의 디지털 T1 연결이 작동 또는 중단되었는지, 제대로 작동하는지 보여줍니다. 이 명령의 출력은 다음과 같습니다.
router# show controllers T1 1/0 T1 1/0 is up. Applique type is Channelized T1 Cablelength is short 133 No alarms detected. Framing is ESF, Line Code is B8ZS, Clock Source is Line Primary. Data in current interval (6 seconds elapsed): 0 Line Code Violations, 0 Path Code Violations 0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins 0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs |
E1을 사용하는 경우 show controllers e1 명령을 사용합니다. 자세한 내용은 다음을 참조하십시오.
show voice port slot-number/port—이 명령을 사용하여 Cisco VIC(Voice-Interface Card)의 음성 포트에 구성된 포트 상태 및 매개변수를 표시합니다. 모든 IOS 명령과 마찬가지로 기본값은 show running-config에 표시되지 않지만 이 명령을 사용하면 표시됩니다.
다음은 E&M 음성 포트의 샘플 출력입니다.
router# show voice port 1/0:1 recEive and transMit Slot is 1, Sub-unit is 0, Port is 1 Type of VoicePort is E&M Operation State is DORMANT Administrative State is UP No Interface Down Failure Description is not set Noise Regeneration is enabled Non Linear Processing is enabled Music On Hold Threshold is Set to -38 dBm In Gain is Set to 0 dB Out Attenuation is Set to 0 dB Echo Cancellation is enabled Echo Cancel Coverage is set to 16 ms Connection Mode is normal Connection Number is not set Initial Time Out is set to 10 s Interdigit Time Out is set to 10 s Call-Disconnect Time Out is set to 60 s Region Tone is set for US Voice card specific Info Follows: Out Attenuation is Set to 0 dB Echo Cancellation is enabled Echo Cancel Coverage is set to 16 ms Connection Mode is normal (could be trunk or plar) Connection Number is not set Initial Time Out is set to 10 s Interdigit Time Out is set to 10 s Call-Disconnect Time Out is set to 60 s Region Tone is set for US Voice card specific Info Follows: Signal Type is wink-start Operation Type is 2-wire E&M Type is 1 Dial Type is dtmf In Seizure is inactive Out Seizure is inactive Digit Duration Timing is set to 100 ms InterDigit Duration Timing is set to 100 ms Pulse Rate Timing is set to 10 pulses/second InterDigit Pulse Duration Timing is set to 500 ms Clear Wait Duration Timing is set to 400 ms Wink Wait Duration Timing is set to 200 ms Wink Duration Timing is set to 200 ms Delay Start Timing is set to 300 ms Delay Duration Timing is set to 2000 ms Dial Pulse Min. Delay is set to 140 ms |
다음 명령은 VPM 텔레포니 인터페이스를 디버깅하는 데 사용됩니다.
debug vpm signal—이 명령은 신호 이벤트에 대한 디버그 정보를 수집하는 데 사용되며 PBX에 대한 신호 처리 문제를 해결하는 데 유용할 수 있습니다.
debug vpm spi - 이 명령은 SPI(voice port module service provider interface)가 통화 제어 API와 인터페이스하는 방법을 추적합니다. 이 debug 명령은 각 네트워크 표시 및 애플리케이션 요청이 처리되는 방법에 대한 정보를 표시합니다.
debug vpm dsp - 이 명령은 VPM의 DSP에서 라우터로 보내는 메시지를 표시하며, VPM이 작동하지 않는다고 생각될 경우 유용합니다. VPM이 오프후크 표시에 응답하는지 확인하고 인터페이스에서 신호 메시지를 보내는 시간을 평가하는 간단한 방법입니다.
debug vpm all—이 EXEC 명령은 모든 debug vpm 명령을 활성화합니다. debug vpm spi, debug vpm 신호 및 debug vpm dsp.
debug vpm port—이 명령을 사용하여 디버그 출력을 특정 포트로 제한합니다. 예를 들어 이 출력은 포트 1/0/0에 대한 debug vpm dsp 메시지만 표시합니다.
debug vpm dsp debug vpm port 1/0/0
자세한 내용은 VoIP 디버그 명령을 참조하십시오.
debug vpm signal 명령의 샘플 출력
maui-voip-austin#debug vpm signal !--- FXS port 1/0/0 goes from the "on-hook" to "off-hook" !--- state. htsp_process_event: [1/0/0, 1.2 , 36] fxsls_onhook_offhook htsp_setup_ind *Mar 10 16:08:55.958: htsp_process_event: [1/0/0, 1.3 , 8] !--- Sends ringing alert to the called phone. *Mar 10 16:09:02.410: htsp_process_event: [1/0/0, 1.3 , 10] htsp_alert_notify *Mar 10 16:09:03.378: htsp_process_event: [1/0/0, 1.3 , 11] !--- End of phone call, port goes "on-hook". *Mar 10 16:09:11.966: htsp_process_event: [1/0/0, 1.3 , 6] *Mar 10 16:09:17.218: htsp_process_event: [1/0/0, 1.3 , 28] fxsls_offhook_onhook *Mar 10 16:09:17.370: htsp_process_event: [1/0/0, 1.3 , 41] fxsls_offhook_timer *Mar 10 16:09:17.382: htsp_process_event: [1/0/0, 1.2 , 7] fxsls_onhook_release |
온후크 및 오프후크가 제대로 신호를 보내지 않는 경우 다음 항목을 확인하십시오.
케이블이 올바른지 확인합니다.
라우터와 스위치(CO 또는 PBX)가 모두 제대로 접지되었는지 확인합니다.
연결의 양쪽 끝에 일치하는 신호 구성이 있는지 확인합니다. 구성이 일치하지 않으면 불완전한 신호 또는 단방향 신호 처리가 발생할 수 있습니다.
E&M 문제 해결에 대한 자세한 내용은 아날로그 E & M 인터페이스 유형 및 배선 배열 이해 및 문제 해결을 참조하십시오.
debug vpm spi 명령의 샘플 출력
maui-voip-austin#debug vpm spi Voice Port Module Session debugging is enabled !--- The DSP is put into digit collection mode. *Mar 10 16:48:55.710: dsp_digit_collect_on: [1/0/0] packet_len=20 channel_id=128 packet_id=35 min_inter_delay=290 max_inter_delay=3200 mim_make_time=18 max_make _time=75 min_brake_time=18 max_brake_time=75 |
온후크 및 오프후크 신호 처리가 확인되고 올바르게 작동하면 음성 포트(디지털 또는 아날로그)에서 올바른 숫자가 수신되거나 전송되는지 확인합니다. 다이얼 피어가 일치하지 않거나 불완전하거나 잘못된 숫자를 보내거나 받는 경우 스위치(CO 또는 PBX)에서 올바른 스테이션에 연결할 수 없습니다. 수신/전송된 숫자를 확인하는 데 사용할 수 있는 몇 가지 명령은 다음과 같습니다.
show dialplan number—이 명령은 특정 전화 번호에 전화를 걸 때 어느 다이얼 피어에 도달했는지를 표시하는 데 사용됩니다.
debug vtsp session - 이 명령은 각 네트워크 표시 및 애플리케이션 요청이 처리되는 방식, 신호 표시, DSP 제어 메시지에 대한 정보를 표시합니다.
debug vtsp dsp - Cisco IOS Software 릴리스 12.3 이전 버전에서는 음성 포트에서 수신한 자릿수를 표시합니다. 그러나 Cisco IOS Software Release 12.3 이상에서는 debug 명령의 출력에 숫자가 더 이상 표시되지 않습니다. 디버그 hpi 세부 정보와 디버그 hpi 알림의 조합을 사용하여 수신 숫자를 볼 수 있습니다.
debug vtsp all—이 명령은 다음 VTSP(음성 전화 통신 서비스 공급자) 명령을 활성화합니다. vtsp 세션, 디버그 vtsp 오류 및 디버그 vtsp dsp 디버그.
자세한 내용은 VoIP 디버그 명령을 참조하십시오.
show dialplan number <digit_string>—이 명령은 숫자 문자열로 일치하는 다이얼 피어를 표시합니다. 여러 다이얼 피어가 일치할 수 있는 경우, 모두 일치하는 순서대로 표시됩니다.
참고: T로 끝나는 대상 패턴과 일치시키려면 가변 길이의 다이얼 피어에 대해 전화 번호의 끝에 있는 # 기호를 사용해야 합니다.
이 명령의 출력은 다음과 같습니다.
maui-voip-austin#show dialplan number 5000 Dial string terminator: # Macro Exp.: 5000 VoiceOverIpPeer2 information type = voice, tag = 2, destination-pattern = `5000', answer-address = `', preference=0, group = 2, Admin state is up, Operation state is up, incoming called-number = `', connections/maximum = 0/unlimited, application associated: type = voip, session-target = `ipv4:192.168.10.2', technology prefix: ip precedence = 5, UDP checksum = disabled, session-protocol = cisco, req-qos = best-effort, acc-qos = best-effort, dtmf-relay = cisco-rtp, fax-rate = voice, payload size = 20 bytes codec = g729r8, payload size = 20 bytes, Expect factor = 10, Icpif = 30, signaling-type = cas, VAD = enabled, Poor QOV Trap = disabled, Connect Time = 25630, Charged Units = 0, Successful Calls = 25, Failed Calls = 0, Accepted Calls = 25, Refused Calls = 0, Last Disconnect Cause is "10 ", Last Disconnect Text is "normal call clearing.", Last Setup Time = 84427934. Matched: 5000 Digits: 4 Target: ipv4:192.168.10.2 |
debug vtsp session 명령은 신호 스택의 신호 표시 및 애플리케이션의 요청을 기반으로 라우터가 DSP와 상호 작용하는 방법에 대한 정보를 표시합니다. 이 debug 명령은 각 네트워크 표시 및 애플리케이션 요청이 처리되는 방식, 신호 표시, DSP 제어 메시지에 대한 정보를 표시합니다.
maui-voip-austin#debug vtsp session Voice telephony call control session debugging is on !--- Output is suppressed. !--- ACTION: Caller picked up handset. !--- The DSP is allocated, jitter buffers, VAD !--- thresholds, and signal levels are set. *Mar 10 18:14:22.865: dsp_set_playout: [1/0/0 (69)] packet_len=18 channel_id=1 packet_id=76 mode=1 initial=60 min=4 max=200 fax_nom=300 *Mar 10 18:14:22.865: dsp_echo_canceller_control: [1/0/0 (69)] packet_len=10 channel_id=1 packet_id=66 flags=0x0 *Mar 10 18:14:22.865: dsp_set_gains: [1/0/0 (69)] packet_len=12 channel_id=1 packet_id=91 in_gain=0 out_gain=65506 *Mar 10 18:14:22.865: dsp_vad_enable: [1/0/0 (69)] packet_len=10 channel_id=1 packet_id=78 thresh=-38act_setup_ind_ack *Mar 10 18:14:22.869: dsp_voice_mode: [1/0/0 (69)] packet_len=24 channel_id=1 packet_id=73 coding_type=1 voice_field_size=80 VAD_flag=0 echo_length=64 comfort_noise=1 inband_detect=1 digit_relay=2 AGC_flag=0act_setup_ind_ack(): dsp_dtmf_mod e()act_setup_ind_ack: passthru_mode = 0, no_auto_switchover = 0dsp_dtmf_mode (VTSP_TONE_DTMF_MODE) !--- The DSP is put into "voice mode" and dial-tone is !--- generated. *Mar 10 18:14:22.873: dsp_cp_tone_on: [1/0/0 (69)] packet_len=30 channel_id=1 packet_id=72 tone_id=4 n_freq=2 freq_of_first=350 freq_of_second=440 amp_of_first= 4000 amp_of_second=4000 direction=1 on_time_first=65535 off_time_first=0 on_time _second=65535 off_time_second=0 |
숫자가 제대로 전송되거나 수신되지 않는 것으로 확인되면 숫자-그래버(테스트 도구) 또는 T1 테스터를 사용하여 숫자가 올바른 빈도 및 시간 간격으로 전송되고 있는지 확인해야 합니다. 스위치(CO 또는 PBX)에 대해 "잘못" 전송될 경우, 라우터 또는 스위치(CO 또는 PBX)의 일부 값을 조정해야 서로 일치하고 상호 작용할 수 있습니다. 일반적으로 숫자 기간 및 숫자 간 기간 값입니다. 숫자를 추가하거나 제거할 수 있는 스위치(CO 또는 PBX)의 숫자 변환 테이블이 올바르게 전송되었는지 확인할 또 다른 항목입니다.
음성 포트 시그널링이 제대로 작동하고 올바른 숫자가 수신되었는지 확인한 후 VoIP 통화 제어 문제 해결 및 디버깅으로 이동합니다. 이러한 요인은 통화 제어 디버깅이 복잡한 작업이 될 수 있는 이유를 설명합니다.
Cisco VoIP 게이트웨이는 H.323 신호 처리를 사용하여 통화를 완료합니다. H.323은 통화 협상 및 통화 설정의 세 계층으로 구성됩니다. H.225, H.245 및 H.323. 이러한 프로토콜은 TCP와 UDP의 조합을 사용하여 통화를 설정하고 설정합니다.
엔드 투 엔드 VoIP 디버깅은 여러 IOS 상태 시스템을 보여줍니다. 상태 시스템에 문제가 있으면 통화가 실패할 수 있습니다.
엔드 투 엔드 VoIP 디버깅은 매우 자세한 정보를 제공하고 많은 디버그 출력을 생성할 수 있습니다.
엔드 투 엔드 VoIP 호출을 디버깅하는 기본 명령은 debug voip ccapi inout입니다. 통화 디버그의 출력은 이 출력에 표시됩니다.
!--- Action: A VoIP call is originated through the !--- Telephony SPI (pots leg) to extension 5000. !--- Some output is omitted. maui-voip-austin#debug voip ccapi inout voip ccAPI function enter/exit debugging is on !--- Call leg identification, source peer: Call !--- originated from dial-peer 1 pots !--- (extension 4000). *Mar 15 22:07:11.959: cc_api_call_setup_ind (vdbPtr=0x81B09EFC, callInfo={called=, calling=4000, fdest=0 peer_tag=1}, callID=0x81B628F0) !--- CCAPI invokes the session application. *Mar 15 22:07:11.963: cc_process_call_setup_ind (event=0x81B67E44) handed call to app "SESSION" *Mar 15 22:07:11.963: sess_appl: ev(23=CC_EV_CALL_SETUP_IND), cid(88), disp(0) !--- Allocate call leg identifiers "callid = 0x59" *Mar 15 22:07:11.963: ccCallSetContext (callID=0x58, context=0x81BAF154) *Mar 15 22:07:11.963: ccCallSetupAck (callID=0x58) !--- Instruct VTSP to generate dialtone . *Mar 15 22:07:11.963: ccGenerateTone (callID=0x58 tone=8) !--- VTSP passes digits to CCAPI. *Mar 15 22:07:20.275:cc_api_call_digit_begin (vdbPtr=0x81B09EFC,callID=0x58,digit=5, flags=0x1, timestamp=0xC2E63BB7, expiration=0x0) *Mar 15 22:07:20.279: sess_appl: ev(10=CC_EV_CALL_DIGIT_BEGIN), cid(88), disp(0) *Mar 15 22:07:20.279: ssaTraceSct: cid(88)st(0)oldst(0)cfid(-1)csize(0)in(1)fDest(0) *Mar 15 22:07:20.279: ssaIgnore cid(88), st(0),oldst(0), ev(10) *Mar 15 22:07:20.327: cc_api_call_digit (vdbPtr=0x81B09EFC, callID=0x58, digit=5 , duration=100) *Mar 15 22:07:20.327: sess_appl: ev(9=CC_EV_CALL_DIGIT), cid(88), disp(0) *Mar 15 22:07:20.327: ssaTraceSct: cid(88)st(0)oldst(0)cfid(-1)csize(0)in(1)fDes t(0) *Mar 15 22:07:21.975:cc_api_call_digit_begin (vdbPtr=0x81B09EFC,callID=0x58,digit=0, flags=0x1, timestamp=0xC2E63BB7, expiration=0x0) *Mar 15 22:07:21.979: sess_appl: ev(10=CC_EV_CALL_DIGIT_BEGIN), cid(88), disp(0) *Mar 15 22:07:21.979: ssaTraceSct: cid(88)st(0)oldst(0)cfid(-1)csize(0)in(1)fDes t(0) *Mar 15 22:07:21.979: ssaIgnore cid(88), st(0),oldst(0), ev(10) *Mar 15 22:07:22.075: cc_api_call_digit (vdbPtr=0x81B09EFC, callID=0x58, digit=0 , duration=150) *Mar 15 22:07:22.079: sess_appl: ev(9=CC_EV_CALL_DIGIT), cid(88), disp(0) *Mar 15 22:07:22.079: ssaTraceSct: cid(88)st(0)oldst(0)cfid(-1)csize(0)in(1)fDest(0) *Mar 15 22:07:23.235: cc_api_call_digit_begin (vdbPtr=0x81B09EFC, callID=0x58, dgit=0, flags=0x1, timestamp=0xC2E63BB7, expiration=0x0) *Mar 15 22:07:23.239: sess_appl: ev(10=CC_EV_CALL_DIGIT_BEGIN), cid(88), disp(0) *Mar 15 22:07:23.239: ssaTraceSct: cid(88)st(0)oldst(0)cfid(-1)csize(0)in(1)fDest(0) *Mar 15 22:07:23.239: ssaIgnore cid(88), st(0),oldst(0), ev(10) *Mar 15 22:07:23.335: cc_api_call_digit (vdbPtr=0x81B09EFC, callID=0x58, digit=0 , duration=150) *Mar 15 22:07:23.339: sess_appl: ev(9=CC_EV_CALL_DIGIT), cid(88), disp(0) *Mar 15 22:07:23.339: ssaTraceSct: cid(88)st(0)oldst(0)cfid(-1)csize(0)in(1)fDes t(0) *Mar 15 22:07:25.147: cc_api_call_digit_begin (vdbPtr=0x81B09EFC, callID=0x58, d igit=0, flags=0x1, timestamp=0xC2E63BB7, expiration=0x0) *Mar 15 22:07:25.147: sess_appl: ev(10=CC_EV_CALL_DIGIT_BEGIN), cid(88), disp(0) *Mar 15 22:07:25.147: ssaTraceSct: cid(88)st(0)oldst(0)cfid(-1)csize(0)in(1)fDest(0) *Mar 15 22:07:25.147: ssaIgnore cid(88), st(0),oldst(0), ev(10) *Mar 15 22:07:25.255: cc_api_call_digit (vdbPtr=0x81B09EFC, callID=0x58, digit=0 , duration=160) *Mar 15 22:07:25.259: sess_appl: ev(9=CC_EV_CALL_DIGIT), cid(88), disp(0) *Mar 15 22:07:25.259: ssaTraceSct: cid(88)st(0)oldst(0)cfid(-1)csize(0)in(1)fDest(0) !--- Matched dial-peer 2 voip. Destination number !--- 5000 *Mar 15 22:07:25.259: ssaSetupPeer cid(88) peer list:tag(2) called number(5000) *Mar 15 22:07:25.259: ssaSetupPeer cid(88), destPat(5000), matched(4), prefix(), peer(81C04A10) !--- Continue to call an interface and start the !--- next call leg. *Mar 15 22:07:25.259: ccCallProceeding (callID=0x58, prog_ind=0x0) *Mar 15 22:07:25.259: ccCallSetupRequest (Inbound call = 0x58, outbound peer =2, dest=, params=0x81BAF168 mode=0, *callID=0x81B6DE58) *Mar 15 22:07:25.259: callingNumber=4000, calledNumber=5000, redirectNumber= !--- VoIP call setup. *Mar 15 22:07:25.263: ccIFCallSetupRequest: (vdbPtr=0x81A75558, dest=, callParams={called=5000, calling=4000, fdest=0, voice_peer_tag=2}, mode=0x0) *Mar 15 22:07:25.263: ccCallSetContext (callID=0x59, context=0x81BAF3E4) *Mar 15 22:07:25.375: ccCallAlert (callID=0x58, prog_ind=0x8, sig_ind=0x1) !--- POTS and VoIP call legs are tied together. *Mar 15 22:07:25.375: ccConferenceCreate (confID=0x81B6DEA0, callID1=0x58, callI D2=0x59, tag=0x0) *Mar 15 22:07:25.375: cc_api_bridge_done (confID=0x1E, srcIF=0x81B09EFC, srcCall ID=0x58, dstCallID=0x59, disposition=0, tag=0x0) !--- Exchange capability bitmasks with remote !--- the VoIP gateway !--- (Codec, VAD, VoIP or FAX, FAX-rate, and so forth). *Mar 15 22:07:26.127: cc_api_caps_ind (dstVdbPtr=0x81B09EFC, dstCallId=0x58, src CallId=0x59,caps={codec=0x4, fax_rate=0x2, vad=0x2, modem=0x1 codec_bytes=20, signal_type=0}) !--- Both gateways agree on capabilities. *Mar 15 22:07:26.127: cc_api_caps_ack (dstVdbPtr=0x81B09EFC, dstCallId=0x58, src CallId=0x59, caps={codec=0x4, fax_rate=0x2, vad=0x2, modem=0x1 codec_bytes=20, signal_type=0}) *Mar 15 22:07:26.139: cc_api_caps_ack (dstVdbPtr=0x81A75558, dstCallId=0x59, src CallId=0x58, caps={codec=0x4, fax_rate=0x2, vad=0x2, modem=0x1 codec_bytes=20, signal_type=0}) *Mar 15 22:07:35.259: cc_api_call_digit (vdbPtr=0x81B09EFC, callID=0x58, digit=T , duration=0) *Mar 15 22:07:35.259: sess_appl: ev(9=CC_EV_CALL_DIGIT), cid(88), disp(0) *Mar 15 22:07:35.259: ssaTraceSct: cid(88)st(4)oldst(3)cfid(30)csize(0)in(1) fDest(0)-cid2(89)st2(4)oldst2(1) *Mar 15 22:07:35.399: cc_api_call_connected (vdbPtr=0x81A75558, callID=0x59) *Mar 15 22:07:35.399: sess_appl: ev(8=CC_EV_CALL_CONNECTED), cid(89), disp(0) *Mar 15 22:07:35.399: ssaTraceSct: cid(89)st(4)oldst(1)cfid(30)csize(0)in(0) fDest(0)-cid2(88)st2(4)oldst2(4) !--- VoIP call is connected. *Mar 15 22:07:35.399: ccCallConnect (callID=0x58) !--- VoIP call is disconnected. Cause = 0x10 *Mar 15 23:29:39.530: ccCallDisconnect (callID=0x5B, cause=0x10 tag=0x0) |
통화가 실패하고 그 원인이 통화 설정의 VoIP 부분에 있는 것 같은 경우 H.323 설정의 UDP 부분과 달리 통화 설정의 H.225 또는 H.245 TCP 부분을 확인해야 할 수 있습니다. H.225 또는 H.245 통화 설정을 디버깅하는 데 사용할 수 있는 명령은 다음과 같습니다.
debug ip tcp transactions and debug ip tcp packet - 이 명령은 H.225 및 H.245 협상의 TCP 부분을 검사합니다. IP 주소, TCP 포트 및 TCP 연결의 상태를 반환합니다.
debug cch323 h225 - 이 명령은 통화 협상의 H.225 부분을 검사하고 처리된 이벤트를 기반으로 H.225 상태 시스템의 상태 전환을 추적합니다. 이를 H.323 3부 통화 설정의 레이어 1 부분으로 간주합니다.
debug cch323 h245 - 이 명령은 통화 협상의 H.245 부분을 검사하고 처리된 이벤트를 기반으로 H.245 상태 시스템의 상태 전환을 추적합니다. 이를 H.323 3부 통화 설정의 레이어 2 부분으로 간주합니다.
VoIP 통화가 제대로 설정되면 다음 단계는 음성 품질이 정상인지 확인하는 것입니다. 이 문서에서는 QoS 트러블슈팅에 대해 다루지 않지만, 음성 품질을 개선하기 위해 다음 지침을 고려해야 합니다.
각 코덱에서 VoIP 통화가 소비하는 대역폭의 양을 이해합니다. 여기에는 레이어 2 및 IP/UDP/RTP 헤더가 포함됩니다. 자세한 내용은 Voice over IP - Per Call Bandwidth Consumption을 참조하십시오.
통화가 이동하는 IP 네트워크의 특성을 이해합니다. 예를 들어 CIR에서 프레임 릴레이 네트워크의 대역폭은 Frame-Relay 클라우드에서 패킷을 삭제하거나 대기열에 추가할 수 있는 위 CIR(또는 버스트)과 크게 다릅니다. 지연과 지터가 최대한 제어되고 제거되도록 합니다. 단방향 전송 지연은 150ms(G.114 권장 사항당)를 초과할 수 없습니다.
VoIP 트래픽을 식별하고 우선 순위를 지정할 수 있는 대기열 기술을 사용합니다.
저속 링크를 통해 VoIP를 전송할 때 포인트-투-포인트 링크의 MLPPP(Link Fragmentation and Interleaving) 또는 프레임 릴레이 링크의 FRF.12와 같은 레이어 2 패킷 프래그먼트화 기술을 사용하는 것이 좋습니다. 대규모 데이터 패킷의 단편화를 통해 VoIP 패킷이 링크로 인터리빙될 수 있으므로 VoIP 트래픽 전송의 지터와 지연을 줄일 수 있습니다.
다른 코덱을 사용하고 VAD가 활성화되고 비활성화된 통화를 시도하여 IP 네트워크와 반대로 DSP로 문제를 좁힐 수 있습니다.
VoIP를 사용하면 QoS 문제를 해결할 때 주로 고려해야 할 사항은 지연과 지터를 일으킬 수 있는 패킷 및 네트워크 병목 현상입니다.
대상:
인터페이스 삭제
버퍼 삭제
인터페이스 혼잡
링크 혼잡
VoIP 통화 경로의 각 인터페이스를 검사해야 합니다. 또한, 떨어뜨리거나 혼잡을 없애줍니다. 또한 왕복 지연 시간을 최대한 줄여야 합니다. VoIP 엔드포인트 간의 ping은 링크 왕복 지연을 나타냅니다. 왕복 지연 시간은 가능하면 300ms를 초과할 수 없습니다. 지연이 이 이 값을 초과해야 하는 경우 지터 또는 변수 지연을 발생시키지 않도록 이러한 지연이 일정하게 유지되도록 해야 합니다.
또한 IOS 대기열 메커니즘이 VoIP 패킷을 적절한 대기열에 배치하는지 확인해야 합니다. show queue interface와 같은 IOS 명령은 show priority를 사용하여 대기열 확인을 수행할 수 있습니다.
디버깅 및 디버깅 내의 관련 값을 읽을 때 이 테이블을 사용합니다.
Q.931 원인 코드 및 값에 대한 자세한 내용은 ISDN 스위치 유형, 코드 및 값을 참조하십시오.
통화 연결 해제 원인 값(16진수) | 의미 및 숫자(10진수) |
---|---|
CC_CAUSE_UANUM = 0x1 | 지정되지 않은 번호입니다. (1) |
CC_CAUSE_NO_ROUTE = 0x3 | 목적지에 대한 경로가 없습니다. (3) |
CC_CAUSE_NORM = 0x10 | 일반 통화 지우기 (16) |
CC_CAUSE_BUSY = 0x11 | 사용자 사용 중. (17) |
CC_CAUSE_NORS = 0x12 | 사용자 응답이 없습니다. (18) |
CC_CAUSE_NOAN = 0x13 | 사용자 응답이 없습니다. (19) |
CC_CAUSE_REJECT = 0x15 | 통화가 거부되었습니다. (21) |
CC_CAUSE_INVALID_NUMBER = 0x1C | 잘못된 번호입니다. (28) |
CC_CAUSE_UNSP = 0x1F | 일반, 지정되지 않음 (31) |
CC_CAUSE_NO_CIRCUIT = 0x22 | 회로가 없습니다. (34) |
CC_CAUSE_NO_REQ_CIRCUIT = 0x2C | 요청된 회로가 없습니다. (44) |
CC_CAUSE_NO_RESOURCE = 0x2F | 리소스가 없습니다. (47) 1 |
CC_CAUSE_NOSV = 0x3F | 서비스 또는 옵션을 사용할 수 없거나 지정되지 않았습니다. (63) |
1 이 문제는 H323 설정 내에서 코덱이 일치하지 않아 발생할 수 있으므로 첫 번째 트러블슈팅 단계는 VoIP 다이얼 피어가 올바른 코덱을 사용하도록 하드코딩하는 것입니다.
CODEC에 대한 자세한 내용은 VoIP - 코덱의 이해: 복잡성, 지원, MOS 및 협상.
협상 값 | 의미 |
---|---|
codec=0x00000001 | G711 ULAW 64K PCM |
codec=0x00000002 | G711 ALAW 64K PCM |
codec=0x00000004 | G729 |
codec=0x00000004 | G729IETF |
codec=0x00000008 | G729a |
codec=0x0000010 | G726r16 |
codec=0x0000020 | G726r24 |
codec=0x0000040 | G726r32 |
codec=0x00000080 | G728 |
codec=0x0000100 | G723r63 |
codec=0x0000200 | G723r53 |
codec=0x0000400 | GSMFR |
codec=0x00000800 | G729b |
codec=0x0001000 | G729ab |
codec=0x00002000 | G723ar63 |
codec=0x00004000 | G723ar53 |
codec=0x00008000 | CLEAR_CHANNEL |
톤 유형 | 의미 |
---|---|
CC_TONE_RINGBACK 0x1 | 벨소리 |
CC_TONE_FAX 0x2 | 팩스 신호음 |
CC_TONE_BUSY 0x4 | 통화 중 신호음 |
CC_TONE_DIALTONE 0x8 | 신호음 |
CC_TONE_OOS 0x10 | 서비스 중지 신호음 |
CC_TONE_ADDR_ACK 0x20 | 주소 확인 신호음 |
CC_TONE_DISCONNECT 0x40 | 연결 끊기 신호음 |
CC_TONE_OFF_HOOK_NOTICE 0x80 | 전화기가 꺼져 있음을 나타내는 신호음 |
CC_TONE_OFF_HOOK_ALERT 0x100 | 보다 시급한 버전의 CC_TONE_OFF_HOOK_NOTICE |
CC_TONE_CUSTOM 0x200 | 사용자 지정 신호음 - 사용자 지정 신호음을 지정할 때 사용됩니다. |
CC_TONE_NULL 0x0 | Null 신호음 |
값 | 의미 |
---|---|
CC_CAP_FAX_NONE 0x1 | 팩스 사용 안 함 또는 사용할 수 없음 |
CC_CAP_FAX_VOICE 0x2 | 음성 통화 |
CC_CAP_FAX_144 0x4 | 14,400보드 |
CC_CAP_FAX_96 0x8 | 9,600보드 |
CC_CAP_FAX_72 0x10 | 7,200보드 |
CC_CAP_FAX_48 0x20 | 4,800보드 |
CC_CAP_FAX_24 0x40 | 2,400보드 |
CC_CAP_VAD_OFF 0x1 | VAD 사용 안 함 |
CC_CAP_VAD_ON 0x2 | VAD 사용 |
개정 | 게시 날짜 | 의견 |
---|---|---|
1.0 |
11-Oct-2005 |
최초 릴리스 |