Настройка динамических абонентов и системы Radius

Что дальше

В последнем разделе мы собрали собственный небольшой биллинг! Остается для полноты картины привернуть какой-нибудь WEB-интерфейс управления Базой Данных, добавить обязательное изменение пароля раз в месяц по крону. А если еще разориться сертификат и контроллер Wi-Fi точек доступа, то у вас в руках есть полноценная корпоративная беспроводная сеть.

1.1. Общие сведения о AAA и RADIUS

AAA – сокращение от Authentication, Authorization and Accounting (Аутентификация, Авторизация, учёт) и используется при предоставлении доступа в сеть, к управлению оборудованием и управления этим доступом. RADIUS – это один из сетевых клиент-серверных протоколов, используемый для централизованного управления авторизацией, аутентификацией и учетов при запросе доступа пользователей к различным сетевым службам.

Клиент RADIUS обычно используется на сетевом устройстве для реализации AAA совместно с протоколом 802.1x. Сервер RADIUS хранит базу данных для AAA и связывается с клиентом RADIUS через протокол RADIUS, который является наиболее распространенным протоколом в рамках AAA.

1.2. Общие сведения о AAA и RADIUS

Протокол RADIUS использует UDP для транспорта. Формат заголовка пакета показан ниже.

Рисунок 57.1 – Формат пакета RADIUS

Code – тип пакета RADIUS, возможные значения для данного поля:

1 – Access-Request2 – Access-Accept3 – Access-Reject4 – Accounting-Request5 – Accounting-Response11 – Access-Challenge

Identifier – идентификатор для пакетов запроса и ответа.Length – длина всего пакета RADIUS.Authenticator – поле используется для проверки пакетов, полученных от RADIUS-сервера, или для передачи зашифрованных паролей.

Поле разделено на две части: аутентификатор запроса и аутентификатор ответа.Attribute – поле используется для передачи детальной информации о ААА. Значение поля формируется из значений полей Type, Length, и Value:

2. Конфигурация RADIUS

  1. Включить функцию аутентификации и учета;
  2. Настроить ключ сервера RADIUS;
  3. Настроить параметры RADIUS сервера;
  4. Настроить параметры сервиса RADIUS;
  5. Настроить адреса RADIUS NAS.
  1. Включить функцию аутентификации и учета:

2. Настроить ключ сервера RADIUS:

3. Настроить параметры RADIUS сервера:

4. Настроить параметры сервиса RADIUS:

5. Настроить адреса RADIUS NAS:

3. Пример конфигурации RADIUS

Рисунок 57.2 – Конфигурация RADIUS

ПК подключен к коммутатору, который имеет IP-адрес 10.0.0.2 и подключен к серверу аутентификации RADIUS. IP-адрес сервера 10.0.0.3, используемый порт для аутентификации по-умолчанию – 1812, для учета – 1812 . Доступ на коммутатор по telnet контролируется сервером аутентификации.

Конфигурация выглядит следующим образом:

4. Устранение проблем при конфигурации RADIUS

Убедитесь, что:

  • IP-связность коммутатора с сервером RADIUS присутствует;
  • ключ аутентификации на коммутаторе совпадает с ключом на RADIUS сервере;
  • подключение осуществляется к правильному RADIUS серверу.
  • Подробная отладочная информация может быть отображена после применения команды debug aaa.

Accounting

После ответа абонента Б, система отправляет Acct-Start Request с информацией о начале вызова и времени ответа на RADIUS сервер. Детально параметры запроса описаны в пункте Настройка динамических абонентов и системы Radius.В ответ RADIUS сервер может прислать максимальную продолжительность вызова (в секундах), запрет вызова (в этом случае система тут же отобьет вызов если он не разрешен в свойстве if_radius_unavaliable), таймаут посылки промежуточных Accounting сообщений Acct-Interim-Update.

Если абоненты А, Б воспользовались услугами ДВО, на RADIUS сервер посылаются Acct-Update Request с информацией об этом, в случае если параметр send_ss_notification = true

domain/<DOMAIN>/aaa/accounting/info send_ss_notification

