Стартова запис (Accounting start record)
Посилається на RADIUS-сервер при отриманні дзвінка (вхідний ділянку дзвінка) або при
Ви надсилаєте ПП SETUP стороні, терминирующего виклик (вихідний ділянку дзвінка).
Тип запиту - AccountingRequest (Code 4)
Таблиця 1. Структура стартовою записи (Accounting Start), що відправляється на RADIUS сервер:
В поле AcctSessionId дані представлені в форматі:
Очікувана відповідь - AccountingResponse.
Стоп запис (Accounting stop record)
Відправляється RADIUS-сервера при завершенні дзвінка.
Тип запиту - AccountingRequest (Code 4)
Примітка: стоп запис (пакет Accountin Stop), що посилається MVTS на RADIUS-сервер
може іноді значно перевищувати максимально можливий розмір UDP-пакета,
заданий в операційній системі - 1500 байт. Оскільки не всі мережеві маршрутизатори
здатні відновлювати передані пакети, розбиті на фрагменти, RADIUS-
сервер, при відсутності пакету Accounting Stop, продовжує нарахування оплати за дзвінком
навіть після того, як даний дзвінок був завершений.
Для вирішення даної проблеми використовуйте параметр stop_acct_level = в секції
[Radius], що дозволяє зменшити розмір пакетів Accounting Stop за рахунок вирізання з
них деяких VSA-полів.
Таблиця 2. Структура стоп записи (Accounting Stop), що відправляється на RADIUS сервер
Зовнішня маршрутизація за допомогою RADIUS
Запит AccessRequest при зовнішньої маршрутизації
MVTS виконує даний запит, якщо в поле gateway = в описі об'єкта набору
(Dial peer) знаходиться ключове слово EXTERNAL.
Мета даного запиту - отримати маршрути для термінації дзвінка в кінцевому пункті.
При цьому існує можливість змінювати ім'я користувача та пароль для даного дзвінка.
Можлива обробка декількох маршрутів, виконувана послідовним
переходом до наступного машрут в разі неможливості термінації виклику по
поточному шляху.
Тип запиту - AccessRequest (Code 1)
Таблиця 3. Структура запиту до RADIUS сервера на маршрутизацію
Таблиця 4 Структура відповіді AccessAccept RADIUS сервера на запит про
маршрутизації
Формат поля XPGK_XROUTING_ROUTING:
Запит про завершення дзвінка, що надходить від RADIUS-сервера
MVTS здатний обробляти запит від RADIUS-сервера на завершення дзвінка
DisconnectRequest (type 40).
У цьому пакеті повинно бути присутнім поле VSA h323-conf-id або VSA
h323_incoming-conf-id у форматі 4 шістнадцяткових октету, розділених пропуском
(Аналогічно тому, як MVTS відправляє ConfId на RADIUS-сервер). цей ConfId
використовується для пошуку активного дзвінка. Дзвінок завершується з локальним кодом 100
(ForceTerminateCall).
Якщо завершення дзвінка пройшло успішно, то MVTS відповідає пакетом
DisconnectAck (type41). Якщо неуспішно, наприклад, такий дзвінок не знайдений, або
відсутня поле з ConfId, то MVTS відповідає DisconnectNack (type 42).
якщо маршрут дозволений і знайдений Radius відповідає
у всіх прикладах виведення верхній рядок є ковій рядком, просто вказує час, і напрям руху запитів. Параметр "session id" є ідентифікатором дзвінка.
Далі SS по одному перебирає видані йому маршрути. Первй параметр в маршруті - ім'я gateway (унікальне) береться з автоматично довантажувати файлу gateway.cfg. Вирізка з нього представлена нижче:
на прикладі 1го gateway:
шлях до каталогу в підкаталозі cfg якого знаходиться gateway.cfg задається довільний (за замовчуванням він дорівнює / mvts, але можна вказати замість - будь-який інший,
тобто gateway.cfg знаходиться за замовчуванням в /mvts/cfg/gateway.cfg)
Після йде запит на accounting Radius:
на що отримує відповідь
по завершенні спроби дзвінка на 1й маршрут шле запит
на що отримує відповідь
якщо 1й постачальник відбив кодом за яким дзвінок повинен перейти далі - йде на следуйщій маршрут:
Все CDR лягають в файли по годинах (в одному файлі CDR за 1 годину). Шлях до каталогу з CDR задається довільний (на поточний момент / mvts / billing /),
назва файлу повинна складатися з довільного префікса (в теперішній час використовуємо bill) і дати / часу в форматі ГГГГммдд_ччммсс, де ММСС завжди 0000 наприклад
стандартна запис CDR
Нижче розкладено по рядках: