Отсутствие accounting stop на SMG-2016

[Ramzai]

Имеется Сабж
Версия ПО V.3.2.0.1098. L. 2016. Build: Oct 30 2014 17:07:01
Версия SIP-адаптера 3.2.0.62

Заводские параметры:
Модель SMG-2016
Ревизия 1v7

Включил Radius accounting, собираю его в UTM.
На SMG аккаунтинг активирован на транке, на сетевом интерфейсе, создан радиус сервер и профиль.

Так вот на части вызовов SMG не шлёт пакеты Accounting-stop пакеты, Accounting-start всегда отправляются
Вот часть лога, где видно, что SMG собирается сгенерить пакет но его отсылки не происходит.

Jul 14 17:12:36 185.20.76.23 <smg1016> 17:12:36.075864 [INFO] Port SIPT:0043. Accounting-stop for 'originate'. Disc-cause-local: 1
Jul 14 17:12:36 185.20.76.23 <smg1016> 17:12:36.075940 [INFO] Port SIPT:0043. Prepare RADIUS Acct Request.
Jul 14 17:12:36 185.20.76.23 <smg1016> 17:12:36.076018 [INFO] Port SIPT:0043. Process modifiers for RADIUS. ModTable: in [-1:-1], out [-1:-1]
Jul 14 17:12:36 185.20.76.23 <smg1016> 17:12:36.076098 [INFO] Port SIPT:0043. RADIUS Acct-Request: cld <495XXXXXXX>, clg <84957777771>
Jul 14 17:12:36 185.20.76.23 <smg1016> 17:12:36.076307 [INFO] Port SIPT:0043. Save CDR. enabled. [0x3]
Jul 14 17:12:36 185.20.76.23 <smg1016> 17:12:36.076336 [INFO] Port SIPT:0043. Process RADIUS Acct-Request. ID [218]
Jul 14 17:12:36 185.20.76.23 <smg1016> 17:12:36.076399 [INFO] Port SIPT:0043. Release peer 'SS7:03:30', cause 'Normal call clearing', dcl '1', loc '0'
Jul 14 17:12:36 185.20.76.23 <smg1016> 17:12:36.076440 [ERR ] RADIUS: failed to send Acct-Req!
Jul 14 17:12:36 185.20.76.23 <smg1016> 17:12:36.076482 [INFO] Port SS7:03:30. Disconnect from SIPT:0043, cause 'Normal call clearing', dcl '1', loc '0'
Jul 14 17:12:36 185.20.76.23 <smg1016> 17:12:36.076510 [INFO] Port SIPT:0043. Process modifiers for CDR. ModTable: in [255:255], out [255:255]
Jul 14 17:12:36 185.20.76.23 <smg1016> 17:12:36.076611 [INFO] Port SS7:03:30. Disconnect, cause 'Normal call clearing', dcl '1', loc '0'
Jul 14 17:12:36 185.20.76.23 <smg1016> 17:12:36.076670 [INFO] Port SIPT:0043. Search Modifier at 'incoming CDR' for 'calling'. ModTable[255] Num <495XXXXXXX> len [10].
Jul 14 17:12:36 185.20.76.23 <smg1016> 17:12:36.076691 [INFO] Port SS7:03:30. SormRelease in state 'Talk'. Flg: 0
Jul 14 17:12:36 185.20.76.23 <smg1016> 17:12:36.076800 [INFO] Port SIPT:0043. Accounting-stop for 'originate'. Disc-cause-local: 1
Jul 14 17:12:36 185.20.76.23 <smg1016> 17:12:36.076803 [INFO] Port SIPT:0043. Search Modifier at 'incoming CDR' for 'calling'. Result: modifier [-5]

Кто-то сталкивался с подобной проблемой? При этом текстовые файлы CDR создаются без проблем, с верными данными

[Женя]

Не было ли проблем со связью с радиус сервером?
можете более полный трейс звонка прислать?

[Ramzai]

Отсутствий связи нет. Проблема в том, что Элтепкс его даже не генерит!
Причём SMG не генерит stop пакет как-то выборочно, не для всех вызовов.
Это видно из трейса (start генерится, stop нет я не приложил эту часть трейса, а только ту где видна проблема) и из tcpdump на SMG

[Fluke]

Отсутствий связи нет. Проблема в том, что Элтепкс его даже не генерит!
Причём SMG не генерит stop пакет как-то выборочно, не для всех вызовов.
Это видно из трейса (start генерится, stop нет я не приложил эту часть трейса, а только ту где видна проблема) и из tcpdump на SMG

Обновите на новую прошивку!!! У нас такая проблема была на этой версии. Сейчас у нас 3.2.1 и этих проблем нет.

[Ramzai]

Отсутствий связи нет. Проблема в том, что Элтепкс его даже не генерит!
Причём SMG не генерит stop пакет как-то выборочно, не для всех вызовов.
Это видно из трейса (start генерится, stop нет я не приложил эту часть трейса, а только ту где видна проблема) и из tcpdump на SMG

Обновите на новую прошивку!!! У нас такая проблема была на этой версии. Сейчас у нас 3.2.1 и этих проблем нет.

Благодарю, отпишусь о результатах.
Переход на новую прошивку прошёл без проблем?

[Fluke]

Отсутствий связи нет. Проблема в том, что Элтепкс его даже не генерит!
Причём SMG не генерит stop пакет как-то выборочно, не для всех вызовов.
Это видно из трейса (start генерится, stop нет я не приложил эту часть трейса, а только ту где видна проблема) и из tcpdump на SMG

Обновите на новую прошивку!!! У нас такая проблема была на этой версии. Сейчас у нас 3.2.1 и этих проблем нет.

Благодарю, отпишусь о результатах.
Переход на новую прошивку прошёл без проблем?

Переход был без проблем. Предварительно рекомендую перезагрузить SMG и без нагрузки выполнить обновление

[Ramzai]

Установил последнюю версию прошивки.
Заметил, что если делать звонок длительностью где-то до 3 секунд то SMG не генерит acсounting stop пакет!

[Fluke]

Установил последнюю версию прошивки.
Заметил, что если делать звонок длительностью где-то до 3 секунд то SMG не генерит acсounting stop пакет!

Видимо вы установили версию прошивки 3.3.1. Ничего по ней сказать не могу.
У нас версия 3.2.1, и проблем нет с RADIUS Accounting

[Женя]

Вас проблемы либо с сервером RADIUS либо с транспортом,
судя по логу при ответе абонента от SMG уходит accounting start пакет, на который SMG не получает подтверждение от сервера (Accounting-response), затем через 700 мс (как настроено в конфигурации) отправляется перепосылка этого accounting start пакета, на который так же нет подтверждения от сервера, после этого SMG считает что сервере недоступен и ничего не шлет на него в течении таймера "Время неиспользования сервера при сбое (сек)" который у Вас = 10 сек, поэтому если произошел отбой перед истечением этого таймера accounting stop не отправляется, SMG тут отработало правильно.
Radius протокол предполагает что на любой request должен быть response. Нужно смотреть на сервер, почему он не шлет response.

[Ramzai]

Благодарю за помощь в решении
Проблема действительно была в неприходе Accounting Response пакетов на SMG. Стыдновато, конечно, за такой прокол.