BiTel

Доброго всем времени суток.
достался в наследство настроенный bgbilling(5.1 сборка 480), VOIP(5.1 сборка 148), JDK 1.6.0, ос freebsd 8.1, cisco 5300
До поры, до времени все работало. Как обычно ничего никто не трогал, но почему-то работать перестало. А именно-при запуске, перезапуске сервера, радиуса, файлы connection.log,error.log,radius.out,script.log пустые(размер 0).
В мануале пишут "Если запуск прошёл успешно, в логе connection.log должен вывестись список загруженных NASов, указанных вами в модуле Voip.

В radius.log

11-17/14:20:59 INFO [main] DefaultServerSetup - Init DB connection pools
11-17/14:21:00 INFO [main] DefaultServerSetup - Init trash pools..
11-17/14:21:00 INFO [main] Radius - Starting radius auth_port:1912 acct_port:1913 admin_port:1956
11-17/14:21:00 INFO [main] Radius - Init processor
<------>class: bitel.billing.server.processor.voiceip.VoiceIpProcessor
<------>mid: 1
11-17/14:21:00 INFO [Thread-10] radius - Starting PortListener port=1912|type=AUTH_LISTENER
11-17/14:21:00 INFO [Thread-11] radius - Starting PortListener port=1913|type=ACCOUNT_LISTENER
11-17/14:21:00 INFO [Thread-12] AdminPortListener - Starting AdminPortListener on 1956

radius status

version 5.0 build 192 from 16.07.2010 13:14:22
17.11.2011 14:23:06
Request accounts per minute: 98
Request auths per minute accept: 0; reject: 0
Ignore per minute auth: 0
Waiting connections: 0
Started: 17.11.2011 14:21:00 Uptime: 0 d 00:02:06
Memory total: 32 768 000; max: 238 616 576; free: 7 675 856
Trees in cache: 40
Connections pool to Master status Idle: 20; Active: 0; maxActive: 300; maxIdle: 20

processor.log

11-17/14:21:00 INFO [main] processor - Loading NAS list...
11-17/14:21:00 INFO [main] processor - LOADED NAS: [ NAS-Identifier: as5350; NAS-IP-Address: 192.168.0.3; SECRET: ********* ; Vendor: 9 ]
CONFIG: auth.out=all/all
auth.in=all/all
acct.out=voip/originate
acct.in=voip/answer
service=1
11-17/14:21:00 INFO [main] VoiceIpProcessor - [ NAS-Identifier: as5350; NAS-IP-Address: 192.168.0.3; SECRET: ********* ; Vendor: 9 ] find modes: h323-remote-address=ALIAS User-Name=ALIAS Calling-Station-Id=ALIAS

и вот пример лога звонка

Type=ACCOUNTING_REQUEST
Attributes:
User-Name=85.234.124.2
Event-Timestamp=1321510745
NAS-IP-Address=192.168.0.3
Service-Type=1
Acct-Status-Type=1
Acct-Delay-Time=114
Calling-Station-Id=9834454304
Acct-Session-Id=0C0000000002507F
<AttrCode[151]>=undef
Acct-Authentic=2
Called-Station-Id=73953470915
h323-gw-id=Galaktika.
h323-conf-id=E2D29084 101A11E1 A6EAF95B 707C2039
cisco-avpair=call-id=E2D29084 101A11E1 A6ECF95B 707C2039
cisco-avpair=h323-incoming-conf-id=E2D29084 101A11E1 A6EAF95B 707C2039
cisco-avpair=subscriber=Unknown
cisco-avpair=session-protocol=cisco
cisco-avpair=gw-rxd-cdn=ton:2,npi:1,#:73953470915
cisco-avpair=connect-progress=Call Up
h323-setup-time=15:19:05.938 IRK Thu Nov 17 2011
h323-call-origin=answer
h323-call-type=VoIP

11-17/14:21:00 INFO [pool-2-thread-1] radius - RESPONSE:
Type=ACCOUNTING_RESPONSE
Process time start: 17
Attributes:

еще пример

