Добрый день!
Взяли в опытную эксплуатацию данную железку и пытаемся скрестить с биллингом UTM5.
Регистрация абонентов с использованием радиуса вроде работает без проблем, автоизация и аккаунтинг исходящих вызово - тоже.
Вопрос такой: возможно ли настроить аторизацию и аккаунтинг входящих вызовов?
О деактивации форума Eltex
Уважаемые коллеги! В связи с потерей актуальности данного ресурса, нами было принято решение о частичной деактивации форума Eltex. Мы отключили функции регистрации и создания новых тем, а также возможность оставлять сообщения. Форум продолжит работу в "режиме чтения", так как за долгие годы работы здесь накопилось много полезной информации и ответов на часто встречающиеся вопросы.
Мы активно развиваем другие каналы коммуникаций, которые позволяют более оперативно и адресно консультировать наших клиентов. Если у вас возникли вопросы по работе оборудования, вы можете обратиться в техническую поддержку Eltex, воспользовавшись формой обращения на сайте компании или оставить заявку в системе Service Desk. По иным вопросам проконсультируют наши менеджеры коммерческого отдела: eltex@eltex-co.ru.
Уважаемые коллеги! В связи с потерей актуальности данного ресурса, нами было принято решение о частичной деактивации форума Eltex. Мы отключили функции регистрации и создания новых тем, а также возможность оставлять сообщения. Форум продолжит работу в "режиме чтения", так как за долгие годы работы здесь накопилось много полезной информации и ответов на часто встречающиеся вопросы.
Мы активно развиваем другие каналы коммуникаций, которые позволяют более оперативно и адресно консультировать наших клиентов. Если у вас возникли вопросы по работе оборудования, вы можете обратиться в техническую поддержку Eltex, воспользовавшись формой обращения на сайте компании или оставить заявку в системе Service Desk. По иным вопросам проконсультируют наши менеджеры коммерческого отдела: eltex@eltex-co.ru.
SMG-1016M и Netup UTM5 radius
Re: SMG-1016M и Netup UTM5 radius
Vans писал(а):Вопрос такой: возможно ли настроить аторизацию и аккаунтинг входящих вызовов?
Входящие вызовы сами по себе никак не настроить на авторизацию.
Как минимум по той причине, что при выходящем для абонента вызове нет возможности запросить авторизационные данные.
Можно зайти с другой стороны: авторизовать абсолютно все вызовы, проходящие через SMG.
Для этого надо настроить radius-профиль на все Транковые группы и все SIP-профили. Только надо учесть, что для транковых вызовов нет возможности запросить авторизацию у инициатора вызова, поэтому авторизация будет проводиться по UserName+Password (а не Digest-авторазиция, как у абонентского вызова). Пароль задается в radius-профиле.
Для аккаунтинга могу посоветовать еще включить флаг "accounting для call-origin=answer" в разделе Accounting, по этому флагу SMG будет отдавать accounting-запросы для исходящей и входящей частей вызова.
Т.е. мы не сможем заблокировать на шлюзе заблокированных в биллинге абонентов по входящим к ним вызовам, а также запретить входящий вызов, если у абонента уже открыто максимальное количество сессий, указанное в биллинге?
А если абонента создавать с авторизацией не через радиус, то тех данных, которые есть в шлюзе (логин, пароль) становится достаточно, чтоб сделать такой запрос по радиусу, но такой возможности все равно не реализовано?
Сейчас у нас реализовано такое в астериске, просто хотелось бы его заменить этим шлюзом...
А если абонента создавать с авторизацией не через радиус, то тех данных, которые есть в шлюзе (логин, пароль) становится достаточно, чтоб сделать такой запрос по радиусу, но такой возможности все равно не реализовано?
Сейчас у нас реализовано такое в астериске, просто хотелось бы его заменить этим шлюзом...
А что это даст?
На данный момент на тестах входящие тоже приходят через транк группу с сип-профилем (но разницы тут скорее всего нет).
Задаем на эту транкгруппу радиус профиль, шлюз посылает запрос на авторизацию, у которого в качестве Username указан номер звонящего или имя транкгруппы. А нужно чтоб передавался вызываемый номер и пароль абонента на шлюзе, которому этот номер принадлежит, тогда можно было б авторизовать.
На данный момент на тестах входящие тоже приходят через транк группу с сип-профилем (но разницы тут скорее всего нет).
Задаем на эту транкгруппу радиус профиль, шлюз посылает запрос на авторизацию, у которого в качестве Username указан номер звонящего или имя транкгруппы. А нужно чтоб передавался вызываемый номер и пароль абонента на шлюзе, которому этот номер принадлежит, тогда можно было б авторизовать.
1. Закрыть входящую связь для заблокированных абонентов.
2. Не пропускать вызовы на абонентов, у которых открыто более чем некоторое количество сессий, указанное в биллинге (количество доступных в биллинге уменшается, грубо говоря, при каждом start пакете и увеличивается при каждом stop). Т.е. ограничить количество занимаемых абонентом линий.
2. Не пропускать вызовы на абонентов, у которых открыто более чем некоторое количество сессий, указанное в биллинге (количество доступных в биллинге уменшается, грубо говоря, при каждом start пакете и увеличивается при каждом stop). Т.е. ограничить количество занимаемых абонентом линий.
Vans писал(а):А если абонента создавать с авторизацией не через радиус, то тех данных, которые есть в шлюзе (логин, пароль) становится достаточно, чтоб сделать такой запрос по радиусу, но такой возможности все равно не реализовано?
Не реализовано такой возможности. Запрос к радиус делается только для "исходящих" для абонента вызовов.
Vans писал(а):...шлюз посылает запрос на авторизацию, у которого в качестве Username указан номер звонящего или имя транкгруппы. А нужно чтоб передавался вызываемый номер и пароль абонента на шлюзе, которому этот номер принадлежит, тогда можно было б авторизовать.
Шлюз так же посылает пару номеров: "Called-Station-Id" и "Calling-Station-Id"
Биллинг не может разве брать в рассчет поле "Called-Station-Id" и по нему анализировать, что сейчас с этим абонентом: "заблокирован" или "все линии заняты" ?
UTM5 похоже не может. Они ищет абонента по UserName, что логично...
Вот выдержка из документации:
Вот выдержка из документации:
Для авторизации звонка привратник или голосовой шлюз посылает на сервер RADIUS запрос на регистрацию с указанием Calling-ID (31) и Called-ID (30). Сервер RADIUS ищет сервисную связку услуги телефонии, идентифицируя её по логину, указанному в свойствах сервисной связки. Если связка обнаружена, баланс счёта положителен, вызываемый телефонный номер входит в направление, включённое в состав услуги телефонии (непосредственно или в составе зоны), и текущее время входит в разрешённый временной диапазон (также задаваемый в свойствах услуги), то выдаётся положительный ответ; в противном случае сервер RADIUS выдаёт отказ в авторизации. Положительный ответ включает максимальную длительность соединения, рассчитываемую либо как срок окончания временного диапазона, для которого задана цена услуги (если данный диапазон не покрывает всё время суток), либо как срок исчерпания баланса счёта, с учётом текущего баланса и стоимости услуги (возможно, меняющейся со временем), в зависимости от того, что из этого наступает скорее.
Давайте попробуем по другому.
Создаем SIP-профиль, создаем статического пользователя.
Пусть у него номер будет 111, пользователь 222 и АОН 333.
Настраиваем софтфон (3CX), софтфон регистрируется, все ок.
Теперь создаем RADIUS-профиль и привязываем его к SIP-профилю. Ставим в нем галку "использовать индивидуальные пароли абонентов".
Как теперь заставить авторизовывать звонки этого абонента?
Если мы ставим галку "Отправлять запросы" "при входящем занятии", то запрос отсылается без Called number, если "при окончании набора", то вообще не отправляется никаких запросов.
При этом, если в первом случае запрос и отправляется, то есть ряд моментов. Если выбрать в качестве имени пользователя IP, то отсылается 0.0.0.0. Тут фиг с ним, нам это не надо. А вот что, CgPN, что Trunk Name - отправляется АОН абонента. Почему не заданный абоненту логин (ведь он же может теоретически отличатся от АОН)? А схема авторизации почему всегда PAP (или этот параметр работает только при регистрации абонентов)?
Создаем SIP-профиль, создаем статического пользователя.
Пусть у него номер будет 111, пользователь 222 и АОН 333.
Настраиваем софтфон (3CX), софтфон регистрируется, все ок.
Теперь создаем RADIUS-профиль и привязываем его к SIP-профилю. Ставим в нем галку "использовать индивидуальные пароли абонентов".
Как теперь заставить авторизовывать звонки этого абонента?
Если мы ставим галку "Отправлять запросы" "при входящем занятии", то запрос отсылается без Called number, если "при окончании набора", то вообще не отправляется никаких запросов.
При этом, если в первом случае запрос и отправляется, то есть ряд моментов. Если выбрать в качестве имени пользователя IP, то отсылается 0.0.0.0. Тут фиг с ним, нам это не надо. А вот что, CgPN, что Trunk Name - отправляется АОН абонента. Почему не заданный абоненту логин (ведь он же может теоретически отличатся от АОН)? А схема авторизации почему всегда PAP (или этот параметр работает только при регистрации абонентов)?
-
Женя
- Сообщения: 1769
- Зарегистрирован: 27 окт 2008 11:48
- Reputation: 0
- Откуда: ELTEX
- Контактная информация:
Сам принцип работы динамических абонентов предусматривает то, что база абонентов (в том числе их логин и пароль) находится на сервере radius.
При попытке регистрации или при звонке от абонента приходит сообщение register/invite затем SMG запрашивает у абонента данные для авторизации (логин/пароль)(это я говорю о режиме draft-sterman для NetUP), сообщением 401, т.е. локально SMG их не хранит, как только получаем эти данные от абонента формируем запрос радиус в который перекладываем полученные логин и пароль, если все ок - сервер отвечает нам добром, мы пропускаем эту регистрацию/звонок.
Теперь рассмотрим ситуацию, когда звонок пришел с левого направления на абонента, у SMG нет данных об абоненте, при этом мы никак не запросим у абонента логин/пароль, т.к. просто так отправить 401 сообщение SMG не может (это сообщение только ответное), т.о. и авторизовать звонок не сможем.
Разделение по направлениям (вход/исход) должно осуществляться по RADIUS-Accounting сообщениям, в котором есть необходимые для этого поля, кстати, возможность четко разделить звонки на входящие-исходящие появится в версии UTM 5.3. Вот вам полезная ссылка на их форум http://www.netup.ru/phpbb/viewtopic.php?t=9267
Поправьте меня если я не прав.
При попытке регистрации или при звонке от абонента приходит сообщение register/invite затем SMG запрашивает у абонента данные для авторизации (логин/пароль)(это я говорю о режиме draft-sterman для NetUP), сообщением 401, т.е. локально SMG их не хранит, как только получаем эти данные от абонента формируем запрос радиус в который перекладываем полученные логин и пароль, если все ок - сервер отвечает нам добром, мы пропускаем эту регистрацию/звонок.
Теперь рассмотрим ситуацию, когда звонок пришел с левого направления на абонента, у SMG нет данных об абоненте, при этом мы никак не запросим у абонента логин/пароль, т.к. просто так отправить 401 сообщение SMG не может (это сообщение только ответное), т.о. и авторизовать звонок не сможем.
Разделение по направлениям (вход/исход) должно осуществляться по RADIUS-Accounting сообщениям, в котором есть необходимые для этого поля, кстати, возможность четко разделить звонки на входящие-исходящие появится в версии UTM 5.3. Вот вам полезная ссылка на их форум http://www.netup.ru/phpbb/viewtopic.php?t=9267
Поправьте меня если я не прав.
Вернуться в «Оборудование VoIP»
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 22 гостя