Page tree
Skip to end of metadata
Go to start of metadata

Для настройки NAS мы должны вначале добавить тип устройства и устройство данного типа(ссылки!).

В типе устройства может быть указан Обработчик процессора протокола.  

В настройке типа в  первую очередь надо указать код вендора

#по умолчанию cisco так как большинcтво параметров оттуда.
vendor.code=9

Это параметр по умолчанию(если не указан) имеет значение 9(Cisco). 

Еще нужно указать ряд radius-параметров, которые используются в логике работы модуля . Все они имеют вид 

radius.attr.X.vendor=
radius.attr.X.code=

Где в первой строке указывают vendor, во второй code утрибута, X - это имя атрибута. 

Все эти атрибуты имеют значение по умолчанию:

 
########H323-credit-time########################
#по умолчанию берется значение из vendor.code(9-cisco)
radius.attr.credit.time.vendor=
#по умолчанию используется H323-credit-time из вендора Cisco
radius.attr.credit.time.code=102
 
########H323-return-code########################
#по умолчанию берется значение из vendor.code(9-cisco)
radius.attr.error.vendor=
#по умолчанию используется H323-return-code из вендора Cisco
radius.attr.error.code=103
 
######## H323-credit-amount########################
#по умолчанию берется значение из vendor.code(9-cisco)
radius.attr.credit.amount.vendor=
#по умолчанию используется H323-credit-amount из вендора Cisco
radius.attr.credit.amount.code=101 

 
######## Acct-Session-Id ########################
#по умолчанию берется значение -1(это стандартные атрибуты)
radius.attr.identifier.vendor=-1
#по умолчанию используется стандартный атрибут Acct-Session-Id 
radius.attr.identifier.code=44
 
######## Calling-Station-Id ########################
#по умолчанию берется значение -1(это стандартные атрибуты)
radius.attr.calling.station.id.vendor=-1
#по умолчанию используется стандартный атрибут Calling-Station-Id 
radius.attr.calling.station.id.code=31
 
######## Called-Station-Id########################
#по умолчанию берется значение -1(это стандартные атрибуты)
radius.attr.called.station.id.vendor=-1
#по умолчанию используется стандартный атрибут Called-Station-Id
radius.attr.called.station.id.code=30
 
######## H323_call_type########################
#по умолчанию берется значение из vendor.code(9-cisco)
radius.attr.call.type.vendor=
#по умолчанию используется H323_call_type из вендора Cisco
radius.attr.call.type.code=27
 
######## H323-call-origin########################
#по умолчанию берется значение из vendor.code(9-cisco)
radius.attr.call.origin.vendor=
#по умолчанию используется H323_call_origin из вендора Cisco
radius.attr.call.origin.code=26

######## Параметр время соединения( опционально можно не указывать) ########################
#по умолчанию берется значение из vendor.code(9-cisco)
radius.attr.connect.time.vendor=
#нет значения по умолчанию( тогда это параметр не используется в логике). 
radius.attr.connect.time.code=
 
Как видно большинство атрибутов берется по умолчанию для cisco. И несколько стандартных атрибутов. 

Вот пример рабочей конфигурации для FreeSwitch(в нестандартном варианте):

#подменяем -1 на код вендора Cisco 
radius.attr.identifier.vendor=9
#H323_conf_id в качестве идентификатора
radius.attr.identifier.code=24
 

Как видно что в данном случае в качестве идентификатора вместо Acct-Session-Id использовали Cisco-ский атрибут H323-conf-id.  Остальное все по умолчанию.

И указываем галочку Устройство является NAS-ом

Далее заводим устройство данного типа :

Тут указываем или ip в поле Хост/порт  или идентификатор.  Поиск NAS происходит по Radius-Атрибутам:

  • NAS-IP-Address - поиск по полю Хост/порт.
  • NAS-Identifier - поиск  по полю идентификатор.

Режимы поиска аккаунта

Вначале в конфигурации модуля мы задаем возможные режим поиска аккаунта в модуле.

radius.search.mode.pattern.<уникальный код>.rule=<Название Radius-атрибута>=<PHONE|LOGIN>

Где PHONE это номер телефона из аккаунта, а   LOGIN - логин.

Например 

radius.search.mode.pattern.1.rule=Calling-Station-id=PHONE
radius.search.mode.pattern.2.rule=Called-Station-id=PHONE
radius.search.mode.pattern.3.rule=User-Name=PHONE
radius.search.mode.pattern.4.rule=User-Name=LOGIN

Потом мы задаем уже в конфигурации устройства (или типа устройства)  как эти режимы будут применяться на устройстве :

#режим поиска при авторизации 
radius.auth.search.mode.order=exp[,exp]
#режим поиска при аккаунтинге
radius.acct.search.mode.order=exp[,exp]

Где exp имеет вид

code[:type]

code - это код режима,поиск из конфигурации , описанный выше. type - тип звонка (1 - исходящий, 2 - входящий). Тип звонка не обязателен (про него будет описано ниже).

Например:

radius.auth.search.mode.order=3
radius.acct.search.mode.order=1:1,2:2,3:1

По умолчанию происходит поиск аккаунтов на NAS, которые удовлетворяют заданным критериям. И так же на устройстве, которое является родительским для NAS - это позволяет сделать режим, когда вы не хотите указывать  NAS явно на абоненте, т.е абонент может выхожить с любого из NAS-ов, тогда имеет смысл объединить все NAS в отдельную папку в дереве устройств и указывать эту папку как  device.const в типе аккаунта

