MERA VoIP Transit Softswitch v 3.1 -...

MERA VoIP Transit Softswitch v 3.1.2 Руководство по эксплуатации

© MERA

MERA VoIP Transit Softswich v 3.1.2

Документ №:

Тип документа: Руководство по эксплуатации

Дата выпуска:

Copyr ight © 1999-2004 Mera Systems Inc. Systems Inc. Al l r ights reserved. Mera Systems Inc. Systems Inc. оставляет за собой право вносить изменения в содержащуюся в данном документе информацию без предварительного уведомления .

ИНФОРМАЦИЯ О ПРАВЕ СОБСТВЕННОСТИ Информация , содержащаяся в данном документе , является собственностью Mera Systems Inc. Systems Inc. Никакая часть этого документа не может быть воспроизведена или заимствована в какой бы то ни было форме или каким-либо способом – в графическом , электронном виде или механическим путем , включая фотокопирование , запись , в том числе и на магнитные носители , или любые другие устройства , предназначенные для хранения информации – без письменного разрешения Mera Systems Inc. Systems Inc. Подобное разрешение не может быть выдано третьей стороной , будь то организация или частное лицо .

2

Хронология изменений

Таблица 1 Изменения, внесенные в документ

Дата Версия документа Изменение и лицо, его внесшее

02.09.05 Release azharkov: описана возможность указывать имя оригинатора или терминатора звонка в команде консоли show call (Синтаксис: sh ca [-dstname ...] [-srcname ...]), добавлены скриншоты

02.09.05 Release azharkov: добавлено описание ACD (в таблицу акронимов)

02.09.05 Release azharkov: описаны два новых поля CDR: PDD Time и PDD Reason

02.09.05 Release azharkov: примечание по команде show dp – ограничение вывода диалпиров

02.09.05 Release azharkov : описан новый локальный код 130

02.09.05 Release azharkov: описано новое поле пакета access request на RADIUS для аутентификации пользователя.

02.09.05 Release azharkov: добавлено примечание об отправке email-сообщения в случае падения основного сервера MVTS

02.09.05 Release azharkov: описано новое поле пакета AccessAccept в ответ на запрос о внешней маршрутизации.

15.09.05 Release azharkov: изменены названия документов в Справочной литературе,

изменено название самого документа,

добавлен скриншот команды di gk

Заменен пример CDR-записи, как устаревший

В таблицу параметров CDR вставлено описание SRC-RTP-IP и

DST-RTP-IP

19.09.05 Release azharkov: внесены изменения в таблицы «Определения» и «Сокращения»

20.09.05 Release azharkov: изменена глава 7.3 «файловые дескрипторы»

22.11.05 Release askudalov: добавлена глава «Аутентификация RAS-пользователей, не описанных в файле user.cfg»

30.01.06 Release ozabytina: добавлено описание новых команд show

3

snmp и di gk all

описаны новые локальные коды 132, 213, 134, 135, 136, 137

28.02.2006 Release ozabytina: добавлено описание новых команд show media (отображает информацию о работе медиа MVTS) и show converter (отображает информацию о работе модуля SIP-HIT).

06.03.2006 Release ozabytina: обновлена таблица локальных кодов разъединения MVTS

20.04.2006 Release azharkov: документ обновлен в соответствии с последними данными от разработчиков

11.07.2006 Release azharkov: обновлена глава по SNMP-статистике и регулярным выражениям

документ обновлен в соответствии с последними данными от разработчиков

4

Содержание

1 ВВЕДЕНИЕ .................................................................................................................. 12 1.1. АННОТАЦИЯ ............................................................................................................. 12 1.2. АУДИТОРИЯ .............................................................................................................. 12 1.3. ТИПОГРАФИЧЕСКИЕ СОГЛАШЕНИЯ .......................................................................... 12 1.4. ОРГАНИЗАЦИЯ ДОКУМЕНТА ..................................................................................... 12

2 ОБЗОР ПРИЛОЖЕНИЯ MVTS............................................................................... 14 2.1. ПРЕДНАЗНАЧЕНИЕ .................................................................................................... 14 2.2 ТЕХНИЧЕСКИЕ ХАРАКТЕРИСТИКИ ............................................................................ 14 2.3 ОДНОСЕРВЕРНЫЙ MVTS ......................................................................................... 16 2.4 КЛАСТЕРНЫЕ СИСТЕМЫ MVTS ............................................................................... 17

2.4.1 Принципы построения кластерных систем ................................................... 17 2.4.2 Регулятор распределения нагрузки ................................................................ 18 2.4.3 Сигнальный MVTS (SMVTS) ......................................................................... 19 2.4.4 Media MVTS ..................................................................................................... 19

2.5 МОДУЛЬ SIP–HIT .................................................................................................... 19 2.6 МОДУЛЬ MVTS TAP ............................................................................................... 20

3 УСТАНОВКА .............................................................................................................. 22 3.1 ПЛАНИРОВАНИЕ УСТАНОВКИ................................................................................... 22 3.1.1 ТРЕБОВАНИЯ К АППАРАТНЫМ СРЕДСТВАМ .............................................................. 22

3.1.2 Сетевое окружение .......................................................................................... 23 3.1.3 Операционная система .................................................................................... 24

3.2 РЕКОМЕНДАЦИИ ПО УСТАНОВКЕ ПРИЛОЖЕНИЯ....................................................... 24 3.2.1 Файловые системы ........................................................................................... 24 3.2.2 Файловые дескрипторы ................................................................................... 25 3.2.3 Пользователи и группы пользователей.......................................................... 25

3.3 УСТАНОВКА ПРИЛОЖЕНИЯ MVTS........................................................................... 26 3.4 ЗАДАЧИ ПОСЛЕ УСТАНОВКИ ПРИЛОЖЕНИЯ .............................................................. 30

3.4.1 Межсетевой экран (firewall)............................................................................ 30 3.4.2 HASP-ключи ..................................................................................................... 30

4 НАСТРОЙКА MVTS.................................................................................................. 32

4.1 ОБЗОР КОНФИГУРАЦИОННЫХ ФАЙЛОВ .................................................................... 32 4.2 СТРУКТУРА КОНФИГУРАЦИОННЫХ ФАЙЛОВ............................................................ 33

5 ЭКСПЛУАТАЦИЯ MVTS......................................................................................... 35 5.1 КОНСОЛЬ АДМИНИСТРИРОВАНИЯ ............................................................................ 35

5.1.1 Запуск и остановка консоли администрирования MVTS............................. 36 5.1.2 Команды консоли администрирования.......................................................... 37

5.2 СТРУКТУРА CDR-ФАЙЛОВ ....................................................................................... 64 5.3 ПРОТОКОЛИРОВАНИЕ MVTS ................................................................................... 68

5.3.1 Трассировочные протоколы............................................................................ 69 5.3.2 Отладочные протоколы ................................................................................... 70 5.3.2.1 Параметры протоколирования........................................................................ 70 5.3.2.2 Степень детализации информации................................................................. 70

5

5.3.2.3 Частота смены файла протокола .................................................................... 72 5.3.2.4 Имя файла протокола....................................................................................... 72 5.3.3 Особенности протоколирования..................................................................... 72

5.4 WEB-ИНТЕРФЕЙС MVTS (MVTS WEB MONITOR) ................................................ 74 5.4.1 Настройка и эксплуатация Web-интерфейса................................................. 74 5.4.2 Настройка языка интерфейса .......................................................................... 78

5.5 ЯДРО MVTS ............................................................................................................. 80 5.5.1 Параметры командной строки ........................................................................ 80 5.5.2 Скрипт запуска ядра mp_kernel.sh.................................................................. 82

5.6 УДАЛЕНИЕ/АРХИВАЦИЯ УСТАРЕВШИХ ФАЙЛОВ ...................................................... 82 5.6.1 Файл rotate.cfg .................................................................................................. 82

5.7 РЕЗЕРВИРОВАНИЕ СИСТЕМЫ, НАХОДЯЩЕЙСЯ ПОД КОММЕРЧЕСКОЙ НАГРУЗКОЙ ............................................................................................................... 84

6 ПОИСК И УСТРАНЕНИЕ НЕИСПРАВНОСТЕЙ .............................................. 85 6.1 НЕИСПРАВНОСТИ И СПОСОБЫ ИХ УСТРАНЕНИЯ ....................................................... 89

7 СПРАВОЧНАЯ ИНФОРМАЦИЯ ........................................................................... 93

7.1 АЛГОРИТМ ВЫБОРА ОБЪЕКТА НАБОРА ..................................................................... 93 7.2 ВЗАИМОДЕЙСТВИЕ MVTS С RADIUS-СЕРВЕРОМ................................................... 95

7.2.1 Проведение авторизации регистрируемого конечного пользователя......... 95 7.2.2 Авторизация вызова......................................................................................... 96 7.2.3 Сервис учета времении и причитающейся платы (тип запроса

Accounting Request).......................................................................................... 98 7.2.4 Внешняя маршрутизация с помощью Radius .............................................. 104 7.2.5 Запрос о завершении звонка, поступающий от RADIUS-сервера ............ 108 7.2.6 Аутентификация RAS-пользователей, не описанных в файле

user.cfg............................................................................................................. 108 7.3 СОЗДАНИЕ НЕОБХОДИМОГО КОЛИЧЕСТВА ФАЙЛОВЫХ ДЕСКРИПТОРОВ................ 112

7.3.1 Увеличение количества файловых дескрипторов в ОС Red Hat Linux ................................................................................................................ 112

7.3.2 Установка количества файловых дескрипторов для ОС FreeBSD............ 115 7.4 ИСПОЛЬЗОВАНИЕ РЕГУЛЯРНЫХ ВЫРАЖЕНИЙ В КОНФИГУРАЦИИ MVTS .............. 116

7.4.1 Префиксы полей dst_pattern и src_pattern .................................................... 116 7.4.2 Трансляция номеров ...................................................................................... 117

7.5 ИСПОЛЬЗОВАНИЕ МАКРОИМЕН В СХЕМАХ ТРАНСЛЯЦИИ НОМЕРОВ ...................... 120 7.6 ДЕИНСТАЛЛЯЦИЯ MVTS ....................................................................................... 121 7.7 ОПРЕДЕЛЕНИЯ ........................................................................................................ 121 7.8 СОКРАЩЕНИЯ ......................................................................................................... 122

ПРИЛОЖЕНИЕ A СИНТАКСИС РЕГУЛЯРНЫХ ВЫРАЖЕНИЙ ................. 125

ПРИЛОЖЕНИЕ B SNMP-СТАТИСТИКА ............................................................. 128

ПРИЛОЖЕНИЕ С ЛОКАЛЬНЫЕ КОДЫ РАЗЪЕДИНЕНИЯ MVTS .............. 133

ПРИЛОЖЕНИЕ D СОВМЕСТИМОСТЬ ОБОРУДОВАНИЯ ............................. 139

VoIP- шлюзы и привратники .................................................................................... 139 Системы учета и начисления оплаты ....................................................................... 139

6

Список таблиц

Таблица 1 Изменения, внесенные в документ .................................................................... 3

Таблица 2 Список справочной литературы ....................................................................... 11

Таблица 3 Соглашения и обозначения, принятые в документе ...................................... 12

Таблица 4 Рекомендуемая конфигурация (только привратник) ..................................... 22

Таблица 5 Рекомендуемая конфигурация (при проксировании только сигнального трафика) ........................................................................................................................ 22

Таблица 6 Рекомендуемая конфигурация (полное проксирование) ............................... 23

Таблица 7 Группы пользователей MVTS .......................................................................... 26

Таблица 8 Конфигурационные файлы MVTS................................................................... 32

Таблица 9 Поля, выводимые командой show call для группы звонков .......................... 43

Таблица 10 Поля, выводимые командой show call с аргументом ICN ........................... 44

Таблица 11 Поля, выводимые командой sh ep .................................................................. 49

Таблица 12 Поля, выводимые командой «show dp» для каждого объекта набора ........ 51

Таблица 13 Параметры команды «show redundancy»....................................................... 58

Таблица 14 Параметры команды «show snmp»................................................................. 60

Таблица 15 Структура записи с данными о звонке (CDR) .............................................. 64

Таблица 16 Параметры командной строки ядра MVTS (mp_kerneld.x) ......................... 80

Таблица 17 Список неисправностей и способы их устранения ...................................... 89

Таблица 18 Содержимое запроса AccessRequest от MVTS к RADIUS-серверу при авторизации RAS-пользователя.................................................................................. 95

Таблица 19 Содержимое ответа AccessAccept от RADIUS-сервера при авторизации RAS-пользователя ........................................................................................................ 96

Таблица 20 Содержимое запроса AccessRequest от MVTS к RADIUS-серверу при авторизации вызова по выбранному направлению .................................................. 96

Таблица 21 Содержимое ответа AccessAccept от RADIUS сервера при авторизации терминации вызова по выбранному направлению ................................................... 98

Таблица 22 Структура стартовой записи (Accounting Start), отправляемой на RADIUS сервер ............................................................................................................................ 99

Таблица 23 Структура стоп записи (Accounting Stop), отправляемой на RADIUS сервер...................................................................................................................................... 101

Таблица 24 Структура запроса к RADIUS серверу на маршрутизацию....................... 105

Таблица 25 Структура ответа AccessAccept RADIUS сервера на запрос о маршрутизации........................................................................................................... 107

Таблица 26 Список терминов, используемых в документе ........................................... 121

Таблица 27 Список сокращений ....................................................................................... 122

7

Таблица 28 Список квантификаторов .............................................................................. 126

Таблица 29 Таблица локальных кодов разъединения, генерируемых MVTS.............. 133

8

Список рисунков

Рис. 1 Односерверный MVTS ............................................................................................. 16

Рис. 2 Двухуровневая кластерная версия MVTS .............................................................. 17

Рис. 3 Трехуровневая кластерная версия MVTS............................................................... 18

Рис. 4 Использование модуля SIP-HIT для трансляции протоколов SIP и H.323 ......... 20

Рис. 5 Взаимодействие MVTS с модулем MVTS TAP ..................................................... 21

Рис. 6 Структура файловой системы MVTS ..................................................................... 28

Рис. 7 Вывод командной консоли MVTS .......................................................................... 36

Рис. 8 Вывод команды «help» ............................................................................................. 38

Рис. 9 Вывод команды «reload config»............................................................................... 39

Рис. 10 Запуск ядра MVTS .................................................................................................. 40

Рис. 11 Остановка MVTS .................................................................................................... 40

Рис. 12 Завершение звонка.................................................................................................. 41

Рис. 13 Вывод команды «show call»................................................................................... 41

Рис. 14 Вывод команды «show call» с аргументом «table» .............................................. 42

Рис. 15 Вывод команды «show call» с аргументом «table» и «name» ............................. 42

Рис. 16 Вывод команды «sh ca» с внутренним номером звонка в качестве аргумента 43

Рис. 17 Вывод команды «show dial»................................................................................... 46

Рис. 18 Вывод команды «show stat rt»................................................................................ 46

Рис. 19 Вывод на экран имени файла со статистикой ...................................................... 48

Рис. 20 Вывод команды «show stat param» ........................................................................ 49

Рис. 21 Список диалпиров, отображаемых командой «sh dp» ........................................ 51

Рис. 22 Список шлюзов, отображаемых командой ‘show gw’......................................... 52

Рис. 23 Отображение информации по отдельному шлюзу .............................................. 53

Рис. 24 Отображение информации о конвертере SIP-HIT............................................... 54

Рис. 25 Отображение нагрузки на локальный IP-адреса.................................................. 55

Рис. 26 Вывод команды show media................................................................................... 55

Рис. 27 Общая статистика MVTS сервера ......................................................................... 57

Рис. 28 Вывод команды «show stat src <name>» ............................................................... 58

Рис. 29 Вывод команды «sh re» .......................................................................................... 58

Рис. 30 Вывод команды «show snmp»................................................................................ 60

Рис. 31 Вывод команды sh gk.............................................................................................. 62

Рис. 32 Диалог авторизации web-интерфейса ................................................................... 74

9

Рис. 33 Главное меню Администратора ............................................................................ 75

Рис. 34 Главное меню Клиента ........................................................................................... 76

Рис. 35 Список существующих учетных записей ............................................................. 77

Рис. 36 Диалог редактирования учетной записи............................................................... 77

Рис. 37 Страница локализации web-интерфейса............................................................... 79

Рис. 38 Выпадающий список вариантов языка ................................................................. 80

Рис. 39 Новый язык интерфейса (испанский) ................................................................... 80

Рис. 40 Стандартная RADIUS аутентификация .............................................................. 109

Рис. 41 Аутетнтификация по хэш-паролю MD5 ............................................................. 110

Рис. 42 Аутентификация по CHAP-паролю .................................................................... 111

Рис. 43 Дайджест-аутентификация .................................................................................. 112

10

Справочная литература

Таблица 2 Список справочной литературы

Ссылка Название документа [1] ITU-T Recommendation H.323 “Packet-based multimedia

communications systems” [2] RFC 1889 “RTP: A Transport Protocol for Real-Time

Applications. Audio-Video” [3] ITU-T Recommendation H.245 “Control protocol for

multimedia communication” [4] ITU-T Recommendation H.225, “Call signaling protocols and

media stream packetization for packet based multimedia communication systems”

[5] Remote Authentication Dial-In User Service (RADIUS), RFC 2138, April 1997 (http://www.pasteur.fr/cgi-bin/mfs/01/21xx/2138?8#mfs)

[6] ITU-T Recommendation Q.931: “ISDN user-network interface layer 3 specification for basic call control”

[7] RADIUS Accounting, RFC 2139, April 1997 (http://www.pasteur.fr/cgi-bin/mfs/01/21xx/2139)

[8] Jeffrey Friedl “Mastering Regular Expressions”, O’Reilly, 1997, ISBN: 5-318-00056-8

[9]

FreeBSD Handbook. The FreeBSD Documentation Project. Copyright © 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002 by The FreeBSD Documentation Project Red Hat Linux Manuals. Red Hat Linux 7.2. “x86 Installation Guide”, “Getting Started Guide”, “Customization Guide”, “Reference Guide”. Copyright © by Red Hat Inc.

[10] ITU-T Recommendation T.38 “Procedures for real-time Group 3 facsimile communication over IP networks”, June 1998

[11] Mozilla Public License, version 1.1. http://www.mozilla.org/MPL/MPL-1.1.html

[12] “Конфигурирование MVTS” [13] “MVTS Management System” [14] “Схемы резервирования MVTS” [15] “MVTS-СОРМ интерфейс для операторов телефонии” [16] “Кластерные системы MVTS”

11

http://www.pasteur.fr/cgi-bin/mfs/01/21xx/2138?8#mfs

http://www.pasteur.fr/cgi-bin/mfs/01/21xx/2138?8#mfs

http://www.pasteur.fr/cgi-bin/mfs/01/21xx/2139

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ln16.html

http://www.redhat.com/docs/manuals/linux/

http://www.mozilla.org/MPL/MPL-1.1.html

1 ВВЕДЕНИЕ

1.1. АННОТАЦИЯ В настоящем руководстве приводится описание продукта MERA VoIP Transit Softswitch v.3.1.2 (в дальнейшем MVTS), его структуры, порядка установки и настройки. В руководстве подробно отражены возможности по администрированию и настройке всех подсистем и компонентов MVTS.

1.2. АУДИТОРИЯ Настоящее руководство предназначено для системного администратора, в обязанности которого входят установка, настройка и эксплуатация MVTS. Предполагается, что пользователи документа обладают практическими знаниями UNIX-подобных ОС (FreeBSD, Red Hat Linux) и некоторым опытом работы с регулярными выражениями.

1.3. ТИПОГРАФИЧЕСКИЕ СОГЛАШЕНИЯ Обозначения, использованные в данном документе, приведены ниже (Таблица 3).

Таблица 3 Соглашения и обозначения, принятые в документе

Пример Назначение

Примечание: текст Информация, требующая специального внимания.

[N] Ссылка на другой документ

void Примеры исходного кода, информации, выводимой программой, протоколов, конфигурационных файлов и т.п.

[user@localhost]# cat user.cfg

Снимки экрана, демонстрирующие введенные в командную строку команды для выполнения

CallingStationId Setup

Параметры звонка и названия стадий сессий звонка

ulimit Имя программы или файла, когда оно встречается в основном тексте документа.

call_radix= Названия параметров конфигурационных файлов и их секций

1.4. ОРГАНИЗАЦИЯ ДОКУМЕНТА

Документ состоит из следующих основных частей:

Глава 1: Введение содержит сведения о назначении и организации документа.

12

Глава 2: Обзор приложения MVTS содержит краткое описание продукта: его назначение, варианты применения, поддерживаемые функции и стандарты, и, кроме того, общие сведения об организации программного и аппаратного обеспечения продукта.

Глава 3: Установка рассматривает процесс установки MVTS, начиная с требований к аппаратной части продукта, операционной системы, пошагового алгоритма установки прикладного программного обеспечения MVTS и заканчивая описанием задач, которые необходимо выполнить после его установки.

Глава 4: Конфигурирование MVTS посвящена вопросам первоначальной настройки MVTS и дает обзор файлов, необходимых для осуществления данной процедуры.

Глава 5: Эксплуатация MVTS освещает вопросы эксплуатации продукта, а также описывает возможности администрирования и управления, предоставляемые системой. Глава разделена на подглавы, позволяющие получить информацию о средствах администрирования MVTS: консоли администрирования MVTS и приложении MVTS Web Monitor. Кроме того, в главе приводится описание CDR-файлов, отладочных и трассировочных протоколов и других системных файлов, также необходимых для администрирования и эксплуатации MVTS.

Глава 6: Поиск и устранение неисправностей содержит сведения о наиболее частых неполадках, описывает их признаки и способы устранения причин сбоев. В главу включен пошаговый алгоритм поиска и устранения неисправностей в зависимости от самой проблем, а так же таблица «Неисправности и способы их устранения».

Глава 7: Справочная информация приводит дополнительные, но тем не менее важные сведения, касающиеся использования регулярных выражений при конфигурировании приложения MVTS, алгоритма поиска объекта набора, взаимодеиствия MVTS с RADIUS-сервером, трансляции номеров, определений и сокращений, используемых в настоящем руководстве, и др.

Приложение A целиком посвящено описанию регулярных выражений.

Приложение B содержит сведения об SNMP-статистике.

Приложение C представляет собой таблицу локальных кодов разъединения MVTS.

Приложение D содержит список VoIP-оборудования (шлюзы, привратники, биллинг-системы), прошедшего тестирование на совместимость с MVTS.

13

2 ОБЗОР ПРИЛОЖЕНИЯ MVTS

2.1. ПРЕДНАЗНАЧЕНИЕ MERA VoIP Transit Softswitch (сокращенно MVTS) - это программное VoIP-устройство коммутации вызовов с функциями привратника (gatekeeper) и проксирования. MVTS представляет собой программно-аппаратный комплекс, подключаемый к VoIP-сети и предназначенный для маршрутизации трафика IP-телефонии между шлюзами.

Несмотря на скромные требования к аппаратному обеспечению, MVTS является полнофункциональным решением, которое предоставляет провайдеру следующие преимущества:

• Сокрытие реальной структуры собственной сети и корпоративных сетей клиентов.

• Обслуживание статических и динамических пользователей

• Возможность двусторонней конвертации сигнальных протоколов SIP и H.323, а также конвертации аудио кодеков (за счет использования модуля SIP-HIT)

• Использование внутреннего механизма маршрутизации вызовов и маршрутизация с помощью внешнего RADIUS-сервера

• Ведение учета начисленной платы на основе записей о звонке (Call Detail Records), а также с помощью RADIUS API

• Решение проблемы совместимости оборудования разных производителей (например, Cisco и VocalTec).

• Получение надежной системы с высокой производительностью (до 40 000 одновременных вызовов) и развитой системой контроля.

• Эффективное использование ресурсов сети за счет механизма распределения нагрузки (Load Balancing) и управления пропускной способностью (bandwidth management).

2.2 ТЕХНИЧЕСКИЕ ХАРАКТЕРИСТИКИ

Поддерживаемые протоколы

• H.323 v.2

• H.245 v.7, H.225 v.4

• SIP v.2 RFC 2543bis (модуль SIP-HIT)

• RTP/RTCP

• T.38, T.120

• SNMP v.1 (statistics and trap)

14

http://www.mera-voip.com/ru/voip/sip-hit.php

• MD5, CHAP

• RADIUS (авторизация пользователей)

• RADIUS Attribute 44 и VSA (учет начисленной платы) [6]

Операционные системы

• Linux Red Hat 9.0;

• Linux Red Hat Enterprise 3.0, 4.0;

• Linux Red Hat Advanced Server 3;

• Linux Fedora Core 3,4;

• FreeBSD 5.0 и выше (только для тестовой версии).

Примечание: приложение MVTS работает под управлением операционных систем Linux с версией ядра 2.4 – 2.6.

Ведение отладочных протоколов

• трассировка действий по обработке звонков с выбором уровня детализации

• отладочные протоколы с выбором уровня детализации

• log extractor – утилита для получения протокола сессии с помощью идентификатора звонка (Call ID)

• просмотр протоколов сессии с использованием MVTS Manager

• автоматизация записи отладочных протоколов: архивирование, управление размером и временем существования файлов (log rotation)

Отказоустойчивость

• удаленный SNMP-мониторинг посредством MVTS Manager или стороннего SNMP-клиента

• встроенный 'watch dog' таймер

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

• дублирование основного MVTS-сервера (system redundancy) [14]

• механизм поддержки альтернативного RADIUS-сервера

Производительность

• стандартные конфигурации системы (односерверный вариант) с количеством одновременных звонков, кратных потоку E1: от 30 до 1500

15

• двух- и трехуровневые кластерные решения с производительностью от 4 500 до 40 000 одновременных сессий

2.3 ОДНОСЕРВЕРНЫЙ MVTS

На Рис. 1 изображен односерверный MVTS с зарегистрированными на нем статическими и динамическими пользователями, резервным сервером MVTS, основным и вспомогательным сервером RADIUS.

Рис. 1 Односерверный MVTS

Односерверный MVTS представляет собой контроллер соединений с функциями сигнального и media-проксирования. Работа в режиме полного проксирования (проксирование сигнального и мультимедийного трафика) требует большой вычислительной мощности аппаратной платформы, поэтому односерверная версия приложения способна обрабатывать около 1 200 одновременных соединений. Соответственно, увеличение объема трафика повлечет за собой необходимость установки дополнительных платформ с приложением MVTS и их объединения под контролем устройства управления.

Кластеризация MVTS позволяет увеличить объем обрабатываемого VoIP-трафика в несколько раз.

16

2.4 КЛАСТЕРНЫЕ СИСТЕМЫ MVTS Работа под большими коммерческими нагрузками требует разделения основных функций MVTS (сигнальное и media-проксирование, функция привратника и т.д.) между компонентами кластерной версии MVTS [16].

2.4.1 ПРИНЦИПЫ ПОСТРОЕНИЯ КЛАСТЕРНЫХ СИСТЕМ В кластерной версии MVTS проксирование media-трафика становится единственной задачей media-сервера, который в дальнейшем мы будем называть MMVTS (Media MVTS). В то же время все задачи, связанные с маршрутизацией вызовов, учетом и начислением причитающейся платы, взаимодействием с RADIUS-сервером будут выполняться системой, которая называется сигнальный MVTS (SMVTS). Так как задачи по маршрутизации звонков, учету платы и т.д. не требуют большой вычислительной мощности, один SMVTS может контролировать несколько MMVTS (обычно три).

Таким образом, базовая (двухуровневая) конфигурация кластерной версии системы состоит из:

• cигнального MVTS (SMVTS), контролирующего

• три Media MVTS

Так как количество Media MVTS в двухуровневой кластерной версии небольшое, административная функция сигнального MVTS ограничивается равномерным распределением трафика между тремя нижестоящими Media MVTS. Такая схема, состоящая из четырех компонентов, является базовым структурным элементом для создания крупных кластерных систем.

Рис. 2 Двухуровневая кластерная версия MVTS

Исходя из того, что один сигнальный MVTS способен контролировать три Media MVTS (каждый из которых обрабатывает до 1 200 звонков), рост числа Media MVTS

17

повлечет за собой увеличение количества сигнальных MVTS, что приведет к необходимости использования элемента, осуществляюшего над ними контроль. Таким элементом является регулятор распределения нагрузки (Load Balancer).

На Рис. 3 показана трехуровневая кластерная система MVTS, созданная на основе двухуровневой версии.

Рис. 3 Трехуровневая кластерная версия MVTS

При наличии регулятора распределения нагрузки, контролирующего сигнальные MVTS, получается трехуровневая кластерная система. Load Balancer, выполняющий лишь одну административную функцию, способен контролировать 4-5 сигнальных MVTS.

2.4.2 РЕГУЛЯТОР РАСПРЕДЕЛЕНИЯ НАГРУЗКИ Единственная задача, стоящая перед регулятором распределения нагрузки, состоит в приеме и равномерном распределении сигнального трафика между сигнальными MVTS. Load Balancer каждые пять секунд производит оценку степени загруженности контролируемых им SMVTS на текущий момент. Опираясь на данные, полученные в результате оценки, регулятор распределения нагрузки сортирует сигнальные MVTS таким образом, что наименее загруженный SMVTS получает новую порцию трафика. Механизм сбора данных с сигнальных MVTS позволяет использовать несколько регуляторов нагрузки.

18

2.4.3 СИГНАЛЬНЫЙ MVTS (SMVTS) Эксплуатация сигнального MVTS практически не отличается от эксплуатации односерверного MVTS, за небольшим исключением: SMVTS осуществляет проксирование только сигнального трафика, независимо от системных настроек.

2.4.4 MEDIA MVTS Функциональные возможности MMVTS сведены до минимума, который позволяет осуществлять полное проксирование (сигнальное и медиа) вызовов.

Media MVTS не способен выполнять следующие функции:

- взаимодействие с удаленным привратником

- работа в качестве привратника

- взаимодействие с RADIUS-сервером

- задание правил маршрутизации

- ведение статистики

2.5 МОДУЛЬ SIP–HIT MVTS при работе использует протокол H.323, поэтому сеть обслуживания оператора, установившего MVTS, ограничивается теми клиентами, оборудование которых поддерживает этот же протокол.

SIP-HIT (SIP-H.323 Interprotocol Translator) модуль предназначен для устранения проблемы совместимости сетей SIP и H.323.

SIP-HIT представляет собой вспомогательный модуль для использования совместно с MVTS для повышения эксплуатационной гибкости последнего за счет обеспечения совместимости работы VoIP-оборудования различных производителей с использованием различных протоколов (SIP и H.323).

Модуль SIP-HIT позволяет:

• Подключать конечные SIP-устройства к H.323-сети оператора.

• Обеспечивать взаимодействие VoIP-сетей операторов и их клиентов, работающих с разными медиа кодеками.

• Сопрягать в обычных условиях несовместимое оборудование различных производителей, использующих различные диалекты протокола H.323.

• Решать проблемы адресной трансляции (связь с устройствами, находящимися за NAT-маршрутизаторами).

Модуль SIP-HIT разработан как дополнительное приложение к MVTS и не может использоваться как самостоятельный продукт для конвертации протоколов или для решения проблем совместимости оборудования.

19

Рис. 4 Использование модуля SIP-HIT для трансляции протоколов

SIP и H.323

Функциональные возможности модуля SIP-HIT включают себя:

• Двусторонняя трансляция сигнальных протоколов SIP и H.323

• Конвертация медиа кодеков (G.729, G.729A, G.723.1, G.711A-LAW, G.711m-LAW)

• SIP-регистрация (авторизация Digest md5 hash)

• Сквозная передача протокола T.38

• Автоматизация записи протокола работы (архивирование, управление размером и периодичностью смены файлов)

Настройка MVTS для работы с модулем SIP-HIT подробно описана в документе [12].

2.6 МОДУЛЬ MVTS TAP MVTS-TAP представляет собой комплекс аппаратно-программных средств для обеспечения оперативно-розыскных мероприятий (СОРМ) на сетях передачи голоса по IP (VoIP). Система MVTS-TAP обеспечивает техническую возможность проведения указанных мероприятий на программных коммутаторах MVTS, обладает возможностями расширения и модернизации с учетом развития технологий и меняющихся требований правоохранительных органов.

Модуль MVTS TAP обеспечивает преобразование интерфейса СОРМ программных коммутаторов MVTS в интерфейс для стандартного телефонного пульта управления.

MVTS-TAP позволяет подключать программные коммутаторы MVTS к стандартному телефонному центру наблюдения (пульту управления).

20

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

Продукт обеспечивает прием голосового RTP-трафика от программных коммутаторов MVTS, его декодирование и передачу на определенные канальные интервалы интерфейсов E1.

Система MVTS-TAP включает в себя аппаратную платформу и программное обеспечение.

• Аппаратная платформа – сервер на платформе Intel для монтирования в стойку.

• Программное обеспечение - единый программный модуль, выполняющий преобразование интерфейса СОРМ программных коммутаторов MVTS в интерфейс стандартного телефонного пульта управления.

Взаимодействие MVTS и модуля MVTS TAP схематично представлено на Рис. 5.

Рис. 5 Взаимодействие MVTS с модулем MVTS TAP

Исчерпывающая информация о модуле MVTS TAP, его взаимодействии с MVTS, эксплуатации и настройках изложена в отдельном документе [15].

21

3 УСТАНОВКА

3.1 ПЛАНИРОВАНИЕ УСТАНОВКИ Целью данного параграфа является ознакомление пользователя с тремя основными параметрами, влияющими на производительность и эксплуатационные качества MVTS. Данными параметрами являются: мощность аппартной платформы, операционная система и возможности локальной сети передачи данных. Ниже мы приводим требования к программному и аппаратному обеспечению для MVTS.

3.1.1 ТРЕБОВАНИЯ К АППАРАТНЫМ СРЕДСТВАМ Аппаратная платформа, на которой планируется эксплуатация MVTS, должна выбираться с учетом требований, предъявляемым к максимальной производительности, а также в зависимости от того, какие функции вы планируете использовать.

Рекомендуемая конфигурация аппаратного обеспечения для использования MVTS только в качестве привратника (без использования функции проксирования) приведена ниже (Таблица 4).

Таблица 4 Рекомендуемая конфигурация (только привратник)

Производительность

Рекомендуемая конфигурация

Низкая Pentium III 833/256Mb RAM/10Gb SCSI HDD

Средняя Pentium III 1,4/1024Mb RAM/10Gb SCSI HDD

Высокая Dual Pentium III 1,4/1024Mb RAM/20Gb SCSI HDD

Если планируется использовать функцию проксирования сигнального трафика (без проксирования речевого трафика), то Таблица 5 содержит сведения для выбора минимально-необходимой конфигурации.

Таблица 5 Рекомендуемая конфигурация (при проксировании только сигнального трафика)

Производительность Рекомендуемая конфигурация

30 одновременных звонков Pentium III 833/256Mb RAM/10 Gb SCSI HDD


120 одновременных Pentium III 933/512Mb RAM/10 Gb SCSI HDD

22


звонков

300 одновременных звонков Pentium III 1.2/512Mb RAM/10 Gb SCSI HDD

600 одновременных звонков Pentium IV 1.4/1024Mb RAM/20 Gb SCSI HDD


Таблица 6 содержит данные, необходимые для выбора конфигурации аппаратной платформы, предназначенной для полного проксирования (проксирование сигнального и медиатрафика).

Таблица 6 Рекомендуемая конфигурация (полное проксирование)




120 одновременных звонков Pentium III 1.15/512Mb RAM/20 Gb SCSI HDD


600 одновременных звонков Xeon Pentium IV 2.4/2048Mb RAM/40 Gb SCSI HDD

1000 одновременных звонков

Dual Xeon Pentium IV 2.0/2048Mb RAM/40 Gb SCSI HDD

Примечание: Для достижения производительности более 300 одновременных соединений с полным проксированием, необходимо использовать сетевую карту 1Gbit Ethernet.

3.1.2 СЕТЕВОЕ ОКРУЖЕНИЕ При установке MVTS следует помнить, что производительность контроллера в большой степени зависит от возможностей сети передачи данных, к которой он подключен. Особую значимость этот параметр обретает при использовании функции проксирования речевого трафика.

23

При включении MVTS в сеть передачи данных типа Ethernet, минимальным требованием является скорость передачи данных не менее 100Mbps. Кроме того, рекомендуется использование оборудования, обеспечивающего работу в полнодуплексном режиме (full-duplex).

Максимально возможная производительность MVTS при проксировании всего речевого трафика (G.729) в сети передачи данных с пропускной способностью 100Mbps в полнодуплексном режиме составляет примерно 1100 одновременных звонков. Это требует установки и конфигурирования не менее двух сетевых интерфейсов для приема и передачи сигнального и речевого трафика Н.323 и дополнительного интерфейса для работы с сервером RADIUS.

Если вам требуется большая производительность при проксировании речевого трафика, рассмотрите возможность использования более производительных сетевых интерфейсов (например, Gigabit Ethernet).

3.1.3 ОПЕРАЦИОННАЯ СИСТЕМА Программное обеспечение MVTS версии 3.1.2 рассчитано для работы под управлением следующих операционных систем:

Linux Red Hat 9.0;

Linux Red Hat Enterprise 3.0, 4.0;

Linux Red Hat Advanced Server 3;

Linux Fedora Core 3,4;

FreeBSD 5.0 и выше (только для тестовой версии).

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

Установка операционной системы должна осуществляться в соответствии с процедурой установки, описание которой приведено в документации по данной операционной системе.

3.2 РЕКОМЕНДАЦИИ ПО УСТАНОВКЕ ПРИЛОЖЕНИЯ В данном разделе приводится информация, призванная помочь пользователю спланировать действия по установке MVTS и подготовке приложения к работе.

3.2.1 ФАЙЛОВЫЕ СИСТЕМЫ Для обеспечения устойчивой работы MVTS файловые системы должны быть организованы определенным образом.

24

В зависимости от вариантов использования MVTS, перед установкой операционной системы администратору рекомендуется зарезервировать дисковое пространство под создание нескольких файловых систем1:

• Для операционной системы и программного обеспечения MVTS рекомендуется создать файловую систему размером не менее 2Гб.

• Место под свопинг должно резервироваться исходя из объема установленной оперативной памяти в соответствии с рекомендациями руководства по установке операционной системы [9]. Однако не рекомендуется создавать раздел для свопинга размером менее 1Гб.

• В случае, когда начисление платы организовано с использованием CDR-файлов (RADIUS не используется), рекомендуется создать отдельную файловую систему размером не менее 5Гб с точкой монтирования в каталоге billing/. Это позволит избежать переполнения корневой файловой системы, где установлено программное обеспечение MVTS.

• Дополнительно рекомендуется создать отдельную файловую систему с точкой монтирования в каталоге debug/. В этом каталоге хранятся файлы с журналом работы системы и core-файлы. В случае, если MVTS функционирует в тестовом режиме, размер файлов с журналом работы может оказаться достаточно большим. В этом случае, создание отдельной файловой системы позволит защитить корневую файловую систему от переполнения.

3.2.2 ФАЙЛОВЫЕ ДЕСКРИПТОРЫ MVTS очень активно использует ресурсы операционной системы и особенно файловые дескрипторы. На каждый открытый файл, сокет или именованный программный канал (fifo) требуется как минимум один дескриптор. Однако, стандартная конфигурация ядра операционной системы позволяет пользователю (процессу) использовать ограниченное количество файловых дескрипторов.

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

Подробная информация о создании необходимого количества дескрипторов файлов содержится в параграфе 7.3.

3.2.3 ПОЛЬЗОВАТЕЛИ И ГРУППЫ ПОЛЬЗОВАТЕЛЕЙ При планировании процесса установки ОС следует учитывать необходимость создания учетных записей пользователей (accounts), которые для облегчения задач администрирования объединяются в группы пользователей с соответствующими правами.

1 Предполагается, что программное обеспечение MVTS устанавливается на ту же файловую систему, куда установлена операционная система, т.е. в корневую файловую систему.

25

В MVTS предусмотрены три группы пользователей, каждая из которых предполагает выполнение специфических задач (Таблица 7).

Таблица 7 Группы пользователей MVTS

Группа Выполняемые задачи

Admin Группа администраторов. Пользователи этой группы имеют доступ к файлам всех каталогов, имеют право принудительно завершить звонок с заданным идентификатором или группу звонков с участием одного шлюза, могут выполнять любые команды консоли администрирования.

Billing Группа учета и начисления платы. Пользователи этой группы имеют доступ к файлам статистики начисления платы из каталога billing/. Из команд консоли администрирования пользователям этой группы доступны только команды, позволяющие просмотр информации о текущих звонках (show call), и просмотр успешно загруженных объектов набора (show dp).

Support Группа технической поддержки. Пользователи этой группы имеют право на выполнение команд просмотра статистики (группа команд show: show call, show dial, show stat

и т.д. консоли администрирования). Пользователям этой группы запрещены команды, влияющие на работу MVTS (start, stop и некоторые другие).

Необходимые группы пользователей с соответствующими правами создаются в процессе исполнения скрипта начальной установки MVTS setup.sh.

3.3 УСТАНОВКА ПРИЛОЖЕНИЯ MVTS Программное обеспечение MVTS поставляется в виде файла, являющегося файлом архива с окончанием tar.gz в имени файла. В имени архивного файла указывается, какая версия программного обеспечения находится внутри и для какой версии операционной системы предназначено поставляемое программное обеспечение. Например, архив с именем MVTS-1.1-linux-x86-7.2.tar.gz содержит программное обеспечение MVTS версии 2.1, скомпилированное для операционной системы RedHat Linux версии 7.2 (для процессоров семейства x86).

В состав поставляемого пакета программного обеспечения MVTS входят:

• Скрипт начальной установки setup.sh, который производит настройку окружения для корректной работы MVTS, т.е. создает необходимые группы

26

пользователей, настраивает права доступа к файлам, добавляет ядро MVTS в число программ запускаемых автоматически при старте операционной системы.

• Исполняемый файл ядра MVTS и скрипт для автоматического перезапуска ядра в случае аварийного завершения (mp_kerneld.x и mp_kerneld.sh).

• Исполняемый файл консоли администрирования и скрипт для запуска консоли администрирования (mp_shell.x и mp_shell.sh).

• Набор шаблонов конфигурационных файлов (meraproxy.cfg, gateway.cfg, dialpeer.cfg, gatekeeper.cfg, user.cfg). Поставляемые шаблоны конфигурационных файлов могут использоваться в качестве примеров при начальной настройке MVTS.

Кроме вышеперечисленных компонентов в состав пакета программного обеспечения MVTS дополнительно могут входить:

• Комплект драйверов HASP-ключей для операционной системы Linux Red Hat в виде rpm-файлов

• Различная документация в электронном формате (включая данное руководство).

• Часть исходных кодов MVTS, которые являются открытыми и публикуются в соответствии с условиями Mozilla Public License (MPL) [11].

Для установки приложения MVTS выполните следующие действия:

1. Войдите в систему с правами пользователя root

2. Скопируйте файл архива в каталог по Вашему выбору (предполагается, что выбран каталог /usr/local)

3. Перейдите в каталог, содержащий файл архива, например [root@localhost]# cd /usr/local

4. Выполните следующую команду, чтобы открыть архив с приложением MVTS # tar xvzf MVTS-1.1-linux-x86-7.2.tar.gz

5. Перейдите в каталог ./mvts

6. Выполните скрипт setup.sh ]# ./setup.sh

и следуйте инструкциям на экране.

Если установка прошла успешно, на экране появится следующая надпись:

Setup finished successfully

27

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

Рис. 6 Структура файловой системы MVTS

28

В каталоге bin/ находятся все исполняемые файлы и скрипты поставляемые в составе программного пакета за исключением скрипта начальной установки setup.sh, который находится в корневом каталоге.

В этом же каталоге находится файл, который содержит информацию об объеме трафика (в секундах), обработанного всеми зарегистрированными на MVTS шлюзами и RAS-пользователями с момента последнего запуска MVTS. Название этого файла формируется по следующей схеме: <file_name>_time, где

<file_name> - это значение конфигурационного параметра "file=" в секции [Statistics], meraproxy.cfg

Информация в данном файле находится в виде отдельных записей. Каждая запись состоит их трех частей, разделеными между собой пробелами. Первая часть (src/dst) показывает тип шлюза по отношению к MVTS (оригинирующий либо терминирующий), вторая – идентификатор шлюза/RAS-пользователя, и третья - количество полученного/отправленного трафика в секундах.

Пример:

src ata 5

src sp 0

src user7001 0

dst ata 5

dst sp 0

Конфигурационные файлы MVTS по умолчанию располагаются в каталоге cfg/. После установки MVTS в этом каталоге находятся шаблоны конфигурационных файлов (meraproxy.cfg, gateway.cfg, dialpeer.cfg, user.cfg, gatekeeper.cfg и rotate.cfg), a также субдиректория synchro/.

При чтении конфигурационных файлов (при выполнении команд start и reload config), MVTS создает папку в субдиректории synchro/ , присваивает папке имя (дата и время ее создания) и записывает в нее копии конфигурационных файлов.

При сборе информации для начисления платы (биллинг) с помощью CDR-файлов, последние помещаются в каталог billing/. В зависимости от своих настроек, MVTS периодически завершает запись текущего файла и создает новый файл. Имена CDR-файлов имеют вид bill_<дата>_<время>, где <дата> - дата создания файла в формате: yyyymmdd, <время> - время создания файла в формате: hhmmss, а префикс bill используется по умолчанию и может быть изменен администратором. Пример имени CDR файла: bill20020327_113000. Файл, в который в текущий момент производится запись, называется по-другому.

Файлы с отладочными протоколами MVTS создает в каталоге debug/logs/. Смена файла отладочного протокола, в который ведется запись, осуществляется аналогично CDR-файлам. Имена файлов с отладочными протоколами имеют вид logs_<дата>_< время>, где <дата> - дата создания файла в формате: yyyymmdd, <время> - время создания файла в формате: hhmmss, а префикс logs используется по умолчанию и может быть изменен администратором. Пример имени файла с отладочными протоколами:

29

log20020327_120000. В таком формате имя присваивается файлу при смене текущего протокола. Файл, в который ведется запись, имеет другое имя..

В случае аварийного завершения работы ядра MVTS могут быть сгенерированы core-файлы, которые копируются скриптом mp_kerneld.sh в каталог debug/cores/. Core-файлы снабжаются пометкой времени аварийного завершения и могут быть использованы администратором или службой технической поддержки для анализа причин сбоев в работе MVTS. Для выделения неограниченного пространства для записи core-файлов рекомендуется добавить в скрипт mp_kerneld.sh строку ulimit -c 10000000. Однако при постоянных отказах приложения существует риск переполнения пространства на жеском диске, так как размер core-файла иногда достигает 100 MB.

Каталог tmp/ содержит внутренние файлы, используемые MVTS. Они не должны изменяться или удаляться администратором во время работы MVTS.

В каталоге doc/ хранится различная документация, поставляемая в электронном виде.

3.4 ЗАДАЧИ ПОСЛЕ УСТАНОВКИ ПРИЛОЖЕНИЯ

3.4.1 МЕЖСЕТЕВОЙ ЭКРАН (FIREWALL) В случае если MVTS устанавливается во внутренней защищенной сети, то необходимо задать соответствующие правила для сервиса брандмауэра (firewall), для того, чтобы MVTS имел возможность инициировать и принимать звонки извне.

Для нужд RAS-трафика, для входящих звонков, а также для обмена сообщениями с RADIUS-сервером в системе задействованы стандартные порты, значения которых и указаны в качестве значений по умолчанию в конфигурационных файлах.

При настройке сервиса брандмауэра следует иметь в виду, что в случае проксирования речевого трафика, порты, по которым происходит передача голосовых данных, назначаются динамически (в диапазоне от 1024 до 65535), поэтому для корректной работы MVTS необходимо открыть следующие порты в направлении шлюзов Ваших партнеров: UDP 1024-65535, TCP 1719, 1720, 1721, а также TCP-порты в диапазоне 1024-65535 (если при установлении соединений не используется H.245 инкапсуляция).

3.4.2 HASP-КЛЮЧИ Ваша лицензионная копия MVTS защищена HASP-ключом, поэтому для запуска и эксплуатации MVTS необходимо установить на Вашей системе необходимые драйверы (Aladdin или Sentinel).

Драйверы Aladdin поставляются в виде файла с расширением .rpm и устанавливаются с помощью утилиты RPM, которая входит в комплект поставки MVTS.

Для установки драйверов Aladdin необходимо перейти в каталог, содержащий файл с названием aksusbd-redhat-*.*-*.i386.rpm

и выполнить следующую команду: > rpm -i aksusbd-redhat-*.*-*.i386.rpm

30

Драйверы Sentinel UNIX устанавливаются либо путем запуска инсталляционного скрипта, либо с помощью комманд PKG.

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

1. Вставьте CD с драйвером Sentinel UNIX в дисковод Вашего компьютера.

2. Произведите монтирование CD с помощью команды > mount -t cd9660 /dev/cdrom /mnt/cdrom

3. Запустите инсталляционный скрипт с помошью команды > sh bsd_drvr_install.sh

4. Далее Вам будет предложено выбрать одну из следующих опций:

1 - (Only parallel driver), 2 – (Only USB daemon), 3 – (Both parallel driver and USB daemon). Мы рекомендуем выбрать третий вариант, который предполагает установку как драйвера, так и USB- демона.

5. Размонтируйте CD с помощью команды > umount /mnt/cdrom

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

1. Для установки драйвера используйте команду > pkg_add /mnt/cdrom/SUD-ParallelDriver-5.50-0.i386.tgz

2. Чтобы установить USB-демон, воспользуйтесь командой > pkg_add /mnt/cdrom/SUD-USBDaemon-5.50-0.i386.tgz

В зависимости от Вашего выбора во время установки, структура каталога может включать в себя следующие компоненты: /opt/RainbowTechnologies/SUD5.50/bsd_drvr_uninstall.sh – скрипт для деинсталяции драйвера Sentinel UNIX. /opt/RainbowTechnologies/SUD5.50/Parallel/rbdr.ko - драйвер порта /opt/RainbowTechnologies/SUD5.50/Parallel/readme.pdf – файл READ ME для драйвера Sentinel. /opt/RainbowTechnologies/SUD5.50/USB/usbdaemon – двоичный (бинарный) файл USB-демона. /opt/RainbowTechnologies/SUD5.50/USB/bsd_load_daemon.sh – скрипт для запуска, перезапуска и остановки USB-демона. После установки необходимых драйверов, приложение MVTS готово к первоначальной настройке.

31

4 НАСТРОЙКА MVTS Все конфигурационные файлы MVTS представляют собой простые текстовые файлы, поэтому конфигурирование MVTS и настройка его основных функций это всего лишь редактирование данных файлов с помощью обычного текстового редактора.

4.1 ОБЗОР КОНФИГУРАЦИОННЫХ ФАЙЛОВ Конфигурирование функций приложения MVTS осуществляется с помощью параметров пяти конфигурационных файлов, название и описание которых приведены ниже (Таблица 8).

Таблица 8 Конфигурационные файлы MVTS

Название файла

Описание

meraproxy.cfg

Общесистемный конфигурационный файл данных, содержащий настройки функций администрирования, отладочного протоколирования, консоли администрирования, начисления платы и т.д.

gateway.cfg Конфигурационный файл данных, содержащий информацию о «статических» шлюзах и их настройках

user.cfg

Конфигурационный файл данных, содержащий информацию о динамических пользователях, регистрирующихся на MVTS по RAS-протоколу (в дальнейшем – RAS-пользователи).

dialpeer.cfg

Конфигурационный файл данных – план набора, содержащий идентификаторы объектов набора, данные о требованиях к вызывающим/вызываемым номерам, внутренние имена шлюзов, правила преобразования номеров.

gatekeeper.cfg Конфигурационный файл, содержащий информацию о привратниках (gatekeepers), на которых MVTS зарегистрирован в качестве клиента.

Файл rotate.cfg не входит в данную таблицу, так как не имеет ничего общего с конфигурацией системы. Он служит для настройки скрипта rotate.sh, который предназначен для выполнения некоторых задач по администрированию системы, связанных с архивированием и удалением устаревших CDR-файлов.

Конфигурирование MVTS предполагает:

1. Настройку общесистемных параметров в секциях файла meraproxy.cfg

32

2. Описание «статических» шлюзов и RAS-пользователей (в файлах gateway.cfg и user.cfg соответственно), взаимодействующих друг с другом.

3. Подготовку плана набора - указание необходимых параметров объектов набора (dial peers) в секциях файла dialpeer.cfg.

4. Описание привратников, регистрирующих MVTS в качестве клиента в файле gatekeeper.cfg.

Информацию о конфигурационных параметрах данных файлов и их секций Вы можете найти в документе «Конфигурирование MVTS» [12].

Во время загрузки MVTS считывает все конфигурационные файлы в кэш, и при обработке звонков вся информация берется только из кэша. Таким образом, изменения, вносимые в любой из конфигурационных файлов, будут восприняты MVTS и вступят в силу только при перезапуске программы, происходящем при аварийном или принудительном завершении работы или при выполнении команды reload config из консоли администрирования.

4.2 СТРУКТУРА КОНФИГУРАЦИОННЫХ ФАЙЛОВ Пять конфигурационных файлов (meraproxy.cfg, user.cfg, gateway.cfg, gatekeeper.cfg, dialpeer.cfg) выполняют двойную функцию – содержат настройки системы и одновременно являются файлами хранения данных, необходимых для работы MVTS.

Все конфигурационные файлы имеют текстовый формат. Файлы разбиты на секции, каждая из которых представляет собой запись об объекте. Название каждой секции пишется с новой строки в квадратных скобках и может состоять только из следующих символов:

• Латинские буквы в верхнем или нижнем регистре

• Цифры ‘0’-‘9’

• Знак подчеркивания

• Точки

Открывающая скобка должна быть в начале строки. Пробелы после открывающей скобки, перед закрывающей скобкой и после неё игнорируются.

Пример правильного названия секции: [ Section ]

Порядок следования параметров внутри секции не важен. Названия параметров пишутся с начала строки. Между названием параметра и его значением ставится знак “=”. Если в качестве значения выступает список, для разделения его составляющих используется точка с запятой ‘;’. Длинный список значений, не умещающийся в пределах одной строки для удобства редактирования может быть перенесен на слудющую строку с обязательным дублированием названия параметра.

Пример: [ata3]

33

address=183.132.44.76;183.132.44.78;183.132.44.71;183.132.44.79; address=183.132.44.77

Значение параметра не должно содержать символов:

• пробел, табуляция

• перевод строки

Регистр букв в названиях параметров и секций должен соблюдаться.

MVTS игнорирует следующие символы:

• пробелы и знаки табуляции до и после знака “=”

• пробелы между скобками и названием секции

• пустые строки

• строки, начинающиеся со знака “#” (комментарии)

• параметры с неизвестными названиями

Целые положительные значения конфигурационных параметров могут вводиться в десятичном, шестнадцатиричном и восьмиричном представлении. Значения в шестнадцатиричном представлении должны начинаться с 0x, значения в восьмиричном представлении должны начинаться с 0.

После установки MVTS, параметры секций общесистемного конфигурационного файла meraproxy.cfg содержат настройки по умолчанию, а файлы gateway.cfg и gatekeeper.cfg представлены лишь в виде шаблонов.

Для изменения текущих настроек необходимо внести соответствующие изменения в конфигурационные файлы и выполнить команду “reload config”. Предыдущая конфигурация MVTS автоматически сохраняется в каталоге mvts/cfg/synchro.

34

5 ЭКСПЛУАТАЦИЯ MVTS Обеспечение безотказного и корректного функционирования системы достигается с помощью мероприятий, направленных на предотвращение последствий несоблюдения правил эксплуатации продукта, а также быстрого и адекватного реагирования администратора на неудовлетворительную обработку трафика системой.

Задачи по администрированию MVTS выполняются с помощью нескольких приложений: консоли администрирования MVTS, графического интерфейса пользователя MVTS (MVTS Management System [13]) и приложения MVTS Web Monitor. Информация о каждом из данных приложений будет приведена ниже.

5.1 КОНСОЛЬ АДМИНИСТРИРОВАНИЯ В данном разделе описываются возможности, предоставляемые системной консолью администрирования, подключение и отключение консоли, предназначение команд и их формат.

Консоль администрирования является вспомогательным приложением, предназначенным для мониторинга работы и администрирования MVTS. Одновременно может быть запущено несколько экземпляров консоли.

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

Admin Пользователь, принадлежащий к группе администраторов, имеет право выполнить любую команду консоли администрирования.

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

Billing Пользователь группы учета начисляемой платы может только просмотреть информацию о текущих звонках.

Для идентификации пользователя приложение проверяет GID пользователя на принадлежность к той или иной группе. Консоль администрирования позволяет:

• Остановить и запустить MVTS

• Загрузить конфигурационные файлы в кэш MVTS, не прекращая выполнение программы

• Получить некоторую статистику работы MVTS

• Принудительно завершить текущие звонки, удовлетворяющие определенным условиям

• Просматривать статистику звонков

• Задавать правила маршрутизации

35

5.1.1 ЗАПУСК И ОСТАНОВКА КОНСОЛИ АДМИНИСТРИРОВАНИЯ MVTS Обычно запуск консоли производится с помощью вызова программы mp_shell.sh При вводе команды консоль администрирования пытается установить соединение с MVTS.

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

Рис. 7 Вывод командной консоли MVTS

В ожидании команд консоль показывает приглашение на ввод (prompt):

#>

Для выхода из консоли администрирования выполните команду “quit”

Пример:

36

Командная строка консоли может содержать одну команду или параметр циклического повторения repeat: , за которым следует команда, требующая циклического исполнения. Если команда задана без параметра цикличности, по окончании ее выполнения работа консоли администрирования завершается. Результат работы передается в коде возврата:

• 0 – команда выполнена

• 1 – не удалось подключиться к MVTS

Если скрипт консоли администрирования запускается с ключевым словом repeat:в качестве параметра, то команда, следующая за ключевым словом, будет выполняться каждые 10 секунд до тех пор, пока процесс не будет прерван одновременным нажатием CTRL+C.

5.1.2 КОМАНДЫ КОНСОЛИ АДМИНИСТРИРОВАНИЯ Все команды консоли администрирования MVTS подразделяются на 3 группы:

• Справочные команды: help, info

• Команды администрирования и настройки: reload config, reset statistics, start, stop, stop gracious, terminate call, disable gatekeeper, unregister endpoint

• Команды диагностики: show call, show dial, show disconnect, show dp, show gw, show stat, show route, show stat route, show ep, show converter, show incoming, sh ipload, show media, show stat file, show stat param, show redundancy

Консоль не воспринимает новую команду до тех пор, пока не обработана предыдущая.

5.1.2.1 Reference commands

help Данная команда без аргументов выводит список возможных команд с краткими пояснениями. Если в качестве аргумента задать имя любой команды, help выведет подробное описание, формат и пример использования команды. Команда доступна пользователям любой из групп.

Пример:

37

Рис. 8 Вывод команды «help»

Команlа info используется для отображения текущих процессов MVTS.

Пример:

5.1.2.2 Команды настройки и администрирования

disable gatekeeper (di gk) Команда, решающая проблему некорректного завершения звонков, требующих авторизации на привратнике (gatekeeper), при выполнении команды перезагрузки конфигурации из консоли администрирования (reload config).

Команда прекращает использование привратника (gatekeeper).

Пример:

Регистрация на привратнике не закрывается до тех пор, пока не завершатся все текущие звонки через данный привратник (gatekeeper)

Для возбновления регистрации на таком привратнике (gatekeeper) требуется:

1. Завершение всех активных звонков через данный привратник

38

2. Наличие описания привратника в конфигурационном файле (gatekeeper.cfg)

3. Выполнение команды перезагрузки конфигурации reload config

disable gatekeeper all (di gk all) Команда прекращает использование всех привратников одновременно. Ее назначение аналогично команде disable gatekeeper .

Пример:

reload config [-d][-ras] Команда заставляет MVTS заново считать все конфигурационные файлы.

При выполнении с аргументом –d сообщения об ошибках в конфигурации выводятся на экран.

Аргумент –ras вызвает перепривязку RAS сокета.

Если Вы хотите использовать оба аргумента (–d и –ras ) одновременно, помните, что аргумент –ras должен следовать за аргументом –d.

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

Команда доступна пользователям группы Admin .

Пример:

Рис. 9 Вывод команды «reload config»

reset statistics (re st) Команда выполняет сброс текущей статистики.

Пример:

39

reset stat all Команда очщиает область памяти, отведенную под статистику.

Пример:

reset stat src|dst|gw|dp Команда обнуляет статистику по категориям объектов IP-телефонии (по оригинирующим, терминирующим, по шлюзам, по объектам набора)

reset stat src|dst|gw|dp [name] Команда обнуляет статистику указанного объекта

start Команда запускает MVTS, если он не был запущен.

Пример:

Рис. 10 Запуск ядра MVTS

Команда доступна пользователям группы Admin.

stop Команда завершает текущие звонки и работу MVTS. Команда доступна пользователям группы Admin.

Пример:

Рис. 11 Остановка MVTS

stop gracious (stop gra, stop gr) MVTS, получив данную команду от консоли, ожидает окончания текущих звонков, не принимая при этом новых, и только после этого завершает работу.

Пример:

40

terminate call Консоль администрирования позволяет администратору принудительно завершить определенный звонок или группу звонков, удовлетворяющих заданным фильтрам.

Исполнение команды разрешено пользователям из группы Admin.

Пример:

Рис. 12 Завершение звонка

unregister endpoint [num] (unregister ep [num]) Данная команда служит для выполнения принудительной разрегистрации RAS-пользователя, зарегистрированного на привратнике MVTS.

Выполнение команды разрешено пользователям группы Admin.

Аргумент «num» представляет собой номер RAS-пользователя, который находится в первой колонке таблицы, получаемой с помощью команды show ep При выполнении команды с данным аргументом производится разрегистрация пользователя с таким номером.

Пример:

5.1.2.3 Diagnostic commands

show call[table][name](sh ca [ta][na]) Команда позволяет просмотреть все текущие звонки, или же некоторые из них, выделенные по определенным критериям. Команда доступна пользователям групп Admin, Support и Billing.

Пример:

Рис. 13 Вывод команды «show call»

41

При введении команды со опцией [table ] информация отображается в форме таблицы.

Пример:

Рис. 14 Вывод команды «show call» с аргументом «table»

Команда с опцией [name ] для шлюзов вместо IP адресов выводит имена шлюзов.

Пример:

Рис. 15 Вывод команды «show call» с аргументом «table» и «name»

Если значение поля превышает ширину столбца, значение выводится в урезанной форме и оканчивается на символ >.

Команда может также задавать фильтр по следующим параметрам:

• IP-адрес вызываемого (-dst) шлюза либо вызывающего (-src) шлюза

• Идентификатор звонка (CALL ID)

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

Вывод команды представляет собой последовательность значений, разделенных запятой. Каждая запись о звонке (call record) состоит из значений, описание которых приведено в таблице ниже:

42

Таблица 9 Поля, выводимые командой show call для группы звонков

Название поля Описание

ICN Внутренний номер звонка

number_src_out Номер вызывающего абонента

number_dst_out Номер вызываемого абонента

ip_address_src IP-адрес шлюза, с которого получен звонок

ip_address_dst IP-адрес шлюза, на который отправлен звонок

talk_time Общее время разговора в секундах

src_bytes in Количество байт, принятых вызывающим абонентом

dst_bytes in Количество байт, принятых вызываемым абонентом

dst_bytes out Количество байт, переданных вызываемым абонентом

src_bytes out Количество байт, переданных вызывающим абонентом

Во втором случае, когда в роли аргумента выступает CALL ID, вывод команды будет иметь следующий формат:

Рис. 16 Вывод команды «sh ca» с внутренним номером звонка в

качестве аргумента Таблица 10 поясняет параметры звонка, выведенные с помощью команды sh ca с аргументом в виде внутреннего номера звонка (ICN).

43

Таблица 10 Поля, выводимые командой show call с аргументом ICN


ICN Порядковый номер звонка

number_src_in Номер вызывающего абонента, полученный MVTS

number_dst_in Номер вызываемого абонента, полученный MVTS

number_src_out Номер вызывающего абонента, который MVTS посылает терминатору

number_dst_out Номер вызываемого абонента, который MVTS посылает терминатору

src_number_bill Номер вызывающего абонента, посылаемый на RADIUS-сервер

dst_number_bill Номер вызываемого абонента, посылаемый на RADIUS-сервер

ip_address_src IP-адрес вызывающего абонента

ip_address_dst IP-адрес вызываемого абонента

gw name src Имя шлюза-оригинатора

gw name dst Имя терминирующего шлюза

call_id Идентификатор звонка

conf_id Идентификатор конференции, частью которой является данный звонок

setup_time Время начала звонка

connect_time Время начала разговора

talk_time Общее время разговора в секундах (время, за которое взимается плата)

src_bytes (i/o) Количество переданных байтов от вызывающего абонента

dst_bytes (i/o) Количество полученных байтов от вызывающего абонента

used_codecs src Кодеки, использованные вызывающим абонентом

used_codecs dst Кодеки, использованные вызываемым абонентом

Вы также можете указать имя оригинатора или терминатора звонка в качестве аргументов данной команды (sh ca [-dstname <name>] или sh ca [-srcname <name>]).

Пример:

44

или

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

show dial Данная команда доступна пользователям групп Admin, Support.

Команда позволяет проследить путь маршрутизации звонка с заданными вызываемым (вызывающим) номерами. Команда ищет оптимальный dial peer для данного сочетания номеров в кэшированном плане набора. В процессе исполнения команды система сообщает о принятых решениях работы алгоритма, найденный шлюз, а также всю результирующую информацию, необходимую для установления звонка.

Также существует возможность отображать результат предварительной (до поиска по объектам набора) трансляции номеров, заданных в полях in_src_translate= и in_dst_translate=. Для этого необходимо выполнить команду ‘show dial’ со следующими аргументами:

sh[ow] di[al] вызываемый_номер [[вызывающий_номер] [[-src ID_устройства] [-g имя_группы]]]

Пример:

45

Рис. 17 Вывод команды «show dial»

show stat route (sh st rt) [all] [-dst] [-src] [-dp] Команда выводит статистическую информацию по маршрутам (оригинатор → объект набора → терминатор) вызовов. Содержимое столбцов таблицы аналогично статистическим таблицам для оригинаторов, объектов набора и терминаторов, за исключением последнего столбца. В нем отражается текущее состояние данного маршрута и процент успешных звонков среди последних 200 звонков. Команда, введенная без аргументов, выводит информацию о 250 маршрутах.

Пример:

Рис. 18 Вывод команды «show stat rt»

Аргументы [-dst] [-src] [-dp]служат для ограничения поиска.

46

Аргумент [-all]служит для выведения статистики по всем активным маршрутам. Аргумент [–src] используется для задания начала имени оригинирующего шлюза на данном маршруте (направлении)

Аргумент [–dst] используется для задания начала имени терминирующего шлюза на данном маршруте (направлении)

Аргумент [–dp] применяется для задания начала имени объекта набора на данном маршруте (направлении)

Пример:

Состояние маршрута отображается следующими кодами:

FA (fully accessible) – нет ограничений на прохождение звонка по этому маршруту

PA (partially accessible) – прохождение звонка по такому маршруту временно разрешено

NA (non-accessible) – прохождение звонка по данному маршруту заблокировано

Правила перехода маршрута из одного состояния в другое.

FA → NA – ASR по последним 200 звонкам ниже 20%

NA → PA – прошло 30 минут с момента перехода маршрута в состояние NA

PA → NA – ASR последних 20 звонков ниже 20%

PA → FA – ASR последних 20 звонков выше 20%

Примечание: 1. Указанные константы (30 минут, 200 и 20 звонков, 20% на

данный момент жестко прописаны в MVTS, планируется реализовать их задание в конфигурации)

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

3. MVTS вычисляет ASR по собственной формуле путем умножения отношения количества успешных звонков к их числу, указанному в поле call_radix=, на 100.

(Количество успешных звонков (successful calls)/(количество звонков, указанных в call_radix=) *100). ASR рассчитывается каждые три секунды.

4. Общепринятый способ вычисления ASR (показывается в скобках рядом

47

со значением ASR, рассчитанному по внутренней формуле MVTS) рассчитывается как простое отношение количества всех звонков ненулевой продолжительности к общему числу звонков.

Задавая команду с опцией all (sh st rt all ), можно вывести подробную статистику по маршрутам. Поскольку выводимая информация может иметь большой обьем, рекомендуется сохранять вывод этой команды в файл, а уже потом анализировать. Для этого в командной строке наберите #> ./mp_shell.x sh st rt all > route_stat.txt

show stat file (sh st file) При выполнении команды MVTS генерирует файл с полной статистической информацией и выводит на экран имя этого файла.

Example:

Рис. 19 Вывод на экран имени файла со статистикой

show stat param (sh st pa) Команда выводит значения всех параметров работы статистики, в том числе количество шлюзов, объектов набора и направлений в статистике

Пример:

48

Рис. 20 Вывод команды «show stat param»

show endpoint (show ep) [number] С помощью команды show ep , введенной без аргумента [number], администратор может получить список всех конечных пунктов (end points) в виде таблицы.

Пример:

Таблица 11 Поля, выводимые командой sh ep


Num порядковый номер

Gateway/Endpoint псевдоним конечного пункта

Endpoint ID идентификатор конечного пункта

Username Имя пользователя

dst/src IP Входящий/исходящий IP-адрес

RegTime Время регистрации устройства на MVTS (в скобках содержится продолжительность регистрации)

49

Синтаксис данной команды позволяет использовать номер оконечного устройства (number) либо его идентификатор (endpoint_id). При указании аргумента [number] или [endpoint_id] будет выведена таблица, содержащая информацию только о том оконечном устройстве, номер или идентификатор которого соответствует аргументу.

Пример:

show disconnect (sh dc) Команда отражает статистику причин завершения звонков с краткой расшифровкой кодов завершения.

Пример:

show dp

50

Команда позволяет просмотреть все объекты набора, успешно загруженные из плана набора, либо конкретное направление. Команда доступна пользователям групп Admin, Support и Billing.

Пример:

Рис. 21 Список диалпиров, отображаемых командой «sh dp»

Таблица 12 Поля, выводимые командой «show dp» для каждого объекта набора


dial peer Псевдоним объекта набора

gateway Псевдоним шлюза

prio(rity) Приоритет шлюза

capacity Максимально разрешенное количество звонков на данном диалпире

51


hunt_stop Флаг, останавливающий дальнейший просмотр объектов, если данное направление подходит, но соответствующий ему шлюз недоступен или перегружен.

hunt_mode Режим распределения нагрузки

dst_pattern

src_pattern Шаблоны номера вызываемого и вызывающего абонентов в формате regexp.

Примечание: максимальный вывод команды sh dp – 250 диалпиров.

show gw [name], [IPaddress] Команда позволяет получить информацию о текущем состоянии любого шлюза, содержащегося в файле данных шлюзов gateway.cfg.

Пример:

Рис. 22 Список шлюзов, отображаемых командой ‘show gw’

52

Если в качестве аргумента команды “sh gw” указывается IP-адрес или имя конкретного шлюза, то команда выводит информацию только по этому шлюзу.

Пример:

Рис. 23 Отображение информации по отдельному шлюзу

show converter (sh co) Команда show converter (sh co) позволяет отображать параметры конвертера SIP/H.323 (см. Рис. 24)

53

Рис. 24 Отображение информации о конвертере SIP-HIT Данная команда выводит следующую информацию:

Name – внутреннее имя конвертера Address – IP-адрес конвертера Port – номер порта Mode – режим работы конвертера (значение both говорит о том, что конвертер настроен как на прием, так и на отправление звонков) Proto – тип сигнального протокола (H323, SIP) Active calls – количество активных в настоящий момент звонков

show incoming <IP address> (sh in <IP address>) Команда выводит идентификатор оконечного пункта (endpoint ID) динамически регистрирующегося пользователя либо имя секции (записи) в файле статически зарегистрированных шлюзов (gateway.cfg), содержащей параметры оригинирующего шлюза. Команда доступна пользователям групп Admin и Support.

Пример:

54

show ipload (sh ipload) Команда показывает расчет нагрузки по локальным IP-адресам.

Пример:

Рис. 25 Отображение нагрузки на локальный IP-адреса

show media (sh me) Команда show media (sh me) позволяет просматривать статистику работы медиа MVTS, используемого для обработки трафика (медиа MVTS является составляющей частью кластерного MVTS, который осуществляет обработку только media-трафика).

Рис. 26 Вывод команды show media Данная команда выводит данные в виде таблицы, за которой следует информация о текущих настройках MMVTS. Таблица содержит следующие поля:

Address – IP адреса медиа серверов MVTS ASR (std) – текущее значение ASR (стандартное) ACD – средняя продолжительность звонка MaxL – зарегистрированное максимальное количество одновременных звонков Act – количество активных на данный момент звонков Total – общая длительность звонков (чч:мм) Normal – количество успешных звонков Failed – количество неуспешных звонков

55

Status – текущий статус медиа серверов MVTS (FA – полностью доступен/ASR=73%/ACD=46 секунд/текущее значение параметра call_radix= ). Строки, расположенные под таблицей, отражают текущие настройки медиа сервера MVTS: min_asr - минимальный заданный уровень ASR для медиа MVTS min_acd - минимальный заданный уровень ACD для MMVTS mode – режим работы системы при отсутствии доступных медиа серверов MVTS. Принимаемые значения: 1 или 0. 1 – завершить звонок с помощью терминирующего устройства, указанного в конфигурации; 0 – прервать звонок с причиной завершения LDC 400 (NoMediaServer) call_radix – количество звонков, используемых для вычисления значений ASR и ACD suspend_time – период времени блокировки серверов MMVTS с низкими показателями ASR и ACD no_connect_suspend_time – режим работы системы при отсутствии TCP-соединения с MMVTS. show route Команда выводит на экран таблицу маршрутизации. Также команда позволяет администратору локальные адреса, выбираемые прокси-сервером для вызываемого абонента.

Пример:

show stat [full | src | ds t | gw | dp ] С помощью этой команды администратор может получить статистику работы сервера с точностью до отдельного шлюза (как оригинирующего так и терминиующего) или объекта набора (dialpeer). Вывод данной команды также содержит информацию об используемой в настоящий момент схеме резервирования (не показывается только схема резервирования типа «Привратник – RAS-пользователь»).

Команда может быть выполнена пользователями групп Admin и Support.

Пример:

56

Рис. 27 Общая статистика MVTS сервера

Статистика выводится также следующими вариантами команды:

show stat full - выводит полную статистику.

Пример:

show stat src|dst|gw|dp - отображает статистику по категориям интересующих объектов (оригинирующие, терминирующие шлюзы и объекты набора)

Example:

или

57

show stat src|dst|gw|dp <name> показывает подробную статистику по конкретному объекту.

Пример:

Рис. 28 Вывод команды «show stat src <name>»

show redundancy Данная команда выводит на экран параметры резервирования системы.

Рис. 29 Вывод команды «sh re»

Таблица 13 Параметры команды «show redundancy»

Параметр Описание

Redundancy state Состояние сервера в режиме резервирования:

undefined/initial state – начальное состояние до момента определения типа версии

master: master is active, slave is inactive – состояние работающего основного сервера при неактивном резервном сервере

master: master and slave are active – состояние

58


работающего основного сервера при работающем резервном сервере

slave: slave is waiting for master – состояние резервного сервера при ожидании соединения с основным сервером

slave: slave is in standby mode, master is active – состояние резервного сервера, находящегося в режиме ожидания при работающем основном сервере

slave: slave is active, master is broken down – состояние работающего резервного сервера, когда основной сервер вышел из строя

Is slave Флаг, показывающий является ли данный сервер резервным по отношению к другому серверу

Check period Период проверки доступности основного сервера

Max failed retries Максимальное число неудачных попыток установки соединения с основным сервером

Connect timeout Лимит продолжительности ожидания TCP-соединения

Master address IP-адрес основного сервера для удаленного «опускания» входящих IP-адресов на основном MVTS

Slave address IP-адрес резервного сервера для удаленного «опускания» рабочих IP-адресов на резервном MVTS

Last slave connect time Время установления последнего удачного соединения резервного и основного серверов. Данный параметр является актуальным только для основного MVTS сервера.

Master down time Время начала выполнения резервным сервером функций основного сервера

Checked address Группа параметров входящего IP-адреса для проверки резервным сервером

Address Входящие IP-адрес и порт, которые проверяются резервным сервером

Local address Локальный IP-адрес резервного сервера, с которого выполняется проверка входящего IP-адреса и порта основного MVTS сервера

Last check time Время последней проверки

59


Bring up command Команда на «поднятие» IP-адреса

Shutdown command Команда на «опускание» IP-адреса

show snmp Данная команда выводит на экран информацию об SNMP-настройках.

Рис. 30 Вывод команды «show snmp»

Таблица 14 Параметры команды «show snmp»


snmp enable Включение/выключения режима ответа на SNMP-запросы

snmp stat start time Дата и время начала сбора SNMP-статистики

snmp stat duration Длительность периода сбора SNMP-статистики

local port номер локального порта, на котором MVTS ожидает SNMP-запроса

community имя SNMP-сообщества

trap enable Включение/выключение режима отправки trap-сообщений

trap port Порт для отправки trap-сообщений

60


trap community имя сообщества получателей trap-сообщений

trap level уровень важности отправляемых trap-сообщений:

0 – trap-сообщения не рассылаются

1 – критические ошибки (critical errors)

2 – некритические ошибки (non-critical errors)

3 – предупреждения (warnings)

4 – информация (information)

5 – уведомления (notifications)

email trap command команда (скрипт), отвечающий за отправку tarp-сообщений

email trap email адрес для отсылки trap-сообщений

email trap_email_subject

содержание строки «тема» сообщения, отправляемого по электронной почты

email tarp period периодичность отправки сообщений электронной почтой (интервал времени в формате <[[<часы>:] минуты:] секунды>)

email from содержимое строки «от кого» электронного сообщения

tarusted ip’s список IP-адресов, с которых могут приниматься SNMP-запросы

sh[ow] gk Вывод данной команды содержит информацию обо всех привратниках, на которых в данный момент зарегистрирован MVTS.

61

Рис. 31 Вывод команды sh gk

Значение полей вывода команды приводится ниже в таблице:

Parameter Description

state Рабочее состояние привратника на текущий момент

address IP-адрес привратника

port Порт привратника

type Тип взаимодействия привратника с MVTS

security Метод авторизации на привратнике

terminal Режим работы MVTS при взаимодействии с привратником

keepalive Периодичность обновления регистрации MVTS на привратнике

keepalive type Тип сообщения, посылаемого на привратник при перерегистрации

options Показывает включена (1) или отключена (0) функция трансляции номера вызываемого абонента в положительных ответах, получаемых MVTS от привратника

local_address IP-адрес, с которого осуществляется отправка RAS-сообщений

user Имя пользователя для авторизации на привратнике

password Пароль пользователя для авторизации на привратнике

id Идентификатор привратника

endpoint_id Идентификатор конечного оборудования

62

Parameter Description

active_admissions Данное поле содержит три значения:

Первое значение показывает количество сессий, обрабатываемых привратником в данный момент

Второе значение показывает число активных запросов ARQ (Admission Request), которые MVTS отправил привратнику

Третье значение – число DRQ, которые MVTS отправил привратнику

‘show ras request’ Вывод данной команды содержит три блока данных:

1. IP-адрес и идентификатор шлюзов, в конфигурации которых присутствует параметр lrq_allowed_only= со значением 1. 2. Список запросов, актуальных на момент вывода данных, с указанием идентификатора конференции (для запроса ARQ) или идентификатора вызова (для запроса LRQ), период времени, прошедший с момента получения запроса, идентификатор шлюза, пославшего этот запрос и индикатор истечения времени хранения запроса. 3. Статистика по запросам, включающая в себя счетчики пакетов LRQ:

- полученных - обработанных - отклоненных по причине неактивности шлюза - отклоненных по причине истечения периода времени, указанного в параметре

arq_alive_time= Пример вывода данной команды приведен на рисунке ниже:

63

5.2 СТРУКТУРА CDR-ФАЙЛОВ CDR-файлы (Call Detail Record) представляют собой текстовые файлы, организованные по принципу «один звонок – одна запись» и использующиеся как для систем учета и начисления платы, так и для администрирования приложения (так как в них содержится информация о кодах разъединения каждого звонка, обработанного MVTS).

Ниже приводится пример отдельной CDR-записи с данными о звонке:

Существует четыре формата вывода CDR-записей на экран. Выбор желаемого формата осуществляется изменением значения параметра cdr_format=, который находится в секции [Billing] файла meraproxy.cfg.

При значении данного поля, равном нулю (cdr_format=0),CDR-записи будут генерироваться в формате MVTS, то есть с названиями полей (как это показано в примере отдельной CDR-записи выше).

Если значение данного поля равно 1, (cdr_format=1 ), CDR-записи будут выводиться на экран в формате MIND CTI, то есть без названий полей. В данном формате поля с нулевыми значениями не отображаются.

Примечание: поле ELAPSED-TIME= присутствует всегда в CDR-записях всех форматов, даже если его значение равно нулю.

При значении поля, равном 2 (cdr_format=2 ), CDR-записи выводятся в формате, похожем на формат MVTS, за исключением того, что в данном случае показываются даже нулевые значения полей.

Если значение параметра равняется 3 (cdr_format=3), то CDR-записи будут иметь такой же формат, как при cdr_format=2, с той лишь разницей, что значения параметров setup_time=, connect_time= и disconnect_time= будут представлять собой количество времени в секундах, истекшего с 1 января 1970 года.

Таблица, приведенная ниже содержит поля в том порядке, в котором они находятся в CDR-записи.

Таблица 15 Структура записи с данными о звонке (CDR)

Поле Назначение

HOST Локальный адрес MVTS

SRC-NUMBER-IN Номер вызывающего абонента до трансляции

Fri Sep 23 13:12:43 2005, HOST=212.92.148.13, SRC-NUMBER-IN=12345678901, DST-NUMBER-IN=789, SRC-NUMBER-OUT=12345678901, DST-NUMBER-OUT=999999, SRC-NUMBER-BILL=12345678901, DST-NUMBER-BILL=999999, SRC-IP=212.92.148.251:3317, DST-IP=212.92.148.251:1721, SRC-RTP-IP=212.92.148.251:16384, DST-RTP-IP=212.92.148.251:16386, SRC-USER=12345678901, DST-USER=999999, SRC-NAME=ata, DST-NAME=a ta2, DIALPEER-NAME=dp1, INITIAL-INCOMING-LOCAL-ADDRESS=212.92.148.13, SELECTED-INCOMING-LOCAL-ADDRESS=212.92.148.13, OUTGOING-LOCAL-ADDRESS=212.92.148.13, RECORD-ID=1127465365-3, ELAPSED-TIME=6, SETUP-TIME=13:12:25.000 +0400 Fri Sep 23 2005, CONNECT-TIME=13:12:36.000 +0400 Fri Sep 23 2005, DISCONNECT-TIME=13:12:42.000 +0400 Fri Sep 23 2005, DISCONNECT-CODE-LOCAL=1, DISCONNECT-CO DE-Q931=16, SRC-BYTES-IN=793, DST-BYTES-IN=668, SRC-BYTES-OUT=653, DST-BYTES-OUT=589, QOS=0, SRC-CODEC=g711A64k g711U64k g7231, DST-CODEC=g711A64k , CALLID=6000100036b4c41c140c000ccee57293, CONFID=600010003832a01a0802000ccee57293, PROXY-MODE=0, ROUTE-RETRIES=2, SCD-TIME=11, SOURCE-FASTSTART=1, DESTINATION-FASTSTART=1, SOURCE-TUNNELLING=1, DESTINATION-TUNNELLING=1, PDD-TIME=10,PDD-REASON=ALERT, REDIRECT-NUMBER=999999 (END), LAST-CHECKED-DIALPEER=to_ata

64

DST-NUMBER-IN Номер вызываемого абонента до трансляции

SRC-NUMBER-OUT Номер вызывающего абонента после трансляции

DST-NUMBER-OUT Номер вызываемого абонента после трансляции

SRC-NUMBER-BILL Номер вызывающего абонента после трансляции, для системы начисления платы (биллинга)

DST-NUMBER-BILL Номер вызываемого абонента после трансляции, для системы начисления платы (биллинга)

SRC-IP:SRC-PORT IP-адрес шлюза и порт с которого получен звонок

DST-IP:DST-PORT IP-адрес шлюза и порт на который отправлен звонок

SRC-RTP-IP:SRC-RTP-PORT

При использовании нескольких шлюзов для маршрутизации вызова, в данном поле указывается реальный IP-адрес и порт шлюза-оригинатора

DST-RTP-IP:DST-RTP-PORT

При использовании нескольких шлюзов для маршрутизации вызова, в данном поле указывается реальный IP-адрес и порт терминирующего шлюза

REMOTE-GATEKEEPER-IP

IP-адрес привратника (gatekeeper)

MEDIA-SERVER-IP:MEDIA-SERVER-PORT

IP-адрес и порт Media-сервера (в кластерной системе MVTS)

CONVERTER-NAME В данном поле указано имя конвертера протоколов (SIP-HIT)

CONVERTER-IP:CONVERTER-PORT

Данное поле содержит IP-адрес и порт конвертера протоколов (SIP-HIT)

SRC-USER Имя вызывающего пользователя

DST-USER Имя вызываемого пользователя

RADIUS-USER Имя пользователя, полученное от RADIUS сервера при включенном режиме use_h323_ivr_in и используемое в accounting-пакетах (см. секция [Radius] в файле meraproxy.cfg)

65

SRC-NAME Имя секции с описанием оригинирующего шлюза

DST-NAME Имя секции с описанием терминирующего шлюза

DIALPEER-NAME Имя секции с описанием задействованного объекта набора

INITIAL-INCOMING-LOCAL-ADDRESS

Локальный IP-адрес, на который был принят Setup от оригинатора

SELECTED-INCOMING-LOCAL-ADDRESS

Выбранный локальный IP-адрес для обмена с оригинатором

OUTGOING-LOCAL-ADDRESS

Выбранный локальный IP-адрес для обмена с терминатором

RECORD-ID Уникальный идентификатор звонка в формате <start-time>-<call-number>, где <start-time> - штамп времени текущей сессии MVTS, выраженный в количестве секунд с 1-го января 1970г до момента последнего запуска MVTS, а <call-number> - порядковый номер звонка с момента последнего запуска MVTS

ELAPSED-TIME Общее время разговора в секундах

SETUP-TIME Время установления звонка

CONNECT-TIME Время начала разговора

DISCONNECT-TIME Время окончания звонка

DISCONNECT-CODE-LOCAL

Причина разъединения

DISCONNECT-CODE-Q931

Код разъединения по Q931

SRC-BYTES-IN Количество полученных байт от вызывающего абонента

DST-BYTES-IN Количество полученных байт от вызываемого абонента

SRC-BYTES-OUT Количество переданных байт вызывающему абоненту

DST-BYTES OUT Количество переданных байт вызываемому абоненту

QOS QoS

SRC-CODEC Кодеки, использованные вызывающим абоненто

66

DST-CODEC Кодеки, использованные вызываемым абонентом

CALLID Идентификатор вызова

CONFID Идентификатор конференции в которой участвовал данный звонок

LAR-FAULT-REASON Код ошибки по LAR (функция перенаправления звонка), причина функции перенаправления вызова reason for call routing interruption

PROXY-MODE Режим проксирования

ROUTE-RETRIES Количество попыток перенаправления звонка

SCD-TIME Время в секундах между поступлением SETUP и моментом CONNECT либо моментом завершения звонка (при отсутствии CONNECTa)

SOURCE-FASTSTART SOURCE-FASTSTART=1, когда в SETUP от оригинатора вызова имеются поля с FASTSTART

DESTINATION-FASTSTART

DESTINATION-FASTSTART=1, когда пакеты, получаемые от терминатора, содержат поля с FASTSTART

SOURCE-TUNNELLING SOURCE-TUNNELLING=1, когда флаг инкапсуляции (tunneling flag) в сообщениях от оригинатора вызова выставлен (1)

DESTINATION-TUNNELLING

DESTIANTION-TUNNELLING=1, когда флаг инкапсуляции (tunneling flag) в сообщениях от терминатора вызова выставлен (1)

PDD-TIME Интервал между получением пакета SETUP от оригинатора звонка и получением пакета ALERT, CONNECT или ProgresIndicator со значением 8 (ProgressInbandInformationAvailable) от терминирующей стороны

67

PDD-REASON Сообщение, получаемое от терминатора звонка после получения SETUP, заканчивающее PDD-интервал.

Может принимать следующие значения:

ALERT – от терминатора был получен пакет ALERT

PI8 – от терминатора был получен пакет ProgressIndicator=8

CONNECT – от терминатора был получен пакет CONNECT

N/A – ни одно из указанных сообщений не было получено

REDIRECT-NUMBER В данном поле указывается список номеров, полученных от RADIUS-сервера в поле VSA(106) h323-redirect-number

INFO-NUMBER Содержит номера, скомбинированные конкатенацией из сообщения Setup и последующих пакетов Information

5.3 ПРОТОКОЛИРОВАНИЕ MVTS Протоколы работы MVTS содержат информацию обо всех рабочих процессах и операциях приложения, поэтому они так же важны для его администрирования, как и CDR-записи. MVTS генерирует два вида протоколов: трассировочные протоколы (trace logs) и отладочные протоколы (debug logs).

Примечание: MVTS не удаляет устаревшие отладочные протоколы, CDR-записи, файлы статистики, core-файлы и т.д., и не предупреждает администратора о переполнении диска, поэтому администратор сам должен следить за своевременным удалением старых файлов.

Отладочные протоколы занимают достаточно много дискового пространства и могут полностью переполнить жесткий диск. В этом случае сохранение CDR-записей, статистики и отладочных протоколов будет невозможно.

Вы всегда можете использовать дополнительный жесткий диск для хранения отладочных протоколов, статистики и т.д., но мы настоятельно рекомендуем Вам использовать скрипт mvts/bin/rotate.sh, предназначенный для архивирования и удаления устаревших файлов.

Настройка скрипта архивации/удаления файлов осуществляется системным администратором в файле rotate.cfg.

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

68

При переполнении дискового пространства администратору необходимо удалить все устаревшие файлы в соответствии с принятой в Вашей компании политикой документооборота.

5.3.1 ТРАССИРОВОЧНЫЕ ПРОТОКОЛЫ Трассировочные протоколы создаются MVTS в периоды его некорректного функционирования и содержат информацию в виде системных сообщений, которая используется для поиска и устранения неисправностей, а также для анализа причин сбоев в работе приложения.

Также трассировочный протокол MVTS содержит информационные события, сообщающие о снижении значений ACD, ASR, SCD, и о росте значения SCD, в следующем формате:

"ASR level calculated for the last <call_radix> calls at gateway <gateway name> dropped down to its critical point of <asr_min>%"; - событие, сообщающее о падении значения ASR до критического уровня, указанного пользователем в параметре asr_min=.

"ACD level calculated for the last <call_radix> calls at gateway <gateway name> dropped down to its critical point of <acd_min> seconds"; - событие, сообщающее о падении значения ACD до критического уровня, указанного пользователем в параметре acd_min=.

"SCD level calculated for the last <call_radix> calls at gateway <gateway name> dropped down to its critical point of <scd_min> seconds"; - событие, сообщающее о падении значения SCD до критического уровня, указанного пользователем в параметре scd_min=.

"SCD level calculated for the last <call_radix> calls at gateway <gateway name> reached its critical point of <scd_max> seconds"; - событие, сообщающее о росте значения SCD до критического уровня, указанного пользователем в параметре scd_min=.

При генерации локального кода 202 (вызов с неизвестным адресом оригинатора) в трассировочный протокол также записывается событие в формате “call from unregistered gateway located on <IP address>”, т.е. получение вызова с незарегистрированного объекта, (с указанием его IP-адреса).

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

Однако, по запросу инженеров техподдержки трассировочные протоколы могут быть извлечены из директории $H323PROXY_ROOT/debug/logs/mp.kernel.sh.log-<date> , куда они записываются MVTS.

Все пользователи MVTS обладают необходимыми правами на извлечение трассировочных протоколов из данной директории. Располагая трассировочными протоколами Вашего MVTS, инженеры поддержки используют их в качестве источника информации о системных ошибках и сбоях в работе приложения и, проанализировав их, предлагают Вам наиболее эффективные способы устранения этих ошибок.

69

Единственный параметр трассировочных протоколов, рекомендуемый к конфигурированию самим пользователем – степень детализации трассировочной информации. Степень детализации определяется значением поля trace_level=, которое находится в секции [Debug] файла meraproxy.cfg.

При значении данного поля, равном нулю (trace_level=0), запись трассировочных протоколов не ведется.

Если это поле принимает значение 1, (trace_level=1), запись трассировочных протоколов ведется с минимальным уровнем детализации.

Для ведения записи протоколов с максимальным уровнем детализации установите данное поле на значение 3 (trace_level=3).

5.3.2 ОТЛАДОЧНЫЕ ПРОТОКОЛЫ Отладочные протоколы содержат информацию о каждой сессии звонка, поступившего на MVTS или сессии с участием отдельного шлюза, поэтому они представляют не меньшую ценность для анализа и устранения неисправностей и ошибок в работе приложения, чем трассировочные протоколы.

Отладочные протоколы сохраняются MVTS в виде текста в формате ASCII в файл logs_<date>_<time> (<date> и <time> указывают на время начала записи в файл), находящийся в каталоге logs/ для удобства инженеров техподдержки. Все протоколы, находящиеся в данном каталоге, могут быть удалены по усмотрению администратора.

При очередном старте системы открывается новый файл для записи протокола.

Отладочые протоколы предоставляют следующую информацию для каждой сессии:

• время получения сообщений

• тексты сообщений в абстрактной синтаксической нотации ASN.1

5.3.2.1 ПАРАМЕТРЫ ПРОТОКОЛИРОВАНИЯ Администратору разрешается конфигурировать следующие параметры протоколирования:

- Степень детализации информации - Частота смены файла протокола - Имя файла протокола

5.3.2.2 СТЕПЕНЬ ДЕТАЛИЗАЦИИ ИНФОРМАЦИИ Данный параметр определяется значением поля level= секции [Debug] файла meraproxy.cfg. Чем больше значение данного поля, тем выше уровень детализации записываемой информации.

Нулевое значение данного поля (level=0, значение по умолчанию), отлючает протоколирование MVTS.

70

Самый низкий уровень детализации информации достигается установкой этого поля на 1 (level=1). В данном случае запись будет содержать лишь информацию о дате и времени получения либо отправки сообщения, его типе, и IP-адресе компьютера, пославшего или получившего сообщение.

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

<time> <date> <Recv/Sent> <IP address> <protocol> <message type>

где:

<time> и <date> отметка времени и даты

<Recv/Sent> - отметка, показывающая, что сообщение было отправлено (Sent) или принято (Recv).

<IP address> - адрес компьютера, оправившего/получившего сообщение.

<protocol> - протокол, по которому сообщение было отправлено

<message type> - тип сообщения. (по протоколу H.323 [1])

Пример: 12:16:47 12/09/2001 Recv 192.168.5.1:1813 Q.931 Setup

12:16:47 12/09/2001 Sent 192.168.5.1:1720 Q.931 Setup

12:16:47 12/09/2001 Recv 192.168.5.1:1720 Q.931 Facility

12:16:47 12/09/2001 Sent 192.168.5.1:1813 Q.931 Facility

12:16:47 12/09/2001 Recv 192.168.5.1:1720 Q.931 Connect

12:16:47 12/09/2001 Sent 192.168.5.1:1813 Q.931 Connect

12:16:47 12/09/2001 Recv 192.168.5.1:1813 Q.931 Facility

Для установки максимально высокого уровня детализации отладочных протоколов MVTS следует установить поле debug_level= на значение 3.

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

Формат записи протоколирования при данном уровне детализации имеет следующий вид: <time><date><Recv/Sent><IP address><protocol><message text>

где:

<time> и <date> отметка времени и даты

<Recv /Sent> – отметка, показывающая, что сообщение было отправлено (Sent) или принято (Recv).

<IP address> - адрес компьютера, оправившего/получившего сообщение.

71

<protocol> протокол, по которому сообщение было отправлено

<message text> текст сообщения (может состоять из нескольких строк).

Пример: 15:05:05 12/09/2001 Recv 192.168.5.1:2883 Q.931

{

protocolDiscriminator = 8

callReference = 1

from = originator

messageType = Setup

IE: Bearer-Capability = {

88 c0 a5 ...

}

IE: Display = {

4d 45 52 41 20 70 68 6f 6e 65 20 37 37 37 37 30 MERA phone

77770

30 0

}

}

5.3.2.3 ЧАСТОТА СМЕНЫ ФАЙЛА ПРОТОКОЛА Позволяет менять текущий файл протокола работы через заданные промежутки времени. По умолчанию такой промежуток времени составляет 120 минут.

5.3.2.4 ИМЯ ФАЙЛА ПРОТОКОЛА Позволяет администратору MVTS присваивать любое имя файлу, куда записываются отладочные протоколы. По умолчанию имя этого файла - log.

Вышеупомянутые параметры называются общими, так как находятся в секции [Debug] системного файла общей конфигурации MVTS (meraproxy.cfg).

5.3.3 ОСОБЕННОСТИ ПРОТОКОЛИРОВАНИЯ Другие секции файла meraproxy.cfg, а также другие конфигурационные файлы тоже могут содержать поля, контролирующие протоколирование MVTS. Эти поля отвечают только за протоколирование отдельных функциональных возможностей MVTS, а не всего приложения, поэтому они называются специальными.

72

Таким образом, поле debug_level= присутствует в списке конфигурационных параметров секции [Gatekeeper] и [Radius] и контролирует протоколирование соответствующих функциональностей MVTS, если общее протоколирование в секции [Debug] отключено (level=0).

Значения для поля debug_level= этих двух секций совпадают со значениями поля level= в секции [Debug] файла meraproxy.cfg.

Протоколирование MVTS также может конфигурироваться в других файлах MVTS: gateway.cfg и user.cfg, с помощью того же поля debug_level=, которое позволяет выставлять уровень детализации информации о статических шлюзах или динамичесих пользователях, которые принимали участие в установлении соединения.

Например, если общее протоколирование системы в секции [Debug] отключено, можно установить поле debug_level= в конфигурации отдельного шлюза или RAS-пользователя на желаемое значение (например на 3), обеспечив, таким образом, максимальный уровень протоколирования в сессиях, где данный шлюз/RAS-пользователь принимает участие.

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

Представьте, что Вам необходимо получить протокол сессии (с участием только одного конкретного шлюза) с самой высокой степенью детализации. Для экономии места на жестком диске Вы отключаете общее протоколирование системы (level=0 в секции [Debug] файла meraproxy.cfg). Самый эффективный способ получения протокола нужной сессии (с максимальной степенью детализации) с участием интересуещего Вас шлюза заключается в том, чтобы установить поле debug_level= в конфигурации предполагаемого оригинатора звонка на 3. Если Вы установите поле debug_level=3 в конфигурации терминируещего шлюза, то протоколирование сессии начнется только после отправки сообщения SETUP на данный шлюз. Трудность заключается в том, что данный шлюз может оказаться последним в списке шлюзов, выбираемых для терминации звонков, и в таком случае Вы получите протокол с нужной степенью детализации только небольшой части сессии.

73

5.4 WEB-ИНТЕРФЕЙС MVTS (MVTS WEB MONITOR) Web-интерфейс MVTS (Web Monitor) представляет собой web-приложение для удаленного доступа к оперативной статистике MVTS сервера при помощи web-клиентов (например, MS Internet Explorer или Opera Web browser). Для обеспечения гибкости применения система учетных записей пользователей в Web Monitor никак не свзяана с учетными записями графического интерфейса MVTS Manager. Учетные записи в Web-интерфейсе создаются и редактируются независимо от учетных записей GUI.

Web Monitor для MVTS включен в комплект поставки пограммного обеспечения и устанавливается вместе с серверной частью графического интерфейса администратора MVTS. Вы имеете полный доступ к Web-интерфейсу сразу же после установки и запуска MVTS-агента. Во время установки приложения обратите внимание (запомните или запишите) на IP адрес и порт, которые появятся на экране среди сообщений инсталлятора. Именно этот порт будет «слушать» MVTS-агент (по умолчанию 1730) при работе с Web-интерфейсом.

5.4.1 НАСТРОЙКА И ЭКСПЛУАТАЦИЯ WEB-ИНТЕРФЕЙСА После установки Web Monitor’а имеется единственная учетная запись «admin» с паролем «admin», которая предоставляет доступ к интерфейсу и права на уровне администратора для работы в нем. Права администратора включают неограниченный доступ к статистике по всем видам VoIP-объектов, сконфигурированных в MVTS, а также права на создание, удаление и редактирование учетных записей пользователей.

Для доступа к web-интерфейсу MVTS введите адрес (или доменное имя) MVTS и номер порта в строке Address web-браузера. Обратите внимание на правильное указание протокола перед группой адрес:порт.

Например:

https://<server IP address>:1730 или https://<servername.com>:1730

После ввода адреса в окне web-браузера появится форма для ввода имени и пароля на вход как на Рис. 32.

Рис. 32 Диалог авторизации web-интерфейса

При правильно введенных имени и пароле вы попадаете на страницу общей статистики, на которой расположены три таблицы:

74

Статистика оригинаторов

Статистика терминаторов

Статистика объектов набора (dialpeers) В целом web-интерфейс доступа к статистике MVTS интуитивно понятен, поэтому мы ограничимся замечаниями по функциям и возможностям, не очевидным с первого взгляда.

Рис. 33 Главное меню Администратора

75

Рис. 34 Главное меню Клиента

Главное отличие двух меню заключается в том, что в меню клиента отсутствует пункт Учетные записи.

Пункт меню Статистика служит для вызова страницы с полными данными по всем VoIP-объектам, сконфигурированным в MVTS, представленными в табличной форме с информацией по шлюзам, инициаторам вызовов, терминирующим пунктам и объектам набора (dial peers). Подпункты пункта Статистика (Шлюзы, Оригинаторы, Терминаторы, Объекты набора (dial peers) открывают страницы с таблицами статистики по соответствующим объектам. (Пользователь с правами клиента будет иметь доступ к статистике только по тем объектам, которые разрешит Администратор при создании/редактировании учетной записи клиента).

Пункт Объекты вызывает страницу со списком объектов доступных для просмотра статистики. Подпункты выполняют ту же функцию, но только в отношении соответствующей категории.

Пункт меню Настройки вызывает диалог личных настроек, который позволяет сменить пароль доступа и выбрать язык интерфейса. Доступные варианты языка интерфейса можно создать, путем редактирования содержимого текстового файла (подробно см. в разделе 5.4.2 Настройка языка интерфейса).

Пункт Учетные записи – это инструмент администратора, при помощи которого он создает учетные записи пользователей, определяет их права и решает какие объекты будут доступны клиенту для просмотра статистики.

76

Рис. 35 Список существующих учетных записей

Для создания новой учетной записи щелкните по кнопке Создать учетную запись.

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

Рис. 36 Диалог редактирования учетной записи

В режиме редактирования диалог учетной записи появляется с уже оформленными свойствами, изменить которые можно выставляя или сбрасывая отметку в соответствующих флаговых кнопках (checkboxes). Основными настройками в диалоге учетной записи являются:

Опция Активировать/Заблокировать учетную запись (флажок

77

Включена)

Предоставление/ликвидация прав на просмотр статистики по объектам (флаговые кнопки у названий шлюзов, объектов набора, маршрутов)

Предоставление/ликвидация права на изменение пароля (флажок Смена пароля)

Предоставление/ликвидация права на сброс статистики по объектам (флажок Может сбрасывать статистику)

Флажок Администратор сервера MVTS – это атрибут учетной записи, определяющий полноту прав пользователя и являющийся признаком учетной записи пользователя с правами Администратора (т.е. по умолчанию обладающего неограниченными правами доступа к информации и возможностью создавать, удалять и редактировать все записи).

5.4.2 НАСТРОЙКА ЯЗЫКА ИНТЕРФЕЙСА Языковое оформление web-интерфейса легко разнообразить или изменить применительно к индивидуальным запросам клиента. Это достигается за счет редактирования файла-шаблона подписей и всплывающих подсказок интерфейса. Редактировать файл следует в текстовом редакторе, позволяющем записывать данные в кодировке UNICODE/UTF-8, UNICODE/UTF-16.

Структура файла оформления интерфейса:

LANGUAGE = Русский ACD = Стандартное значение ACD ASR = Значение ASR Account = Учетная запись Accounts = Учетные записи Active_calls = Текущие звонки Administrator_of_MVTS_server = Администратор сервера MVTS Apply = Применить Are_you_sure = Вы уверены? Can_reset_statistics = Может сбрасывать статистику Cancel = Отменить Change_password = Изменить пароль Common_settings = Общие настройки Common_statistics = Общая статистика Create_account = Создать учетную запись Creating_account = Создание учетной записи Delete = Удалить Delete_account = Удалить учетную запись …………... и т.д.

Название языкового варианта интерфейса, появляющееся в выпадающем меню, должно находиться в строке LANGUAGE.

Чтобы изменить язык оформления интерфейса и всплывающих подсказок перейдите на страницу Локализация, щелкнув по одноименной ссылке в главном меню.

78

Рис. 37 Страница локализации web-интерфейса

Щелчком мыши по названию Шаблон в первой колонке таблице вызовите шаблон подписей и всплывающих подсказок и запишите его в любом удобном для работы каталоге.

Отредактируйте шаблон, вводя необходимые названия и тексты подсказок в поля шаблона после символа ‘=’.

Пример: LANGUAGE = Spanish

ACD = ACD

ASR = ASR

Account = Cuenta

Accounts = Cuentas

Active_calls = Llamadas activas

Administrator_of_MVTS_server = Administrador del servidor MVTS

Are_you_sure = Esta seguro?

Can_reset_statistics = Puede reajustar estadística

Cancel = Cancelación

Change_password = Cambiar la contraseña

... ... ... ... ... etc.

Название варианта локализации, которое появляется в качестве одного из пунктов выпадающего списка на странице Персональные настройки, во избежании путаницы, рекомендуется всегда вводить в поле LANGUAGE на английском языке (напр. LANGUAGE = Russian).

Сохраните готовый файл в кодировке UNICODE/UTF-8,-16 под любым другим именем. Для того, чтобы загрузить файл обратно на сервер щелкните мышью по кнопке Browse (эта кнопка не поддается локализации, так как не является частью Web Monitor’а) на странице Локализация и, выбрав вновь отредактированный файл языкового оформления интерфейса в вызванном файловом диалоге, загрузите его на сервер щелчком по кнопке Загрузить.

После успешной загрузки имя нового варианта оформления интерфейса должно появиться в колонке Модуль в таблице Локализация.

79

Для того чтобы изменить языковое оформление интерфейса, перейдите на страницу Персональные настройки (вызываемую щелчком по ссылке Настройки), выберите из выпадающего списка нужный язык интерфейса и нажмите на кнопку Сохранить настройки.

Рис. 38 Выпадающий список вариантов языка

Рис. 39 Новый язык интерфейса (испанский)

5.5 ЯДРО MVTS В редких случаях необходимости выполнения действий непосредственно с ядром MVTS (запуск/остановка), администратор может запустить консоль администрирования и выполнить необходимые манипуляции с указанием при запуске (команда start) в командной строке необходимых параметров.

Ядро MVTS можно также запустить скриптом, что имеет свои преимущества. Подробно о скрипте запуска см. пункт 5.5.2.

5.5.1 ПАРАМЕТРЫ КОМАНДНОЙ СТРОКИ Команда на запуск ядра MVTS (start) должна содержать один или несколько параметров, значения которых приведены в таблице ниже.

Таблица 16 Параметры командной строки ядра MVTS (mp_kerneld.x)

Поле команды «start»

Описание

-h --help Вывод подсказки и завершение работы. -v --version Вывод информации о номере версии и

завершение работы -d --daemon Запуск в качестве фонового процесса

(демона) -u --uid uid Запуск в качестве процесса с

идентификатором пользователя

80

Поле команды Описание «start» -g --gid gid Запуск в качестве процесса с

идентификатором группы пользователей -p --pid-file Запуск с указанием имени или полного

пути для файла идентификатора процесса (pid-file) .

-t --terminate Запуск с нормальным завершением процесса в файле идентификатора (pid-file)

-k --kill Запуск с предварительным завершением процесса в файле идентификатора (pid-file)

-c --console Запуск с выводом сообщений в стандартный поток вывода (консоль) вместо журнала syslog

-l --log-file Запуск с выводом сообщений в файл с именем или каталог вместо журнала syslog

-x --execute Выполнять как обычную программу -i --ini-file Запуск с указанием имени (пути) файла

инициализации или списка каталогов для поиска файла инициализации, разделенного ':'

-C --core-size Запуск с заданием максимального размера core-файла

Попытка запустить ядро без указания параметров команды: #>start

приведет к выводу на экран подсказки о параметрах командной строки

bash-2.05$ ./mp_kerneld.x error: must specify one of -v, -h, -t, -k, -d or -x usage: [-c] -v|-d|-h|-x -h --help output this help message and exit -v --version display version information and exit -d --daemon run as a daemon -u --uid uid set user id to run as -g --gid gid set group id to run as -p --pid-file name or directory for pid file -t --terminate orderly terminate process in pid file -k --kill preemptively kill process in pid file -c --console output messages to stdout rather than syslog

81

-l --log-file file output messages to file or directory instead of syslog -x --execute execute as a normal program -i --ini-file set the ini file to use, may be explicit file or a ':' separated set of directories to search. -C --core-size set the maximum core file size

5.5.2 СКРИПТ ЗАПУСКА ЯДРА MP_KERNELD.SH Данный способ запуска системы обеспечивает:

• сохранение core-файлов

• внесение записей в протокол работы при аварийном завершении программы

• автоматический перезапуск программы при аварийном завершении

Запуск осуществляется командой

#> mp_kerneld.sh [cfg_file], выполненной из каталога bin/.

[cfg_file] - системный конфигурационный файл (по умолчанию meraproxy.cfg).

Данный способ позволяет запустить MVTS, не подключая консоль администрирования.

5.6 УДАЛЕНИЕ/АРХИВАЦИЯ УСТАРЕВШИХ ФАЙЛОВ Удаление или архивация устаревших файлов (отладочных протоколов, CDR-файлов) выполняется с помошью специального скрипта rotate.sh, рабочие параметры которого конфигурируются пользователем в файле rotate.cfg.

5.6.1 ФАЙЛ ROTATE.CFG Конфигурационный файл rotate.cfg состоит из двух секций: [Billing] и [Logs], задающих параметры удаления/архивации для CDR-файлов и отладочных протоколов соответственно. Каждая секция включает в себя пять абсолютно идентичных полей.

[Billing], [Logs] path=

С помощью данного параметра указывается директория, куда MVTS записывает CDR-файлы или отладочные протоколы.

Значения:

Строка символов, выражающая путь к файлу.

82

Пример:

path=$H323PROXY_ROOT/billing (для CDR-файлов)

или

path=$H323PROXY_ROOT/debug/logs (для отладочных протоколов)

file=

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

Значения:

Строка буквенно-цифровых символов, выражающих маску файлов.

Пример:

file= bill[0-9]*_[0-9]*

file=log[0-9]*_[0-9]*

time=

С помощью данного параметра пользователь может установить периодичность архивирования либо удаления CDR-файлов (протоколов).

Значения:

Данный параметр имеет следующие значения:

day – удаление/архивация производится каждый день

week - удаление/архивация производится каждую неделю

month – удаление/архивация производится каждый месяц

year – удаление/архивация производится каждый год

Пример: time=day

action=

Выберите действие, которое скрипт rotate.sh будет выполнять с CDR-файлами либо отладочными протоколами.

Значения:

delete – скрипт удаляет отладочные протоколы или CDR-файлы

compress – скрипт выполняет архивацию протоколов (CDR-файлов) и записывает их в директорию, указанную в параметре archive= (см. ниже).

Пример: action=compress

83

archive=

В данном поле указывается имя директории, куда скрипт записывает файл с архивом протокола либо CDR-файла.

Значения:

Строка символов, выражающая имя директории.

Пример:

archive=$H323PROXY_ROOT/bil.tar

5.7 РЕЗЕРВИРОВАНИЕ СИСТЕМЫ, НАХОДЯЩЕЙСЯ ПОД КОММЕРЧЕСКОЙ НАГРУЗКОЙ

Резервирование системы, находящейся под коммерческой нагрузкой осуществляется за счет установки дублирующего сервера MVTS, контролирующего работу главного сервера и находящегося в постоянной готовности принять на себя трафик в случае выхода из строя основного сервера.

Примечание: системный администратор получает email-уведомление о сбое в работе основного сервера MVTS в момент активизации резервного сервера.

Вся необходимая информация, касающаяся резервирования MVTS, подробно изложена в документе [14].

84

6 ПОИСК И УСТРАНЕНИЕ НЕИСПРАВНОСТЕЙ Данная глава содержит информацию, необходимую для эффективного поиска и устранения неисправностей в случае некорректной работы приложения.

В процессе эксплуатации MVTS, пользователь может столкнуться со следующими трудностями:

I. Приложение MVTS не запускается

II. Приложение запущено и работает нормально, но MVTS не устанавливает устойчивые сессии звонков.

Ниже приведены алгоритмы устранения данных неисправностей:

I. Если Ваше приложение MVTS не запускается, выполните следующие действия:

1. Запустите командную консоль MVTS командой $H323PROXY_ROOT/bin/mp_shell.x

2. Выполните команду “info”. Команда выведет на экран список рабочих процессов. Если вывод команды не содержит ни одного процесса, значит приложение не работает. Выполните команду “start”, чтобы запустить MVTS.

3. Через 5-10 минут снова выполните команду “start”. Если список процессов содержит записи mp_kerneld.sh и хотя бы одну запись mp_kerneld.x, то приложение MVTS работает.

4. Чтобы удостовериться в том, что оно работает нормально, выполните команду “sh st”. Эта команда показывает номер версии Вашего MVTS, количество звонков и т.д.

Если по выполнении действий, описанных в пункте 3, список процессов не содержит ни одной записи mp_kerneld.x, это значит, что произошел сбой в системе, вследствие которого приложение MVTS не запускается. Информация обо всех системных ошибках хранится в трассировочных протоколах, которые создаются MVTS в периоды некорректной работы приложения. Трассировочные протоколы находятся в каталоге $H323PROXY_ROOT/debug/logs

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

1. Для перехода в каталог, содержащий трассировочные протоколы, выполните следующую команду: cd $H323PROXY_ROOT/debug/logs

2. Выполните команду “ls –latr” для сортировки всех протоколов по времени создания. Информация о текущих системных ошибках сохраняется в самом последнем трассировочном mp_kernel протоколе, который находится внизу экрана.

3. Выполните команду “less <name of the trace log>”, чтобы открыть данный протокол.

85

4. Выполните архивацию этого протокола с помощью команды ‘tar –czf trace.tar.gz <name of the trace log>’

5. Отправьте архив трассировочного протокола в службу поддержки компании MERA.

II. Если приложение MVTS работает удовлетворительно, но при этом все же не устанавливает соединения, выполните следующие действия.

1. Запустите консоль администрирования MVTS с помощью команды $H323PROXY_ROOT/bin/mp/shell.x

2. Выполните команду “info”. Команда выведет на экран список рабочих процессов. Вывод команды должен содержать по меньшей мере одну запись mp_kerneld.x, которая свидетельствует о нормальной работе приложения.

3. Выполните команду “show stat” для вывода информации о количестве текущих звонков. Помните, что Ваш MVTS имеет предельную пропускную способность (т.е. способность обрабатывать определенное количество одновременных вызовов). Звонки, превышающие пропускную способность MVTS, не принимаются.

4. Если список текущих звонков содержит хотя бы одну запись, это значит, что сбоев в работе приложения MVTS нет, и неисправность, вследствие которой звонки не принимаются, существует только в пределах определенного направления (направлений).

5. Проверка направлений осуществляется командой “show dial”. Если вывод команды содержит хотя бы одно направление (route), это значит, что Ваш диалпир (dialpeer) составлен верно и MVTS направляет звонки на терминирующий шлюз. Если вывод команды не содержит направлений (routes), значит в плане набора нет диалпиров, соответствующих набранному номеру или группе. В этом случае Вам необходимо проверить план набора на наличие ошибок в диалпирах. Помните, что конфигурационные поля плана набора MVTS различают регистр символов, а это значит, что «My_gateway» и «my_gateway» - это два разных шлюза.

Диалпиры, отображаемые командой “show dial”, являются свидетельством того, что Ваш план набора составлен правильно и MVTS направляет звонки по назначению.

Для выяснения причин неудачных звонков при правильной конфигурации Вашего приложения необходим анализ CDR-записей.

CDR-записи создаются MVTS и включают в себя коды разъединения (локальные коды MVTS и коды стандарта Q931), которые генерируются как MVTS, так и оборудованием Ваших партнеров.

Для получения кодов разъединения необходимо найти CDR-запись интересующего Вас звонка. Это можно сделать двумя способами – с помощью приложения MVTS Manager и с помощью консоли администрирования.

Для получения CDR-записи с помощью консоли MVTS выполните следующие действия:

86

1. Для перехода в каталог, содержащий CDR-записи, выполните команду cd $H323PROXY_ROOT/debug/logs

2. Выполните команду “ls -latr”, чтобы показать список всех CDR в данном каталоге.

3. Информация о текущих звонках, обрабатываемых MVTS, содержится в последней CDR-записи в списке.

4. Для просмотра содержимого выбранного CDR выполните команду less “<filename>”.

5. Задайте параметр поиска (номер телефона, время оригинации вызова, и т.д) с помощью команды / <search string>.

Для просмотра необходимой CDR-записи с помощью приложения MVTS Manager необходимо выполнить следующие действия:

1. С помощью MVTS Manager установите связь с хостом MVTS.

2. Убедитесь, что в диалоговом окне “Connect” НЕ выбрана опция “Local”.

3. Для просмотра списка CDR-файлов перейдите в секцию “CDR”.

4. Для просмотра параметров звонка дважды щелкните левой кнопкой мыши по нужному CDR-файлу.

5. Для просмотра отладочного протокола, соответствующего выбранной CDR-записи, правой кнопкой мыши щелкните по CDR-записи и выберите “debug” из опций «выпадающего» меню.

В найденной любым из двух способов CDR-записи находится идентификатор звонка (CALL ID) и необходимые Вам коды разъединения.

Найдите код разъединения звонка и с помощью Таблицы Кодов Разъединения выясните его значение.

Описание CDR-файла, подробное объяснение всех полей CDR-записи и пример CDR-записи находятся здесь.

Если все параметры обработки вызовов (оригинирующий и терминирующий пользователи, возможный маршрут звонка и т.д) настроены правильно, как правило сложно найти причину неудачных звонков. Единственным способом выяснить, что препятствует установлению вызовов, может служить тщательное изучение отладочных протоколов, которые содержат последовательную запись о сессии вызова. Для получения отладочного протокола нужного Вам звонка, необходимо знать идентификатор этого звонка (Call ID). Идентификатор звонка может быть получен из записи о звонке (CDR).

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

1. Убедитесь, что поля trace_level= и level= секции [Debug]

87

88

файла meraproxy.cfg имеют значение “3”.

2. Найдите CDR-запись нужного Вам звонка (алгоритм поиска дан выше) и узнайте идентификатор звонка (Call ID), который представляет собой 32-битное шестнадцатиричное число

3. Перейдите в каталог, где находится утилита logextractor.sh (/mvts/bin)

4. Запустите утилиту, используя имя отладочного протокола и идентификатор звонка в качестве параметра команды:

#> ./logextractor.sh “logfile” ‘call_id’ > log.txt

где:

logfile - имя отладочного протокола

call_id - идентификатор интересующего Вас звонка (взят из CDR)

log.txt - имя текстового файла куда записывается отладочный протокол

Пример:

./logextractor ".tmp_log_64359bb828958d9127f5a4f6681e60f74c84bb64” ’20 a1 1a 90 7d f5 d8 11 86 29 00 0e 0c 30 a2 1f’ > log.txt

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

Таблица, приведенная ниже, содержит список ошибок системы которые могут быть исправлены пользователем MVTS, не обладающим знаниями обо всех принципах работы приложения и без помощи службы технической поддержки компании MERA.

6.1 НЕИСПРАВНОСТИ И СПОСОБЫ ИХ УСТРАНЕНИЯ Таблица 17 Список неисправностей и способы их устранения

Проблема Вероятная причина Способ устранения

Звонки «не проходят» при значении LDC (local disconnect code) = 200, несмотря на правильную конфигурацию в файлах шлюзов и плане набора.

Звонки данного направления не авторизованы по RADIUS-протоколу

1. Правильно настройте авторизацию вызовов по RADIUS-протоколу.

2. Отключите авторизацию через RADIUS для конкретных оригинирующих шлюзов, сбросив флаг (auth_enable=0).

MVTS не запускается. Система не поддерживает USB-устройства.

Не обнаружен HASP ключ.

Проверьте, правильно ли вставлен HASP ключ в USB-порт.

Проверьте, настроено ли ядро Linux на поддержку USB-устройств.

Убедитесь, что установлены драйверы HASP ключа (service aksusbd start).

Проверьте, загружены ли драйверы USB-устройств(ps –aux|grep usb).

Если все вышеуказанные проверки прошли с положительным результатом запустите на исполнение утилиту обнаружения HASP ключа hasp_detect.x

[root@host local]# ./hasp_detect.x

При положительном результате проверки утилитой вывод будет: Try to detect HASP key

89


HASP key is connected

При кажущейся полной исправности MVTS не регистрирует пользователей, отсутствует TCP соединение и не принимаются вызовы.

HASP ключ запрограммирован на ограниченную по времени лицензию, срок которой истек.

Проверьте срок своего лицензионного соглашения и обратитесь в компанию МЕРА к своему менеджеру по продажам для решения вопроса о перепрограммировании HASP ключа.

MVTS отказывает в RAS-регистрациях с причиной Duplicate alias (дублирование псевдонима) или Security denial (отказ по причинам безопасности) в отладочных протоколах.

Неправильная конфигурация RAS-пользователя, в отношении которого был получен отказ.

1. Причина ошибки Duplicate alias (дублирование псевдонима) указывает на то, что шлюз, которому было отказано в регистрации, одновременно присутствует в конфигурации системы и как статический шлюз (в файле gateway.cfg), и как RAS-пользователь (в файле user.cfg). Удалите ту запись, которую считаете лишней, и оставьте только ту, которая описывает шлюз как статический (в файле gateway.cfg) или как пользователя, регистрирующегося по протоколу RAS (в файле user.cfg).

2. Причина ошибки Security denial (отказ по причинам безопасности) указывает на проблемы с паролем пользователя. MVTS воспринимает поле H323_ID как строку в формате “имя пользователя|пароль”, т.е.

90


регистрация пройдет успешно только в том случае, если содержимое поля H323_ID, посылаемое регистрирующимся пользователем, имеет формат H323_ID=123|456, т.е. запись о RAS-пользователе в файле user.cfg содержит параметры: user=123, password=456.

Количество одновременных сессий никогда не превышает 100. Система часто завершает вызовы с локальным кодом разъединения 112.

Нехватка свободных файловых дескрипторов (сокетов).

Сконфигурируйте операционную систему на большее число одновременно используемых файловых дескрипторов (сокетов) или перекомпилируйте ядро операционной системы (см. раздел 8.2).

Вызовы «не проходят» при выключенной H.245 инкапсулляции.

На каком-либо брандмауэре по маршруту вызова закрыты TCP-порты в диапазоне 1024-65535.

Откройте TCP-порты в диапазоне 1024-65535 на всех межсетевых экранах по всему маршруту вызова.

Невозможен просмотр записей с информацией о вызове (CDR records) в графическом интерфейсе пользователя MVTS (MVTS MS)

Пользователь, пытающийся просмотреть записи, не имеет прав на чтение каталога mvts/billing или содержащихся в нем файлов с CDR записями.

Чтобы обеспечить создание новых файлов биллинговой статистики (CDR-файлов) с нужными правами доступа пользователя, присвойте параметрам bil_file_attr= и bil_tmpfile_attr= в секции [Billing] конфигурационного файла meraproxy.cfg значение 444, т.е. bil_file_attr=444 и bil_tmpfile_attr=444

При работе в графическом интерфейсе пользователя (MVTS MS) пункт выпадающего меню debug остается

Отсутствуют права на чтение файлов из каталога $H323PROXY_ROOT/debug/logs

Убедитесь, файлы с префиксами имен tmp_log* и log* в каталоге $H323PROXY_ROOT/debug/logs доступны

91

92


недоступным, при щелчке правой кнопкой мыши по CDR-записи.

для чтения пользователем mvts по умолчанию. Чтобы предоставить пользователю mvts доступ на чтение вновь создаваемых файлов выставьте значения параметров debug_file_attr=444 и debug_tmpfile_attr=444 в секции [Debug] файла meraproxy.cfg. В качестве альтернативной меры включите пользователя mvts в пользовательскую группу с необходимыми правами.

7 СПРАВОЧНАЯ ИНФОРМАЦИЯ

7.1 АЛГОРИТМ ВЫБОРА ОБЪЕКТА НАБОРА

Сервер просматривает все адресуемые направления передачи звонка (объекты набора) в порядке убывания их приоритета. Объект набора (dial peer) считается подходящим, если он удовлетворяет следующим условиям:

• номера вызываемого и вызывающего абонентов удовлетворяют условиям dst_pattern и src_pattern соответственно

Если условие src_pattern не сформулировано, то любой номер считается удовлетворительным для данного направления.

• группе, к которой принадлежит шлюз-оригинатор, не запрещены исходящие звонки через данный объект набора

Множества групп шлюзов, которым разрешено/запрещено совершать звонок через данный объект набора, определяются по следующему алгоритму:

o если group_allow и group_deny - пустые, то разрешено всем группам, иначе

o если group_deny - не пустое и group_allow - пустое, то разрешено всем группам, кроме перечисленных в group_deny , иначе

o если group_allow – не пустое и group_deny – пустое, то разрешено только группам, перечисленным в group_allow , иначе

o если group_allow и group_deny – не пустые, то разрешено только группам, перечисленным в group_allow и не перечисленым в group_deny

• шлюз, указанный в поле gateway записи об объекте набора загружен полностью и не имеет признака временной неработоспособности (параметр accessibility=1 )

Звонок направляется на шлюз, связанный с найденным объектом набора.

Если в записи об объекте набора, выбранном в соответствии с полями dst_pattern и src_pattern , в поле gateway указано служебное слово AGAIN (gateway=AGAIN), то производится трансляция номеров, и поиск объекта начинается заново с измененными номерами (максимальный уровень вложенности поиска - 10).

Ниже приводится графическое представление алгоритма поиска объекта набора.

93

7.2 ВЗАИМОДЕЙСТВИЕ MVTS С RADIUS-СЕРВЕРОМ MVTS может обращаться к RADIUS-серверу за тремя типами сервиса: авторизация (Authorization), учет (Accounting), и маршрутизация (Routing).

При любом из этих видов сервисов инициатором обмена является MVTS. RADIUS-сервер выступает инициатором обмена лишь в одном случае - при необходимости завершить звонок по исчерпанию кредитового остатка.

При запросах на авторизацию и маршрутизацию MVTS отправляет на RADIUS сервер запрос AccessRequest соответсвующего типа и в ответ получает AccessAccept либо AccessReject. При обмене учетного характера (Accounting) MVTS посылает запрос AccountingRequest (Code 4) и в ответ ожидает AccountingResponse.

RADIUS сервер инициирует связь с MVTS запросом на завершение звонка DisconnectRequest (type 40), и MVTS отвечает либо подтверждением завершения сессии DisconnectAck(type41), либо сообщением об отказе в завершении звонка DisconnectNack(type 42). Ниже приводится подробное изложение структры обмена MVTS и RADIUS-сервера.

7.2.1 ПРОВЕДЕНИЕ АВТОРИЗАЦИИ РЕГИСТРИРУЕМОГО КОНЕЧНОГО ПОЛЬЗОВАТЕЛЯ

Данный тип запроса к RADIUS серверу выполняется при получении запроса на регистрацию RegistrationRequest, поступающего на MVTS-привратник при авторизации регистрируемого пользователя (RAS пользователя).

Таблица 18 Содержимое запроса AccessRequest от MVTS к RADIUS-серверу при авторизации RAS-пользователя

Номер

атрибута

IETF

Наименование атрибута

Номер атрибута VSA

Описание Формат данных Обязательный/необязательный

(О/Н)

1 User name Имя пользователя Строка символов О

2 User password Пароль закодированный через MD5, или в plain виде

BYTE[16] или строка символов

Н

3 User chap password CHAP-криптованный пароль

BYTE[16] Н

60 Chap challenge Time stamp, использованный для CHAP-криптования пароля

BYTE[4] Н

4 NasIpAddress Локальный IP-адрес MVTS

BYTE[4] О

5 NasPortType Тип локального порта

Всегда 0 О

95

6 ServiceType Тип сервиса Всегда 1 О

30 CallingStationId ANI номер Строка символов Н

31 CalledStationId DNIS номер Строка символов Н

26 MD5 password Полученный из RegistrationRequest MD5 пароль

xpgk-md5-auth=<username/<timestamp>>/HEX[16]

Н

26 AuthRequestType Тип запроса на авторизацию

xpgk-request-type=user О

26 SourceAddress 1 IP адрес и порт, с которых был получен RRQ

xpgk-source-addr=IP:port О

Ожидаемые ответы: AccessAccept и AccessReject.

Таблица 19 Содержимое ответа AccessAccept от RADIUS-сервера при авторизации RAS-пользователя

Номер

атрибута

IETF


Номер атрибута

VSA


(О/Н)

26 EndpointNumber 1 Номер для звонка

на данного пользователя

xpgk-ep-number=<номер> Н

При получении AccessReject авторизация считается неуспешной, и пользователю отсылается RegistrationReject c причиной SecurityDenial.

7.2.2 АВТОРИЗАЦИЯ ВЫЗОВА Данный вид запроса на авторизацию обращается к RADIUS-серверу перед отправкой звонка на выбранное направление для терминации.

Таблица 20 Содержимое запроса AccessRequest от MVTS к RADIUS-серверу при авторизации вызова по выбранному направлению

Номер

атрибута

IETF


Номер атрибута VSA


(О/Н)


2 User passwd Пароль закодированыый через

BYTE[16] или строка символов

Н

96

MD5, или в plain виде


BYTE[16] Н

60 Chap chellenge Отметка времени (time stamp), использованная для CHAP-криптования пароля

BYTE[4] Н

4 NasIpAddress Локальный адрес MVTS

BYTE[4] О

5 NasPortType Тип локального порта Всегда 0 О




26 MD5 password 1 Полученный из RegistrationRequest MD5 пароль


Н

26 AuthRequestType 1 Тип запроса на авторизацию

xpgk-request-type=number

О

26 Conf ID 4 Conference ID (идентификатор конференции)

h323-conf-id=<HEX[16]> О

26 Call ID 1 Call ID (идентификатор звонка)

h323-call-id=<HEX[16]> Н

26 SrcGatewayId 33 ID шлюза-оригинатора для RADIUS сервера (либо его IP адрес если ID не задан)

h323-gw-id=<string> or <IP-address>

Н

26 SrcGatewayIP 1 IP адрес оригин. шлюза

h323-gw-address=<IP-address>

Н

26 DstGatewayIP 23 IP адрес терм. шлюза или привратника (gatekeeper)

h323-remote-address=<IP-address>

Н

26 DstGatewayId 1 Идентификатор терм. шлюза или привратника, либо IP адрес, если идентификатор не задан

h323-remote-id=<IP-address>

Н

26 DstUserName 1 Пользовательское имя терм. шлюза

xpgk-destination-user=<string>

Н

26 ReceivedH323Id 1 H323 алиас, полученный в пакете SETUP

xpgk-h323-id=<string> Н

26 IncomingAniNumber 1 ANI номер, полученный в пакете SETUP

xpgk-src-number-in=<number>

Н

26 OutgoingAniNumber 1 ANI номер отправленный на терминирующий

xpgk-src-number-out-<number>

Н

97

шлюз

26 IncomingDnisNumber 1 DNIS номер полученный в пакете SETUP

xpgk-dst-number-in=<number>

Н

26 OutgoingDnisNumber 1 Номер DNIS, отправляемый на терминирующий шлюз

xpgk-dst-number-out-<number>

Н

26 RouteRetries 1 Текущий номер попытки

xpgk-route-retries=<number>

О

Ожидаемые ответы: AccessAccept и AccessReject

Таблица 21 Содержимое ответа AccessAccept от RADIUS сервера при авторизации терминации вызова по выбранному направлению

Номер

атрибута

IETF



VSA


(О/Н)

26 CISCO_H323_CREDIT_TIME 102 Максимальная продолжительность сессии

h323-credit-time=<время в секундах>

Н

26 CISCO_H323_RETURN_CODE 103

h323-return-code (если это поле отсутствует или если присутствует, и значение поля равно 0, 13, 51 или 52, то авторизация считается успешной, иначе звонок завершится с LDC 208)

h323-return-code=<число>

Н

26 h323-ivr-in 1

Имя пользователя, которое будет использовано в данной сессии для биллингования

h323-ivr-in=<string> Н

26 CISCO_H323_REDIRECT_NUMBER 106 Трансляция DNIS

номера сессии h323-redirect-number=<номер>

Н

При получении AccessReject авторизация считается неуспешной и данное направление завершается с соовтетствующим локальным кодом разъединения (LDC).

7.2.3 СЕРВИС УЧЕТА ВРЕМЕНИИ И ПРИЧИТАЮЩЕЙСЯ ПЛАТЫ (ТИП ЗАПРОСА ACCOUNTING REQUEST)

98

7.2.3.1 Стартовая запись (Accounting start record) Посылается на RADIUS-сервер при получении звонка (входящий участок звонка) или при отправке сообщения SETUP стороне, терминирующей вызов (исходящий участок звонка).

Тип запроса – AccountingRequest (Code 4)

Таблица 22 Структура стартовой записи (Accounting Start), отправляемой на RADIUS сервер

Номер

атрибута

IETF



VSA


(О/Н)


4 NasIpAddress Локальный адрес MVTS BYTE[4] О



41 AcctDelayTime Всегда 0 О

40 AcctStatusType Тип аккаунтингового пакета

Всегда 1 О



44 AcctSessionId Идентификатор для пары старт-стоп accounting-пакетов

Формат описан после таблицы

О

26 CISCO_H323_CALL_ORIGIN 26 Тип лега, к которому относится данный аккаунтинг

h323-call-origin=answer для входящего лега,

h323-call-origin=originate для исходящего лега

О

26 IncomingConfId 1 Conference Id, полученный в SETUP’е

h323-incoming-conf-id=<conf id>

Н

26 IncomingCallId 1 Call Id, полученный в SETUP’е

h323-incoming-call-id=<conf id>

Н

26 Setup time 25 Время получения SETUP’А

h323-setup-time=< hh:mm:ss.uuu t www MMM dd yyyy>

Н



Н

26 SrcGatewayIP 1 IP адрес шлюза - оригинатора


Н



26 DstGatewayIP 23 IP address of terminating h323-remote-address=<IP- Н

99

gateway or gatekeeper address>



Н

26 DstUserName 1 Имя терминируещего шлюза


Н





Н

26 OutgoingAniNumber 1 ANI номер отправленный на терминирующий шлюз


Н



Н



Н

26 RouteRetries 1 Номер текущей попытки xpgk-route-retries=<number>

О



Redirect number 1 Список номеров, получаемых от RADIUS-сервера в течение одной сессии

xpgk-redirect-number=<список номеров>

Н

26 xpgk-record-id 1 Идентификатор звонка в том формате, в котором он присутствует в CDR

xpgk-record-id=<RECORD-ID>

O

В поле A c c t S e s s i o n I d данные представлены в формате:

<prefix>-<call number>-<hash><leg type><route number>,

где

<prefix> - случайно выбранное шестнадцатиричное число, состоящее из восьми символов

<call number> - порядковый номер вызова с момента последнего запуска MVTS

<hash> - хэш-строка, состоящая из восьми шестнадцатеричных чисел

<leg type> - тип лега (Т для входящего лега и V для исходящего лега при значениях параметра acct_leg_type= от 1 до 3 и AV для входящего лега и 4 или 5 и OV для исходящего лега)

<route number> - номер попытки завершения текущего вызова.

Ожидаемый ответ – AccountingResponse.

7.2.3.2 Стоп запись (Accounting stop record) Отправляется RADIUS-серверу при завершении звонка.

Тип запроса – AccountingRequest (Code 4)

100

Примечание: стоп запись (пакет Accountin Stop), посылаемая MVTS на RADIUS-сервер может иногда значительно превышать максимально возможный размер UDP-пакета, заданный в операционной системе – 1500 байт. Поскольку не все сетевые маршрутизаторы способны восстанавливать передаваемые пакеты, разбитые на фрагменты, RADIUS-сервер, при отсутствии пакета Accounting Stop, продолжает начисление оплаты по звонку даже после того, как данный звонок был завершен.

Для решения данной проблемы используйте параметр stop_acct_level= в секции [Radius], позволяющий уменьшить размер пакетов Accounting Stop за счет вырезания из них некоторых VSA-полей.

Полная информация о данном конфигурационном параметре приведена в документе [12].

Таблица 23 Структура стоп записи (Accounting Stop), отправляемой на RADIUS сервер

Номер

атрибута

IETF



VSA


(О/Н)





41 AcctDelayTime Всегда 0 О

40 AcctStatusType Тип аккаунтингового пакета

Всегда 1 О

30 CallingStationId ANI-номер Строка символов Н

31 CalledStationId DNIS-номер Строка символов Н

44 AcctSessionId Идентификатор для пары старт-стоп accounting-пакетов

Формат описан после таблицы

О

26 CISCO_H323_CALL_ORIGIN 26 Тип лега, к которому относится данный аккаунтинг

h323-call-origin=answer для входящего лега,

h323-call-origin=originate для исходящего лега

О

26 IncomingConfId 1 Conference ID (идентификатор конференции), полученный в SETUP’Е

h323-incoming-conf-id=<conf id>

Н

26 IncomingCallId 1 Call ID (идентификатор звонка), полученный в SETUP’Е

h323-incoming-call-id=<conf id>

Н

26 Setup time 25 Время получения SETUP h323-setup-time=< hh:mm:ss.uuu t www MMM dd yyyy>

Н

26 SrcGatewayId 33 ID шлюза-оригинатора h323-gw-id=<string> or Н

101

для RADIUS сервера (либо его IP адрес если ID не задан)

<IP-address>



Н

26 Connect time 28 Время установления коннекта

h323-connect-time=< hh:mm:ss.uuu t www MMM dd yyyy>

Н

26 Disconnect time 29 Время завершения звонка

h323-disconnect-time=< hh:mm:ss.uuu t www MMM dd yyyy>

Н

26 Disconnect cause 30 Q931 причина завершения звонка

h323-disconnect-cause= < значение >

Н

26 Voice quality 31 Качество голоса, подсчитанное по методике компании МЕРА

h323-voice-quality=<значение>

Н

26 Local disconnect cause 1 Локальный код завершения звонка

xpgk-local-disconnect-cause=<значение>

Н

26 LAR fault reason 1 Причина прекращения поиска роутов для терминации

xpgk-lar-fault=< значение >

Н

26 Codecs of source gateway 1 Список кодеков, заявленных оригинирующим шлюзом

xpgk-src-codec=<список кодеков >

Н

26 Codecs of terminating gateway 1 Список кодеков, заявленных терминирующим шлюзом

xpgk-dst-codec=<список кодеков >

Н

26 Initial incoming IP address 1 Локальный адрес, на который пришел звонок

xpgk-initial-incoming-local-address=<IP-address>

Н

26 Selected incoming IP address 1 Локальный адрес, который был выбран для входящего лега

xpgk-selected-incoming-local-address=<IP-address>

Н

26 Selected outgoing IP address 1 Локальный адрес, использованный для исходящего лега

xpgk-selected-incoming-local-address=<IP-address>

Н

26 Converter name 1 Имя описания конвертера, через который был терминирован звонок

xpgk-converter-name Н

26 Converter IP-address 1 IP-адрес конвертера, через который был терминирован звонок

xpgk-converter-address Н

26 PDD time 1 Интервал времени между поступлением звонка и поднятием трубки

xpgk-pdd-time Н


h323-conf-id=<HEX[16]> Н

102

26 DstGatewayIP 23 IP адерс терминирующего шлюза или привратника (gatekeeper)


Н



Н

26 DstUserName 1 Пользовательское имя терм. шлюза


Н



26 IncomingAniNumber 1 ANI номер, полученный в SETUP пакете


Н

26 OutgoingAniNumber 1 ANI номер, отправленный терм. шлюзу


Н

26 IncomingDnisNumber 1 DNIS номер, полученный в пакете SETUP


Н

26 OutgoingDnisNumber 1 DNIS номер, отправленный на терм. шлюз


Н

26 RouteRetries 1 Текущий номер попытки xpgk-route-retries=<number>

О



Redirect number 1 Список номеров, полученных от RADIUS-сервера в течение одной сессии

xpgk-redirect-number=<список номеров>

Н

26 InfoNumber 1 Номер, сформированный MVTS из данных, полученных в пакете Setup и Information

xpgk-info-number=<номер>

Н

26 xpgk-record-id 1 Идентификатор звонка в том формате, в котором он присутствует в CDR

xpgk-record-id=<RECORD-ID>

O

103

В поле A c c t S e s s i o n I d данные представлены в формате:

<prefix>-<call number>-<hash><leg type><route number>,

где

<prefix> - случайно выбранное шестнадцатеричное число, состоящее из восьми символов

<call number> - порядковый номер вызова с момента последнего запуска MVTS

<hash> - хэш-строка, состоящая из восьми шестнадцатеричных чисел

<leg type> - тип лега (Т для входящего лега и V для исходящего лега при значениях параметра acct_leg_type= от 1 до 3 и AV для входящего лега и 4 или 5 и OV для исходящего лега)

<route number> - номер попытки завершения текущего вызова. Ожидаемый ответ – AccountingResponse.

7.2.4 ВНЕШНЯЯ МАРШРУТИЗАЦИЯ С ПОМОЩЬЮ RADIUS В случае, когда запись об объекте набора a файле dialpeer.cfg содержит настройку gateway=EXTERNAL , авторизации пользователя будет предшествовать запрос к RADIUS-серверу на маршрутизацию, содержащий в поле AV-PAIR значение "xpgk-routing-request=1".

RADUIS-сервер может выдавать один из трех следующих ответов:

Reject – при принятии данного ответа произойдет завершение вызова

Accept without routing information – начнется поиск новых возможных маршрутов

Accept with routing data – в данном пакете будут содержаться следующие ID:

− CISCO VSA ID=251 в записи new_username/new_password (это поле не обязательно для заполнения, оно выполняет ту же функцию, что и параметр override_user в файле dialpeer.cfg). Например, если значение поля - user01/qwerty, тогда имя пользователя и пароль в настоящем вызове будут заменены соответственно на user01 и qwerty.

− CISCO VSA ID=252, представляет собой запись из пяти, шести или семи полей: g a t e w a y / p r o x y _ m o d e / s o u r c e / d e s t / s r c _ b i l l / d s t _ b i l l / i p -a d d r e s s [ : p o r t ] , где

gateway - название секции gateway в файле gateway.cfg

proxy_mode – тип проксирования:

0 – функция проксирования выключена

1 – функция проксирования включена

2 – использовать тип проксирования оригинирующего шлюза

3 – использовать тип проксирования терминирующего шлюза

104

source - номер вызывающего абонента (src_number)

dest - номер вызываемого абонента, который будет передан терминирующему шлюзу (dst_number)

src_bill - номер вызывающего абонента в биллинговой системе

dst_bill - номе вызываемого абонента в биллинговой системе

ip- address[:port] – IP адрес для начала звонка. Значение параметра port не обязательно для заполнения, в случае незаполнения значение по умолчанию – 1720.

Поле, содержащее ID=251, должно быть единственным. Полей с ID=252 может быть несколько, и указанные маршруты будут обрабатываться последовательно.

7.2.4.1 Запрос AccessRequest при внешней маршрутизации

MVTS выполняет данный запрос, если в поле gateway= в описании объекта набора (dial peer) находится ключевое слово EXTERNAL.

Цель данного запроса – получить маршруты для терминации звонка в конечном пункте. При этом существует возможность менять имя пользователя и пароль для данного звонка.

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

Тип запроса – AccessRequest (Code 1)

Таблица 24 Структура запроса к RADIUS серверу на маршрутизацию

Номер

атрибута

IETF



VSA


(О/Н)


2 User passwd Пароль закодированыый через MD5, или в plain виде

BYTE[16] или Строка символов

Н


BYTE[16] Н

60 Chap chellenge Time stamp, использованный для CHAP-криптования пароля

BYTE[4] Н




105



26 MD5 password 1 Полученный из SETUP registrationRequest MD5 пароль


Н

26 AuthRequestType 1 Тип запроса на авторизацию

xpgk-request-type=route О

26 Routing request flag 1 Флаг запроса внешней маршрутизации

xpgk-routing-request=1 О







Н



Н

26 DstGatewayIP 23 IP адрес терминир. шлюза или привратника


Н



Н

26 DstUserName 1 Пользовательское имя терминирующего шлюза


Н





Н

26 OutgoingAniNumber 1 ANI номер отправленный на терминирующий шлюз


Н



Н



Н

26 RouteRetries 1 Текущий номер попытки перемаршрутизации

xpgk-route-retries=<number>

О

Ожидаемый ответ: AccessAccept

106

Таблица 25 Структура ответа AccessAccept RADIUS сервера на запрос о маршрутизации

Номер

атрибута

IETF



VSA

Описание Формат данных

Обязательный/необязательный

(О/Н)

26 XPGK_XROUTING_USERNAME 251

Трансляция имени пользователя и пароля на данную сессию (только 1 вхождение в пакет)

<имя>/<пароль> Н

26 XPGK_XROUTING_ROUTING 252

Набор маршрутов для терминации звонка (может быть несколько маршрутов, которые будут отработаны в порядке расположения в пакете)

Формат описан после таблицы*

Н

26 XPGK-XROUTING-TRANSLATE 250 Трансляция номеров данного звонка

ANI/DNIS/Bill_ANI/Bill_DNIS

Н

* Формат поля XPGK_XROUTING_ROUTING: gateway/proxy_mode/source/dest/src_bill/dst_bill/ip-address[:port]/converter,

где:

gateway - имя шлюза (секции) из файла gateway.cfg;

proxy_mode - режим проксирования:

0 - нет проксирования медиа трафика

1 - есть проксирование медиа трафика;

2 - использовать режим проксирования оригинирующего шлюза;

3 - использовать режим проксирования терминирующего шлюза;

source - номер вызывающего абонента (src_number)

dest - номер вызываемого абонента, который будет отправлен на терминирующий шлюз (dst_number)

src_bill - номер вызывающего абонента для системы биллинга;

dst_bill - номер вызываемого абонента для системы биллинга;

ip-address[:port] - ip-адрес, с которым следует устанавливать соединение, с необязательным параметром номер порта, если номер порта не указан, то считается что это порт 1720

converter – имя описания конвертера, через который будет выполняться терминация звонка

107

AccessReject – маршрутизация считается неуспешной и данный звонок завершается с соовтетствующим локальным кодом

7.2.5 ЗАПРОС О ЗАВЕРШЕНИИ ЗВОНКА, ПОСТУПАЮЩИЙ ОТ RADIUS-СЕРВЕРА

MVTS способен обрабатывать запрос от RADIUS-сервера на завершение звонка DisconnectRequest (type 40).

В этом пакете должно присутствовать поле VSA(24) h323-conf-id или VSA(1) h323_incoming-conf-id в формате 4 шестнадцатеричных октета, разделенных пробелом (аналогично тому, как MVTS отправляет ConfId на RADIUS-сервер). Этот ConfId используется для поиска активного звонка. Звонок завершается с локальным кодом 100 (ForceTerminateCall).

Если завершение звонка прошло успешно, то MVTS отвечает пакетом DisconnectAck(type41). Если неуспешно, например, такой звонок не найден, или отсутствует поле с ConfId, то MVTS отвечает DisconnectNack(type 42).

7.2.6 АУТЕНТИФИКАЦИЯ RAS-ПОЛЬЗОВАТЕЛЕЙ, НЕ ОПИСАННЫХ В ФАЙЛЕ USER.CFG

Для того чтобы разрешить регистрацию на MVTS любому RAS-пользователю, не указанному в файле user.cfg, Вы можете добавить секцию [Default] в файл user.cfg и в ней установить в поле user= значение “default”:

user.cfg

… [default]

user=default … Аутентификация таких пользователей производится только через RADIUS-сервер. Существует несколько возможных сценариев аутентификации RAS-пользователей через секцию [Default], которые зависят от типов аутентификации, поддерживаемых регистрирующимся оборудованием:

Аутентификация по H.323 идентификатору (стандартная RADIUS-аутентификация)

Аутентификация по хэш-паролю MD5 Аутентификация по CHAP-паролю Дайджест-аутентификация (Digest authentication)

108

Аутентификация по H.323 идентификатору (стандартная RADIUS аутентификация)

В ходе стандартной RADIUS-аутентификации пользователь присылает на MVTS пакет AccessRequest, в котором в поле terminalAlias содержится идентификатор пользователя, состоящий из имени пользователя и пароля, между которыми стоит разделитель (выделено красным овалом на Рис. 40). В качестве разделителя могут использоваться символы «|», «:», «!» и «%».

После получения пакета MVTS высылает RADIUS-серверу запрос на доступ (выделено красным прямоугольником), который содержит имя пользователя, его пароль, идентификатор MVTS и идентификатор порта, к которому пользователь пытается получить доступ. Пароль шифруется по алгоритму MD5 (MD5 хэш) и генерируется по следующей схеме: UserPassword = MD5Hash(Shared Secret, RemoteAuthenticator) XOR password, где Shared Secret – значение поля secret в секции Radius файла meraproxy.cfg ; RemoteAuthenticator - псевдослучайное число, которое передается регистрирующимся оборудованием в заголовке запроса AccessRequest; password - пароль пользователя из базы данных MVTS.

Рис. 40 Стандартная RADIUS аутентификация На основе полученных данных и секретного ключа (shared secret), установленного между MVTS и RADIUS-сервером, RADIUS-сервер генерирует свой MD5 хэш, и, если он совпадает с хэшем, полученным от MVTS, то он высылает MVTS сообщение AccessAccept, в противном случае высылается сообщение об отказе в доступе (AccessReject).

Аутентификация по хэш-паролю MD5

109

При данном методе аутентификации регистрирующийся пользователь присылает на MVTS запрос GatekeeperRequest, в котором содержится информация о том, что пользователь поддерживает именно этот метод аутентификации. После получения от MVTS сообщения GatekeeperConfirm, пользователь высылает MVTS запрос на регистрацию, в котором содержится псевдоним пользователя (alias), отметка времени (time stamp), MD5 хэш и информация о параметрах, использовавшихся для его генерации (выделено красным овалом на Рис. 41). Поскольку MVTS не знает настоящего пароля регистрирующегося пользователя, то хэш-пароль передается на RADIUS-сервер не в поле password, а в поле VSA(1) xpgk-md5-auth (выделено красным прямоугольником) вместе с параметрами, использовавшимися для его генерации. В данном случае для аутентификации пользователя RADIUS-сервер должен суметь распознать поле VSA(1) xpgk-md5-auth.

Рис. 41 Аутетнтификация по хэш-паролю MD5

Аутентификация по CHAP-паролю При данном методе аутентификации регистрирующийся пользователь присылает на MVTS gatekeeper request, в котором содержится информация о том, что он поддерживает алгоритм аутентификации по CHAP-паролю. В ответ на запрос MVTS отсылает сообщение GatekeeperConfirm, в котором содержится ключ (challenge), псевдослучайное шестнадцатиразрядное число. Пользователь отсылает MVTS запрос на регистрацию, в котором в поле tokens передает ключ (challenge), хэш, сгенерированный на основе ключа, пароля и идентификатора пользователя. После этого MVTS посылает запрос на регистрацию на RADIUS-сервер, в котором содержится следующая информация: ChapPassword – хэш, сгенерированный пользователем; ChapChallenge – ключ; UserName - имя пользователя.

110

На Рис. 42 приведен пример запроса на регистрацию.

Рис. 42 Аутентификация по CHAP-паролю Задача RADIUS-сервера состоит в том, чтобы распознать поля ChapPassword и ChapChallenge, по имени пользователя найти в своей базе данных пароль пользователя и на основе пароля, имени пользователя и ключа сгенерировать идентичный хэш. В случае если хэш, сгенерированный RADIUS-сервером, не соответствует хэшу, полученному от MVTS, аутентификация отклоняется. Примечание: Если RAS-пользователь поддерживает аутентификацию как по MD5-паролю, так и по CHAP-паролю, то рекомендуется использовать CHAP-аутентификацию, поскольку она не вынуждает MVTS использовать поля VSA.

Дайджест-аутентификация (Digest authentication) Данный метод используется для аутентификации оборудования, поддерживающего протокол SIP. Аутентификация осуществляется следующим образом:

Пользователь присылает на модуль SIP-HIT запрос на регистрацию (пакет REGISTER)

В ответ на запрос модуль SIP-HIT высылает пользователю пакет 401, в котором передает пользователю так называемый "nonce" - псевдослучайное число.

Пользователь на основе “nonce” и других данных генерирует MD5-хэш (DigestResponse), который вместе с параметрами, использованными для его генерации, передается в ответном пакете REGISTER;

Модуль SIP-HIT передает MVTS запрос на регистрацию, в котором в поле tokens передает сертификат, состоящий из MD5-хэша, сгенерированного пользователем, а также данных, которые были использованы для его генерации.

MVTS в пакете AccessRequest в разных полях передает на RADIUS-сервер этот хэш и данные, использовавшиеся пользователем для его генерации.

RADIUS-сервер должен сгенерировать идентичный MD5 хэш с

использованием полученных данных и пароля этого пользователя из

111

своей базы данных. Если сгенерированный хэш совпадет с полученным от MVTS в атрибуте SipDigestResponce (выделено красным овалом на Рис. 43), то пользователь будет авторизован. В противном случае аутентификация отклоняется.

Рис. 43 Дайджест-аутентификация

7.3 СОЗДАНИЕ НЕОБХОДИМОГО КОЛИЧЕСТВА ФАЙЛОВЫХ ДЕСКРИПТОРОВ

Примечание: Если Вы планируете установить демо-версию программного продукта или производительность Вашего MVTS составляет менее 60 одновременных звонков, Вам не нужно увеличивать количество одновременно открываемых файловых дескрипторов и Вы можете опустить информацию, приведенную ниже.

Для расчета количества одновременно используемых дескрипторов, исходите из того, что на каждый звонок при проксировании всего трафика требуется от 6 до 20 сокетов (дескрипторов). Дополнительно необходимо зарезервировать некоторое количество файловых дескрипторов для нужд операционной системы. С учетом этих рекомендаций, для проксирования речевого трафика до трехсот звонков, следует установить число одновременно используемых файловых дескрипторов из расчета 20 дескрипторов на один обслуживаемый звонок. Ориентируйтесь на то, что ограничение в 8192 дескриптора будет достаточным для обслуживания 600 вызовов, а при 16384 дескрипторах система сможет обработать 1000 одновременных звонков.

7.3.1 УВЕЛИЧЕНИЕ КОЛИЧЕСТВА ФАЙЛОВЫХ ДЕСКРИПТОРОВ В ОС RED HAT LINUX

Прежде чем устанавливать определенное количество файловых дескрипторов в операционной системе Linux Red Hat, Вам необходимо решить, от имени какого пользователя будет осуществляться запуск MVTS.

Возможны три варианта:

1. MVTS запускается только от имени пользователя root, соответственно увеличенное количество дескрипторов будет сохраняться при входе в систему именно этого пользователя.

2. Запуск MVTS осуществляется от имени другого конкретного пользователя (кроме пользователя root).

3. MVTS запускается от имени любого пользователем.

112

Ниже приводятся алгоритмы действий оператора системы для использования каждого из трех вариантов.

Если Вы хотите установить постоянное количество файловых дескрипторов (например 8192) только для одного пользователя root, Вам необходимо проделать следующие операции:

1. Открыть файл /etc/profile в любом текстовом редакторе (например vi)

vi /etc/profile

2. Добавить в файл /etc/profile строку ulimit –n 8192

3. Сохранить изменения последовательным нажатием клавиш

ESC : x ! Enter

Для проверки количества доступных файловых дескрипторов, используйте команду ulimit –n

Если предполагается, что MVTS будет запускаться от имени другого конкретного пользователя (кроме пользователя root), и нужно увеличить количество файловых дескрипторов именно для этого пользователя, Вам необходимо будет выполнить следующие действия:

1. Открыть файл /etc/pam.d/login с помощью редактора vi

vi /etc/pam.d/login

2. Удостовериться, что в файле /etc/pam.d/login указан путь к файлу /pam_limits.so

- если путь к данному файлу указан, в файле /etc/pam.d/login должна присутствовать строка /lib/security/pam_limits.so

- если путь к данному файлу не указан, указать его (добавить строку /lib/security/pam_limits.so)

3. Сохранить изменения в файле /etc/pam.d/login

113

4. Открыть файл /etc/security/limits.conf

vi /etc/security/limits.conf

5. В данный файл добавить имя пользователя, от имени которого Вы планируете осуществлять запуск MVTS.

<имя пользователя> soft nofile 1024

<имя пользователя> hard nofile 8192

6. Сохранить сделанные изменения в файле /etc/security/limits.conf

7. Открыть файл /etc/profile

vi /etc/profile

8. Добавить в файл имя пользователя, от имени которого запускается MVTS, следующим образом:

if [ $USER = "имя пользователя" ]; then

ulimit -n 8192

9. Сохранить изменения

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

1. Открыть файл etc/profile

vi etc/profile

2. Добавить в данный файл строку ulimit –n 8192

3. Сохранить изменения

114

4. Открыть файл etc/security limits.conf

vi etc/security limits.conf

5. Добавить в данный файл строку * soft nofile 1024

* hard nofile 8192

6. Сохраните внесенные изменения.

7.3.2 УСТАНОВКА КОЛИЧЕСТВА ФАЙЛОВЫХ ДЕСКРИПТОРОВ ДЛЯ ОС FREEBSD

В отличие от OC Red Hat, в ОС FreeBSD количество одновременно открываемых файловых дескрипторов (kern.maxfiles) непосредственным образом не задается, а связано со значением MAXUSERS (Для более подробной информации см. http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/configtuning-kernel-limits.html) . Зависимость количества одновременно открытых файловых дескрипторов от числа пользователей выражается следующим образом:

kern.maxfiles=(20+MAXUSERS*16)*2

Таким образом, чтобы ОС FreeBSD имела возможность возможность открывать от 8000 файловых дескрипторов одновременно и более(из расчета 20 сокетов на один звонок), нужно перекомпилировать ядро OC, определив значение MAXUSERS равным не менее 249, т.е.

kern.maxfiles = (20+249*16)*2 = 8008

Примечание: Максимально допустимое значение переменной MAXUSERS в FreeBSD – 384.

Для изменения значения переменной kern.maxfiles измените значение параметра в нужной строке файла sysctl.conf. В большинстве случаев таким образом удается решить данную задачу. Но при работе сервера в условиях очень интенсивного трафика может понадобиться дополнительная настройка конфигурационного параметра ядра NMBCLUSTERS. Чтобы получить более подробную информацию по настройке параметра NMBCLUSTERS, обратитесь к руководству пользователя по FreeBSD, используя ссылку http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/configtuning-kernel-limits.html

115

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/configtuning-kernel-limits.html

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/configtuning-kernel-limits.html

7.4 ИСПОЛЬЗОВАНИЕ РЕГУЛЯРНЫХ ВЫРАЖЕНИЙ В КОНФИГУРАЦИИ MVTS

Регулярные выражения используются при задании значений следующим конфигурационным параметрам: dialpeer.cfg - dst_pattern=, src_pattern=,

- dst_translate=, src_translate=

- dst_bill_translate=, src_bill_translate=

- user_translate=

- display_ie_translate=

user.cfg; gateway.cfg - dst_pattern=, src_pattern=,

- dst_translate=, src_translate=,

- in_dst_translate=, in_src_translate=

При необходимости указания пустого номера в описании объектов набора (dialpeer) используется ключевое слово «empty».

Пример:

При значении параметра src_translate=empty/123456, MVTS преобразует полученный пустой номер вызывающего абонента в номер 123456.

Данное ключевое слово также может использоваться для трансформации информационного элемента «display» (параметр display_ie_translate=), в случае, если оно отсутствует в получаемом пакете SETUP.

MVTS проверяет регулярные выражения в правилах преобразования номеров на присутствие запрещенных символов и при обнаружении удаляет их. Регулярные выражения допускают использование следующих символов: ^0123456789*#\& При возникновении ошибки (недопустимый символ в регулярном выражении) результат проверки выводится в трассировочный журнал, который записывается в файл с названием mp.kernel.sh.log-<date>

7.4.1 ПРЕФИКСЫ ПОЛЕЙ DST_PATTERN И SRC_PATTERN Наиболее часто используемые конструкции: dst_pattern=777[0-9]+

116

Комментарий: номера, начинающиеся с 777 и состоящие далее любого количества цифр от 0 до 9. удачные примеры: 77711, 777922 неудачные примеры: 77811, 7767 dst_pattern=777[0-5]{1}[0-9]+ Комментарий: номера начинающиеся с 777, далее следует любая цифра в диапазоне от 0 до 5 и затем любое количество цифр от 0 до 9. удачные примеры: 77711, 777422 неудачные примеры: 777, 77811, 77761, 7775 dst_pattern=...... или dst_pattern=.{6} Комментарий: шесть любых знаков, включая все разрешенные цифры и знаки – например, символ # удачные примеры: 123456, 976065, 123#56 неудачные примеры: 1111111, 111, 123456#

7.4.2 ТРАНСЛЯЦИЯ НОМЕРОВ Основной целью преобразования (трансляции) является приведение телефонных номеров к определенному формату. Для трансляции номеров наиболее часто используются такие операции как добавление, удаление или замена отдельных частей телефонного номера.

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

• символ «/» делит регулярное выражение трансляции на две части: шаблон поиска и строка замены. Все, что находится слева от символа «/» является шаблоном поиска (все номера, подходящие под шаблон поиска, подлежат дальнейшему преобразованию). Все, что находится справа от символа «/», является строкой замены (т.е. тем, на что будет заменен номер, подошедший под шаблон в левой части выражения).

• символ «|» делит шаблон поиска на несколько логических частей • символ «\» ставится в правой части регулярного выражения. Следующая за

этим знаком цифра обозначает какую часть шаблона, разделенного символами «|» следует использовать для формирования нового номера

• символ «&» обозначает все выражение, подошедшее под шаблон поиска. Данный символ употребляется в правой части выражения.

• символ «.» означает любой знак (включая цифры, буквы и символы)

117

• выражение в квадратных скобках [] используется только в шаблоне поиска и означает одну любую цифру из заданного в скобках интервала или последовательности цифр. Например: [0-9] означает одну любую цифру от 0 до 9. [1234] означает одну цифру от 1 до 4, [1236-9] означает одну любую цифру из следующих: 1,2,3,6,7,8,9.

• Число в фигурных скобках означает количество повторений предшествующего символа (цифры, буквы, символа или выражения). Например: .{4} означает четыре любых символа. [0-9]{2} означает два повторения выражения [0-9], т.е. [0-9] [0-9]

• символ «*» означает любое количество повторений предшествующего символа (включая цифры, буквы или выражения). Например: [0-9]* означает любое количество цифр от 0 до 9. .* означает любое количество любых знаков.

Примеры преобразования номеров

1. Операции добавления Задача 1: добавить префикс 78 к номеру 12345: dst_translate=12345/78& результат: 12345 → 7812345 Задача 2: добавить префикс 78312 к любому шестизначному номеру: dst_pattern=.{6} dst_translate=.{6}/78312& результат: 123456 → 78312 123456 результат: 654321 → 78312 654321 Задача 3: добавить префикс 78312 к номеру, начинающемуся с 777: dst_pattern=< .*> dst_translate=777.*/78312& результат: 777123456 → 78312777123456 результат: 777121212 → 78312777121212 Задача 4: добавить последовательность символов 77 в конец строки dst_translate= .*/&77 результат: 1234 → 123477

118

2. Операции удаления Задача 1: из любого номера с префиксом 095 удалять префикс dst_pattern=.* dst_translate=095|.*/\2

результат: 095123456# → 095 | 123456# → 123456#

Комментарий: выражение 095|.*/ в данном случае является шаблоном поиска, поэтому преобразованию подлежат только номера, начинающиеся с 095 + любое количество любых символов. Символ «|» делит шаблон поиска на две логические части. Строка замены состоит лишь из выражения «\2», что означает «взять вторую логическую часть из разделенного шаблона поиска». Задача 2: из любого номера с префиксом 8182 удалять префикс dst_pattern= .* dst_translate=8182|[0-9]*/\2 результат: 8182123456 → 8182 | 123456 → 123456 Задача 3: удалять символ # из середины строки dst_translate=[0-9]*|#|[0-9]*/\1\3 результат: 123#45 → 123 | # | 45 → 12345

Комментарий: в данном регулярном выражении шаблон поиска делится двумя символами «|» на три части: [0-9]* - любое количество цифр от 0 до 9. # - символ «решетка». [0-9]* - любое количество цифр от 0 до 9. Из синтаксиса строки замены данного регулярного выражения видно, что для создания нового номера берется только первая и третья логические части из трех выделенных в шаблоне поиска. 3. Операции замены Задача 1: заменять префикс 8182 в любых номерах с таким префиксом на 777 dst_pattern= .* dst_translate=8182|[0-9]*/777\2 результат: 8182123456 → 8182 | 123456 → 777 123456 Комментарий: как и в предыдущих случаях, шаблон поиска делится на две логические части символом «|» (8182 – первая логическая часть, [0-9]* - вторая логическая часть). В данном случае строка замены содержит дополнительную

119

подстроку (777), которая будет подставлена перед второй логической частью ([0-9]*), т.е. фактически вместо первой логической части (8182). Таким образом, мы осуществляем замену первой логической части шаблона дополнительной подстрокой. Задача 2 заменять префикс 1212 в любых номерах с таким префиксом на 1718 dst_pattern= .* bill_translate=1212|.*/1718\2 результат: 121212345 → 1212 | 12345 → 1718 | 12345 → 171812345 Задача 3: заменять символ # в середине строки на последовательность цифр 555 dst_translate=[0-9]*|#|[0-9]*/\1 555\3 результат: 123#45 → 123 | # | 45 → 123 | 555 | 45 →12355545

Примечание: обратите внимание на пробел между \1 и 555. Отсутствие пробела будет воспринято системой как выражение \1555 – «взять одна тысяча пятьсот пятьдесят пятую логическую часть из шаблона поиска» Задача 4: заменять символ # в конце строки на последовательность цифр 123 dst_bill_translate=[0-9]*|#/\1 123 результат: 123456# → 123456 | # → 123456123

Комментарий: Символ «|» делит шаблон поиска на две логические части, причем символ «решетка» находится во второй. Строка замены использует только первую логическую часть и добавляет к ней 123. Примечание: обратите внимание на пробел между \1 и 123. Отсутствие пробела будет воспринято системой как выражение \1123 – «взять одна тысяча сто двадцать третью логическую часть из строки поиска».

7.5 ИСПОЛЬЗОВАНИЕ МАКРОИМЕН В СХЕМАХ ТРАНСЛЯЦИИ НОМЕРОВ

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

$ani$ - подставить номер вызывающего абонента

$dnis$ - подставить номер вызываемого абонента

$user$ - подставить имя пользователя

$bill_ani$ - подставить номер вызывающего абонента для системы биллинга

$bill_dnis$ - подставить номер вызываемого абонента для системы биллинга.

120

$id$ – уникальный идентификатор вызова (извлеченный из CDR-записи) в формате <time stamp момента запуска MVTS>#<порядковый номер звонка>#

Пример: (Задача - поменять местами номер вызывающего и вызываемого абонентов) dst_translate=.*/$ani$ src_translate=.*/$dnis$ Макроимена $bill_ani$, $bill_dnis$ не могут использоваться в трансляции, предшествующей поиску объекта набора, т.е. в полях, начинающихся с префикса in_ , (например, in_dst_translate= , in_src_translate= ).

7.6 ДЕИНСТАЛЛЯЦИЯ MVTS В редких случаях, когда необходимо полностью удалить MVTS из системы выполните в системной консоли следующую последовательность команд:

#> rm -rf $H323PROXY_ROOT

#> vi /etc/profile #remove $H323PROXY_ROOT

#> runlevel

#> cd /etc/rc5.d

#> ls |grep mvts

#> rm -rf S50mvts

#> cd /etc/init.d

#> rm -rf mvts

7.7 ОПРЕДЕЛЕНИЯ Таблица 25 содержит термины, использующиеся в данном руководстве пользователя.

Таблица 26 Список терминов, используемых в документе

CDR-файл Файл, содержащий записи о параметрах звонков (время установления звонка, время окончания звонка и т.д.).

RAS-пользователь Абонент сети IP-телефонии (шлюз, терминал), регистрирующийся на привратнике по RAS-протоколу.

MVTS (MERA VoIP Transit Softswitch)

Дополнительное устройство, подключаемое к сети IP-телефонии, основной задачей которого является маршрутизация трафика IP-телефонии между шлюзами.

Кодек (codec) Алгоритм кодирования голоса.

Объект набора (dial peer) Адресуемая точка звонка. В цифровой телефонии

121

существуют два вида объектов набора (dial peers): объект обычной телефонной сети (POTS dial peer) и адресуемый объект голосовой связи по Интернет протоколу (VoIP dial peer)

Система начисления платы (billing system)

Система, ведущая статистику использования услуг MVTS клиентами и начисляющая по результатам этой статистики причитающуюся плату.

Отладочный протокол (debug log)

Текстовый файл, содержащий записи о событиях, состоянии MVTS, смене фаз сессий звонков с указанием времени.

Трассировочный файл/протокол (trace log)

Файлы, содержащие информацию в виде системных сообщений, которая используется для поиска и устранения неисправностей, а также для анализа причин сбоев в работе приложения.

Шлюз (gateway) Устройство, подключенное к IP-сети и к телефонной сети (PBX/PSTN) и выполняющее следующие функции:

- ответ на вызов вызывающего абонента PBX/PSTN

- установление соединения с удаленным шлюзом

- установление соединения с вызываемым абонентом PBX/PSTN

- сжатие, пакетирование и восстановление голоса (или факс-сигнала)

Привратник (gatekeeper) H.323 устройство в локальной сети, которое осуществляет трансляцию адресов и контролирует доступ в сеть Н.323 терминалов и шлюзов. Привратник может предоставлять Н.323 терминалам и шлюзам и другие виды сервиса, такие как управление пропускной способностью и обнаружение шлюзов. Привратник ведет реестр устройств в мультимедийной сети. При запуске устройства регистрируются на привратнике и запрашивают у привратника разрешение на звонок.

7.8 СОКРАЩЕНИЯ

Таблица 27 Список сокращений

ACD Средняя продолжительность вызовов, рассчитываемая как отношение общей продолжительности звонков, указанных в параметре call_radix= к их количеству (Average Call Duration)

Рассчитывается каждые три секунды

122

ANI Автоматическое определение номера (Automatiс Number Identification)

ANI-номер Номер вызывающего абонента

ASR Answer Seizure Ratio

Показатель успешных вызовов, рассчитываемый как отношение общего количества успешных вызовов к количеству вызовов, указанному в параметре call_radix=, умноженное на 100. Рассчитывается каждые три секунды.

CDR Call Detail Record (Запись о параметрах звонка)

CHAP Протокол обоюдной аутентификации, при работе с которым удаленный сервер посылает клиенту ключ для шифрования имени пользователя и пароля (Challenge Handshake Authentication Protocol).

CLI Интерфейс командной строки (Command Line Interface)

CSV Comma-Separated Values (Значения, разделенные запятыми)

DNIS Служба/функция определения набираемого номера (Dialed Numder Identification Service).

DNIS-номер Номер вызываемого абонента

FTP File Transfer Protocol (Протокол передачи файлов)

GID (Group Identifier) - Идентификатор группы (например, пользователей)

GUI Графический интерфейс пользователя (Graphics User Interface)

HASP Ключ защиты от несанкционированного копирования (Hardware Against Software Piracy)

HDD Накопитель на жестком диске (Hard Disk Drive)

ICN Внутренний номер звонка (Internal Call Number). Порядковый номер звонка, рассчитываемый с последнего запуска приложения MVTS.

LB Регулятор распределения нагрузки (Load Balancer)

LDC Локальный код разъединения (Local Disconnect Code)

MMVTS Медиа MVTS

MVTS MERA VoIP Transit Softswitch

NAT Трансляция сетевого адреса/Устройство трансляции сетевого адреса (Network Address Translation/Translator)

PBX телефонная система для частного пользования (Private Branch eXchange)

POTS Обычная телефонная сеть (Plain Old Telephone Service). В настоящем документе противопоставляется термину VoIP

123

124

PSTN Коммутируемая телефонная сеть общего пользования (Public Switched Telephone Network)

QoS Качество канала, рассчитываемое как отношение количества потерянных RTP-пакетов к общему количеству принятых RTP-пакетов, умноженное на 100 (Quality of Service). Так как информация о количестве потерянных и принятых пакетов получается из RTCP пакетов, поступающих ежеминутно, система вычисляет этот параметр для каждой минуты длящегося соединения и в качестве QoS канала выдает наибольший из полученных результатов (следует помнить, что чем меньше значение показателя, тем лучше QoS соединения).

RADIUS Cлужба идентификации удаленных пользователей (Remote Authentication Dial In User Service)

RAS Registration, Admission, and Status protocol. (протокол регистрации, допуска и состояния). Н.225 сигнальный протокол, по которому осуществляется управляющий обмен между конечными точками сети и привратником. RAS сигнальная функция предусматривает процедуры обмена между шлюзом и привратником по поводу регистрации, допуска, управления пропускной способностью, статуса и рассоединения.

RPM Диспетчер пакетов Red-Hat (Red-Hat Package Manager)

RTCP Real-time Transport Control Protocol – управляющий протокол реального времени (протокол управления передачей в реальном времени)

RTP Real-time Transport Protocol – Транспортный протокол реального времени

SBC Пограничный контроллер сессий (Session Border Controller)

SC Контроллер сессий (Session Controller)

SIP Протокол начала сессии (Session Initiation Protocol)

SMVTS Сигнальный MVTS

SNMP Simple Network Managament Protocol – простой протокол управления сетью

VSA Vendor-Specific Attribute – провайдер-зависимый (провайдер-специфический) признак (атрибут)

SCD SETUP-CONNECT delay – время задержки между получением пакетов SETUP и CONNECT

Среднее значение SCD рассчитывается каждые три секунды

125

ПРИЛОЖЕНИЕ A СИНТАКСИС РЕГУЛЯРНЫХ ВЫРАЖЕНИЙ В двойных кавычках далее будут употребляться значения, выдаваемые регулярными выражениями, а в одинарных - синтаксис регулярных выражений. Искомые выражения Выражением может быть один символ или последовательность символов, заключенных в круглые или квадратные скобки. Особенности использования скобок будут описаны ниже. Классы символов (Character class) Используя квадратные скобки, можно указать группу символов (это называют классом символов), для поиска. Например, конструкция '1[23]45' соответствует словам <1245> и <1345>, т.е.словам, начинающимся с <1>, за которым следуют <2> или <3>, и заканчивающимся на <45>.

Возможно и обратное, то есть, можно указать символы, которых не должно содержаться в найденной подстроке. Так, '[^1-6]' находит все символы, кроме цифр от 1 до 6.

Квантификаторы, они же умножители (Quantifiers) Если неизвестно, сколько именно знаков должна содержать искомая подстрока, можно использовать спецсимволы, именуемые мудреным словом квантификаторы (quantifiers). Например, можно написать "1234+5", что будет означать слово, начинающееся с "123", со следующими за ним одно или несколько "4", и заканчивающееся на "5". Следует понять, что квантификатор относится к предшествующему выражению, а не отдельному символу.

126

Таблица 28 Список квантификаторов

Символ Описание

* Соответствует 0 или более вхождений предшествующего выражения. Например, '12*' соответствует "1" и "122".

+ Соответствует 1 или более предшествующих выражений. Например, "12+" соответствует "12" and "122", но не "1".

? Соответствует 0 или 1 предшествующих выражений. Например, '12(34)?' соответствует "12" в "12" или "1234"

{n} n - неотрицательное целое. Соответствует точному количеству вхождений. Например, '1{2}' не найдет "1" в "121",но найдет два "1"' в "2113".

{n,} n - неотрицательное целое. Соответствует вхождению, повторенному не менее n раз. Например, '1{2,}' не находит "1" в "212", зато находит все "1" в "2111113". '2{1,}' эквивалентно '2+'. '2{0,}' эквивалентно '2*'.

{n,m} m и n - неотрицательные целые числа, где n <= m. Соответствует минимум n и максимум m вхождений. Например, '4{1,3} находит три первые "4" в "5444446". '4{0,1}' эквивалентно '4?'. Пробел между запятой и цифрами недопустим.

«Жадность»

Важной особенностью квантификаторов '*' и '+' является их всеядность. Они находят все, что смогут - вместо того, что нужно. То есть, $test = "hello out there, how are you"; $test =~ m/h.*o/ означает "искать 'h', за которым следует несколько произвольных символов, за которыми следует 'o'". В виду, наверное, имелось "hello", но найдено будет "hello out there, how are yo" - из-за жадности регулярного выражения, ищущего не первую, а последнюю "о". Излечить квантификатор от жадности можно, добавив '?'. То есть, $test = "hello out there, how are you"; $test =~ m/h.*?o/ найдет именно "hello", что и было нужно, поскольку ищет 'h', за которым следует несколько произвольных символов, до первого встреченного 'o'". Концы и начала строк

127

Проверка начала или конца строки производится с помощью метасимволов ^ и $. Например, "^thing" соответствует строке, начинающейся с "thing". "thing$" соответствует строке, заканчивающейся на "thing". Вариации и группировка Символ '|' можно использовать для перебора нескольких вариантов. Использование этого символа совместно со скобками - '(...|...|...)' - позволяет создать группы вариантов. Скобки используются для "захвата" подстрок для дальнейшего использования и сохранения их во встроенных переменных $1, $2, ..., $9.

Обратные ссылки

Мы уже говорили об одной из важнейших возможностей регулярных выражений – способность сохранения части соответствий для дальнейшего использования. Кстати, избежать этого можно с помощью использования '?:'. Например, $test = "Today is monday the 18th."; $test =~ m/([0-9]+)th/ сохранит "18" в $1, а $test = "Today is monday the 18th."; $test =~ m/[0-9]+th/ ничего не станет сохранять - из-за отсутствия скобок. $test = "Today is monday the 18th."; $test =~ m/(?:[0-9]+)th/ также ничего не станет сохранять благодаря использованию оператора '?:'. Следующий пример демонстрирует, как можно использовать эту возможность в операции замены: $test = "Today is monday the 18th."; $test =~ s/ the ([0-9]+)th/, and the day is $1/ приведет к записи "Today is monday, and the day is 18." в переменную $test. Можно ссылаться на подстроки, уже найденные данным запросом, используя \1, \2, ..., \9. Следующее регулярное выражение удалит повторяющиеся слова: $test = "the house is is big"; $test =~ s/\b(\S+)\b(\s+\1\b)+/$1/ записывает "the house is big" в $test.

128

ПРИЛОЖЕНИЕ B SNMP-СТАТИСТИКА

Сбор информации по SNMP ведется по следующим объектам: оригинаторы, объекты набора (dial peers), терминаторы, шлюзы, и маршруты. В MIB данные для каждого типа объектов хранятся в виде таблиц.

Идентификаторы таблиц:

Таблица идентификаторов

Описание

1.3.6.1.4.1.999.10.101.1 Данные для оригинаторов вызовов

1.3.6.1.4.1.999.10.103.1 Данные для обектов набора

1.3.6.1.4.1.999.10.105.1 Данные для терминирующих устройств

1.3.6.1.4.1.999.10.107.1 Данные для шлюзов

1.3.6.1.4.1.999.10.109.1 Данные для маршрутов

Идентификаторы объектов статических переменных MVTS 1.3.6.1.2.1.1.1.0 – описание системы (sysdescr) 1.3.6.1.2.1.1.2.0 – параметры MVTS (sysobjectid) 1.3.6.1.2.1.1.3.0 – продолжительность работы системы (sysuptime) 1.3.6.1.2.1.1.4.0 – контактная информация (syscontact) 1.3.6.1.2.1.1.5.0 – имя системы (sysname) 1.3.6.1.2.1.1.6.0 – местонахождение системы (syslocation) 1.3.6.1.2.1.1.7.0 – номер сервиса (sysservices) 1.3.6.1.2.1.1.8.0 – время последнего изменения в работе MVTS с начала запуска приложения 1.3.6.1.4.1.999.10.1.0 – количество активных звонков 1.3.6.1.4.1.999.10.2.0 – среднее количество активных звонков за последние 5 минут 1.3.6.1.4.1.999.10.3.0 – средняя скорость нарастания вызовов за последнюю минуту 1.3.6.1.4.1.999.10.4.0 – средняя скорость нарастания вызовов за последние 5 минут 1.3.6.1.4.1.999.10.5.0 – максимальное количество одновременных звонков 1.3.6.1.4.1.999.10.6.0 – продолжительность непрерывной работы системы 1.3.6.1.4.1.999.10.7.0 – продолжительность ведения статистики 1.3.6.1.4.1.999.10.8.0 – общая продолжительность звонков 1.3.6.1.4.1.999.10.9.0 – количество принятых вызовов 1.3.6.1.4.1.999.10.10.0 – количество успешных звонков 1.3.6.1.4.1.999.10.11.0 – количество неуспешных вызовов 1.3.6.1.4.1.999.10.12.0 – количество отклоненных вызовов

Статистика для оригинаторов, объектов набора, терминаторов и шлюзов Обозначения:

Y – индекс объекта статистики (>=1)

X = 101 для оригинаторов

129

X = 103 для объектов набора

X = 105 для терминаторов

X = 107 для шлюзов

Индексом во всех таблицах является целочисленный индекс объекта статистики (индекс>=1). За каждым объектом, по которому MVTS ведет статистику, закрепляется динамический индекс. Информация об объектах статистики и закрепленных за ними индексах сохраняется в файл snmp_index. При перезагрузке MVTS прочитывает этот файл и присваивает каждому создаваемому объекту статистики тот динамический индекс, который у него был до перезагрузки приложения. Индекс считается устаревшим и подлежащим удалению в случае отсутствия какой-либо активности объекта SNMP-статистики в течение 48 часов.

Идентификатор объекта (OID)

Тип значения Описание

1.3.6.1.4.1.999.10.X.1.1.Y Целочисленный Индекс объекта статистики

1.3.6.1.4.1.999.10.X.1.2.Y Строковый Имя объекта статистики

1.3.6.1.4.1.999.10.X.1.3.Y Строковый в формате “dd.MM.yy hh:mm:ss“

Общее время ведения статистики

1.3.6.1.4.1.999.10.X.1.4.Y Строковый в формате “dd.MM.yy hh:mm:ss“

Время последнего обновления статистики

1.3.6.1.4.1.999.10.X.1.5.Y Целочисленный ASR

1.3.6.1.4.1.999.10.X.1.6.Y Целочисленный Standard ASR

1.3.6.1.4.1.999.10.X.1.7.Y Строковый в формате “hh:mm:ss“

ACD

1.3.6.1.4.1.999.10.X.1.8.Y Целочисленный Average QOS

1.3.6.1.4.1.999.10.X.1.9.Y Целочисленный Максимальное количество одновременных звонков

1.3.6.1.4.1.999.10.X.1.10.Y Целочисленный Количество активных звонков

1.3.6.1.4.1.999.10.X.1.11.Y Строковый в формате “hh:mm “

Общая продолжительность звонков

1.3.6.1.4.1.999.10.X.1.12.Y Целочисленный Количество полученных звонков

1.3.6.1.4.1.999.10.X.1.13.Y Целочисленный Количество успешных звонков (Normal)

1.3.6.1.4.1.999.10.X.1.14.Y Целочисленный Количество успешных звонков (Normal) с нулевой

130

продолжительностью

1.3.6.1.4.1.999.10.X.1.15.Y Целочисленный Количество неудачных звонков (Failed)

1.3.6.1.4.1.999.10.X.1.16.Y Целочисленный Количество неудачных звонков (Failed) с нулевой продолжительностью

1.3.6.1.4.1.999.10.X.1.17.Y Целочисленный Количество полученных килобайт

1.3.6.1.4.1.999.10.X.1.18.Y Целочисленный Количество отправленных килобайт

Статистика по маршрутам Обозначения:

Y – индекс объекта статистики (>=1)

Идентификатор объекта (OID)


1.3.6.1.4.1.999.10.109.1.1.Y Целочисленный Индекс маршрута

1.3.6.1.4.1.999.10.109.1.2.Y Строковый в формате “src->dp->dst “

Имя маршрута

1.3.6.1.4.1.999.10.109.1.3.Y Строковый в формате “dd.MM.yy hh:mm:ss“

Общее время ведения статистики

1.3.6.1.4.1.999.10.109.1.4.Y Строковый в формате “dd.MM.yy hh:mm:ss“

Время последнего обновления статистики

1.3.6.1.4.1.999.10.109.1.5.Y Целочисленный ASR

1.3.6.1.4.1.999.10.109.1.6.Y Целочисленный Standard ASR

1.3.6.1.4.1.999.10.109.1.7.Y Строковый в формате “hh:mm:ss“

ACD

1.3.6.1.4.1.999.10.109.1.8.Y Целочисленный Average QOS

1.3.6.1.4.1.999.10.109.1.9.Y Целочисленный Максимальное количество одновременных звонков

1.3.6.1.4.1.999.10.109.1.10.Y Целочисленный Количество активных

131

вызовов

1.3.6.1.4.1.999.10.109.1.11.Y Строковый в формате “hh:mm “

Общая продолжительность вызовов

1.3.6.1.4.1.999.10.109.1.12.Y Целочисленный Количество принятых вызовов

1.3.6.1.4.1.999.10.109.1.13.Y Целочисленный Количество успешных звонков (Normal)

1.3.6.1.4.1.999.10.109.1.14.Y Целочисленный Количество успешных вызовов (Normal) с нулевой продолжительностью

1.3.6.1.4.1.999.10.109.1.15.Y Целочисленный Количество неудачных звонков (Failed)

1.3.6.1.4.1.999.10.109.1.16.Y Целочисленный Количество неудачных звонков (Failed) с нулевой продолжительностью

1.3.6.1.4.1.999.10.109.1.17.Y Целочисленный Количество полученных килобайт

1.3.6.1.4.1.999.10.109.1.18.Y Целочисленный Количество отправленных килобайт

1.3.6.1.4.1.999.10.109.1.19.Y Строковый Статус маршрута. Возможные значения: "NotAccessible" (недоступен)

"PartlyAccessible" (доступен частично)

"FullyAccessible" (доступен полностью)

1.3.6.1.4.1.999.10.109.1.20.Y Целочисленный Количество успешных звонков через данный маршрут

Статистика по кодам завершения звонков

Обозначения:

Y – индекс объекта статистики (>=1).

132

Z – индекс конкретной пары кодов завершения. Вычисляется по формуле 100+LDC*127+Q931, где LDC – локальный код разъединения MVTS, Q931 – код разъединения q931.

X = 101 для статистики кодов завершения звонков по оригинаторам,

X = 103 для статистики кодов завершения звонков по объектам набора,

X = 105 для для статистики кодов завершения звонков по терминаторам,

X = 107 для статистики кодов завершения звонков по шлюзам,

X = 109 для статистики кодов завершения звонков по маршрутам.

Идентификатор объекта

(OID)


1.3.6.1.4.1.999.10.X.1.Z.Y Строковый Строка в формате «LDC,Q931,count», где LDC – локальный код разъединения, Q931 – код разъединения по стандарту Q931, count – количество звонков, завершившихся с данной парой кодов разъединения.

133

ПРИЛОЖЕНИЕ С ЛОКАЛЬНЫЕ КОДЫ РАЗЪЕДИНЕНИЯ MVTS

Таблица 29 Таблица локальных кодов разъединения, генерируемых MVTS

Код Название Описание 1 eCallerNormal Звонок завершился нормально с

отправкой ReleaseComplete от оригинирующей стороны

2 eCallerNormal Звонок завершился нормально с отправкой ReleaseComplete от терминирующей стороны

3 eCallerDropTCP Звонок завершился без получения ReleaseComplete в результате обрыва TCP-соединения ОРИГИНИРУЮЩЕЙ стороной

4 eCallerDropTCP Звонок завершился без получения ReleaseComplete в результате обрыва TCP-соединения ТЕРМИНИРУЮЩЕЙ стороной

10 eRemoteGkDRQ звонок завершился при получении disangageRequest от удаленного привратника

100 eForceTerminateCall Звонок был завершен в принудительном порядке (останов MVTS, команда terminate call)

101 eTimeoutTCPConnectH225 Не установлено H225 соединение с терминирующей стороной в течение 3 секунд

102 eTimeoutConnectMsg Не получено сообщение Connect Message в течение 120 секунд

103 eTimeoutRBT Не получен Alerting Message в течение 30 секунд

104 eInvalidH225SizeCaller Получен H.225-пакет неверной длины от оригинатора звонка

105 eInvalidH225SizeCalled Получен H.225-пакет неверной длины от терминатора звонка

106 eInvalidH225MsgCaller Получен некорректный H.225-пакет от оригинатора звонка

107 eInvalidH225MsgCalled Получен некорректный H.225-пакет

134

Код Название Описание от терминатора звонка

108 eInvalidH225ReadCaller MVTS не смог прочитать полученный от оригинатора звонка H.225-пакет

109 eInvalidH225ReadCalled MVTS не смог прочитать полученный от терминатора звонка H.225-пакет

110 eDestinationUnreachable Не найден соответствующий объект набора (dial peer) или ни один из требуемых шлюзов не был доступен

112 eFailedTCPConnectH225 Сбой при установлении H225 сессии с терминирующей стороной

113 eInvalidCalledIpAddress Некорректный адрес терминатора звонка (согласно плану маршрутизации)

114 eFailedDecodeUUCaller MVTS не смог декодировать поле UserUserField в пакете, полученном от оригинатора звонка

115 eInvalidTPKTCaller Ошибка в заголовке пакета, полученного от терминатора звонка. Встречается в случае некорректной работы шлюза

116 eFailedDecodeUUCalled MVTS не смог декодировать поле UserUserField в пакете, полученном от терминатора звонка

118 eDuplicateCallId Был получен звонок с Call ID, уже используемом в одном из активных соединений (защита от зацикливания звонков)

119 eInvalidTPKTCalled Ошибка в заголовке пакета, полученного от оригинатора звонка. Встречается в случае некорректной работы шлюза

120 eTimeoutRouteAttempt Не было установлено соединение с терминирующим шлюзом в течении 10 секунд после начала маршрутизации на этот шлюз.

121 eTimeoutSetupMsg Не получен Setup Message в течении 15 секунд.

122 eTimeoutRTPidle В режиме полного проксирования отсутствие голосового трафика в течение 180 секунд. В этом случае звонок считается зависшим и

135

Код Название Описание завершается.

123 eFailedTCPConnectH245Caller

Сбой при установлении H245 сессии на оригинатора вызова

124 eInvalidSetupMsg Неверный Setup Message (в пакете отсутствуют UserUserField или первым пришел не Setup Message)

125 eMaxRerouteRetries Предпринято более 10 попыток перемаршрутизации (защита от зацикливания при процедуре look ahead routing)

126 eMaxCapacityExceed Превышено максимально допустимое значение параметра capacity для оригинатора звонка

127 eRouteBlocked Маршрут «оригинатор-объект набора-терминатор» заблокирован интеллектуальной маршрутизацией

128 eFailedTCPConnectH245Called Сбой при установлении H245 сессии на терминирующую вызов сторону

129 eNotAllowedPrefix Попытка совершения вызова на номер с запрещенным префиксом

130 eDuplicateCalledPartyNumber Превышено максимально разрешенное число вызовов с одинаковым номером вызываемого абонента

131 eNoPacketTimeOut Звонок завершен по причине отсутствия пакетов в течение заданного периода времени

132 eConsoleTerminatedCall Звонок завершен в принудительном порядке командой terminate call

133 eDialpeerCapacityExceeded Превышено максимально допустимое значение параметра сapacity= для объекта набора

134 eGatewayUnaccessible Недоступность терминирующего шлюза

135 eGatewayIncompatible Несовместимость оригинирующего и терминирующего шлюзов по полю c o mpa t i b i l i t y

136 eDestinationGatewayCapacityExceeded Превышено максимально допустимое количество звонков для данного терминирующего шлюза, заданноe в

136

Код Название Описание поле c a p a c i t y

137 eGatewayNullReached Маршрутизация вызова завершена с причиной Q931 в результате обнаружения объекта набора с параметром g a t e w a y =NULL

138 eHuntStopped Поиск по объектам набора остановлен при значении параметра hunt_stop=1

139 eNoAppropriateDialpeer

Не найден подходящий диалпир при поиске маршрута для терминации

141 eMaxCallRateExceeded Превышена максимальная скорость нарастания вызовов, указанная в поле max_callrate= (meraproxy.cfg [H.323])

200 eRadiusAdmissionCallerReject RADIUS-сервером отклонена авторизация оригинатора звонка

201 eGkClientAdmissionTimeout На запрос Admission Request от удаленного привратника (gatekeeper) не получен ответ в течении 10 секунд

202 eSourceGatewayUnknown Получен звонок с неизвестным адресом оригинатора (при прохождении звонка через конвертер SIP-HIT)

203 eGkClientAdmissionReject запрос Admission Request отклонен удаленным привратником (gatekeeper)

205 eSourceGatewayAniReject Originator’s s r c _ n umb e r does not match the number, specified in the a n i _a l l ow field of the gateway or RAS-user record

206 eRadiusAdmissionTimeout Отсутствие ответа от RADIUS-сервера в течение 10 секунд

207 eRadiusAdmissionCallerReject Radius-сервером отклонена авторизация терминатора звонка

208 eRadiusAdmissionRouteReject Radius-сервер отказал во внешней маршрутизации

209 eRouteProhibited Звонок с/на запрещенный адрес

210 eIncomingBandwidthOverload Превышена входящая ширина полосы пропускания IP-адреса при использовании параметра local_ip_manager=

137

Код Название Описание 211 eOutcomingBandwidthOverload Превышена исходящая ширина

полосы пропускания IP-адреса при использовании параметра local_ip_manager=

212 eOutgoingDestNumberEmpty Предпринята попытка отправить Setup с пустым полем CalledStationId

213 ePacketOfDisconnect Звонок завершен в принудительном порядке при получении от RADIUS-сервера пакета PacketOfDisconnect

300 eMaxSessionTime Превышен лимит продолжительности звонка (определенный Radius-сервером в поле CISCO_H323_CREDIT_TIME)

301 eDanglingCall Превышена максимальная длительность звонка (10000 секунд, т.е. 2 часа 46 минут 40 секунд), и предполагается, что это «зависший» звонок.

302 eSystemOverflow Превышено количество одновременных звонков, указанных в лицензионном соглашении

303 eSourceGatewayExpired Истекла дата, заданная в e x p i r e _ d a t e у шлюза-оригинатора звонка

304 eDestinationGatewayExpired Истекла дата e x p i r e _ d a t e у терминатора звонка

305 eIncomingTrafficExceeded Превышен лимит, определенный в ma x _ i n c o mi n g _ t i me

306 eOutgoingTrafficExceeded Превышен лимит времени, заданный в ma x _ o u t g o i n g _ t i me

400 eNoMediaServer Отсутствие Media MVTS серверов для терминации звонка с сигнального MVTS

401 eFailedTCPConnectMediaServer Ошибка в установлении TCP-соединения с Media MVTS

Локальные коды разъединения, создаваемые кластерной версией MVTS отличаются от кодов разъединения односерверного варианта MVTS. Отличие заключается в следующем: в момент завершения вызова MediaMVTS генерирует обычный LDC для отправки сигнальному MVTS и прибавляет к нему 1000. Например, при удачном завершении вызова с отправкой сообщения ReleaseComplete от терминирующей

138

стороны (то есть с LDC=2), MediaMVTS отправит сигнальному MVTS код разъединения 1002.

139

ПРИЛОЖЕНИЕ D СОВМЕСТИМОСТЬ ОБОРУДОВАНИЯ

VOIP- ШЛЮЗЫ И ПРИВРАТНИКИ Контроллер соединений MERA VoIP Transit Softswitch успешно прошел тестирование со многими решениями ведущих разработчиков H.323-оборудования, среди которых:

• CISCO (IOS-based, ATA 186) • VocalTec (VGW 1.4f+, VGK 1.3+) • Samsung (SMG 400, SMG 3200) • Nortel Networks (BCM v. 4.0, Succession) • Clarent (Clarent GK) • D-Link (DG-10xSH DG-104SH, DVG-1120, DVG-1402S, DVG-1024, DVG-

1104TH, DVG-2004S, DVG-4022, DVG-5030S) • BosCom (Bosanova) • Well-Tech (SmartNode 1200, 1400, 2300, 2400) • AudioCodes (Mediant-2000, MP-104) • Quintum (Tenor Digital MaltiPath Switch) • Network Systems Group (NSGate) • Sysmaster (SM7000 VoIP Gateway) • Broadsoft (BroadWorks platform) • IP and Softphones (Microsoft NetMeeting, VocalTec Phone Lite)

СИСТЕМЫ УЧЕТА И НАЧИСЛЕНИЯ ОПЛАТЫ Поддержка MVTS протокола RADIUS позволяет провайдерам самостоятельно выбирать биллинговую систему исходя из множества представленных на рынке решений. Ниже приводится список биллинговых решений, чаще всего используемых нашими клиентами:

• PortaBilling • EyeBill VoIP Billing • IPSoft Billing • T-Soft Billing • CBOSS Billing • MIND CTI • Advanced VoIP Billing System • ISA Billing • Switch Management Billing • Cyneric Billing

MERA VoIP Transit Softswitch v 3.1 -...

Documents

Transcript of MERA VoIP Transit Softswitch v 3.1 -...