Что бы это могло значить....
0 (Valid cause cod not yet recived) - звонок проходит коректно, и isdn error cod вполне коректный приходит, вот только в отчете по телефонии ему присваевается цена 0, направление и зону верно выставляет
Иногда выставляет цену, а иногда нет....
Такое только с дебиткарда происходит. С гейткипера все нормально.
0 (Valid cause cod not yet recived)
С тарифом все нормально.... При одинаковой длительности и одинаковом направлении иногда звонок общитываетсяaospan писал(а):Проверьте как устроен тариф ? Возможно есть время когда стоимость равна 0 ?
Приведите пожалуйста логи радиуса при тарификации таких звонков.
-------------------- Два тестовых звонока --------------
Отчет по телефонии
ftp://ftp.bintel.ru/pub/netup_tt/screen2.jpg
radius_debug.log 37 Кб
ftp://ftp.bintel.ru/pub/netup_tt/radius_debug.log2.txt
radius_main.log 16 Кб
ftp://ftp.bintel.ru/pub/netup_tt/radius_main.log2.txt
debug.log (если вдруг нужно) 70 Кб
ftp://ftp.bintel.ru/pub/netup_tt/debug.log2.txt
select value from tel_sessions_log_attrs; 1,4 Кб
ftp://ftp.bintel.ru/pub/netup_tt/tel_se ... attrs2.txt
Причем раньше у меня все это на freeradius работало и биловалось без проблем
часть pots ложилось в одну таблицу, часть voip в другую (и в старт и в стоп) При этом couse cod одинаков как для pots так и для voip
детальный лог аттрибутов которые приходят с cisco нормальный, а не тот кусочек который пришел в примере с "первым звонком" в utm5_radius
Непонятна строчка вида:
?Debug : Nov 16 14:05:51 RADIUS Acct: No h323_disconnect_cause in packet!
На самом деле она есть.................
Детальный лог аттрибутов с фрирадиуса тому подтверждение, если есть сомнения могу выслать
P.S. То что вышло что состоявшиеся звонки с кауз код 11 (User busy) это так иногда бывает на MTA M200 из-за преобразования CAS2 в PRI (там непонятно откуда ноги ростут). Просьба не обращать внимания
-------------------- Первый тестовый звонок --------------
Отчет по телефонии
ftp://ftp.bintel.ru/pub/netup_tt/screen1.jpg
radius_debug.log 11 Кб
ftp://ftp.bintel.ru/pub/netup_tt/radius_debug.log.txt
radius_main.log 6,3 Кб
ftp://ftp.bintel.ru/pub/netup_tt/radius_main.log.txt
debug.log (если вдруг нужно) 28 Кб
ftp://ftp.bintel.ru/pub/netup_tt/debug.log.txt
select value from tel_sessions_log_attrs; 1,4 Кб
ftp://ftp.bintel.ru/pub/netup_tt/tel_se ... _attrs.txt
Судя по радиус-логу у вас тарификация прошла звонка:
?Debug : Nov 16 14:05:51 RADIUS Tarif: Telephony service <17> free time <0>
Info : Nov 16 14:05:51 UT: session_addon <0>
Info : Nov 16 14:05:51 UT: tel tarification for slink 57, tr_id 1, mult 0.040000, next 1132142417
Info : Nov 16 14:05:51 UT: cost info:
Info : Nov 16 14:05:51 UT: type 0 deny 0 base_cost 1.000000 size 9 tr_id 1 mult 0.040000 added 0 sum 0.000000
?Debug : Nov 16 14:05:51 RADIUS Tarif: UT cost_info sum:0.0060 setup_time <1132142408>
?Debug : Nov 16 14:05:51 RADIUS DBA: VoIP Discount: TR ID 1004914: 0.006 for 9 sec setup_time <1132142408>
?Debug : Nov 16 14:05:51 RADIUS Tarif: UT tkey <1004914> downloaded <9>
?Debug : Nov 16 14:05:51 RADIUS DBA: VoIP calculated cost: 0.006
стоимость должна быть 0.006.
Возможно из-за округления стоимость в отчете не показывается (правда странно, что длительность 0) ? посмотрите в базе какие есть записи на этот звонок ?
Как устроена стоимость в услуге 17 для этого направления (1004914 ?) ?
?Debug : Nov 16 14:05:51 RADIUS Tarif: Telephony service <17> free time <0>
Info : Nov 16 14:05:51 UT: session_addon <0>
Info : Nov 16 14:05:51 UT: tel tarification for slink 57, tr_id 1, mult 0.040000, next 1132142417
Info : Nov 16 14:05:51 UT: cost info:
Info : Nov 16 14:05:51 UT: type 0 deny 0 base_cost 1.000000 size 9 tr_id 1 mult 0.040000 added 0 sum 0.000000
?Debug : Nov 16 14:05:51 RADIUS Tarif: UT cost_info sum:0.0060 setup_time <1132142408>
?Debug : Nov 16 14:05:51 RADIUS DBA: VoIP Discount: TR ID 1004914: 0.006 for 9 sec setup_time <1132142408>
?Debug : Nov 16 14:05:51 RADIUS Tarif: UT tkey <1004914> downloaded <9>
?Debug : Nov 16 14:05:51 RADIUS DBA: VoIP calculated cost: 0.006
стоимость должна быть 0.006.
Возможно из-за округления стоимость в отчете не показывается (правда странно, что длительность 0) ? посмотрите в базе какие есть записи на этот звонок ?
Как устроена стоимость в услуге 17 для этого направления (1004914 ?) ?
странная ситуация выходит....aospan писал(а):Судя по радиус-логу у вас тарификация прошла звонка:
стоимость должна быть 0.006.
Возможно из-за округления стоимость в отчете не показывается (правда странно, что длительность 0) ? посмотрите в базе какие есть записи на этот звонок ?
Как устроена стоимость в услуге 17 для этого направления (1004914 ?) ?
откатился на 15 сборку, вроде как все заработало....
до этого стояла 16ая (базу оставил от 16ой сборки, вроде в логах никаких ошибок нет)
продолжаю тестировать....
услуга 17 на 1004914 направление имеет All Days и цену 0,04 бесплатное время 0, длительность 1 сек, шаг 1 сек, шаг2 1 сек, ед. тарификации 60 сек.
еще раз пробовал на 16ой сборке, даже базу еще раз обновил ....
те же грабли =(
может это как то связанно вот с этим:
Добавлен функционал позволяющий тарифицировать объемы трафика, информацию о которых содержится в Radius Accounting-Stop пакетах. Для включения необходимо добавить в интерфейсе администратора параметр radius_do_accounting. Значение должно быть равно 1.
те же грабли =(
может это как то связанно вот с этим:
Добавлен функционал позволяющий тарифицировать объемы трафика, информацию о которых содержится в Radius Accounting-Stop пакетах. Для включения необходимо добавить в интерфейсе администратора параметр radius_do_accounting. Значение должно быть равно 1.
Очень похожая ситуация.
Есть два сервера. Один тестовый другой рабочий.
На тестовом сервере поднят UTM5-016. На рабочем точно такая же конфигурация.
При направлении аккаунтинга с циски на тестовый сервер все звонки тарифицируются так как надо.
Стоит только переключить циску на рабочий сервер, сразу же все звонки имеют длительность 0. Все направления проставляются верно.
Далее, в настройках радиуса на тестовой машине указываю ядро на рабочем сервере и направляю аккаунтинг на тестовую машину. Все считается нормально.
На рабочем сервере радиус авторизует также пользователей PPPoE.
Как такое может быть, если обе машины различаются только железом и IP-адресом?
Есть два сервера. Один тестовый другой рабочий.
На тестовом сервере поднят UTM5-016. На рабочем точно такая же конфигурация.
При направлении аккаунтинга с циски на тестовый сервер все звонки тарифицируются так как надо.
Стоит только переключить циску на рабочий сервер, сразу же все звонки имеют длительность 0. Все направления проставляются верно.
Далее, в настройках радиуса на тестовой машине указываю ядро на рабочем сервере и направляю аккаунтинг на тестовую машину. Все считается нормально.
На рабочем сервере радиус авторизует также пользователей PPPoE.
Как такое может быть, если обе машины различаются только железом и IP-адресом?
Была такая хрень звонить не мог... Завел номер исходящий в направлениях и всё окей стало.
Да все направления определяются правильно. Есть также Зона, в которой определены все наши телефоны и в тарифах проставлена стоимость 0..
Но еще раз повторюсь.. Что на тестовой машине радиус подключается к ядру на рабочем сервере и все нормально.. Аккаунтинг падает на тестовую машину... Стоит только переключить аккаунтинг на радиус на рабочем сервере - ничего не считается.
Но еще раз повторюсь.. Что на тестовой машине радиус подключается к ядру на рабочем сервере и все нормально.. Аккаунтинг падает на тестовую машину... Стоит только переключить аккаунтинг на радиус на рабочем сервере - ничего не считается.