11-17/14:21:00 INFO [pool-2-thread-3] radius - ACCOUNT:
Type=ACCOUNTING_REQUEST
Attributes:
User-Name=3953400444
NAS-IP-Address=192.168.0.3
Service-Type=1
Acct-Input-Octets=1607543
Acct-Output-Octets=798232
Acct-Status-Type=2
Acct-Delay-Time=26
Acct-Session-Time=121
Acct-Input-Packets=11139
Acct-Session-Id=0C0000000002504C
Acct-Authentic=2
Acct-Output-Packets=6377
Event-Timestamp=1321510833
Calling-Station-Id=3953400444
<AttrCode[151]>=undef
Called-Station-Id=74957847793
h323-gw-id=Galaktika.
h323-voice-quality=0
h323-remote-address=85.234.124.3
h323-disconnect-cause=10
h323-connect-time=15:18:32.765 IRK Thu Nov 17 2011
h323-disconnect-time=15:20:33.827 IRK Thu Nov 17 2011
h323-conf-id=C9C4CA6A 101A11E1 8BED000F 8FCF2254
cisco-avpair=call-id=C9C602BA 101A11E1 A2868EC9 6EB8D23E
cisco-avpair=h323-incoming-conf-id=C9C4CA6A 101A11E1 8BED000F 8FCF2254
cisco-avpair=subscriber=RegularLine
cisco-avpair=session-protocol=cisco
cisco-avpair=gw-rxd-cdn=ton:0,npi:1,#:84957847793
cisco-avpair=release-source=1
cisco-avpair=alert-timepoint=15:18:25.977 IRK Thu Nov 17 2011
cisco-avpair=remote-media-address=85.234.124.3
cisco-avpair=in-trunkgroup-label=2xE1
cisco-avpair=gw-rxd-cgn=ton:0,npi:1,pi:0,si:1,#:400444
cisco-avpair=gw-final-xlated-cdn=ton:0,npi:1,#:74957847793
cisco-avpair=gw-final-xlated-cgn=ton:0,npi:1,pi:0,si:1,#:3953400444
cisco-avpair=charged-units=0
cisco-avpair=disconnect-text=normal call clearing (16)
cisco-avpair=peer-address=74957847793
cisco-avpair=info-type=speech
cisco-avpair=peer-id=84955
cisco-avpair=peer-if-index=538
cisco-avpair=logical-if-index=0
cisco-avpair=codec-bytes=160
cisco-avpair=coder-type-rate=g711alaw
cisco-avpair=ontime-rv-playout=39000
cisco-avpair=remote-udp-port=1720
cisco-avpair=remote-media-udp-port=16398
cisco-avpair=vad-enable=disable
cisco-avpair=receive-delay=150 ms
cisco-avpair=round-trip-delay=0 ms
cisco-avpair=hiwater-playout-delay=155 ms
cisco-avpair=lowater-playout-delay=40 ms
cisco-avpair=gapfill-with-interpolation=20 ms
cisco-avpair=gapfill-with-prediction=0 ms
cisco-avpair=gapfill-with-redundancy=0 ms
cisco-avpair=gapfill-with-silence=40 ms
cisco-avpair=early-packets=474
cisco-avpair=late-packets=7
cisco-avpair=lost-packets=10
h323-setup-time=15:18:23.829 IRK Thu Nov 17 2011
h323-call-origin=originate
h323-call-type=VoIP

11-17/14:21:00 INFO [pool-2-thread-3] radius - RESPONSE:
Type=ACCOUNTING_RESPONSE
Process time stop: 59
Attributes:


Проблема в том что биллинг перестал делить звонки на входящие/исходящие, хотя радиус вроде обрабатывает их правильно.

Сильно не ругайтесь, если что-то сформулировал не так, недавно начал только работать со всем этим "добром".

У меня connection.log, error.log - тоже пустые, это нормально.

radius.out:



script.log допускаю, что будет пустой если нет скриптов

Но это всё неважно.
Как вы определили, что биллинг перестал делить входящие/исходящие?
Вообще звонки пишутся? Как входящие или как исходящие?
Можно пример, когда звонок неправильно определился?

вот radius.out как ни странно у нас тоже пустой..скриптов действительно никаких не используется.

картинки как было в мониторе звонков раньше и как стало сейчас.

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

А в log4j.xml у вас что указано в секции


Если вместо INFO стоит ERROR, то он вам и будет в логи класть только ошибки и никак иначе

_________________
Цитаты великих людей
Напишите в helpdesk © stark
повторяю: => хелпдеск => доработка => профит © dimOn
свершилось... © skn
Мой код изящен, лёгок, оригинален, краток. Как прохладный весенний ветерок, как звонкий ручей! © dimOn
Вежливый разработчик © Artur
Эти баги тоже исправлены, как и те, которые еще не написаны © Artur
ну т.е. существует воркэраунд, ок © dimOn

стоит priority value="INFO"

Хм, все как входящие определяются (или скорее все исходящие не протарифицировались)
Можете показать на вкладке "Типы логинов" открытый тип логина, который у вас используется?
Нужно посмотреть, по какому из режимов:

у вас определяется принадлежность звонка договору

