Элтекс

Подключение по схеме:
PRI->SMG1016M->SIP-Call Center

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

Вместе с тем, в CDR записях SMG1016M вижу такие строки:



Отсюда вопрос, что значит "причина разъединения согласно ITU-T Q.850" (SeparationReason=102)?
И как такое могло произойти, учитывая, что вызов был успешно (с точки зрения телефонии) обработан на платформе колцентра?
Проблема к счастью не частая, посмотрел логи CDR, звонков с подобной причиной отбоя не очень много, но они есть.
Хотелось бы понять, у нас что то не так настроено или же есть какая то проблема с аппартаной частью (шлюзом)?

PS
Версия ПО V.2.14.01.652. L. M. Build: Oct 7 2013 09:41:16
Версия SIP-адаптера 2.14.1.61
Время в работе 26d 04hour 09min 34sec
Информация о сборке:
Дата сборки initrd 2013-10-07 09:49:10
Дата сборки filesystem 2013-10-07 09:49:23
Дата сборки filesystem update 2013-10-07 09:49:23

Как такое может проихойти нам могут ответить только трассировки, необходимо PBX_PSTN все уровни =1,
если проблема не частая, то можете сконфигурировать syslog, чтобы не копить большие логи на устройстве.В syslog аналогично выставить все уровни =1

Женя писал(а):Как такое может проихойти нам могут ответить только трассировки, необходимо PBX_PSTN все уровни =1,
если проблема не частая, то можете сконфигурировать syslog, чтобы не копить большие логи на устройстве.В syslog аналогично выставить все уровни =1

Для диагностики действительно нужны данные по всем пунктам?
Просто на сислог сервер пошел довольно большой трафик, если столько всего не нужно, было бы не плохо исключить лишнее.
И еще вопрос, PBX_PSTN все уровни =1 он будет писать в лог на шлюзе или отправлять на syslog сервер? опасаюсь, не переполнилась бы память устройства, при работе с таким объемом логов.

AlexeyMish писал(а):Отсюда вопрос, что значит "причина разъединения согласно ITU-T Q.850" (SeparationReason=102)?

Всё же она не "separation reason", а "disconnect reason".

Код 102 обозначает разъединение вызова по причине истечения таймера. Какого именно сказать без логов невозможно.
Как по SIP так и по PRI какое-то сообщение могло не получить подтверждения.

AlexeyMish писал(а):Для диагностики действительно нужны данные по всем пунктам?
Просто на сислог сервер пошел довольно большой трафик, если столько всего не нужно, было бы не плохо исключить лишнее.

Обычно это минимально необходимый набор трейсов.

Какой у вас средний CPS ?

AlexeyMish писал(а):И еще вопрос, PBX_PSTN все уровни =1 он будет писать в лог на шлюзе или отправлять на syslog сервер? опасаюсь, не переполнилась бы память устройства, при работе с таким объемом логов.

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

что бы получить полные логи, лучше использовать именно syslog.

Понял оставляю все пункты для syslog.

что бы получить полные логи, лучше использовать именно syslog.

Т.е. если включен syslog, pbx_pstn лог не нужен?

Он у меня включен, если не нужен, могу выключить.
CPS как померить не придумал.

> Т.е. если включен syslog, pbx_pstn лог не нужен?

Да не нужен, это одно и тоже, только в одном случае он копит логи у себя, а в другом отправляет на syslog сервер

Пример вызова:
986540 20 10819 Eltex2_ 2013-12-19 21:48:41.000 0 102 uncomplete number 0.0.0.0 trunk-Q931 TrunkGroup_PRI_292_9E1 8432035550 8432035550 none none 172.19.252.59 trunk-SIP TrunkGroup_INF10 2216714 2216714 2013-12-19 21:48:21.000 2013-12-19 21:48:41.000 2013-12-20 01:30:10.500 1

данные с syslog
http://yadi.sk/d/FQ027iR6EcavN

файл конфигурации
http://yadi.sk/d/QD4nykWEEcb3W

Не однозначная проблема.
С одной стороны АТС подключенная по PRI отбиват нас
0x04C2 (from orig), MSG=DISCONNECT:
[cause: Recovery on time expiry (location=user, std=CCITT)]

С другой стороны на сторону SIP мы отправили INVITE и все, нам никаких ответных сообщений по SIP похоже не было, поэтому в присоеденной по PRI АТС истек таймер и она нас отбила.
Можно узнать что происходило в этот момен. что слышал абонент?
Можно ли запустить tcpdump и еще раз отловить пролему?

Отловить проблему не проблема, порядка 20-30 вызовов такого вида в сутки бывает.
Но вот узнать, что слышал абонент уже сложно. Если только звонить и спрашивать, абонента позвонившего нам на сервисный номер и пытаться выяснять.
Дамп снять могу, причем как на шлюзе, так и на сервере телефонии, на сервере куда уходит вызов.
Однако тут другая сложность, писать весь трафик очень накладно, 30-40 тыс вызовов в сутки.
Достаточно будет только сигнального трафика или нужен еще и медиатрафик?