Голосовая связь : H.323

Основы устранения неполадок и отладки вызовов по протоколу VoIP

5 апреля 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Перевод, выполненный профессиональным переводчиком (23 марта 2008) | Английский (22 августа 2015) | Отзыв


Содержание


Введение

В этом документе демонстрируются основные приемы и команды для устранения неполадок и отладки сетей VoIP. Представлен общий обзор потока голосового вызова и архитектуры телефонии в маршрутизаторе Cisco, а также пошаговый подход к устранению неполадок Cisco, описанный в нескольких пунктах:

  1. Проверка цифровой и аналоговой сигнализации.

  2. Проверка цифр, полученных и отправленных с аналоговых и цифровых голосовых портов.

  3. Проверка сквозной передачи сигналов VoIP.

  4. Сведения об ошибках качества обслуживания (QoS) VoIP.

  5. Данные кодов причины и значений отладки для VoIP.

Примечание: Этот документ не объясняет каждый фасет Cisco архитектура IOS�, используемая в VOIP - шлюзах Cisco и сторожевых устройствах. Он предназначен для объяснения того, какие команды могут использоваться и какие поля из выходных данных команд могут иметь наибольшее значение.

caution  Внимание:отладка Cisco IOS может вызвать сильную нагрузку на процессор. Будьте внимательны при использовании процедур отладки, приведенных в этом документе. Для получения дополнительных сведений обратитесь к разделу "Важные сведения о командах отладки".

Процедуры отладки необходимо запускать со включенными в журнале метками времени. Включите установку штампа времени, добавив следующие команды: service timestamps debug datetime msec, service timestamps log datetime msec в режиме enable. Метки времени помогают определить интервал времени между изменениями состояния.

Предварительные условия

Требования

Этот документ предназначен для специалистов по обслуживанию сети, вовлеченных в дизайн и развертывания Сетей VoIP. Читатели этого документа должны знать следующее:

  • Конфигурация VoIP

  • Качество обслуживания голосовой связи

Используемые компоненты

Настоящий документ не имеет жесткой привязки к каким-либо конкретным версиям программного обеспечения и оборудования. Однако показанные выходные данные основываются на Cisco Выпуск ПО IOS� 12.3 (8).

Сведения, представленные в этом документе, были получены от устройств в специфической лабораторной среде. Все устройства, используемые в этом документе, были запущены с чистой конфигурацией (конфигурацией по умолчанию). При работе с реальной сетью необходимо полностью осознавать возможные результаты использования всех команд.

Условные обозначения

Дополнительные сведения об условных обозначениях см. в документе Технические рекомендации Cisco. Условные обозначения.

Поток вызовов в сети

Важным фактором, который надо учитывать до начала любого устранения неполадок VoIP или отладки, является то, что соединения VoIP состоят из трех участков. Этими тремя участками соединения являются исходная обычная телефонная сеть (POTS), VoIP и POTS назначения. Это показано на следующем рисунке. Устранение неполадок и отладка должны быть нацелены сначала отдельно на каждый участок, а затем на все соединение VoIP в целом.

/image/gif/paws/14081/call-legs.gif

Поток вызова маршрутизатора

/image/gif/paws/14081/call-flow.gif

В данных определениях объясняются функции главных компонентов, показанных на диаграмме потока вызова маршрутизатора:

API-интерфейс контроля вызововAPI-интерфейс контроля вызовов используется тремя клиентами. Это интерфейс командной строки, агент SNMP и приложение сеанса. Главными функциями API-интерфейса контроля вызовов (CCAPI) являются:

  • Идентификация участков вызова (например какая это точка вызова, откуда это соединение)?).

  • Принятие решения о том, какое приложение сеанса примет вызов (например кто его будет обрабатывать)?).

  • Вызов обработчика пакетов.

  • Общая обработка всех ветвей вызова.

  • Начало записи статистики вызовов.

Приложение сеанса и программа сопоставления плана соединенийПриложение сеанса использует программу сопоставления плана соединений для сопоставления номера точке вызова (местной POTS или удаленной VoIP). Программа сопоставления плана соединений использует таблицу одноранговых узлов для поиска активных адресуемых точек вызова.

SPI-интерфейс телефонии и VoIPКомпонент SPI телефонии соединяется с точками вызова POTS (аналоговыми: fxs, fxo, em, цифровыми: isdn, qsig, em и т.д.). SPI VoIP - особый интерфейс для одноранговых узлов VoIP. Драйверы телефонии/DSP обеспечивают доставку услуг к SPI телефонии, в то время как SPI VoIP опирается на протоколы сеанса.