Вообще, можно запустить пересчет за один день - тогда на почту придёт лог ошибок по всем непротарифицировавшимся звонкам.

вот скрин с типов логинов, при чем пробовал разные варианты, ничего не менялось
еще момент-никто ничего не менял и чуть ранее все считалось и работало отлично..

Мм, не могу понять..
Раньше выходит все звонки были исходящими, а стали входящими?
Они все идут на один договор (я так понимаю, учет операторского трафика). На этом договоре алиас какой?
Судя по скриншоту, исходящие привязываются к договору по User-Name. А в логе исходящего звонка User-Name=3953400444. Т.е. алиас такой же должен быть.
Для входящих указано определять по h323-remote-address, а в логе входящего его вообще нет о_О
Может на самом деле по-другому?
Какие в конфиге модуля строчки findmode?
Можете привести логи радиуса до возникновения проблемы?

--10 00:09:16
Type=ACCOUNTING_REQUEST
Attributes:
User-Name=85.234.124.2
NAS-IP-Address=192.168.0.3
Service-Type=1
Acct-Input-Octets=38860
Acct-Output-Octets=34643
Acct-Status-Type=2
Acct-Delay-Time=203
Acct-Session-Time=33
Acct-Input-Packets=1943
Acct-Session-Id=0B0000000037A572
Acct-Output-Packets=1735
Event-Timestamp=1320854752
Calling-Station-Id=9140024222
Called-Station-Id=303000
<AttrCode[151]>=undef
h323-gw-id=Galaktika.
h323-voice-quality=3
h323-remote-address=85.234.124.2
h323-disconnect-cause=10
h323-connect-time=01:05:19.530 IRK Thu Nov 10 2011
h323-disconnect-time=01:05:52.483 IRK Thu Nov 10 2011
h323-conf-id=6F2302E2 0A2311E1 80BFF95B 707C2039
cisco-avpair=call-id=6F2302E2 0A2311E1 80C1F95B 707C2039
cisco-avpair=h323-incoming-conf-id=6F2302E2 0A2311E1 80BFF95B 707C2039
cisco-avpair=subscriber=Unknown
cisco-avpair=session-protocol=cisco
cisco-avpair=gw-rxd-cdn=ton:2,npi:1,#:73953303000
cisco-avpair=release-source=3
cisco-avpair=remote-media-address=85.234.124.2
cisco-avpair=in-trunkgroup-label=smartdial
cisco-avpair=out-trunkgroup-label=2xE1
cisco-avpair=gw-rxd-cgn=ton:2,npi:1,pi:1,si:3,#:9140024222
cisco-avpair=charged-units=0
cisco-avpair=disconnect-text=normal call clearing (16)
cisco-avpair=peer-address=9140024222
cisco-avpair=info-type=speech
cisco-avpair=peer-id=0
cisco-avpair=peer-if-index=0
cisco-avpair=logical-if-index=0
cisco-avpair=codec-bytes=20
cisco-avpair=coder-type-rate=g729r8
cisco-avpair=ontime-rv-playout=29000
cisco-avpair=remote-udp-port=57545
cisco-avpair=remote-media-udp-port=18004
cisco-avpair=vad-enable=enable
cisco-avpair=receive-delay=80 ms
cisco-avpair=round-trip-delay=13 ms
cisco-avpair=hiwater-playout-delay=90 ms
cisco-avpair=lowater-playout-delay=60 ms
cisco-avpair=gapfill-with-interpolation=0 ms
cisco-avpair=gapfill-with-prediction=0 ms
cisco-avpair=gapfill-with-redundancy=0 ms
cisco-avpair=gapfill-with-silence=0 ms
cisco-avpair=early-packets=3
cisco-avpair=late-packets=2
cisco-avpair=lost-packets=2
h323-setup-time=01:05:10.306 IRK Thu Nov 10 2011
h323-call-origin=answer
h323-call-type=VoIP

и вот как выглядела оригинация

