BiTel

Скажиет как можно посмотреть почему постоянно растет Waiting connections.
Как отключаем авторизацию - значение перестает расти.
Что интересно в минуту всего несколько авторизаций и reject ни одного.

Мы выяснили почему так происходит.
Оказывается процес радиуса слушает запросы и если приходит запрос типа
Type=AUTHENTICATION_REQUEST
где присутствуют поля
Called-Station-Id=
Тогда Радиус помещает его в память и пишет порядковый номер Waiting connection
Далее когда приходит Accounting stop пакет, система освобождает память Waiting connection и помещает звонок в базу.

Тогда возникает вопрос сколько времени радиус держит запрос в памяти до того как придет Accounting stop?
И что может случиться если запросы приходят, но Accounting stop не приходят так как например звонок не установлен и соответственно нечего посылать радиус оборудованию - а из-за этого постоянно растут записи в памяти Радиус сервера

Держит 2*максимально возможная длительность звонка (есть в конфиге).

Вы имеете ввиду вот эту запись
#максимальная длительность сессии
voip.max.time=1800

Но при такой записи возникает другая проблема. Например карточным абонентам радиус говорит что они могут разговаривать не более 30 минут, даже если у них гораздо больше времени - так как радиус посылает значение значение h323-credit-time=3600.

если поставить voip.max.time=7200 то растет значение Waiting connection которая забирает память.

Может быть можно где-нибудь задавать значение сколько держать Waiting connection, а то смена voip.max.tim влияет на другие вещи.

Сессия лежит ровно до стоп пакета, а потом удаляется. Лежит указанное мною время только если была успешная авторизация а стопа всё нет.
Такого при нормальной работе не должно быть вообще.. Изучите, что за авторизации идут.

Да так оно и есть, авторизация проходит успешно и далее идет звонок и если никто не поднял трубку то stop не приходит.
В оборудовании так и настроено. Это нужно для того чтобы в биллинг не приходили нулевые сессии например при звонке в город.
Например звонок в Город все равно ничего не стоит зачем его учитывать.

Мы вернулись к нашей непонятной ситуации. Никак не можем понять почему растет значение Waiting connection.
Вот логи в которых все приходит правильно, но значение все равно увеличивается
Я не могу понять Почему при данных логах счетчик все равно растет??????

Type=AUTHENTICATION_REQUEST
Attributes:
User-Name=123
User-Password=1235789
NAS-IP-Address=1.1.1.1
NAS-Port=1810
Service-Type=5
Framed-Protocol=1
Calling-Station-Id=123
NAS-Port-Type=0
Called-Station-Id=321
h323-gw-id=2.2.2.2
cisco-avpair=h323-call-id=CD6CBDA4 78A511DF A3C618A9 054181C0
cisco-avpair=h323-gw-address=2.2.2.2
cisco-avpair=xpgk-request-type=route
cisco-avpair=xpgk-src-number-in=123
cisco-avpair=xpgk-dst-number-in=321
cisco-avpair=xpgk-src-number-out=123
cisco-avpair=xpgk-dst-number-out=321
cisco-avpair=xpgk-service-type=Call
h323-conf-id=1AFC560D 8D8C45F5 81F79939 7AF3F361
h323-incoming-connection-ID=CD6CBDA4 78A511DF A3C618A9 054181C0

06-15/23:44:57 INFO [pool-1-thread-2] radius - RESPONSE:
Type=AUTHENTICATION_ACCEPT
Process time auth: 194 common_auth: 139
Attributes:
h323-credit-amount=-462533.88
h323-credit-time=10800
h323-return-code=0

Trace:
Login found.

06-15/23:44:57 INFO [pool-2-thread-3] radius - ACCOUNT:
Type=ACCOUNTING_REQUEST
Attributes:
User-Name=123
NAS-IP-Address=1.1.1.1
NAS-Port=1811
Service-Type=5
Acct-Status-Type=1
Acct-Delay-Time=0
Acct-Session-Id=a42d4149be1b4d9c9cc4ed823e22363d-VoIP
Calling-Station-Id=123
NAS-Port-Type=0
Called-Station-Id=321
h323-gw-id=1.1.1.1
h323-remote-address=3.3.3.3
cisco-avpair=h323-call-id=A42D4149 BE1B4D9C 9CC4ED82 3E22363D
cisco-avpair=h323-remote-id=3.3.3.3
cisco-avpair=h323-gw-address=1.1.1.1
cisco-avpair=xpgk-src-number-in=123
cisco-avpair=xpgk-dst-number-in=321
cisco-avpair=xpgk-src-number-out=123
cisco-avpair=xpgk-dst-number-out=321
cisco-avpair=xpgk-service-type=Call
h323-conf-id=1AFC560D 8D8C45F5 81F79939 7AF3F361
h323-setup-time=17:45:35.820 GMT Tue Jun 15 2010
h323-incoming-connection-ID=CD6CBDA4 78A511DF A3C618A9 054181C0
h323-call-origin=originate
h323-call-type=VoIP

06-15/23:44:57 INFO [pool-2-thread-3] radius - RESPONSE:
Type=ACCOUNTING_RESPONSE
Process time start: 2
Attributes:

06-15/23:45:00 INFO [pool-2-thread-4] radius - ACCOUNT:
Type=ACCOUNTING_REQUEST
Attributes:
User-Name=123
NAS-IP-Address=1.1.1.1
NAS-Port=1811
Service-Type=5
Acct-Input-Octets=0
Acct-Output-Octets=0
Acct-Status-Type=2
Acct-Delay-Time=0
Acct-Session-Time=2
Acct-Input-Packets=0
Acct-Session-Id=a42d4149be1b4d9c9cc4ed823e22363d-VoIP
Acct-Output-Packets=0
NAS-Port-Type=0
Calling-Station-Id=123
Called-Station-Id=321
h323-gw-id=1.1.1.1
h323-voice-quality=0
h323-remote-address=3.3.3.3
h323-disconnect-cause=10
h323-connect-time=17:45:36.616 GMT Tue Jun 15 2010
h323-disconnect-time=17:45:39.041 GMT Tue Jun 15 2010
cisco-avpair=h323-call-id=A42D4149 BE1B4D9C 9CC4ED82 3E22363D
cisco-avpair=h323-remote-id=3.3.3.3
cisco-avpair=h323-gw-address=1.1.1.1
cisco-avpair=xpgk-src-number-in=123
cisco-avpair=xpgk-dst-number-in=321
cisco-avpair=xpgk-src-number-out=123
cisco-avpair=xpgk-dst-number-out=321
cisco-avpair=xpgk-service-type=Call
h323-conf-id=1AFC560D 8D8C45F5 81F79939 7AF3F361
h323-setup-time=17:45:35.870 GMT Tue Jun 15 2010
h323-incoming-connection-ID=CD6CBDA4 78A511DF A3C618A9 054181C0
h323-call-origin=originate
h323-call-type=VoIP

06-15/23:45:00 INFO [pool-2-thread-4] radius - RESPONSE:
Type=ACCOUNTING_RESPONSE
Process time stop: 45

Прошу точнее сказать.
Правильно что система делает проверку только по трем параметрам.
Calling-Station-Id=123
Called-Station-Id=321
h323-gw-id=2.2.2.2
Или идет проверка по еще некоторым параметрам

разработчики скажите почему так происходит.
Что-только не проверяли все равно Waiting не уходит.
Вот если убрать запросы на авторизацию и оставить accounting то Waiting перестает расти.
Непонятно что ему не нравиться.

Прошу ответить.
Может быть проблема в том что в Радиус приходит параметр h323-conf-id с пробелами
У нас вот от железки отправляются таким образом т.е значения идут с пробелом.
h323-conf-id=1AFC560D 8D8C45F5 81F79939 7AF3F361

Хотя нет у Вас по документации в примере этот параметр также идет с пробелами. И Cisco также присылает этот параметр с пробелами.
Что еще может быть?

Да самое главное проблема появляется именно с Мерой.
Не знаю почему другие ничего не пишут но Мера РТУ Центрикс как-то криво передает параметры или биллинг что-то криво обрабатывает
Но в чем проблема не могу понять, да и вы не отвечаете.

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

В общем проблема была в радиусе у нас стоял он от мая месяца.
Последняя версия решила все проблемы