Случается, что отлаженная связка между 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 в идеальных условиях должен быть равен 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 и им подобным. В каждом конкретном случае методы шутинга будут отличаться.