10 00:04:07
Type=ACCOUNTING_REQUEST
Attributes:
User-Name=3953346087
NAS-IP-Address=192.168.0.3
Service-Type=1
Acct-Input-Octets=24560
Acct-Output-Octets=24560
Acct-Status-Type=2
Acct-Delay-Time=83
Acct-Session-Time=0
Acct-Input-Packets=1228
Acct-Session-Id=0B0000000037A55B
Acct-Output-Packets=1228
Event-Timestamp=1320854563
Calling-Station-Id=3953346087
Called-Station-Id=79642226044
<AttrCode[151]>=undef
h323-gw-id=Galaktika.
h323-voice-quality=0
h323-remote-address=85.234.124.2
h323-disconnect-cause=10
h323-connect-time=01:02:43.192 IRK Thu Nov 10 2011
h323-disconnect-time=01:02:43.192 IRK Thu Nov 10 2011
h323-conf-id=030A2E4A 0A2311E1 8DC6000F 8FCF2254
cisco-avpair=call-id=030ACA72 0A2311E1 B150EAB1 43799069
cisco-avpair=h323-incoming-conf-id=030A2E4A 0A2311E1 8DC6000F 8FCF2254
cisco-avpair=subscriber=RegularLine
cisco-avpair=session-protocol=cisco
cisco-avpair=gw-rxd-cdn=ton:0,npi:1,#:89642226044
cisco-avpair=release-source=1
cisco-avpair=alert-timepoint=01:02:18.492 IRK Thu Nov 10 2011
cisco-avpair=remote-media-address=85.234.124.2
cisco-avpair=in-trunkgroup-label=2xE1
cisco-avpair=gw-rxd-cgn=ton:0,npi:1,pi:0,si:1,#:346087
cisco-avpair=gw-final-xlated-cdn=ton:0,npi:1,#:79642226044
cisco-avpair=gw-final-xlated-cgn=ton:0,npi:1,pi:0,si:1,#:3953346087
cisco-avpair=charged-units=0
cisco-avpair=disconnect-text=normal call clearing (16)
cisco-avpair=peer-address=79642226044
cisco-avpair=info-type=speech
cisco-avpair=peer-id=796421
cisco-avpair=peer-if-index=400
cisco-avpair=logical-if-index=0
cisco-avpair=codec-bytes=20
cisco-avpair=coder-type-rate=g729r8
cisco-avpair=ontime-rv-playout=13000
cisco-avpair=remote-udp-port=1720
cisco-avpair=remote-media-udp-port=16912
cisco-avpair=vad-enable=disable
cisco-avpair=receive-delay=60 ms
cisco-avpair=round-trip-delay=12 ms
cisco-avpair=hiwater-playout-delay=100 ms
cisco-avpair=lowater-playout-delay=60 ms
cisco-avpair=gapfill-with-interpolation=0 ms
cisco-avpair=gapfill-with-prediction=0 ms
cisco-avpair=gapfill-with-redundancy=0 ms
cisco-avpair=gapfill-with-silence=0 ms
cisco-avpair=early-packets=1
cisco-avpair=late-packets=0
cisco-avpair=lost-packets=0
h323-setup-time=01:02:08.907 IRK Thu Nov 10 2011
h323-call-origin=originate
h323-call-type=VoIP

Ну по текущей конфигурации даже старые логи бы не прошли:
для входящих настроено определять алиас по h323-remote-address, а для исходящих - по User-Name. А в логах - наоборот.
Возможно кто-то поменял конфигурацию уже давно, но не рестартовал сервер например. Потом он однажды перезагрузился и всё сломалось.
Попробуйте поменять местами в типе логина режимы поиска для ACCT OUT и ACCT IN.

во вкладке типы логинов у меня почему-то 2 строчки
тот человек, который работал до меня настраивал все по своему, а когда ушел-ничего не объяснил, сейчас приходится разбираться во всем самому.
В общем менял местами эти параметры, исходящие звонки появились, но не определяется направление как раньше и некоторые звонки начали "множиться", сейчас буду пробовать менять разные авторизации входящих и исходящих

в конфигурации прописана такая штука

findmode.0.title=Поиск по User-Name=LOGIN
findmode.0.value=User-Name=LOGIN
findmode.1.title=Поиск по User-Name=ALIAS
findmode.1.value=User-Name=ALIAS
findmode.2.title=Поиск по Calling-Station-Id=ALIAS
findmode.2.value=Calling-Station-Id=ALIAS
findmode.3.title=Поиск по h323-remote-address
findmode.3.value=h323-remote-address=ALIAS
#
find.order=3,1,2

подскажитеп пожалуйста что нужно прописать для корректного определения входящих исходящих звонков в типах логинов в AUTH OUT, AUTH IN и ACCT OUT, ACCT IN

тему можно закрывать, экспериментальным путем выяснили что для корректного определения входящих/исходящих звонков ставим в AUTH OUT-user name=ALIAS AUTH IN-user name=ALIAS ACCT OUT-h323 -remote adrdess ACCT IN-h323 -remote adrdess.
В результате получили конфигурацию звонков с точностью до наоборот от той что была у нас ранее, то есть выходящие и исходящие поменялись почему-то местами. Решение созрело очень быстро, поменяли в NAS местами вот эти строки acct.out=voip/answer и acct.in=voip/originate.
Итог-все встало на свои места.