Отдельно можно указать чтобы аккаунты искались так же до дочерних устройствах(расположенные ниже в дереве устройств) данного NAS, это настройка указывается в типе устройства :

#искать на дочерних устройствах. 1- включено, 0(по умолчанию) -выключено. 
radius.search.mode.device.deep=1

Она означает что надо искать аккаунт не только на устройстве NAS, но и сразу его потомков. 

Тут есть отличие как работает поиск в  access и accounting. Для access мы просто находим один аккаунт, который удовлетворяет первый совпадающему в списке режиму. Далее поиск прекращается, проверяется баланс и т.п для этого аккаунта чтобы выдать ему access или reject. 

Для accounting ищутся все аккаунты удовлетворяющие заданным в списке режимам и для каждого из низ создается отдельная  сессия. Это сделано  для того, когда в случае звонка абонент-абонент, создать исходящую сессию на одном абоненте и исходящую на другом(подробнее о определении типа звона написано ниже). 

Определение типа звонка

Типа звонка (входящий или исходящий) определяется в следующем порядке ( каждый способ может переопределить предыдущий):

  1. Определяем типа звонка на основе атрибутов.
  2. Скрипт обработки процессора протокола.
  3. Направление указанное в настройке поиска account-а.

1-ый способ. Для определения типа звонка (входящий или исходящий) на основе атрибутов  radius-запроса(1-ый способ) используются  такие настройки :

#входящие  при авторизации
radius.auth.in=voip/originate
#исходящие при авторизации 
radius.auth.out=voip/answer
#входящие  при accounting-е
radius.acct.in=voip/originate
#исходящие  при accounting-е
radius.acct.out=voip/answer

Для определения типа используются атрибуты h323-call-type и h323-call-origin(эти параметры можно поменять на другие в настройке, описанной выше)  из RADIUS-запроса. Значения этих атрибутов, соответствующие каждому типу звонка, необходимо указать через дробь и в нижнем регистре (даже если в запросе указан верхний регистр). В этом случае авторизационные запросы с атрибутами h323-call-type=Voip h323-call-origin=originate будут считаться исходящими, h323-call-type=Voip h323-call-origin=answer входящими. Еще есть специальное значение all . Например вот так можно указать что все вызовы идут как исходящие 

radius.auth.out=all/all
radius.acct.out=all/all

Так же любой из атрибутов может быть пустым. Например

radius.auth.in=/incoming


2-ой способ. Так же тип звонка можно определить в обработчике протокола с помощью установки опции  VoiceNas.CALL_TYPE. Пример обработчика, где все звонки делаются исходящими:

package ru.bitel;
import ru.bitel.bgbilling.kernel.network.radius.RadiusPacket;
import ru.bitel.bgbilling.modules.voice.access.om.ProtocolHandler;
import ru.bitel.bgbilling.modules.voice.api.common.bean.VoiceDevice;
import ru.bitel.bgbilling.modules.voice.api.common.bean.VoiceDeviceType;
import ru.bitel.bgbilling.modules.voice.api.common.bean.VoiceSession;
import ru.bitel.bgbilling.modules.voice.radius.VoiceNas;
import ru.bitel.bgbilling.server.util.Setup;
import ru.bitel.common.ParameterMap;
import ru.bitel.common.sql.ConnectionSet;
public class Prot3
	implements ProtocolHandler
{
	@Override
	public void preprocessAccessRequest( RadiusPacket request, RadiusPacket response, ConnectionSet connectionSet )
		throws Exception
	{        
        //все звонки помечяем  исходящими
	    request.setOption( VoiceNas.CALL_TYPE, VoiceSession.CALL_TYPE_OUTGOING );        
	}
	@Override
    public void preprocessAccountingRequest( RadiusPacket request, RadiusPacket response, ConnectionSet connectionSet )
        throws Exception
    {      
        //все звонки помечяем  исходящими
        request.setOption( VoiceNas.CALL_TYPE, VoiceSession.CALL_TYPE_OUTGOING );           
    }
	@Override
	public void init( Setup setup1, int int2, VoiceDevice voiceDevice3, VoiceDeviceType voiceDeviceType4, ParameterMap parameterMap5 )
		throws Exception
	{
	}
	@Override
	public void postprocessAccountingRequest( RadiusPacket radiusPacket1, RadiusPacket radiusPacket2, ConnectionSet connectionSet3 )
		throws Exception
	{
	}
	@Override
	public void postprocessAccessRequest( RadiusPacket radiusPacket1, RadiusPacket radiusPacket2, ConnectionSet connectionSet3 )
		throws Exception
	{
	}
}

3-тий способ. При указании режимов поиска на устройстве(описано выше) мы можем опционально задать тип звонка(1 - исходящий, 2 - входящий). В этом случае если аккаунт будет найден для указанной пары режим:тип звонка, то тип звонка возьмется из этой пары.

radius.acct.search.mode.order=1:1,2:2

В данном примере для 1-го режима поиcка звонок  помечается как исходящий, а для второго как входящий . При этом в конфигурации модуля эти режимы могут быть определены так:

radius.search.mode.pattern.1.rule=Calling-Station-id=PHONE
radius.search.mode.pattern.2.rule=Called-Station-id=PHONE

Если происходит звонок от одного абонента провайдера к другому, то он найдет 2 разных аккаунта, на один  добавится исходящий звонок, на второй - входящий. 

  • No labels