Архитектура интерфейса IP-телефонии

На этой схеме показана архитектура компоновочных блоков телефонии маршрутизатора Cisco и их взаимодействие друг с другом.

telephony-int.gif

Далее описываются функции и даются определения главных компонентов схемы:

  • API-интерфейс контроля вызовов (CCAPI)Элемент программного обеспечения, который устанавливает, завершает и связывает ветви вызова.

  • Поставщик услуг голосовой телефонии (VTSP)Процесс IOS, который обслуживает запросы из API-интерфейса контроля вызовов и формулирует соответствующий запросы к процессору цифровых сигналов (DSP) или к VPM.

  • Модуль голосового процессора (VPM)VPM ответственен за объединение и координирование процессов передачи сигнала между SSM портов телефонии, менеджером ресурсов DSP и VTSP.

  • DSP Resource ManagerDSPRM предоставляет интерфейсы, с помощью которых VTSP может обмениваться сообщениями с DSP.

  • Обработчик пакетовОбработчик пакетов пересылает пакеты между DSP и ветвями одноранговых соединений.

  • Партнер по вызовуПартнер по вызову - это противоположная ветвь вызова. Это может быть другое телефонное голосовое соединение (POTS), соединение VoFR, VoATM или VoIP.

Проверьте цифровую и аналоговую сигнализацию (ветвь вызова POTS)

Целью проверки цифровой и аналоговой сигнализации является:

  • Определить, что принимаются правильные аналоговые или цифровые сигналы подключения и отключения.

  • Убедиться, что на маршрутизаторе и коммутаторе (центральная или офисная АТС) правильно настроена сигнализация EM, FXO и FXS.

  • Убедитесь, что DSP находятся в режиме сбора цифровых данных.

Подчеркнутые команды из этого раздела могут использоваться для проверки сигнализации.

show controllers T1 / E1 (digital)

show controllers t1 [слот/порт] — Использование эта команда сначала. Она показывает, установлено или нет цифровое соединение 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

show voice port slot-number/port — Использование эта команда для показа состояния порта и параметров, настроенных на голосовом порту голосовых интерфейсных карт (VIC) Cisco. Как и во всех командах IOS, параметры по умолчанию не отображаются в выходных данных show running-config, но отображаются с помощью этой команды.

Это пример выходных данных для голосового порта EM:

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

debug vpm (модуль голосового процессора)

Эти команды используются для отладки Телефонного интерфейса VPM:

  • debug vpm signal — Эта команда используется для сбора отладочной информации для событий сигнализации и может быть полезной в решении проблем с сигнализацией к УАТС.

  • debug vpm spi — Эта команда отслеживает, как интерфейс поставщика услуг (SPI) модуля голосового порта взаимодействует с API управления вызовами. Данная команда отладки выводит на экран сведения об обработке запросов индикации и приложений сети.

  • debug vpm dsp — Эта команда сообщения показов от DSP на VPM к маршрутизатору и может быть полезной, если вы подозреваете, что VPM не функционален. Это - простой путь, чтобы проверить, отвечает ли VPM на индикации со снятой трубкой и оценить синхронизацию для сообщений о передаче сигнала от интерфейса.

  • debug vpm all — Эта команда EXEC включает все команды debug vpm: debug vpm spi, debug vpm signal и debug vpm dsp.

  • debug vpm port — Используйте эту команду для ограничения выходных данных отладки определенным портом. Например, в данном примере показан вывод сообщений debug vpm dsp только для порта 1/0/0:

    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

Если в состоянии подключения и отключения сигнализация происходит неправильно, проверьте следующее:

  • Проверьте подключение кабеля.

  • Проверьте заземление маршрутизатора и коммутатора (центральная или офисная АТС).

  • Убедитесь в том, что конечные точки соединения имеют соответствующие настройки сигнализации. Несоответствующие конфигурации могут вызывать неполную или одностороннюю сигнализацию.

Подробнее об устранении неполадок EM см. Общие сведения и устранение неполадок аналоговых интерфейсов 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

Проверьте цифры полученных и отправленных данных (по ветвях звонков POTS)