По завершению вызова посылается сообщение Acct-Stop Request с информацией о абонентах А, Б, а так же о времени начала, ответа и завершения вызова.В случае, если ответа на вызов не было Acct-Stop Request посылается только в том случае, если параметр unsuccessful_call_info = true.

domain/<DOMAIN>/aaa/accounting/info unsuccessful_call_info

Radius маршрутизация

На этапе маршрутизации вызова в правиле контексте маршрутизации можно указать, что необходимо выполнить внешнюю RADIUS маршрутизацию.

В этом случае на RADIUS сервер посылаются следующие параметры:

  • текущие номера А, Б и их признаки;
  • имя текущего контекста маршрутизации;
  • текущее значение параметра tag контекста маршрутизации;
  • имя домена;
  • имя входящего интерфейса;
  • номер попытки маршрутизации (начинается с 1, и в в случае перемаршрутизации увеличивается);
  • причина release-а предыдущего вызова по SIP, ISUP, ACP (в случае перемаршрутизации).

В ответ RADIUS сервер может прислать команды на изменения номеров А, Б, их признаков, параметра tag

После маршрутизации, прежде чем отправить вызов на абонента Б, делается запрос в подсистему Authentication. На этом этапе проверяется, можно совершать вызов с номера А на номер Б, или нет.Если Authentication подсистема вернула accept — вызов отправляется на абонента Б.

domain/<DOMAIN>/aaa/general/info if_radius_unavaliable

В параметре if_radius_unavaliable перечислены направления, на которые необходимо отправлять вызов даже если RADIUS сервер недоступен, не пропускает вызов (Например вызовы на номера спецслужб).Access-Request сторону RADIUS содержит параметры, детально описанные в пункте Настройка динамических абонентов и системы Radius.

Radius-сервер

Зайдем на наш компьютер с Linux и установим RADIUS-сервер. Я брал freeradius, и ставил я его на gentoo. К моему удивлению, в рунете нет материалов, относящихся к настройке Freeradius 2 для наших целей. Все статьи довольно стары, относятся к старым версиям этого програмного обеспечения.

root@localhost ~ # emerge -v freeradius

Все:) RADIUS-сервер уже может работать:) Вы можете проверить это так:

root@localhost ~ # radiusd -fX

Это debug-mode. Вся информация вываливается на консоль. Приступем к его настройке.


Как это водится в Linux, настройка выполняется через конфигурационные файлы. Конфигурационные файлы хранятся в /etc/raddb. Сделаем подготовительные действия — скопируем исходные конфиги, почистим конфигурация от всякого мусора.

root@localhost ~ # cp -r /etc/raddb /etc/raddb.olg
root@localhost ~ # find /etc/raddb -type f -exec file {} ;  | grep 'text' | cut -d':' -f1 | xargs sed -i '/^ *t* *#/d;/^$/d'

Далее добавим клиента — точку доступа. Добавляем в файлик /etc/raddb/clients следующие строки:

root@localhost ~ # cat /etc/raddb/clients.conf | sed '/client test-wifi/,/}/!d'
client test-wifi {
        ipaddr = 192.168.0.1 #IP адрес точки, которая будет обращаться к радиусу
        secret = secret_key #Секретный ключик. Такой же надо будет поставить на Wi-Fi точке.
        require_message_authenticator = no  #Лучше так, с каким-то D-Linkом у меня не получилось иначе
}

Далее добавляем домен для пользователей. Сделаем дефолтовый.

root@localhost ~ # cat /etc/raddb/proxy.conf | sed '/realm DEFAULT/, /^}/!d'
realm DEFAULT {
        type = radius
        authhost = LOCAL
        acchost = LOCAL
}

Базовая настройка

В этой статье нас будут интересовать в первую очередь WPA2-EAP/TLS способ авторизации.


Практически все современные точки доступа Wi-Fi стоимостью больше 3 тыс. рублей поддерживают нужную нам технологию. Клиентские устройства поддерживают и подавно.

В статье я буду использовать следующее оборудование и програмное обеспечение:

Добавление radius-серверов

Начиная с версии 3.5.0 RAIDUS-сервера создаются для каждой виртуальной АТС отдельно, и затем могут быть использованы в подсистеме авторизации.

Команды по настройки RADIUS серверов детально описаны в разделе Команды настройки параметров соединения c RADIUS-сервером.

Конфигурирование подсистемы aaa

Конфигурирование подсистемы AAA состоит из трех этапов:

  1. Задание параметров подключения в RADIUS серверу(ам)
    Детально команды по управлению RADIUS серверами описаны в пункте Команды настройки параметров соединения с RADIUS-сервером.
  2. Конфигурирование подсистемы Authorization (access запросы)
    Детально команды по управлению службой Authorization описаны в пункте Команды управления службой RADIUS AAA (Authorization).
  3. Конфигурирование подсистемы Accounting (accounting запросы)
    Детально команды по управлению службой Accounting описаны Команды управления службой RADIUS AAA (Accounting).

Настройка группы динамических абонентов

Порядок настройки группы динамических абонентов:

Настройка динамических абонентов (уровень sip-адаптера)

В системе поддерживается возможность дайджест-аутентификации и авторизации абонентов с использованием RADIUS-сервера. Для этого необходимо создать динамических абонентов. Система не хранит данные о динамических абонентах. Номер абонента и его пароль для аутентификации хранятся на RADIUS-сервере. В системе ECSS-10 необходимо только указать количество динамических абонентов и параметры доступа к RADIUS-серверу.

Авторизация осуществляется при регистрации абонента (запрос REGISTER) и определяет, существует ли абонент в системе. Дополнительно авторизация осуществляется при совершении вызова абонентом (запрос INVITE) и определяет, разрешено ли абоненту пользоваться ресурсом. Все запросы (регистрация, установление соединений) обязательно проходят процедуру аутентификации.

Например, у абонента нет средств на счете, но при этом с отрицательным балансом он должен быть авторизован и иметь возможность совершать вызовы на экстренный номер 112. При этом требование прохождения процедуры аутентификации сохраняется. При вызовах на другие номера процедура авторизации вернет запрет на соединение — данные вызовы будут отбиты.

Комплекс ECSS-10 поддерживает три варианта дайджест-аутентификации на RADIUS-сервере:

  • RFC — согласно полной рекомендации RFC5090 (обновленная версия стандарта, RFC4590 — устаревшая версия). Формирование базы запроса аутентификации (nonce и другие) выполняется сервером RADIUS (challenge запрос);
  • RFC-no-challenge — согласно RFC5090, но без “challenge” запроса на сервере. База запроса аутентификации (nonce и другие) формируется адаптером и затем передается на сервер RADIUS вместе с ответом клиента;
  • Draft-sterman — работа по черновику RFC “draft-sterman”. Аналогично предыдущему варианту не выполняется “challenge” запроса на сервер, при отправке запроса на сервер RADIUS используется другая кодировка команд. В частности, такой вариант аутентификации поддерживают сервера FreeRadius, NetUp).

Порядок настройки динамических абонентов:

  1. Добавить в систему информацию о RADIUS-серверах.
  2. Создать группы с определенным количеством динамических абонентов.
  3. Назначить группе абонентов список RADIUS-серверов, с которыми они будут взаимодействовать, и настроить параметры группы.

Настройка индикаторов сети на интерфейсах системы на уровне администратора ватс

Для настройки индикаторов сети на интерфейс системы используется следующая команда:

/domain/<DOMAIN>/alias/set-for-iface <GROUP_NAME> <INTERFACE> ni <VALUE>

Для настройки индикаторов сети профиля домена алиаса необходимо выполнить следующую команду:

/domain/<DOMAIN>/alias/set-for-domain ni <VALUE>

где

Настройка клиентов

Пробежимся по настройке основных пользовательских устройств. У наших сотрудников есть клиенты, работающие на Android, iOS и Windows 7. Оговоримся сразу: так как мы используем самосозданные сертификаты, то нам нужно несколько раз вносить всевозможные исключения и подтверждать действия. Если бы мы пользовали купленные сертификаты, возможно, все было бы проще.

