BiTel

Суть в следующем: имеем астериск, который шлет пакеты аккаутнинга в BGRadiusVoip. Астериск работает с несколькими провайдерами, расценки на одни и те-же направления у провайдеров разные. Астериск по некоему алгоритму выбирает, через какого провайтера делать исходящий звонок. Возникает вопрос - как биллинг может тарифицировать звонки в зависимости от того, через какого провайдера прошел звонок?

Несколько вариантов, которые пока мне пришли в голову, это:

1. Самый предпочтительный вариант, ибо он должен работать с любым софтсвичем, а не только с теми, у которых можно изменять исходный код. Создать несколько услуг в модуле ВОИП (по одной для каждого провайдера) и создать тарифы для каждой услуги. В дальнейшем анализировать в скрипте предобработки получаемые атрибуты и соответственно устанавливать требуемый serviceid.
Вопрос - как его установить? В конфигурации НАСа он прописывается жестко, функции его изменения в документации не нашел.

2. Аналогично предыдущему варианту создать несколько услуг и соответствующих тарифов. Создать несколько НАСов (по одному для каждого провайдера) с одинаковыми адресами IP, но с разными NAS_ID, прописать для каждого соответствующую услугу. Подправить астериск на предмет выдачи определенного NAS_ID для каждого провайдера. Вариант кривой, но терпимый.
Вопрос - биллинг каким-то образом обращает внимание на NAS_ID при определении НАСа?

3. Повесить на астериск несколько адресов IP и заставить его слать запросы для каждого провайдера с разных адресов. В биллинге, соответственно, завести несколько НАСов со своими serviceid ну и т.д. Работать это уже точно будет, но править астериск до такой степени явно не хочется, да и вообще вариант самый кривой!

Господа уважаемые, посоветуйте пожалуйста решение для данной проблемы? Может оно на поверхности, а я не туда долблюсь?

Проще всего реализуемый 1ый вариант. Только в voip радиусе сейчас скриптом нельзя установить код услуги. Можно только установить режим поиска и направление вызова.
Но можем исправить и помочь с написанием скрипта Даже в текущей версии. Но от вас тогда - подробное описание в wiki.bgbilling.ru как вы Asterisk скрестили с биллингом.
Если согласны - пишите описание того что есть, затем мы делаем доработку.

Всеми руками за ваше предложение! Тем более, что аналогичная проблема у меня сейчас стоит при связке биллинга с CommuniGatePro. К своему стыду, я так и не нашел, где в wiki создаются новые странички, поэтому помещаю информацию сюда, ну а уж вы с ней, я думаю, разберетесь, если она будет того стоить... Кстати, в модуле телефонии у вас присутствует опция привязки тарифов к порту АТС, может быть для в качестве решения на поставленный мною вопрос более правильно будет портировать эту опцию в модуль IP-телефонии?

---
Статья перенесена:
http://wiki.bgbilling.ru/index.php/%D0% ... _BGBilling
...

Там вверху каждой страницы есть кнопка Править, в теле страницы создается ссылка на новую страницу, потом страница сохраняется. При переходе по ссылке на новую страницу открывается редактор.

Можете вкратце описать, что изменяет патч в поведении Астериска и по какому полю RADIUS запроса определить услугу?

В логику работы ядра Астериска патч никаких изменений не вносит. Изменения касаются только модуля, отвечающего за взаимодействие Астериска с Радиусом, а именно:
- Заменяются атрибуты вендора Digium (22736) на аналогичные атрибуты вендора Cisco (9)
- Если в поле accountcode стандартной статистики Астериска (CDR) присутствует какое-либо значение, то оно подставляется в атрибут User-Name, если значения нет, то User-Name не выдается
- В каждый пакет добавляется атрибут h323-call-type=voip
- Если в поле userfield стандартной статистики Астериска (CDR) присутствует значение "answer", то оно подставляется в атрибут h323-call-origin, при ином значении или отсутствии значения в поле userfield, Радиус получит h323-call-origin=originate

Я так понимаю, что обычно для идентификации шлюза, через который проходит звонок, используется h323-gw-id? Я предполагаю доработать патч, чтобы в этот атрибут помещалось значение идентификатора канала Астериска, например h323-gw-id=SIP/pbxpress. Но при этом наверно не совсем удачным решением будет жестко привязывать service к этому атрибуту, лучше все-таки иметь функцию для установки service (какой-нибудь setServiceId()), доступную из скрипта предобработки запросов Радиуса. В этом случае можно будет сделать, к примеру, следующее:

1. В Астериске прописывать peer по правилу [peer_name-service], например [pbxpress-5]. Астериск поместит в h323-gw-id=SIP/pbxpress-5.
2. В скрипте предобработки отрезать "-5" от полученного значения и установить service=5
3. Если в скипте предобработки мы не установили значение service, то используется код услуги, указанный в конфигурации НАСа

Если же по каким причинам, явно обозначить код услуги в Астериске будет невозможно, то тогда просто прийдется в скрипте предобработки выстраивать таблицу соответствия идентификатора канала Астериска и кода услуги биллинга, типа:

if (h323-gw-id == "SIP/pbxpress")
setServiceId(5);
if (h323-gw-id == "SIP/cgp")
setServiceId(6);

(в примере описана просто логика, а не пример на BGBS)

В дополнение к предлагаемому функционалу, можно также сделать упрощенный вариант, введя дополнительные опции в конфигурацию НАСа, например:

service.gw.1=SIP/pbxpress
service.1=5
service.gw.2=SIP/cgp
service.2=6
service.default=7

значения SIP/pbxpress и SIP/cgp в этом случае будут однозначно браться из h323-gw-id

Тут я, конечно, был не прав... из описания на http://www.cisco.com/en/US/docs/ios/voice/vsa/developer/guide/vsaig3.html:

Наиболее подходящим из атрибутов Cisco для этих целей на мой взгляд могут быть:











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

P.S. Реализовал на практике и добавил в Wiki статью Интеграция Asterisk и BGBilling (Accounting) посредством скрипта предобработки запросов Radius, получается даже проще, чем править Астериск... жаль только, что нет функции removeVendorAttributes(int vcode, int code)! Кстати, для этого метода интеграции совершенно необязательно подбирать какой-либо атрибут для идентификации исходящего канала, поскольку у Digium он уже есть, и остается только установить код услуги на его основании.

А для чего это делается? А давайте может попробуем без патчей, средствами биллинга сделать? Нам такое решение более интересно будет. Со своей стороны я так понял, нужно только в find.mode сделать поддержку поиска по атрибутам нескольких вендоров.
Ну и установку скриптом кода услуги.
У вас есть возможность, например, воткнуть 4.5 радиус тестовый? Я бы вносил правки - а вы пробовали.
Вот еще товарищ с аналогичной проблемой:
http://bgbilling.ru/forum/viewtopic.php?t=1003
Биллинг определяет NAS по атрибуту NAS-IP-Address, NAS-Identifier

С удовольствием поработаю с Вами по всем этим вопросам, но позвольте сначала задать несколько вопросов-предложений:

1. Я правильно понимаю, что Вы хотите фактически вписать в тело модуля ВоИП логику, описанную мною в скрипте предобработки? Если да, то не окажется-ли это не совсем гибким решением? Если нет, то прошу Вас поделиться алгоритмом работы предлагаемого вами решения.

2. У Диджиума отсутствуют атрибуты и средства, необходимые для аудентификации и авторизации через радиус. Сейчас я тестирую и планирую выложить в ближайшие дни на Вики решение, использующее сторонее приложение для астериска. Это приложение работает с атрибутами h323-... Нормально-ли с точки зрения логики (и БГБиллинга) при этом будет, если для аудентификации и авторизации будут использоваться атрибуты cisco, а для аккаунтинга (в соответствии с предлагаемым Вами решением) - атрибуты digium?

Все эти вопросы сводятся к одному - а не лучше-ли будет (во всяком случае до тех пор, пока Астериск не обзаведется полноценной поддержкой радиуса) обрабатывать пакеты аккаунтинга одним из двух предложенных мною методов, тем более что в одном из них Астериск править совершенно необязательно? Или по другому: учитывая, что пока не существует ни одной распространенной бинарной сборки астериска с поддержкой радиуса (во всяком случае я о таких не знаю), то в любом случае избавиться от компиляции исходного кода Астериска и radiusclient-ng не удастся, тем более, если будет необходимость работы со всеми ААА, то есть-ли вообще смысл вносить изменения в код БГБиллинг для поддержки нескольких нестандартных атрибутов? Может действительно стоит ограничиться функциями установки кода услуги и удаления ненужных атрибутов (чтобы логи не засоряли)?



Да могу, при условии, что он совместим с сервером 4.4

Вообще-то это ссылка на мой пост

Ошибся ссылкой
http://bgbilling.ru/forum/viewtopic.php?p=5785

1. Нет, будем делать скрипты предобработки. Просто сейчас там нету возможности вообще код услуги ставить, даже в скрипте. И еще режимы поиска логинов тяжело делать, если приходят различные атрибуты от разных NAS-ов с разными вендорами.

2. Хм, насчет отсутствия бинарной сборки не знал. Просто хотелось решить проблему вообще максимально гибко и максимально на стороне биллинга (чтобы люди патчами морочились поменьше), и в т.ч. решить проблему по вышеуказанной ссылке..

4.5 радиус должен совмещатся с 4.4 севером без проблем..

P.S. В федоре предлагает какой-то пакет asterisk-radius:

Как я понял из этого поста, товарищ Sergey Murzin остановился на проблеме с подчисткой уже не нужных атрибутов AudioCodes? Если так, то это еще один аргумент в пользу removeVendorAttributes(int vcode, int code)!

А скрипт, предложенный в Интеграция Asterisk и BGBilling (Accounting) посредством скрипта предобработки запросов Radius чем-то не подходит? За исключением того, что в нем не устанавливается код услуги?

Тут уже я лажанулся Под бинарными сборками я подразумевал AsteriskNow, TrixBox и прочие... Действительно, в указанных Вами сборках присутствует модуль cdr_radius, он делает аккаунтинг с использованием атрибутов Digium. Значит это еще один довод в пользу скрипта предобработки!

Тогда с Вас ссылочку на то место, где его можно взять, ну и Changelog не помешал-бы...

Резюме всего вышесказанного:
1. Требуется функция установки кода услуги
2. Требуется функция удаления атрибутов вендора, отличного от текущего

1. Брать радиус здесь ftp://bgbilling.ru/pub/bgbilling/4.5
2. Сделал установку в скрипте кода услуги

3. ChangeLog а нет, это фактически неизмененный 4.4 радиус. Ну разве что вот добавил установку услуги.
4. По установки постронних атрибутов - уточните сигнатуру метода. Только код вендора, либо код вендора + код параметра (второй вариант не очень понимаю).

В идеале функция должна поддерживать 2 варианта:
removeVendorAttributes(int vendorCode) - удаляет все атрибуты данного вендора
removeVendorAttributes(int vendorСode, int attributeCode) - удаляет только один (указаный во втором параметре) атрибут данного вендора

После установки BGRadiusVoip 4.5, при обработке Accounting Stop появилась ошибка:

Вы можете поднять отдельно BGBilling 4.5 и туда дублировать аккаунтинг? Воип радиус то не менялся, зато API ядра поменялось и структура БД. Не учел

Попробую.... как сделаю - отпишусь!