Александр Мутовин
22.02.2019
272

Траблшутинг АТС Panasonic в связке с Asterisk

Случается, что отлаженная связка между Asterisk и Panasonic выходит из строя. Поиск проблем требует наличия определённого набора знаний, а так же, обычно, двух специалистов: один со стороны сервера Asterisk, другой со стороны АТС Panasonic KX TDA-200. Вариативность проблем носит необъемлемый характер, потому в рамках данной статьи будет описан конкретный случай. Описание схемы подключения. Описание проблемной […]

Случается, что отлаженная связка между Asterisk и Panasonic выходит из строя. Поиск проблем требует наличия определённого набора знаний, а так же, обычно, двух специалистов: один со стороны сервера Asterisk, другой со стороны АТС Panasonic KX TDA-200. Вариативность проблем носит необъемлемый характер, потому в рамках данной статьи будет описан конкретный случай.

  1. Описание схемы подключения.
  2. Описание проблемной ситуации.
  3. Разбор логов, согласование конфигурации, сбор индикации с Panasonic и Parabell Quasar.
  4. Диагностика серверной платы Parabell Quasar-M х2 port’s.
  5. Рекомендации по траблшутингу.

Описание схемы подключения

Для начала давайте ознакомимся со схемой подключения:

Схема подключения реализована по типу “Транзитный шлюз”. АТС

АТС Panasonic служит аналоговым шлюзом, к которому подключаются аналоговые телефоны в нумерации 1ХХ-4ХХ. Коммутация Asterisk и Panasonic происходит посредством E1 кабеля от Panasonic в серверную плату Parabell Quasar x2 ports. Так же, к Asterisk подключены IP-телефоны с нумерацией 5ХХ. Всей маршрутизацией вызовов занимается Asterisk за исключением случая, при котором абоненты, которые находятся за Panasonic, совершают исходящий вызов.  На Asterisk имеются внешние операторские SIP-линии.

Описание проблемной ситуации

Суть проблемной ситуации в следующем: абоненты 5ХХ не могут звонить на 1ХХ-4ХХ, а абоненты 1ХХ-4ХХ вовсе находятся без связи, за исключением внутренней между собой, т.е. на 5ХХ они не могут дозвониться, но между собой связь есть.

Разбор логов, согласование конфигурации, сбор индикации с Panasonic и Parabell Quasar.

Во время совершения вызовов со стороны Asterisk на Panasonic было следующее:

Ответом Panasonic служит 34 HangupCause, что означает, что Panasonic не может создать канал.

В то время на Panasonic:

QSIG line->PBX   No.3029  Port:1    (elapsed time from LPR reset) 01/01/01 00:58:14
                                 L2: I   SAPI:0 TEI:0
                                 L3:
                                  SETUP  crn:008A (O)
                                    Bearer Capability: 80 90 A3 (Speech  A-Law)
                                    Channel Identity: A1 83 81  (channel=B1 pref.)
                                    Called Party Number: A1 31 30 38
                                       Type of Number= National Number, Numbering Plan= ISDN/Telephony
                                       Number= 108
                                    Sending Complete
                                      00 01 DE DE 08 02 00 8A 05 04 03 80 90 A3 18 03
                                      A1 83 81 70 04 A1 31 30 38 A1
 PBX->QSIG line   No.3030  Port:1    (elapsed time from LPR reset) 01/01/01 00:58:14
 L2: I   SAPI:0 TEI:0
 L3:
  RELEASE COMPLETE  crn:008A (D)
    Cause: 81 A2
       Cause Value= "#34 No channel available"
       Location= "private network serving the local user"
      02 01 DE E0 08 02 80 8A 5A 08 02 81 A2

Аналогичный ответ о том, что ATC не может сформировать канал связи.

Во время совершения обратного вызова с Panasonic на Asterisk, абоненты Panasonic получали сообщение о том, что нет доступных каналов связи.

В то время Asterisk не получал никаких сообщений с противоположной стороны.

Регулярно в лог Asterisk сыпались сообщения о нарушении синхронизации и разрушении канала:

  1. Перегрузка канала синхронизации.
  2. Red Alarm на канале связи, что говорит о его полной неработоспособности, как следствие, потерей связи с Panasonic.
  3. Падение канала синхронизации вследствие перегрузки.
  4. Падение голосовых каналов типа B.

После этого произошло восстановление синхронизации.

Источником синхронизации, а иначе – Master (pri_net) является Asterisk. Стороной, принимающей синхронизацию – Slave (pri_cpe), является Panasonic, обе стороны работали по протоколу ISDN.

Конфигурация драйвера платы Parabell Quasar выглядела следующим образом:

Конфигурация модуля chan_dahdi.so:

Собранная индикация с платы PRI 30 на Panasonic и Parabell Quasar на сервере с Asterisk о проблемах не сообщали:

Asterisk Server

ATC Panasonic

Исходя из вышестоящих фотографий, никаких проблем на физическом уровне не имелось.

Диагностика серверной платы Parabell Quasar-M х2 port’s.