Настройка локального адреса

Для настройки локального адреса RADIUS-клиента используется команда: 

/domain/<DOMAIN>/voip/aaa/accounting/set my_address <ADDRESS>

где

Настройка работы с radius c помощью web-конфигуратора

Работа с RADIUS настраивается также через расширенный web-конфигуратор в приложении Домены (Domains) → Свойства → RADIUS

Настройка серверов авторизации

RAIDUS сервера создаются для каждой виртуальной АТС отдельно, и затем могут быть использованы в подсистеме аккаунтинга.

Команды по настройки RADIUS серверов детально описаны в секции Команды настройки параметров соединения c RADIUS-сервером

Далее нужно назначить RADIUS сервера для авторизации командой:

/domain/<DOMAIN>/aaa/access/set servers add <ID>

где

Затем назначить имя пользователя и пароль, с которыми будут авторизоваться все вызовы данной виртуальной АТС:

/domain/<DOMAIN>/aaa/access/set login <login>/domain/<DOMAIN>/aaa/access/set password <password>

Для запуска RADIUS-клиента (включения взаимодействия с RADIUS-сервером авторизации) используется команда:

/domain/<DOMAIN>/aaa/access/set enable true

Если необходимо отключить RADIUS-клиента нужно установить значение “false” в команде.

Для просмотра данных о настройках подсистемы аккаунтинга используется команда:

/domain/<DOMAIN>/aaa/access/info

где

Настройка серверов аккаунтинга

RAIDUS сервера создаются для каждой виртуальной АТС отдельно, и затем могут быть использованы в подсистеме аккаунтинга.

Команды по настройки RADIUS серверов детально описаны в секции Команды настройки параметров соединения c RADIUS-сервером

Далее нужно назначить RADIUS-сервер для версии аккаунтинга командой:

/domain/<DOMAIN>/aaa/accounting/set servers add <ID>

где

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

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

/domain/<DOMAIN>/aaa/general/set if_radius_unavaliable [NI1] … [NI6]

где

Для настройки передачи на сервер аккаунтинга информации о “неуспешных” вызовах используется команда:

/domain/<DOMAIN>/aaa/accounting/set unsuccessful_call_info true

При этом в атрибутах cisco_vsa будет передаваться причина “неуспешного” вызова. Если необходимо отключить передачу на сервер аккаунтинга информации о “неуспешных” вызовах, то нужно установить значение “false”.

Следующая команда позволяет настроить профиль взаимодействия с системой учета, но в текущей версии программного обеспечения его устанавливать не требуется, поскольку в системе поддержан всего один профиль — CISCO_VSA. Профиль “default” соответствует CISCO_VSA.

/domain/<DOMAIN>/aaa/general/set profile <cisco_vsa|default>

Для возможности передачи промежуточных сообщений аккаунтинга необходимо настроить “интервал передачи промежуточных сообщений аккаунтинга”. Для этого воспользуйтесь командой:

/domain/<DOMAIN>/aaa/accounting/set interim_interval <value|disable|server_configured>

где

  • value — значение интервала в диапазоне от 60 до 86400 секунд;
  • disable — не передавать промежуточные сообщения аккаунтинга;
  • server_configured — использовать в качестве значения интервала значение, принятое от сервера авторизации в ответе access-accept.

Для запуска RADIUS-клиента (включения взаимодействия с RADIUS-сервером аккаунтинга) используется команда:

/domain/<DOMAIN>/aaa/accounting/set enable true

Если необходимо отключить RADIUS-клиента нужно установить значение “false” в команде.

Для просмотра данных о настройках подсистемы аккаунтинга используется команда:

/domain/<DOMAIN>/aaa/accounting/info

где

Настройка точки доступа

Главное, чтоб точка поддерживала нужный способ аутентификации. Оно может называться по разному в разных устройствах: WPA-EAP, WPA2 Enterprise и т.д. Во всяком случае выбираем аутентификацию, устанавливаем IP-адрес и порт RADIUS-сервера и ключ, который мы вводили в clients.conf при настройке Freeradius.

