Prepaid через радиус.

Kamailio/OpenSIPS и другие производные от SER.

Модераторы: Admins, Модераторы

Ответить
Homer
Сообщения: 41
Зарегистрирован: 24 июл 2009, 12:58

Prepaid через радиус.

Сообщение Homer » 18 янв 2010, 10:51

Схема - Kamailio + Radius + Billing.
Модуль ACC замечательно шлёт аккаунтинг через радиус при начале вызова (INVITE) и при завершении его (BYE), с помощью взвода нужного флага в нужном месте конфига (setflag(1); ).
В начале соединения, после авторизации биллинг по радиусу присылает возможное время разговора которое хранится в переменной AVP и используется модулем DIALOG.
Модуль DIALOG отсчитывает таймер по этому времени и если оно заканчивается то рвет соединение (для этого надо в коде в нужном месте поставить dlg_bye_all(dlg, NULL); ) и отсылает участникам соединения BYE, но т.к. это сообщение (BYE) не проходит конфиг то и аккаунтинг по этому сообщению не отсылается.

Пытался в коде добавить функцию взвода флага прямо в модуле dialog.so но не получается, я в программировании не силён.

Может у кого есть идеи как это реализовать ? Или может это уже както реализованно в Kamailio, а я не увидел ?
Последний раз редактировалось Homer 18 янв 2010, 11:48, всего редактировалось 1 раз.

tma
Сообщения: 361
Зарегистрирован: 11 июл 2005, 17:52
Контактная информация:

Сообщение tma » 18 янв 2010, 11:41

Вообще-то аккауинтинг на SER'е не очень хорошая идея поднимать, т.к. SER никак не контроллирует медиа сессию.
Как Вы авторизацию вызова сделали? У меня что-то не получилось. Я поднимал только аудентификацию. Аккаунтинг у меня на Quintum Call Relay.
Я пытался сделать авторизацию вызова по INVITE, но в результате у меня реагирует на каждый re-INVITE и рвет сессию, если не хватает данных.
Maksim Timofejev

Homer
Сообщения: 41
Зарегистрирован: 24 июл 2009, 12:58

Сообщение Homer » 18 янв 2010, 12:10

SER никак не контроллирует медиа сессию.
- Модуль tm занимается обработкой stateful SIP транзакций (где результат обработки SIP сообщений зависит от состояния диалога). <...> функция - t_relay(). Она инициирует транзакцию и устанавливает ее состояние, контролирует и отбрасывает повторные передачи с upstream, генерирует повторные передачи SIP сообщений для downstream, и сопоставляет SIP ответы соответствующим запросам.
Я пытался сделать авторизацию вызова по INVITE, но в результате у меня реагирует на каждый re-INVITE и рвет сессию, если не хватает данных.
- модуль rr, функция loose_route() - выполняет маршрутизацию SIP запросов, которые содержат набор параметров для маршрутов. <...> Эта функция часто используется, для маршрутизации запросов в пределах диалога (такие, как: ACK, BYE, re-INVITE).

Надеюсь я правильно понял тебя и это поможет ответить на твой вопрос.

tma
Сообщения: 361
Зарегистрирован: 11 июл 2005, 17:52
Контактная информация:

Сообщение tma » 18 янв 2010, 12:22

Спасибо, попробую.
Maksim Timofejev

Homer
Сообщения: 41
Зарегистрирован: 24 июл 2009, 12:58

Сообщение Homer » 20 янв 2010, 08:40

Мой вопрос еще актуален, может хоть подскажите в какую сторону копать ?

ddkprog
Сообщения: 81
Зарегистрирован: 03 июл 2009, 22:09

Сообщение ddkprog » 20 янв 2010, 11:55

а что подсказывать
поставь дебаг
посмотри по каким частям программы бегает вся стейт-машин
и впендюрь в нужное место что то свое

pelingator
Сообщения: 9
Зарегистрирован: 04 янв 2010, 16:10

Сообщение pelingator » 19 фев 2010, 15:42

Homer, а у вас аудентификация работает в радиусе? какая версия радиуса?

Homer
Сообщения: 41
Зарегистрирован: 24 июл 2009, 12:58

Сообщение Homer » 21 фев 2010, 19:08

Регитстрациия пользователей и авторизация Инвайтов просиходит по протоколу RADIUS. В качетстве сервера FreeRADIUS Version 2.0.4, для аккаунтинга используется правда встроенный radius-сервер биллинга (utm5 в качестве тестов используем, т.к. не все нас устраивало в его работе то прикрутили свой радиус сервер к utm таблицам). По мимо стандартных атрибутов в ответе возвращаются нужные нам дополнительные, в utm такого сделать не знаем как.
Kamailio версии 3.0.0

Кстати выше указанную мною проблему решил:
1. в исходниках модуля dialog в момент исхода таймера сессии вызываем функцию dlg_bye_all(dlg, NULL);
2. перед компиляциея модулей делаем это - make EXTRA_DEFS="-DWITH_EVENT_LOCAL_REQUEST" cfg , что в ключает в модуле tm новые фичи.
3. и собсна в конфиги применяем эту новую фичу: (раньше как говорят она называлась local_route)

event_route[tm:local-request] {
xlog("L_INFO", "event_route $rm\n");
if(is_method("BYE")) {
# Account BYE transactions
xlog("L_INFO", "event_received_BYE from $fU to $tU\n\n");
acc_rad_request("Bablo zakonchilos!");
$avp(s:can_uri) = $ru;
};

arcan
Сообщения: 3
Зарегистрирован: 07 мар 2010, 16:27

Сообщение arcan » 07 мар 2010, 16:43

Есть схожая проблема с использованием модуля Opensips - B2BUA.

Как уже было сказано, модуль ACC шлёт аккаунтинг через радиус при начале вызова (INVITE) и при завершении его (BYE), с помощью взвода нужного флага в нужном месте конфига setflag(1)

Модуль B2BUA создавая новое "плечо" (сессия с новым Call-ID) грубо говоря "перехватывает управления на себя", сообщение (BYE) не проходит конфиг и, как следствие, аккаунтинг по этому сообщению не отсылается.

Согласно описанию http://www.opensips.org/Resources/B2buaTutorial у модуля есть "Special B2B route", но, устанавливать туда флаги бесполезно...

Реально ли использовать указанный выше метод для модуля b2bua?

drakosha
Сообщения: 1
Зарегистрирован: 03 сен 2011, 20:02

Сообщение drakosha » 03 сен 2011, 21:29

Homer писал(а):

Спасибо за очень ценную информацию.
В данный момент пробую эту тему. Скажите, пожалуйста, а какими арибутами от радиуса Вы "в ответе возвращаются нужные нам дополнительные", т.е. какие атрибуты, и как выглядит часть конфига, которые эти атрубуты отрабатывает (таймер с заданным временем запускает)?

Ответить