Непонятная проблема SeparationReason=102. SMG1016M

[AlexeyMish]

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

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

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

Код: Выделить всё

ID   ID_File   Unical   TimeConnection   CallDuration   SeparationReason   ConInfo   InvokeAbon_IP   InvokeAbon_SourceType   InvokeAbon_TruncName   InvokeAbon_InputNumber   InvokeAbon_OutputNumber   InvokeAbon_CategoryInput   InvokeAbon_CategoryOutput   AcceptAbonIP   AcceptAbon_SourceType   AcceptAbon_TruncName   AcceptAbon_InputNumber   AcceptAbon_OutputNumber   CallTimeStart   CallTimeEnd   DT_Create   Enable
897536   9835   Eltex2_   2013-12-16 01:38:38.000   0   102   uncomplete number   0.0.0.0   trunk-Q931   TrunkGroup_PRI_292_6E1   9600363142   9600363142   none   none   172.19.252.59   trunk-SIP   TrunkGroup_INF10   2215800   2215872   2013-12-16 01:38:28.000   2013-12-16 01:38:38.000   2013-12-17 01:29:51.210   1
897540   9835   Eltex2_   2013-12-16 01:39:22.000   0   102   uncomplete number   0.0.0.0   trunk-Q931   TrunkGroup_PRI_292_8E1   9600363142   9600363142   none   none   172.19.252.59   trunk-SIP   TrunkGroup_INF10   2215800   2215872   2013-12-16 01:39:12.000   2013-12-16 01:39:22.000   2013-12-17 01:29:51.217   1

Отсюда вопрос, что значит "причина разъединения согласно 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

[AlexeyMish]

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

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

[Bokrenok]

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

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

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

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

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

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

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

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

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

[AlexeyMish]

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

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

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

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

[Женя]

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

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

[AlexeyMish]

Пример вызова:
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 и еще раз отловить пролему?

[AlexeyMish]

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