Приведу картинку с настроенной точки Ubiquiti. Помечено галкой то, что нужно менять.

image

Немного теории

Когда-то давно инженерами IEEE был придуман стандарт 802.1x. Этот стандарт отвечает за возможность авторизации пользователя сразу при подключении к среде передачи данных. Иными словами, если для соединения, например, PPPoE, вы подключаетесь к среде(коммутатору), и уже можете осуществлять передачу данных, авторизация нужна для выхода в интернет.

В случае же 802.1x вы не сможете делать ничего, пока не авторизуетесь. Само конечное устройство вас не допустит. Аналогичная ситуация с Wi-Fi точками доступа. Решение же о допуске вас принимается на внешнем сервере авторизации. Это может быть RADIUS, TACACS, TACACS и т.д.

Общая схема сети

Для наглядного понимания приведем общую схему работы нашей будущей схемы:

Настройка динамических абонентов и системы Radius

Параметры передающиеся на radius сервер

В таблице ниже представлены все параметры передающиеся на Radius сервер при запросах на номер динамического абонента. Если данные верны, Radius сервер возвращает access на запроса и обработка интерфейса продолжается как с локальным абонентом SSW.

Таблица 1 — параметры запроса на Radius сервер

Более подробно команды для работы с динамическими абонентами описаны в справочнике CLI, раздел Команды управления динамически конфигурируемыми интерфейсами

Понятия, определения

В системе поддерживаются три независимых режима работы с сервером RADIUS:

  1. Работа с сервером авторизации. Данный режим реализован для аутентификации и авторизации динамических абонентов, все аутентификационные данные в этом случае хранятся на RADIUS-сервере.
  2. Работа с сервером учета стоимости. В этом случае для всех вызовов, совершенных через виртуальную АТС, будут отправляться запросы аккаунтинга (accounting-request) на RADIUS-сервер;
  3. Внешняя маршрутизация посредством RADIUS-сервера.

Подсистема AAA позволяет проверять права на совершение вызовов абонентом, слежение за потреблением ресурсов абонентом.

Пример команд cocon-а по конфигурированию подсистемы aaa

После этого при вызовах будут идти запросы на система AAA.

Работа с сервером авторизации

Если нужно авторизовать все совершаемые через виртуальную АТС вызовы, то настраивается взаимодействие с RADIUS-сервером авторизации.

Работа с сервером аккаунтинга

Если нужно тарифицировать все совершаемые через виртуальную АТС вызовы, то настраивается взаимодействие с RADIUS-сервером аккаунтинга.

Система ESCC-10 в рамках виртуальной АТС поддерживает взаимодействие с несколькими серверами аккаунтинга. Если в течение определенного времени система не получает ответа от сервера, то выполняется повторная попытка отправки запроса на сервер. По истечении заданного числа попыток сервер считается неактивным. Запрос перенаправляется на другой сервер, если он указан, иначе детектируется сбой сервера.

При сбое сервера возможно установление ограничений на исходящую связь:

  • разрешать все вызовы;
  • разрешать вызовы только на локальные сети, междугородные сети, международные сети, спецслужбы, местные или зоновые сети (одновременно можно настроить любую комбинацию);
  • запрещать все вызовы.

Данное ограничение определяет возможность маршрутизации вызова на определенные интерфейсы системы, в настройках которых устанавливается соответствующее значение параметра признака номера. NumberIndicator — признак номера, принимает значения:

  • private — частная сеть;
  • local — местная сеть;
  • zone — зоновая сеть;
  • intercity — междугородная сеть;
  • international — международная сеть;
  • emergency — спецслужбы.

Порядок настройки:

  1. Настроить локальный адрес, на котором будет работать RADIUS-клиент.
  2. Настроить сервера аккаунтинга.
  3. При необходимости настроить индикаторы сети на интерфейсах системы.

Терминология

Вообще авторизация пользователя на точке может быть следующих видов:

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