После того как сигнализация подключения и отключения проверена и работает правильно, убедитесь в том, что на голосовой порт (цифровой или аналоговый) принимаются и отправляются правильные цифры. Если принимаются или отправляются неправильные цифры, точка вызова может не согласовываться, а коммутатор (центральная или офисная АТС) может не соединяться с нужной станцией. Некоторые команды, которые можно использовать для проверки полученных/отправленных цифр:

  • show dialplan number команда используется для показа, какая точка вызова достигнута, когда набран конкретный телефонный номер.

  • debug vtsp session команда отображает информацию о том, как каждая индикация сети и запрос приложения обработаны, индикации сигнализации и управляющие сообщения DSP.

  • debug vtsp dsp — Ранее, чем программное обеспечение Cisco IOS версии 12.3, эта команда отображает цифры, поскольку они получены голосовым портом. Однако в программном обеспечении Cisco IOS релиз 12.3 и более поздние выходные данные команды debug больше не показывают цифры. Комбинация подробности debug hpi и уведомления debug hpi может использоваться для наблюдения входящих знаков.

  • debug vtsp all команда выполняет эти команды поставщика службы голосовой телефонии (VTSP) отладки: debug vtsp session, debug vtsp error и debug vtsp dsp.

Подробнее см. Команды отладки VoIP.

show dialplan number

show dialplan number <digit_string> — Эта команда отображает точку вызова, с которой совпадает строка цифр. Если могут быть сопоставлены несколько точек вызова, они показываются все, в том порядке, в котором были сопоставлены.

Примечание: Необходимо использовать знак # в конце номеров телефона для точек вызова с переменной длиной для соответствия на destination-pattern с тем концом с 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

Команда debug vtsp session показывает информацию о том, как маршрутизатор взаимодействует с DSP на основе индикаций сигнализации от стека сигналов и запрашивает из приложения. Эта команда отладки отображает информацию о том, как каждая индикация сети и запрос приложения обрабатываются, индикации сигнализации и управляющие сообщения 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, чтобы проверить, что цифры передаются в правильной частоте и рассчитывающей интервал. Если они "неправильно" отправляются для коммутатора (центральная или офисная АТС), некоторые значения маршрутизатора или коммутатора (центральная или офисная АТС), возможно, потребуется их скорректировать, чтобы они согласовывались и были совместимы. Обычно это значения длительности цифры и интервала между цифрами. Необходимо также проверить, не являются ли цифры, которые отправляются как будто правильно, какими-либо таблицами трансляции номеров в коммутаторе (центральная или офисная АТС), которые могут добавлять или удалять цифры.

Проверьте передачу сигналов по сквозному IP протоколу (участок вызова передачи голоса по IP протоколу)

После того, как вы убедитесь, что сигнализация голосового порта работает правильно и принимаются правильные цифры, переходите к устранению неполадок и отладке управления вызовами VoIP. Следующие факторы объясняют, почему отладка управления вызовами может оказаться сложной работой:

  • Шлюзы Cisco VoIP для выполнения вызовов используют сигнализацию H.323. H.323 состоит из трех уровней согласования вызовов и установления вызовов: H.225, H.245 и H.323. Эти протоколы используют сочетание TCP и UDP для установления и организации вызова.

  • Отладка сквозного VoIP показывает число конечных автоматов IOS. Проблемы с любым из конечных автоматов могут вызвать обрыв соединения.

  • Отладка сквозного VoIP может оказаться очень многословной и произвести большой объем выходных данных отладки.

debug voip ccapi inout

Основная команда для отладки сквозных вызовов 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.225 или H.245 TCP, а не просто на UDP-часть установки H.323. Команды, которые можно использовать для отладки настройки вызова H.225 или H.245, приведены ниже:

  • debug ip tcp transactions и debug ip tcp packet эти команды проверяют TCP-часть согласования H.225 и H.245. Они возвращают IP-адреса, порты TCP и состояния TCP - подключений.

  • debug cch323 h225 — Эта команда исследует часть H.225 согласования вызова и отслеживает изменение состояния механизма состояний H.225 на основе обработанного события. Думайте об этом как о части Уровня 1 трех настроек вызова части H.323.

  • debug cch323 h245 — Эта команда исследует часть H.245 согласования вызова и отслеживает изменение состояния механизма состояний H.245 на основе обработанных событий. Это можно представить как часть "уровень 2" из трех частей установки звонка Н.323.

Сведения об ошибках качества обслуживания (QoS) VoIP