Для диагностики серверной платы. Была использована утилита Dahdi_Tools. Транковая линия Е1 приходила в Span1, т.е. в первый порт.

Данная утилита позволяет производить диагностику платы, установленной в сервер. Производится диагностика каждого модуля. Результативным выводом является наличие тревожных сигналов на конкретной плате, потери платы, потери кабеля.

В примере выше также говорится о том, что проблем нет.

Ничто не указывало на суть проблемы, до тех пор, пока на телефонных станциях не начали менять конфигурацию, а именно, изменили протокол сигналинга на QSIG, после этого в Dahdi_Tool начал изменяться параметр Bipolar Violation, что является плохим признаком.

Bipolar Violation – это сравнение сигналов передачи по модулю. Нарушение правил биполярного кодирования, когда два импульса одинаковой полярности возникают без промежуточного импульса противоположной полярности. Это указывает на ошибку при передаче сигнала.

Данная зацепка говорит о том, что имеется проблема физического характера на противоположной стороне. Проблема с принимающим устройством, либо же плохо обжата приёмная пара.

Параметр Bipolar Violation в идеальных условиях должен быть равен 0, либо всегда одному и тому же значению. Если параметр меняет значение, значит, имеется проблема. Изначально, во время начала траблшутинга, значение было равным нулю, впоследствии же оно менялось следующим образом:

Вначале значение стало равным 241:

Затем359:

В данном случае источником проблемы оказался слот для платы PRI 30 на Panasonic. Плата была переставлена в другой свободный слот, переконфигурирована в полном соответствии с Master-стороной, т.е. Asterisk. Так же у данного экземпляра IP-ATC Panasonic KX TDA-200 было обнаружено, что конфигурация очень медленно считывается с флеш-накопителя, что так же могло стать причиной сбоев.

Рекомендации по траблшутингу.

  1. Чтобы видеть полную информацию о статусе вызова через Е1, используйте команду в консоли Asterisk:

CLI> pri set debug on span1 – span1 – это номер порта, в который приходит поток Е1. Может отличаться от примера. Если присутствуют проблемы при звонках, необходимо смотреть на Cause Codes звонка. Полное описание можно найти в гугле при запросе “ISDN Cause Codes”

  • Для полной диагностики платы пользуйтесь утилитами Dahdi_Tool, Dahdi_Test.

# dahdi_tool – утилита для диагностики серверной платы.

# dahdi_test – утилита для диагностики готовности сервера обрабатывать прерывания платы. Значения 99,9% – норма, всё, что ниже – плохо. Если значение ниже, значит, что у сервера большой износ, либо какое-то устройство пытается работать на одном прерывании с платой.

  • Чтобы узнать, есть ли иные устройства, прерывания которых, конфликтуют с прерываниями платы, используйте:

# cat /proc/interrupts – вывод файла прерываний в терминал.

В идеальных условиях карта должна работать на одном прерывании. При попытке какого-либо устройства работать на том же прерывании, что и карта рекомендуется отключать устройства с тем же прерыванием, в противном случае карта будет плохо работать.

  • В случае, когда Вы конфигурируете драйвер платы system.conf, большое значение имеет параметр crc4. CRC4 – это циклические избыточные коды, которые носят сервисный характер, а именно помогают проверять целостность передаваемой информации. CRC4 опция определяется на стороне оператора связи, либо в случае связки 2 АТС, стороной, которая является источником синхронизации. Если её включить, а оператор связи её не предоставляет, то информация будет искажаться до нечитаемой, возможно возникновение Blue статуса в dahdi_tool, что говорит о том, что канал работает, но его нельзя использовать для связи, потому что невозможно провести декодирование информации. Данная опция должна быть в обязательно порядке согласована с оператором связи.
  • Обращайте внимание на то, кто Вы по отношению к противоположной стороне: Если Вы связываете Asterisk и Panasonic, согласуйте с администратором Panasonic, кто будет источником синхронизации, а кто будет синхронизироваться с источником. Если Вы подключаете многоканальную Е1 линию, предоставляемую оператором связи, то Вы всегда будете синхронизироваться источником, т.е. оператором связи.

В противном случае, в логе Asterisk Вы будете видеть подобного рода сообщения:

Это общие рекомендации к траблшутингу проблем, возникающих в интеграции АТС Asterisk с Panasonic и им подобным. В каждом конкретном случае методы шутинга будут отличаться.

 
avatar
  Подписаться  
Уведомление о

Остались вопросы?

Я - Кондрашин Игорь, менеджер компании Voxlink. Хотите уточнить детали или готовы оставить заявку? Укажите номер телефона, я перезвоню в течение 3-х секунд.

VoIP оборудование

ближайшие курсы

ближайшие Вебинары

ONLINE

Why Choose HUGE?

Unlimited pre-designed elements

Each and every design element is designed for retina ready display on all kind of devices

User friendly interface and design

Each and every design element is designed for retina ready display on all kind of devices

100% editable layered PSD files

Each and every design element is designed for retina ready display on all kind of devices

Created using shape layers

Each and every design element is designed for retina ready display on all kind of devices