Также существует довольно большое количество способов соедининея конечного устройства к серверу авторизации (PEAP, TLS, TTLS…). Я не буду их здесь описывать.

Формат пакетов radius и значение атрибутов cisco vsa

В системе поддержаны два независимых режима работы с сервером RADIUS:

  1. Работа с сервером авторизации. Данный режим реализован для аутентификации и авторизации динамических абонентов, все аутентификационные данные в этом случае хранятся на RADIUS-сервере. Используется пакет Аccess-Request.
  2. Работа с сервером учета (аккаунтинга). В этом случае для всех вызовов, совершенных через виртуальную АТС, будут отправляться запросы аккаунтинга (Accounting-Request) на RADIUS-сервер.

Описание каждого из режимов и процедуру настройки смотрите в Настройка динамических абонентов и системы Radius.

Описание каждого RADIUS-пакета состоит из описания всех пар Атрибут-Значение (Attribute-Value Pair) для этого типа пакета. Атрибуты могут быть как стандартными, так и специфичными атрибутами вендоров (Vendor-Specific Attribute). Если значение атрибута неизвестно (например, при отсутствии исходящего транка невозможно определить значение переменной CdPN_OUT, которое используется в качестве значения некоторых атрибутов), то этот атрибут не добавляется в сообщение.

Для стандартных атрибутов описание имеет вид:

Имя атрибута(Номер атрибута): Значение атрибута

Для специфичных атрибутов вендоров описание имеет вид:

Имя атрибута(Номер атрибута): Имя вендора(Номер вендора): Имя VSA: Значение VSA

где:

В качестве значения атрибута может использоваться конструкция вида <$NAME>, где NAME – это имя переменной. Описание значения переменных приведено ниже.

Пакет Аccess-Request:

В ответ на данное сообщение ожидается одно из следующих сообщений: Access-Reject — в случае, если не было дано разрешение на выполнение вызова; Access-Accept — в случае, если разрешение на выполнение вызова было получено. В сообщение Access-Accept могут присутствовать следующие атрибуты:

Стартовый пакет Accounting-Request (Start):

В ответ на данное сообщение ожидается сообщение Accounting-Response, в котором может присутствовать следующий атрибут:

Промежуточный пакет Interim Accounting Request (Update):

В ответ на данное сообщение ожидается сообщение Accounting-Response, в котором может присутствовать следующий атрибут:

Завершающий пакет Accounting-Request (Stop):

Таблица 2 — Описание переменных

ПеременнаяОписание и возможные значения
$CdPN_INномер вызываемого абонента до преобразования (принятого из интерфейса)
$CdPN_OUTномер вызывающего абонента после преобразования (переданного в интерфейс)
$CgPN_INномер вызывающего абонента до преобразования (принятого из интерфейса)
$CgPN_OUTномер вызывающего абонента после преобразования (переданного в интерфейс)
$LOCAL_DISCONNECT_CAUSEпричина завершения вызова в формате системы ECSS-10, описание значений приведено в следующей таблице
$DISCONNECT_CAUSEпричина завершения вызова согласно рекомендации Q.850
$CALL_TYPEтип вызова, всегда “Telephony”
$CALL_IDидентификатор вызова
$SSW_IPIP-адрес интерфейса системы ECSS-10, аутентифицирующего пользователя
$SSW_PORTтранспортный порт интерфейса системы ECSS-10, аутентифицирующего пользователя
$ROUTE_RETRIESтекущий номер попытки, отсчёт начинается с 1 (для первой попытки, соответственно)
$SESSION_IDидентификатор сессии
$INTERIM_SESSION_TIMEвремя разговора к моменту отправки промежуточного сообщения
$SESSION_TIMEвремя продолжительности разговора
$TIME_SETUPвремя поступления инициирующего запроса во входящий интерфейс в формате hh:mm:ss.uuu t www MMM dd yyyy
$TIME_CONNECTвремя ответа вызываемой стороны в формате hh:mm:ss.uuu t www MMM dd yyyy
$TIME_DISCONNECTвремя отбоя вызова одной из сторон в формате hh:mm:ss.uuu t www MMM dd yyyy
$DOMAINимя виртуальной АТС
$Authуникальный идентификатор запроса
$InTrunkGroupимя входящей транковой группы
$OutTrunkGroupимя исходящей транковой группы
$InIfaceимя входящего интерфейса
$OutIfaceимя исходящего интерфейса
$INTERIM_INTERVALинтервал времени (в секундах), через который будут посылаться промежуточные Acct-Interim-Update сообщения. Значение должно быть не меньше 60. В случае, если на уровне домена задано свойство interim_interval (domain/DOMAIN_NAME/aaa/accounting/info), то значение $INTERIM_INTERVAL будет вычислено на основе его значения
$SESSION_TIMEOUTвыделенное время на разговор (в секундах). В случае, если время равно 0 — то вызов запрещен. -1 — вызов не ограничен
$H323_CREDIT_TIMEвыделенное время на разговор (в секундах). В случае, если время равно 0 — то вызов запрещен. -1 — вызов не ограничен. В случае, если данный параметр пришел на Acct-Interim-Update запрос, то это время на оставшуюся часть разговора