После того как все проблемы с вызовами VoIP должным образом решены, необходимо убедиться в качестве передаваемого голосового сигнала. Хотя в данном документе не описывается устранение неполадок, связанных с качеством обслуживания, данные инструкции следует учитывать при работе над хорошим качеством передачи голоса:

  • Следует выяснить ширину полосы пропускания, которую вызов VoIP задействует с каждым из кодеков. Это включает заголовки уровня 2 и IP/UDP/RTP. Дополнительные сведения см. в разделе "IP-телефония: использование полосы пропускания для каждого вызова".

  • Следует выяснить характеристики IP-сети, через которую передается вызов. Например, полоса пропускания в сети frame-relay при согласованной скорости передачи данных (CIR) сильно отличается от полосы при скорости выше CIR (или при всплеске), когда пакеты могут отбрасываться или скапливаться в облаке Frame-Relay. Убедитесь, что задержка и помехи контролируются и устраняются, насколько это возможно. Задержка передачи по одному направлению не должна превышать 150 мс (по рекомендациям G.114).

  • Используйте метод очереди, который позволяет идентифицировать трафик VoIP и устанавливать в нем приоритеты.

  • При передаче VoIP по низкоскоростным каналам помните о возможности использования методов фрагментации пакетов уровня 2, таких как MLPPP с фрагментацией чередования каналов (LFI), в каналах точка-точка или FRF.12 в каналах Frame-Relay. Фрагментация пакетов данных большого размера позволяет снизить объем помех и задержки при передаче трафика VoIP, так как выполняется чередование пакетов в канале.

  • Попытайтесь использовать разные кодеки и произвести вызов со включенным и выключенным VAD, чтобы по возможности уменьшить вывод в DSP, в отличие от IP-сети.

При наличии VoIP, устраняя неполадки QoS, следует прежде всего искать отброшенные пакеты и критические места сети, которые могут вызвать задержки и дрожание.

Ищите:

  • интерфейсные отбрасывания

  • сбросы буфера

  • перегрузка интерфейса

  • перегрузка канала

Каждый интерфейс в пути вызова VoIP должен быть исследован. Необходимо также устранить сбросы и перегрузки. Двухсторонняя задержка должна быть уменьшена настолько, насколько это возможно. Двухстороннюю задержку канала можно определить при помощи команд ping, посылающих пакеты между конечными точками VoIP. Когда это возможно, двухсторонняя задержка не должна превышать 300 мс. Если задержка вынужденным образом превышает это значение, следует предпринять усилия и убедиться в том, что она постоянна и не вносит помехи или переменную задержку.

Следует также выполнить проверку, чтобы убедиться, что механизм IOS формирования очереди размещает пакеты VoIP в правильной очереди. В проверке формирования очереди могут помочь такие команды IOS, как show queue interface или show priority.

Данные кодов причины и значений отладки для VoIP

Используйте данные таблицы при чтении процедур отладки и соответствующих значений в процессе отладки.

Q.931 Причины отключения вызова (коды_причин из debug voip ccapi inout)

Для получения дополнительной информации о Кодах причин Q.931 и Значениях, обратитесь к Типам коммутатора ISDN, Кодам и Значениям

Значение причины отключения вызова (в шестнадцатеричной системе) Значение и номер (в десятичных числах)
CC_CAUSE_UANUM = 0x1 /* неназначенный номер. (1)
CC_CAUSE_NO_ROUTE = 0x3 /* нет маршрута к пункту назначения. (3)
CC_CAUSE_NORM = 0x10 обычный сброс вызова. (16)
CC_CAUSE_BUSY = 0x11 user-Busy; . (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 для использования корректного кодека.

Значения согласования кодека (из debug voip ccapi inout)

Для получения дополнительной информации о 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=0x00000010 G726r16
codec=0x00000020 G726r24
codec=0x00000040 G726r32
codec=0x00000080 G728
codec=0x00000100 G723r63
codec=0x00000200 G723r53
codec=0x00000400 GSMFR
codec=0x00000800 G729b
codec=0x00001000 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 Нулевой тональный сигнал

Значения возможностей FAX-Rate и VAD

Значения Значение
CC_CAP_FAX_NONE 0x1 Факс отключает или не доступный
CC_CAP_FAX_VOICE 0x2 Голосовой вызов
CC_CAP_FAX_144 0x4 14,400 бодов
CC_CAP_FAX_96 0x8 9600 бод
CC_CAP_FAX_72 0x10 7,200 бодов
CC_CAP_FAX_48 0x20 4 800 бит/с
CC_CAP_FAX_24 0x40 2400 бод
CC_CAP_VAD_OFF 0x1 Определение присутствия голосового сигнала (VAD) отключено
CC_CAP_VAD_ON 0x2 VAD включено

Связанные обсуждения сообщества поддержки Cisco

В рамках сообщества поддержки Cisco можно задавать и отвечать на вопросы, обмениваться рекомендациями и совместно работать со своими коллегами.


Дополнительные сведения


Document ID: 14081