Таблица 3 – Описание внутренних системных причин разъединения, которые могут передаваться в LOCAL_DISCONNECT_CAUSE

Внутренняя причинаЗначение причины согласно рекомендации Q.850Описание
normal16нормальное разъединение
originationDenied16абоненту запрещено совершать вызов, возможно административная блокировка
authorisationFailure50ошибка авторизации
aPtyAbandon16вызывающий абонент положил трубку до ответа
invalidCollectedInformation1номер набран неверно, не найден маршрут
collectInformationFailure1ошибка сбора цифр номера, может возникнуть, когда система ожидает дополнительных цифр номера, но они не поступают до истечения таймера
aPtyDisc16разъединение по инициативе вызывающего абонента
bPtyDisc16разъединение по инициативе вызываемого абонента
routeSelectFailure1ошибка установления соединения, обычно возникает, когда все каналы в исходящем интерфейсе заняты либо от интерфейса принята ошибка
oNoAnswer34внутренняя ошибка, возникает, когда таймер ожидания ответа в плече вызывающего абонента истек, а со стороны плеча вызываемого абонента не было ни ответа, ни сообщения отбоя
terminationDenied27вызов на вызываемого абонента запрещен, например абонент заблокирован
notReachable3вызываемый абонент недоступен, например не зарегистрирован или номер не существует
bPtyNoAnswer18вызываемый абонент не отвечает
bPtyBusyUDUB17отбой по инициативе вызываемого абонента до ответа
bPtyBusyNDUB17вызываемый абонент занят
ss7Failure38ошибка на сети ОКС7
calledPartyRejected21вызов к вызываемому абоненту запрещен, например анонимный вызов на абонента с активным сервисом ACB
tException41ошибка обслуживания вызова, возникает обычно в случае системных проблем
routeFailure12ошибка маршрутизации к вызываемому абоненту по причине занятости всех каналов в исходящем транке
routeFailure22ошибка маршрутизации к вызываемому абоненту по причине занятости всех каналов направления на каком-то транзитном участке сети
conversationTimeout31возникает, когда истек таймер, ограничивающий общую продолжительность разговора
systemFailure127внутренняя неустранимая ошибка, детальное описание ошибки доступно в системном журнале

Были добавлены RADIUS атрибуты вендора:

  • xpgk-original-called-number-in — Оригинальный номер вызываемого абонента до преобразования
  • xpgk-redirected-number-in — Номер абонента который совершил переадресацию до преобразования
  • xpgk-original-called-number-out — Оригинальный номер вызываемого абонента после преобразования
  • xpgk-redirected-number-out — Номер абонента который совершил переадресацию после преобразования

Этапы работы подсистемы ааа

Подсистема AAA подключается при обработки вызова на нижеперечисленных этапах (каждым из этапом может отсутствовать)

Похожее:  5 менеджеров входа в систему и как изменить тот, который вы используете | Убунлог

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *