Iptel длчайников.docx

Оглавление1. Если вы получили дистрибутив на флешке.............................................................................3

1.1. Подбираем компьютер...............................................................................................................3

1.2. Переносим ПО на жёсткий диск..............................................................................................4

1.3. Определяем политику назначения имён сетевых интерфейсов.................................4

1.4. Корректируем сетевые настройки..........................................................................................5

1.5. Включаем синхронизацию по NTP.........................................................................................6

1.6. Подстраиваемся под телефонную сигнализацию............................................................7

1.7. Откуда брать данные..................................................................................................................7

1.8. Поднимаем виртуальную машину..........................................................................................7

1.9. Подключаем Phobos Server....................................................................................................10

1.10 Если сильно напортачили в системе..............................................................................11

1.11 Как без остатков удалить содержимое диска...............................................................11

2. Глубокий экскурс для тех, кто хочет выжать больше...........................................................11

2.1. Общие сведения.........................................................................................................................11

Рис. 1. Взаимодействие основных элементов Phobos Iptel.....................................................................12

2.2. SPAN-сессия.................................................................................................................................12

2.3. Сетевые карты............................................................................................................................12

2.4. Iptel Core........................................................................................................................................12

2.5. Сниффер.......................................................................................................................................13

2.6. Область временного хранения данных из сети MFS.....................................................15

2.7. Логи.................................................................................................................................................15

2.8. Декодеры протоколов..............................................................................................................16

2.9. Менеджер атрибутов.................................................................................................................20

2.10. Подстановщик строк в атрибуты......................................................................................21

2.11. Модуль связи с Phobos........................................................................................................21

2.12. Модуль связи с USB-Key.....................................................................................................22

2.13. Модуль очистки области MFS............................................................................................22

3. Что делать, если большие проблемы с «зеркалированием» трафика............................22

3.1. Проксирование SIP-телефонов.............................................................................................23

3.1.1. Параметры файла конфигурации прокси-сервера.....................................................23

3.1.2. Управление работой siproxd..............................................................................................24

3.1.3. Включаем кластеризацию...................................................................................................24

3.2. Проксирование телефонов с сигнализацией SCCP/SKINNY фирмы Cisco............26

3.2.1. Конфигурируем skinny_proxy.............................................................................................26

3.2.2. Управление работой skinny_proxy...................................................................................27

3.2.3. Включаем резервирование.................................................................................................28

3.3. Проксирование телефонов с сигнализацией UNISTIM..................................................28

3.3.1. Конфигурируем unistim_proxy...........................................................................................28

3.3.2. Вопросы запуска unistim_proxy........................................................................................30

3.3.3. Повышаем отказоустойчивость........................................................................................30

3.3.3.1. Резервирование через IP-АТС или Node....................................................................30

3.3.3.2. Резервирование через запасной прокси....................................................................31

3.4. Проксирование телефонов с сигнализацией HFA/CornetIP фирмы Siemens........31

3.4.1. Конфигурируем cornet_proxy.............................................................................................31

3.4.2. По поводу запуска cornet_proxy........................................................................................32

3.4.3. Вопрос резервирования......................................................................................................32

3.5. Начинаем записывать звонки через прокси-сервер......................................................32

4. Поддержка систем сетевого управления................................................................................33

ТерминологияОбъясним некоторые термины, которые в данной книге часто используются, но не имеют единого и

широкого представления. Среди них есть и такие, которые можно отнести к профессиональному жаргону.«IP-ATC» - специализированный компьютер, взаимодействующий с VoIP-устройствами: IP-

телефонами или другой IP-АТС в части обработки сигнализации.«Сигнальный сервер» - IP-АТС, которая управляет IP-телефонами. Понятие несколько сужено по

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

«Станция записи» — компьютер с установленными программными модулями Phobos Server. На нём хранится база данных о записанных вызовах и звуковые данные.

«Съёмник» — компьютер с установленными программными модулями Phobos Iptel.«Прослушивание» - основной способ записи разговоров. Копия сетевого трафика поступает на

отдельный (отдельные) Ethernet-порт съёмника. Съёмник в этом случае не влияет на работу VoIP-устройств.«Проксирование» - дополнительный способ записи разговоров, при котором весь трафик VoIP-

телефонов проходит через съёмник. Съёмник влияет на работу VoIP-устройств.

1. Если вы получили дистрибутив на флешке

1.1. Подбираем компьютер

Если Вы заказали поставку предустановленного ПО «Phobos Iptel», большая часть данного подраздела для Вас не особо актуальна.

Процессор может быть практически любой из современных, обязательно с поддержкой 64-раздядной адресации. Если есть желание поставить на съёмнике виртуальную машину плюс станцию записи, очевидным требованием будет поддержка технологии виртуализации Intel VT-х. Не забудем проверить, чтобы в BIOS компьютера не стоял запрет на использование Intel VT-x. Виртуализация от AMD пока не поддерживается. Если число одновременно записываемых звонков больше 60, то виртуальной машиной лучше и не пользоваться, надо ставить Phobos Server на отдельный компьютер.

Памяти хотя бы 1 Гбайт будет вполне достаточно в большинстве случаев, если Вы не собираетесь ставить виртуальную машину для установки Phobos Server. Для виртуальной машины также надо предусмотреть хотя бы 1 Гбайт ОЗУ.

Решите, в каком режиме вы будете подключать съёмник: прослушивания или проксирования. Если в режиме прослушивания, то на компьютере должно быть, минимум два интерфейса Ethernet: один для взаимодействия по сети, другой для подключения к порту с «зеркальной» копией трафика VoIP-устройств.

Один USB-порт необходим для подключения ключа защиты от копирования USB-ключа. Без ключа запись работать может. Но не более 1 разговора одновременно и только 1 час. После чего надо вставить

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

Жёсткий диск настоятельно рекомендуется, так как у него производительность и износоустойчивость повыше, чем у флешки. Желающие могут отказаться от отдельного жёсткого диска при желании ограничится не покупкой, а тест-драйвом. Но тогда +1 USB-порт.

1.2. Переносим ПО на жёсткий диск

Скачиваем дистрибутивный ISO-образ с сайта. Образ можно накатить как на DVD-ROM, так и на USB-флешку. Ставим полученный дистрибутивный носитель в DVD-привод или порт USB будущего съёмника. Заходим в его BIOS. Активируем загрузку с дистрибутивного носителя. Сохраняем BIOS. Перезагружаем. Появляется на экране приветствие загрузчика:

ISOLINUX 4.04 2011-04-18 EHDD Copyright © 1994-2011 H. Peter Anvin et alGentoo Linux Installation LiveCDEnter to boot: F1 for kernels F2 for options.Press any key in next 15 seconds or we’ll try to boot from disk.boot:В идеале просто жмём Enter – идет загрузка до появления подсказки:livecd ~ #Загрузили. Посмотрим, что разглядела дистрибутивная система в качестве своей корневой файловой

системы:livecd ~ # mount | grep iso9660/dev/sdb on /mnt/cdrom/ type iso9660/dev/sdb on /mnt/cdrom/ type iso9660

Если мы загрузились с флешки и видим в строке вывода /dev/sdb, это значит, что система увидела наше USB-устройство как второе виртуальное SCSI-устройство. Или вот как будет выглядеть вывод, если мы загрузились с SATA DVD-диска:livecd ~ # mount | grep iso9660/dev/sr0 on /mnt/cdrom/ type iso9660/dev/sr0 on /mnt/cdrom/ type iso9660

Откуда бы мы ни загрузились, скорее всего первым виртуальным SCSI-устройством /dev/sda будет жёсткий диск, на который мы будем устанавливать. Давайте проверим:login: cat /proc/partitionsmajor minor #blocks name 8 0 244198584 sda

Ага, в данном случае есть жёсткий диск, на котором написано, что он на 250 Гбайт. Число блоков по 1024 байта – то, что стоит в столбике “blocks”. Что-то ещё должен будет вывести, про флешку рассказать, но в примере рассказчик оставил лишь то, что нас интересует.

Что ж, пора приступить к установке. ВСЕ ИМЕЮЩИЕСЯ ДАННЫЕ НА ЖЕСТКОМ ДИСКЕ БУДУТ УНИЧТОЖЕНЫ. Записываем систему на диск#/mnt/cdrom/iptel_paste /dev/sda

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

Установка систему на SATA-диск займёт не более 3 минут и будет сопровождаться выдачей некоторого текста. В конце может быть выдано сообщение об ошибке, но это допустимо:

umount: /mnt/cdrom/opt: target is busy (In some cases useful info about processes thatuse the device is found by lsof(8) or fuser(1).)

По окончании останавливаем систему:#halt

Система установлена. Изымаем дистрибутивные носители из привода (порта USB).

1.3. Определяем политику назначения имён сетевых интерфейсов

Загрузим вновь установленную систему. Во время загрузки ядра ОС загружаются драйверы сетевых контроллеров. Загружаются они в произвольном порядке, причём при загрузке драйвера очередного установленного сетевого контроллера все сетевые интерфейсы получают имена по возрастанию номера: eth0, eth1, … Во избежание путаницы интерфейсов менеджер устройств udev переименовывает все интерфейсы, давая им малосодержательные названия. Тем не менее, при последующих загрузках имена интерфейсов будут гарантированно повторяться, чего невозможно было бы, если бы мы хотели, чтобы имена начинались на “eth”. Наблюдать следы этой переименования можно примерно так:#dmesg | grep udev[ 4.290268] e1000e 0000:00:19.0 enp 1 s 0 : renamed from eth0[ 4.307264] systemd-udevd[413]: renamed network interface eth0 to enp1s0[ 4.331232] e1000e 0000:01:00.0 enp0s25: renamed from eth1[ 4.343265] systemd-udevd[412]: renamed network interface eth1 to enp0s25

Подчёркнутые имена enp1s0 и enp0s25 – как раз такие бессмысленные имена. Переход на малосодержательное именование интерфейсов разработчиками udev – плод компромисса между несколькими противоречивыми требованиями по функциональности, надёжности, предсказуемости поведения системы и формат книги не позволяет нам углубиться в его обсуждение. Важно лишь то, что компромисс предусматривает отказ от возможности, чтобы имена интерфейсов Ethernet начинались с «eth». У нас они будут называться, начинаясь на “lan”. Так что, нам предстоит освоить механизм переименования сетевых устройств.

Итак, для начала определим физическое расположение интерфейсов #ethtool –p enp1s0

Светодиод сетевого интерфейса enp1s0 начинает мигать, выдавая себя. Запомним его. Нажмём по окончании Ctrl-C. Теперь определим его MAC-адрес:# ifconfig enp1s0enp1s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500

ether 00:1c:c0:a3:37:10 txqueuelen 1000 (Ethernet)device interrupt 20 memory 0xe4100000-e4120000

Запишем имя интерфейса и MAC-адрес. Аналогично находим следующий интерфейс:#ethtool –p enp0s25

И его MAC-адрес:# ifconfig enp0s25enp0s25: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500

ether 00:1c:c0:a3:62:13 txqueuelen 1000 (Ethernet)device interrupt 20 memory 0xe4100000-e4120000

Теперь отредактируем файл /etc/udev/rules.d/70-persistent-net.rules, который определит переименование сетевых интерфейсов, например:

SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:1c:c0:a3:37:10 ", KERNEL=="eth*", NAME="lan1"SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:1c:c0:a3:62:13", KERNEL=="eth*", NAME="lan0"Обратите внимание на поля “ATTR{address}” и “NAME” – смысл их очевиден. Отредактировали,

сохранили. После перезагрузки в системе появятся интерфейсы lan0 и lan1. Подразумевается, что работа с сетью будет вестись через интерфейс lan0, а ввод данных с «зеркального» порта коммутатора – через интерфейс lan1. Если расклад имён интерфейсов выглядит несоответствующим каким-либо соображениям (расположение, скорость и др.), можно подправить файл /etc/udev/rules.d/70-persistent-net.rules и снова перезагрузить систему.

1.4. Корректируем сетевые настройки

Теперь надо обеспечить назначение сетевому интерфейсу lan0 нужного IP-адреса и маски. Отредактируем файл /etc/conf.d/net. Из встроенных средств пользователям, не владеющим криптографическим интерфейсом vim, трудно предложить что-нибудь лучше, чем Midnight Commender. Действительно, очень он похож на свой прообраз Norton Commander:#mc

Лазить по каталогам можно, работая клавишами-стрелками. Бегунок нам подсказывает наш текущий выбор. Выбрали каталог, «Enter» - зашли в него. Так же легко вышли, выбрав элемент «..».

Клавиша «F4» - редактируем файл встроенным редактором.

В редакторе «F2» - сохранить;«Esc» - выйти без сохранения;Clrl-O – спрятать/показать панели.Итак, ищем файл /etc/conf.d/net. Открываем для редактирования. Внутри видим что-то вроде:modules="!iproute2"#config_lan0="192.168.3.139/22"#routes_lan0="default via 192.168.0.1"Надо убрать символ комментария “#” в началах строк, поправить содержимое в кавычках.Параметр config_lan0 означает IP-адрес и через косую черту длину сетевой маски. Например, длина

сетевой маски 22 соответствует маске 255.255.252.0. Параметр routes_lan0 описывает маршрут «по умолчанию». Не следует ставить лишние пробелы между кавычками и буквами (цифрами) строки. Например, можно указать:

config_lan0="192.168.3.139/22 192.168.3.140/22 192.168.3.141/22"Интерфейс lan0 получит адрес 192.168.1.139, lan0:1 получит 192.168.1.140, lan0:2 получит

192.168.1.141. Маска сети будет 255.255.248.0.Рассмотренного примера достаточно для настройки в подавляющем большинстве случаев. При

желании более подробно о сетевых настройках можно прочитать, выдав команду:#bzcat /usr/share/doc/netifrc-0.2.2/net.example.bz2 | less

1.5. Включаем синхронизацию по NTP

Точность времени на съёмнике обычно не очень важна. Лишь в редких случаях, например, если мы хотим построить кластер из SIP-прокси (см. п. 3.1.3), точность времени, точнее синхронность хода времени на съёмниках приобретает высокую значимость. Впрочем, настройка NTP-службы у сисадминов считается признаком хорошего тона и выполнить её можно так.

Открываем на редактирование файл /etc/ntp.conf по <F4>:Строки-комментарии начинаются с символа «#», адреса серверов времени указываются в

параметрах server. Сформировать один или несколько параметров server с указанием IP-адреса (адресов) используемых на объекте серверов времени. Эти адреса следует уточнить в службе эксплуатации сети. Сохранить изменения в файле клавишей <F2>, выйти из редактора клавишей <F10>;

Найти файл /etc/conf.d/ntp-client. Открыть его для редактирования клавишей «F4». В нём будет указан параметр, который предстоит скорректировать:

NTPCLIENT_OPTS="-s -b -u \0.gentoo.pool.ntp.org 1.gentoo.pool.ntp.org \2.gentoo.pool.ntp.org 3.gentoo.pool.ntp.org"Внесём список адресов NTP-серверов, по которым будет выставляться приблизительной значение

системного времени после загрузки, например:NTPCLIENT_OPTS="-s -b -u 10.77.32.254 10.77.33.254"Замечание о часовом поясе: временная зона обычно Москва. Можно поменять временную зону на

желаемую, подобрав одну из числа имеющихся в каталоге /usr/share/zoneinfo и его подкаталогах. Справится о текущем времени:# dateMon May 28 13:40:52 MSK 2015# date –s 13:44Mon May 28 13:44:00 MSK 2015

Сохраним время в энергонезависимых часах компьютера:#hwclock -w

Запустим демоны ntp-client и ntpd:/etc/init.d/ntp-client start* Starting ntp-client … [ ok ]/etc/init.d/ntpd start* Starting ntpd … [ ok ]

Выждем несколько минут. Дадим команду «ntpq -p», в результате которой должно быть выдано примерно следующее:# ntpq -premote refid st t when poll reach delay offset jitter

==============================================================================192.168.0.1 77.233.172.7 3 u 16 64 3 0.170 -233210 13.615

В поле «reach» должно указываться положительное число не более 377. Это будет означать, что система ведёт постепенную синхронизацию времени с сервером.

Задать обязательность запуска служб ntpd и ntp-client во при загрузке системы:#rc-update add ntp-client default#rc-update add ntpd default

ntp-client выполняет грубую синхронизацию, ntpd поддерживает относительно точную.

1.6. Подстраиваемся под телефонную сигнализацию

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

Посмотрим возможные варианты сигнализаций:#cd /usr/local/opt/iptel/etc#ls -l iptel.conf*# lrwxrwxrwx 1 root root 18 Apr 13 23:06 iptel.conf -> iptel.conf.unistim-rw-r--r-- 1 root root 1335 Apr 13 22:01 iptel.conf.alcatel-rw-r--r-- 1 root root 1463 Apr 13 22:01 iptel.conf.h323-rw-r--r-- 1 root root 1333 Apr 6 17:13 iptel.conf.iax-rw-r--r-- 1 root root 1318 Apr 6 17:13 iptel.conf.lync-rw-r--r-- 1 root root 1200 Apr 6 17:13 iptel.conf.mgcp-rw-r--r-- 1 root root 2613 Apr 13 18:28 iptel.conf.sigtran-rw-r--r-- 1 root root 1428 Apr 13 21:59 iptel.conf.sip-rw-r--r-- 1 root root 1473 Apr 13 20:16 iptel.conf.skinny-rw-r--r-- 1 root root 1491 Apr 13 22:01 iptel.conf.smpp-rw-r--r-- 1 root root 1309 Apr 13 22:01 iptel.conf.unistim

В данном случае основной файл конфигурации модулей съёмника iptel.conf указывает на iptel.conf.unistim – предопределённый набор настроек для записи звонков с телефонов фирмы Nortel, взаимодействующих с АТС по протоколу Unistim. Пусть нам нужно записывать звонки SIP-телефонов. Поправим ссылку на файл конфигурации:#ln –sf iptel.conf.sip iptel.conf

Или пусть нам нужно записывать звонки абонентских аппаратов АТС «Avaya», которая работает по протоколу DCP поверх H.323:#ln –sf iptel.conf.h323 iptel.conf#rc-update add h323_dec default

Теперь съёмник готов работать в режиме прослушивания.

1.7. Откуда брать данные

Ответ: с «зеркального» порта коммутатора. Зеркалирование трафика - функция для сетевых коммутаторов нестандартная. В широко распространённых коммутаторах фирмы Cisco эта функция называется SPAN – Switched Port Analysis. Требуется сделать так, чтобы на порт lan1 съёмника был подан и сигнальный, и голосовой трафик. Надо учитывать, что пути следования сигнального и голосового трафиков могут не совпадать. Если телефоны включены в коммутаторы доступа, уместнее делать RSPAN – Remote SPAN. Если построить SPAN-сессию невозможно, следует рассмотреть вариант с проксированием – см. раздел .

1.8. Поднимаем виртуальную машину

Нет, мы не обязаны этого делать. Но вправе. Если хотим сэкономить на «железе», а потребности в записи у нас не велики, не более 60 каналов одновременно – можно попробовать. А можем и не попробовать, а пропустить, перейдя к подразделу .

Ладно, решили попробовать. Система занимает на жёстком диске 8 ГБ. Остальное пространство пусто. Создадим пустой второй раздел на жёстком диске:

#fdisk /dev/sda

Welcome to fdisk (util-linux 2.25.2).Changes will remain in memory only, until you decide to write them.Be careful before using the write command.

Command (m for help): pDisk /dev/sda: 465.8 GiB, 500107862016 bytes, 976773168 sectorsUnits: sectors of 1 * 512 = 512 bytesSector size (logical/physical): 512 bytes / 512 bytesI/O size (minimum/optimal): 512 bytes / 512 bytesDisklabel type: dosDisk identifier: 0xfd6856a0

Device Boot Start End Sectors Size Id Type/dev/sda1 * 2048 16779263 16777216 8G 83 Linux

Command (m for help): nPartition type p primary (1 primary, 0 extended, 3 free) e extended (container for logical partitions)Select (default p): pPartition number (2-4, default 2):First sector (16779264-976773167, default 16779264):Last sector, +sectors or +size{K,M,G,T,P} (16779264-976773167, default 976773167):

Created a new partition 2 of type 'Linux' and of size 457.8 GiB.

Command (m for help): tPartition number (1,2, default 2): 2Hex code (type L to list all codes): 7

Changed type of partition 'Linux' to 'HPFS/NTFS/exFAT'.

Command (m for help):wqThe partition table has been altered.Calling ioctl() to re-read partition table.Re-reading the partition table failed.: Device or resource busy

The kernel still uses the old table. The new table will be used at the next reboot or after you run partprobe(8) or kpartx(8).

Утилита fdisk предлагает нам перезагрузить систему, чтобы внесённые изменения вступили в силу. Ладно, перезагружаем.

# reboot

По окончании загрузки раздел /dev/sda2 будет создан. Можем хоть поверить, хоть проверить:# fdisk /dev/sda

Welcome to fdisk (util-linux 2.25.2).Changes will remain in memory only, until you decide to write them.Be careful before using the write command.

Command (m for help): pDisk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectorsUnits: sectors of 1 * 512 = 512 bytesSector size (logical/physical): 512 bytes / 512 bytesI/O size (minimum/optimal): 512 bytes / 512 bytesDisklabel type: dosDisk identifier: 0xa545a8ea

Device Boot Start End Sectors Size Id Type/dev/sda1 * 2048 16779263 16777216 8G 83 Linux/dev/sda2 16779264 1953525167 1936745904 923.5G 7 HPFS/NTFS/exFAT

Command (m for help): q

#

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

Основным скриптом для запуска монитора виртуальных машин (MBM) является файл /root/qemu_run. Откроем его. Вот пример реально работающего скрипта:

#!/bin/bashqemu-system-x86_64 -boot cd -smp 2 -soundhw sb16 -m 2048 -vnc 127.0.0.1:0 \ -net nic,macaddr=a0:1a:64:49:ab:e1,model=rtl8139 \ -net tap,script=/etc/qemu-ifup,ifname=tap0 \ -enable-kvm \ -hda /dev/sda2 \ -monitor telnet:127.0.0.1:4444,server,nowait \ -cdrom /dev/sr0Разберём скрипт по косточкам. Сведём все в Таблицу 1. В конце многих строк видим обратный

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

Таблица 1. Параметры виртуальной машины

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

-boot cd Попытаться загрузиться с жёсткого диска, затем с CD-ROM, который будет описан ниже.

-smp 2 2 центральных процессора.

-soundhw sb16 Звуковая плата Sound Blaster (помните такую?). Особого смысла нет, но работать не мешает.

-m 2048 Виртуальная память 2 ГБ.

-vnc 127.0.0.1:0 МВМ будет работать как VNC-сервер. Можно значение переправить на 0.0.0.0:0 и тогда можно будет подключаться извне с помощью VNC Viewer. У нас тоже есть VNC-клиент, так что сможем обойтись без внешнего. Рассмотрим это позже:0 означает работу на стандартном TCP-порту 5900. Лучше не менять, если не знаете, что делаете.

-net nic, macaddr=a0:1a:64:49:ab:e1, model=rtl8139-net tap, script=/etc/qemu-ifup, ifname=tap0

Будет создан виртуальный сетевой контроллер Realtek 8139 с указанным MAC-адресом. В базовой системе он будет видеться как TAP-устройство под именем tap0, которое будет донастроено после создания внешним скриптом /etc/qemu-ifup.

-enable-kvm Использовать поддержку виртуализации ядром базовой ОС.

-hda /dev/sda2 Второй раздел первого жёсткого диска реальной машины трактовать как первый жёсткий диск виртуальной машины.

- monitor telnet:127.0.0.1:4444, server,nowait

На порту 4444 будет работать консоль управления виртуальной машиной. Нам это будет полезно тем, что по окончании работы можно будет запустить скрипт, который через эту консоль нажмёт виртуальную кнопку выключения питания, инициировав процедуру выключения средствами гостевой ОС.

-cdrom /dev/sr0 В данном примере используем CD/DVD-привод реальной машины как CD-ROM


виртуальной машины. Можно просо указать путь на файл образа ISO с дистрибутивом Windows.

Более полное описание этих и других параметров МВМ можно изучить, прочитав справку по команде:

# qemu-system-x86_64 -h | more

Поправили скрипт, для начала минимально или, что лучше, вообще не меняем.Попробуем запустить МВМ:

# /etc/init.d/qemu start* Starting qemu … [ ok ]

Теперь запустим графический интерфейс. # /etc/init.d/xdm start* Starting xdm … [ ok ]

Появляется графическое приглашение зарегистрироваться. Вводим login=root, password=1. Перед глазами консоль виртуальной машины со знакомым интерфейсом Установщика Windows. Видим благодаря встроенному VNC-клиенту. Пора заняться установкой. Особенностей немного. Главное, пожалуй – имя компьютера лучше выбирать из латинских букв и цифр. Без использования символа “тире”. Поставили.

Сетевые настройки виртуальной машины должны настраиваться так, как будто она в общей сети с хостовой машиной. Действительно, если проанализировать скрипт /etc/qemu-ifup, запускаемый при старте МВМ, то можно увидеть, что создаётся виртуальный коммутатор br0, в который виртуально подключаются физический сетевой интерфейс lan0 и виртуальный tap0.

Теперь попробуем попереключаться между виртуальными консолями. Это делается комбинацией клавиш Ctrl-Alt-Fn

, где Fn – функциональные клавиши F1, …, F7. Каждая из них соответствует виртуальной консоли номер 1, …, 7. 7-я консоль – наш запущенный графический интерфейс.

Перейдём в виртуальную консоль 1: Clrl-Alt-F1.Сконфигурируем диспетчер сервисов запускать МВМ и графический интерфейс:

# rc-update add qemu default* service qemu added to runlevel default# rc-update add xdm default* service xdm added to runlevel default

Теперь при загрузке все важные для работы Windows сервисы будут запускаться. Мы будем иметь графический интерфейс пользователя, где вводим логин=root, пароль=1 и попадаем в знакомый интерфейс Windows.

Настроим интерфейс Windows поудобнее для работы мышью. Выбираем Пуск/Панель Управления/Оборудование и звук/Мышь. Выбираем вкладку «Параметры указателя». На вкладке убираем флажок «Включить повышенную точность движения и указателя». Жмём Ok. Поводим мышью хорошенько вправо-влево, вверх-вниз. Видим, становится удобнее.

1.9. Подключаем Phobos Server

Сначала займёмся установкой MS SQL Server. Есть хорошее руководство по установке SQL 2005 Express, которое скачиваем по ссылке ftp://ftp.vocord.ru/priv/ph_2_2_15/SQL/SQL2005%20Express.pdf.

Собственно дистрибутив можно взять по ссылке:ftp://ftp.vocord.ru/priv/ph_2_2_15/SQL/SQLEXPR_ADV_2005SP4_x86_RUS.exe.EXEФобос Интерфейс ставится также стандартно, без особых вариантов. Потом ставится Phobos System.

Теперь настраиваем сервис фобоса. Затем запускаем Пуск/Программы.Phobos system/Конфигуратор. Вводим логин, пароль. Выбираем слева по дереву Параметры/Общие. В ниспадающем списке «Технический канал связи» выбираем Iptel, жмём «Применить».

Запускаем через меню Пуск/Все Программы/PHOBOS System/Конфигуратор. Вводим логин, пароль. Открывается окно. Слева-вверху раскрывающийся список. Выбираем Параметры/Общие. В правой части окна видим ниспадающий список «Технический канал связи». В нём выбираем пункт «Iptel» (3-й элемент сверху). Жмём кнопку «Применить», закрываем окно.

ftp://ftp.vocord.ru/priv/ph_2_2_15/SQL/SQL2005%20Express.pdf

Запускаем Regedit.exe. Заходим в веточку реестра HKEY_LOCAL_MACHINE\SOFTWARE\Vocord Telecom\PhobosInstallOptions. Находим ключ INSTALLDIR, копируем его содержание в буфер обмена «Ctrl-Ins». Обычно оно содержит строку: «C:\Program Files\Vocord Telecom\Phobos System\». Создаём строковый ключ D8Service1, в который копируем содержание ключа INSTALLDIR из буфера обмена «Shift-Ins».

Далее открываем файл E:\Program Files\Vocord Telecom\Phobos System\D16Proxy.ini, вводим в него строку вида:

IpTel:0:192.168.0.218:10230:128Находим в тексте IP-адрес 192.168.0.218. Заменяем его аккуратно на свой.после чего перезапускаем сервис PhNotifyserv. При перезапуске будет создано 64 (последнее число

128 в D16Proxy.ini, делённое на 2) виртуальные телефонные линии для записи.Запускаем Пуск/Программы.Phobos system/Менеджер Заданий. Добавляем задание на перехват с

IP-адресом телефона/группы телефонов/станции. Добавляем задание на перехват, в котором в поле «B-номер» укажем символ «*» (запись звонков с любыми номерами сторон, если номера известны).

Для дополнительной уверенности можем создать ещё одно задание на перехват, где в поле «B-номер» указываем “*” – звёздочка без кавычек. Это означает «записывать все вызовы, в которых указан номер какой-нибудь стороны».

Следует заполнять, помимо поля «Имя задания», только одно поле критериев отбора, так как при обработке правил применяется логическое правило «И», а не «ИЛИ».

1.10 Если сильно напортачили в системе

Если мы что-то безнадёжно испортили на развёрнутом съёмнике и хотим продолжить исследования «с чистого листа», мы можем просто заново загрузиться с дистрибутивной флешки или DVD-ROM, установиться заново, как описано в подразделе 1.2 за небольшим дополнением. В некоторый момент нам может быть выдан примерно такой наводящий вопрос:# mkfs.ext3 /dev/sda1mke2fs 1.42.12 (29-Aug-2014)/dev/sda1 contains a ext3 file system

created on Thu May 14 21:34:52 2015Proceed anyway? (y,n)

Утилита создания файловой системы нас спрашивает, согласны ли мы заново создать файловую систему на месте обнаружения предыдущей. Согласимся, нажмём «y» и «Enter».

1.11Как без остатков удалить содержимое диска

Возможно, продукт нас разочарует и тогда компьютер надо будет очистить от внесённых изменений. При этом может даже случиться, что установщик Windows не сможет поставить правильно свой загрузчик, не разобравшись, что на диске остался несовместимый LILO. А может случиться, что какие-то файлы будут безнадёжно испорчены и лучшим выходом будет казаться переустановка ПО съёмника заново. Мы можем выйти из положения – сотрём таблицу разделов и загрузчик:#dd if=/dev/zero of=/dev/sda bs=512 count=10241+0 records in1+0 records out512 bytes (512 B) copied, 3.1804e-05 s, 16.1 MB/s#halt

2. Глубокий экскурс для тех, кто хочет выжать больше

2.1. Общие сведения

Итак, в общем виде обработка данных показан на рис. 1.

1 Если у нас уже есть станция записи, которая уже записывает звонки с цифровых линий с помощью плат Vocord D8, то ключ реестра D8Service должен быть уже создан. Прочитаем его содержание, откроем указанный в нём каталог – увидим файл D16Proxy.ini. Он нас сейчас понадобится.

Рис. 1. Взаимодействие основных элементов Phobos Iptel

2.2. SPAN-сессия

Он же «зеркальный» порт. Название взято из документации компании Cisco Systems, но в целом отражает идею перенаправления копии прошедшего сетевого трафика на устройства-анализаторы. Мы опустим возможные примеры их создания, оставив вопрос к сетевикам.

2.3. Сетевые карты

В принципе, с тем или иным успехом могут использоваться любые встроенные и дополнительные контроллеры Ethernet. По опыту самыми лучшими являются гигабитные контроллеры от фирмы Intel. Это в общем случае. Есть и частности, а именно желательны поддержка DMA и дросселирования прерываний. Это чтобы не дёргать ядро ОС при каждом прибытии пакета. Впрочем, для систем с небольшой нагрузкой, до нескольких десятков разговоров одновременно, можно не отвлекаться этими мелочами.

2.4. Iptel Core

Основной процесс, который создаёт при старте несколько процессов-потомков, в числе которых сниффер, декодеры протоколов, подстановщик строк в атрибуты, менеджер атрибутов. Какие именно дочерние процессы запускать, описывается в файле /usr/local/opt/iptel/etc/iptel.conf. В дальнейшем будем для краткости называть его iptel.conf. Iptel Core служит средством передачи сообщений между дочерними процессами через механизм socketpair. Примером сообщений, передаваемых через Iptel Core, являются сообщения от декодеров протоколов к снифферу см. рис. 1. Звук через Iptel Core не передаётся. Декодеры протоколов не знают, был ли звук во время очередного разговора или не было. Файл iptel.conf обычно является символической ссылкой на истинный файл конфигурации под нужную сигнализацию. Так сделано для удобства всех – см. подраздел. 1.6.

Откроем файл iptel.conf. Мы увидим, что он по структуре очень похож на XML, но им не является. Любую строку можно закомментировать, поставив в начале строки символ «#». Тело файла разбито на несколько, скажем так, секций <module>. Процесс Iptel при старте анализирует эти секции на предмет поиска указаний о загрузке дочерних модулей. В каждой секции анализируются параметры (Таблица 2):

Таблица 2. Основные параметры конфигурации модулей, анализируемых Iptel Core


name Имя модуля. Iptel Core и разные дочерние модули распознают тот узел <module>, который сожержит именно его параметры. Так, Iptel Core ищет узел, у которого name=core

so_name Обязательный параметр, который определяет путь доступа к загружаемой динамической библиотеке с модулем. Путь доступа задаётся относительно каталога /usr/local/opt/iptel/bin.

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

affinity Необязательный параметр, определяющий маску предпочтительных для работы процессоров. Смысл параметра – см. man 2 sched_setaffinity

Так же, как и Iptel Core, секции <module> файла iptel.conf анализируют и дочерние процессы-модули. Каждый из них ищет свою секцию <module>, у которой параметр name имеет определённое значение. Например, сниффер ищет такой <module>, у которого name=sniff_h.

2.5. Сниффер

Этот процесс получает данные от одной или более сетевых карт и складывает данные в область MFS. Данные сигнализации складываются постоянно. Звук складывается в том случае, если этот звук относится к разговору, который радо записывать. Иногда спрашивают, можно ли Iptel реализовать под Windows. Здесь самое удобное место ответить, почему положительного решения данного вопроса не предвидится. Дело в том, что в ядре Linuх реализован весьма эффективный механизм доставки данных от сетевых карт до пользовательских процессов. Этот механизм называется memory-mapped packet socket. Ввод данных

выполняется без использования системных вызовов. В Windows нет ничего конкурентоспособного. Основной камень преткновения именно в эффективности механизма ввода данных сниффером.

Откроем файл конфигурации iptel.conf. Найдём секцию <module>, у которой параметр name имеет значение sniff_h. Значения параметров перечислены в Таблице 3.

Таблица 3. Основные параметры конфигурации модуля сниффера


<eth_if> name = lan1</eth_if>

Узел описывает устройство ввода данных. В данном примере указывается, что сетевой интерфейс lan1 должен быть переведён в режим прослушивания всего трафика (promiscuous mode). В конфигурации может быть несколько подобных узлов для разных сетевых интерфейсов – и все они будут использоваться для ввода трафика.

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

play_file Для нормальной работы, т.е. ввода трафика через Ethernet-порты параметр не указывается. Желающие ответить на вопрос «Поддерживает ли Iptel телефонную систему XYZ» могут поисследовать этот вопрос и тогда им придётся редактировать и этот параметр. Допустимое содержание параметра – полный путь доступа к файлу формата tcpdump .pcap (но не .pcapng). Файл с трафиком будет «проигрываться», будто бы мы перехватили этот трафик через Ethernet-порт.

play_to Указывает время задержки (в секундах) при запуске перед началом нормальной работы или проигрывания файла с трафиком. Смысл имеет, если мы пытаемся «проиграть» запись трафика. Для присоединения станции записи Phobos и передачи правил отбора требуется несколько секунд.

play_mode Необязательный параметр. Если значение начинается на букву ‘r’, сниффер задаст себе приоритет планировщика реального времени. Если параметр отсутствует или начинается не на букву ‘r’, сниффер не будет менять приоритета, работая по-прежнему в режиме разделения времени. Режим реального времени считается теоретически лучшим с точки зрения отсутствия пропусков в полученных данных. Режим разделения времени считается практически более устойчивым к ошибкам планировщика ОС, наблюдавшимся при тяжёлых нагрузках (многие десятки тысяч пакетов в секунду на сетях оператора сотовой связи), когда процесс сниффера намертво «замерзал».

play_fmt Формат проигрываемого файла. Если play_file задан, должен начинаться на букву ‘t’ (от tcpdump). В противном случае значения не имеет.

rtp_decoder_version Номер версии декодера RTP-трафика. Внутренне допустимы версии 3, 4, 5. По умолчанию равно 5. Если параметр указывается, должен быть равен 5. Может и не указываться. Менять значения пользователю не рекомендуется.

process_rtcp,rtcp_ipresolve,rtcp_phonenum

process_rtcp определяет, обрабатывать ли трафик RTCP. По умолчанию обработка включена. Действие конкретизируется заданием обработки сообщений с номерами телефонов (rtcp_phonenum) или каноническими именами устройств (rtcp_ipresolve). Для других декодеров значение параметров не принципиально.Если указать значение любого параметра, начинающееся на букву ‘n’, параметр будет выключен. По умолчанию все параметры включены. Могут иметь смысл лишь для H.323-телефонов фирмы Avaya.

rtcp_paranoical Известно, что RTCP-трафик обычно существует только в паре с RTP. Лишь номера портов отличаются на 1. Чётный – RTP, нечётный – RTCP. Если process_rtcp включён, этот параметр позволяет проверять все UDP-пакеты, не относящиеся к известным RTP-сессиям, на предмет относимости из к RTCP. Может иметь смысл лишь для H.323-телефонов фирмы Avaya. По умолчанию опция выключена. Можно в порядке эксперимента включить, указав значение, начинающееся на букву ‘y’,


<modules> Внутренняя секция для описания особенностей обработки разного трафика.

<mod_sip> Начинает описание отдельного внутреннего модуля обработки UDP. Несмотря на присутствие sip в названии, секция нужна для обработки любого трафика UDP, несущего сигнализацию VoIP: SIP, UNISTIM, IAX2, NOE, MGCP. Также может использоваться для обработки трафика H.323-телефонов фирмы Avaya.

enabled Если начинается на букву ‘y’, трафик UDP-протокола будет направляться в UDP-сигнализационный поток данных в области MFS (MFS-сокет), откуда его сможет вычитывать любой декодер протоколов. Критерий направления – см. параметр port.

port Указывает, пакеты с какими UDP-портами направляются в UDP-сигнализационный MFS-сокет. Возможно неоднократное указание параметра. Возможные значения:‘*’- все UDP-пакеты (для реальных задач пользователя не используется);<число> [- <число>] – номер или диапазон номеров портов.Например, если сигнальный трафик проходит с портами UDP 5060, 5061, 5090, можно указать так:port = 5060-5061port = 5090

</mod_sip> Заканчивает описание отдельного внутреннего модуля обработки UDP.

<mod_tcp> Начинает описание отдельного внутреннего модуля обработки TCP.

port Указывает, пакеты с какими TCP-портами направляются в TCP-сигнализационный MFS-сокет. Возможно неоднократное указание параметра. Возможные значения:‘*’- все TCP-пакеты (для реальных задач пользователя не используется);<число> [- <число>] – номер или диапазон номеров портов.Например, если сигнальный трафик проходит с портами TCP 2000 (SKINNY) и 1720 (H.323/H.225), можно указать так:port = 2000port = 1720Если не указан ни один порт, в MFS-сокет будут направляться весть трафик TCP. Это может иметь практический смысл для обработки трафика H.323, в котором нет туннелирования H.245, т.е. любой TCP-пакет должен быть исследован декодером h323_dec на предмет наличия трафика H.225 и H.245.

</mod_tcp> Заканчивает описание отдельного внутреннего модуля обработки TCP.

Другие параметры лучше не изменять.

2.6. Область временного хранения данных из сети MFS

Отображённая на память файловая система. От того и быстрая насколько возможно. Иногда требует немало памяти. Логичная аббревиатура: Memory File System. Данные в неё пишет сниффер, читают декодеры протоколов (сигнализацию) и модуль связи в Phobos (звук).

2.7. Логи

В каталоге /var/log/iptel все программы пакета Iptel пишут свои логи. Речь идёт не только о таковых, которые в списке процессов видятся под именем iptel, но и, например, прокси-серверы, модуль очистки MFS cleaner. Эти процессы пишут свои логи в файлы с именем <некое_имя>.log.tmp. Ежеминутно отслеживается объём накопившихся данных в указанном каталоге. Если объём превысил пороговое значение, всем процессам посылается сигнал USR1. Процессы обучены при получении этого сигнала переименовывать свой файл логов в вид <некое_имя>.log и открывать лог заново в файле <некое_имя>.log.tmp. Проверяющий скрипт файл со старыми логами архивирует в каталог /var/log/iptel/archive – в архив логов. Но и в архиве логов отслеживается накопившийся объём данных, причём при превышении предельно допустимого объёма архива логов наиболее старые файлы архива удаляются. Это всё делает скрипт grablog_run, он же и grablog. Расположен он в

каталоге /usr/local/opt/iptel/bin. Каждую минуту скрипт выполняет проверку как задание для crontab. Посмотреть задание можно по команде:# grablog -e

Так логи переписываются в архив логов при окончании работы системы.Параметры командной строки grablog перечислены в Таблице 4.

Таблица 4. Параметры командной строки grablog


-ld <каталог>,--log-dir=<каталог>

Задаёт путь доступа к каталогу, в который записываются логи. По умолчанию принимается /var/log/iptel.

-ad <каталог>,--archive-dir=<каталог>

Задаёт путь доступа к архиву логов. По умолчанию принимается /var/log/iptel/archive.

-id <каталог>,--iptel-dir=<каталог>

Задаёт путь, в котором находятся двоичные файлы программ, логи которых ротируются. По умолчанию равно /usr/local/opt/iptel/bin. Скрипт высматривает процессы, запушенные из этого каталога. Если суммарный размер файлов в --log-dir превышает порог, заданный параметром --log-limit, то этим процессам рассылается специальный сигнал, трактуемый как требование переименовать старый файл логов и открыть новый.

-al <N>,--archive-limit=<N>

Задаёт пределы архива логов (см. описание --archive-dir) в N Мбайт. Если суммарный объём больше, скрипт удаляет по одному самому старому файлу архива до тех пор, пока суммарный объём архива не станет меньше указываемого значения.

--mask=M Задаёт маску файлов, подлежащих архивированию. По умолчанию принимается .log. Пока необходимости использовать параметр не предвидится.

-f,--force

Конечно, бывает необходимо принудительно архивировать и переоткрыть логи невзирая на накопленный объём. Для этого этот параметр и предназначен. На практике используется при загрузке системы, при старте сервиса iptel.

-q,--quiet

Не выводить сообщения скрипта при работе. Используется при запуске сервиса iptel для устранения визуальных эффектов на экране.

-h,--help

Вывести краткую инструкцию о работе.

Есть ещё пара устаревших параметров, которые теперь рассматривать нет смысла.

2.8. Декодеры протоколов

Декодеры протоколов предназначены для декодирования данных телефонной сигнализации. Т.к. за каждый из поддерживаемых протоколов отвечает один модуль, а на большинстве объектов используется телефонная система от одного производителя, работающая через один из VoIP-протоколов, то и запускается обычно только один модуль декодера. Посмотрите в каталог /usr/local/opt/iptel/etc. Найдите в нём файлы iptel.conf.*. Их несколько. Каждый заготовлен под конкретную сигнализацию. Операция по настройке на сигнализацию описана в подразделе. 1.6. Вообще можно осуществлять запись телефонов с разными сигнализациями одновременно, но тогда надо будет проявить творчество с файлом конфигурации Iptel.

2.8.1. h323_decКонфигурация декодера протокола Н.323 задаётся параметрами командной строки согласно

Таблице 5.Таблица 5. Параметры конфигурации декодера H.323


-l <путь к файлу> Задаёт путь доступа к файлу, в который записываются текущие логи. Параметр обязателен.

-e <путь к файлу> Задаёт путь доступа к файлу, в который переименовывается файл с логами в момент ротации логов. Параметр обязателен.

-a <0 | 1> Указывает, используются ли телефоны фирмы Avaya. 0 – если не используются, 1 – если используются. По умолчанию равно 1.

-с <0 | 1> Указывает, используются ли телефоны фирмы Siemens с сигнализацией CornetIP (HFA). 0 – если не используются, 1 – если используются. По умолчанию равно 1. Декодер подходит для записи HFA-телефонов, которые даже не используют используют H.323 для управления медиа-сессиями. Но тогда в конфигурации sniff_h лучше указать в узле <mod_tcp> параметр port=4060. Сказанное не распространяется на случаи, если надо записывать HFA-телефоны со старой прошивкой, в которй используется H.323.

-P <число> Указывает номер порта с сигнализацией H.225. По умолчанию равно 1720.

-R <0 | 1> Указывает, обрабатывать ли трафик H225 RAS (Gatekeeper). Может быть полезным для определения внутренних номеров телефонных аппаратов Avaya. По умолчанию разрешено (1). Разрешение предусматривает необходимость описания в конфигурации sniff_h такого <mod_sip>, в котором port=1719. Для распознавания собственного extension-номера аппарата его надо выключить и снова включить.

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

Таблица 6. Параметры конфигурации декодера SIPЧто записываем Параметры h323_dec Конфигурация sniff_h

Avaya IP Trunk -c0 -a0 -R0 Секция <mod_tcp>, в которой port=1720«Родные» телефоны Avaya -c0 -a1 -R1 process_rtcp=y

rtcp_ipresolve=yrtcp_phonenum=yСекция <mod_tcp>, в которой port=1720,Секция <mod_sip>, в которой port=1719

Телефоны HFA Siemens с поддержкой H.323

-c1 -a0 -R0 Секция <mod_tcp>, в которой закомментировать port.

Прочие межстанционные звонки по H.323

-c0 -a0 -R0 Секция <mod_tcp>, в которой закомментировать port.

Телефоны HFA Siemens-Unity без поддержки H.323

-c1 -a0 -R0 Секция <mod_tcp>, в которой port=4060

2.8.2. sip_decПараметры работы декодера SIP представлены в Таблице 7. При старте sip_dec ищет в

конфигурационном файле узел <module>, у которого параметр name=sip_dec.Таблица 7. Параметры конфигурации декодера SIP


log_level = <число> Задаёт уровень логирования работы. Является битовой маской. Значения битов:1 – записывать ошибки;2 – записывать предупреждения;4 – записывать трассировку;8 – записывать содержание обрабатываемых данных.Значение по умолчанию – 15, все биты маски выставлены в 1.

process_udp = <0 | 1> Указывает, обрабатывать ли данные протокола UDP. Значение по умолчанию 1, обработка включена. Обрабатываемые данные должны быть определены секцией <mod_sip> в конфигурации модуля с name=sniff_h (см. п. 2.5)

process_tcp = <0 | 1> Указывает, обрабатывать ли данные протокола TCP. Значение по умолчанию 1, обработка включена. Обрабатываемые данные должны быть определены секцией <mod_tcp> в конфигурации модуля с name=sniff_h (см. п. 2.5)

max_call_timeout_sec = Задаёт таймер максимально возможного время продолжения разговора в секундах.


<число> По истечении таймера разговор считается завершённым. Значение по умолчанию 0, время разговора не ограничивается. Лучше указывать ненулевое значение, особенно при работе в режиме прослушивания. Сетевые пакеты могут пропадать из SPAN-сессии. Бывает, что провода переключаются и пропускаются сообщения об окончании разговора. Сессии «зависают». По истечении таймера записи разговора завершаются, предотвращается утечка ресурсов, самый важный из которых для пользователя - лицензии.

ignore_ip = <IP-адрес> Параметром можно указать, трафик с участием каких IP-адресов следует декодеру игнорировать и не сообщать о сессиях, созданных с участием этих адресов. Можно употреблять неоднократно. Использовать эти параметры логичнее в режиме проксирования во избежание перерасхода лицензий.

2.8.3. skinny_decПараметры работы декодера SCCP/Skinny представлены в Таблице 8. Не рассмотренные параметры

лучше не менять. При старте skinny_dec ищет в конфигурационном файле узел <module>, у которого параметр name=skinny_dec.

Таблица 8. Параметры конфигурации декодера SCCP/Skinny


log_path = <путь> Задаёт путь к каталогу, в который пишется файл логов skinny_dec.log.tmp. При ротации логов файл переименовывается в skinny_dec.log. По умолчанию равен /var/log/iptel.

log_level = <число> Задаёт уровень логирования работы. Является битовой маской. Значения битов:1 – записывать ошибки;2 – записывать предупреждения;4 – записывать события, связанные с поступлением данных в декодер;8 – записывать декодированные сообщения о принятых сообщениях протокола;16 – записывать сообщения о предпринимаемых действиях.Значение по умолчанию – 7, младшие 3 бита маски выставлены в 1.

max_tcp_prebuf = <число>

Сообщения протокола содержат в себе собственную длину. Если указываемая длина превышает значение этого параметра, накопленные данные отбрасываются. Механизм предназначен для защиты от переполнения памяти при обработке случайных данных в определённых полях, например, если некий трафик на деле не является Skinny-трафиком или при ошибках стека самих устройств фирмы Cisco. Значение по умолчанию 2048. Предположительно, значения больше нет смысла указывать.

port = <число> Указывает какой номер TCP-порта используется на CallManager для подключения телефонов. По умолчанию равно 2000.

max_call_timeout_sec = <число>

Задаёт таймер максимально возможного время продолжения разговора в секундах. По истечении таймера разговор считается завершённым. Значение по умолчанию 0, время разговора не ограничивается. Лучше указывать ненулевое значение, особенно при работе в режиме прослушивания. Сетевые пакеты могут пропадать из SPAN-сессии. Бывает, что провода переключаются и пропускаются сообщения об окончании разговора. Сессии «зависают». По истечении таймера записи разговора завершаются, предотвращается утечка ресурсов, самый важный из которых для пользователя - лицензии.

max_keep_alive_timeout = <число>

В период отсутствия звонков телефон и CallManager обменивается сообщениями о своём состоянии KEEP_ALIVE. Долгое отсутствие сообщений (дольше указанного времени, миллисекунд) трактуется, как выключение питания телефона и ресурсы, связанные с телефоном ресурсы. По умолчанию равно 0 – время ожидания сообщений KEEP_ALIVE не ограничивается. Особого смысла его задавать нет, т.к. есть и другой механизм контроля жизнеспособности телефонных аппаратов – со стороны сниффера.

prefer_names = <0 | 1> Если параметр не указывать или указать равным 0 (по умолчанию), то в качестве


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

zoom = <0 | 1> Если на объекте используется система записи ZOOM, когда телефоны посылают на себя копию принятого и передаваемого звука, то могут создаваться излишние записи со звуком с одной из сторон. При этом идёт перерасход ресурсов памяти и используемых лицензий. В этом случае надо задать значение “1” данному параметру.

unanswered_calls =<0 | 1>

Параметр задаёт, нужно ли сообщать на станцию записи о неудачных попытках совершения звонков (абонент не ответил). Потребуются определённые настройки системы Phobos чтобы можно было воспользоваться этой возможностью. По умолчанию равно 0, сообщения не отправляются.

ignore_cm = <IP-адрес> Параметром можно указать, трафик с участием каких IP-адресов CallManager следует декодеру игнорировать и не сообщать о сессиях, созданных с участием этих адресов. Можно употреблять неоднократно. Использовать эти параметры логичнее в режиме проксирования во избежание перерасхода лицензий.

2.8.4. unistim_decПараметры работы декодера Unistim представлены в Таблице 9. Не рассмотренные параметры

лучше не менять. При старте unistim_dec ищет в конфигурационном файле узел <module>, у которого параметр name=unistim_dec.

Таблица 9. Параметры конфигурации декодера Unistim


<filter> Открывает внутренний узел конфигурации.

port = <число> Указывает, какой номер UDP-порта используется на АТС или на Node для подключения телефонов. Параметр может указываться неоднократно, касательно разных портов. По умолчанию равно 5000.

log_level = <число> Задаёт уровень логирования. Смысл имеют числа от 0 до 6. Чем больше, тем подробнее логи. Например:0 – записывать ошибки;1 – записывать предупреждения;Значения свыше 6 трактуется как 6 – максимальное значение.Значение по умолчанию 0х14.

</filter> Закрывает внутренний узел конфигурации.

ignore_ip = <IP-адрес> Параметром можно указать, трафик с участием каких IP-адресов следует декодеру игнорировать и не сообщать о сессиях, созданных с участием этих адресов. Можно употреблять неоднократно. Использовать эти параметры логичнее в режиме проксирования во избежание перерасхода лицензий.

Логи пишутся в каталог /var/log/iptel в файл unistim_dec.log.tmp. При ротации логов файл переименовывается в unistim_dec.log.

2.8.5. noe_decПараметры работы декодера NOE компании Alcatel представлены в Таблице 10. При старте noe_dec

ищет в конфигурационном файле узел <module>, у которого параметр name=noe_dec.Таблица 10. Параметры конфигурации декодера NOE


log_path = <путь> Задаёт путь к каталогу, в который пишется файл логов noe_dec.log.tmp. При ротации логов файл переименовывается в noe_dec.log. По умолчанию равен /var/log/iptel.

base_port = <число> Так называемый базовый номер порта. Протокол NOE предусматривает обмен данными поверх UDP, причём порты отправителя и получателя разные: меньший из них называется базовым, больший должен быть на 128 больше базового. Значение по умолчанию 32512.

from_charset = <набор1>to_charset = <набор2>

Указывает, как преобразуются имена участников разговора, с какого символьного набора (from_charset) в какой (to_charset). По умолчаниюfrom_charset=utf8, to_charset=windows-1251. Параметр to_charset лучше не менять, т.к. Phobos рассчитан на эту кодировку. Параметр from_charset может меняться с учётом настроек кодирования на АТС и телефоне. Полный список возможных кодировок можно прочесть, введя команду на съёмнике:#iconv -l

2.8.6. mgcp_decПараметры работы декодера MGCP представлены в Таблице 11. Не рассмотренные в Таблице

параметры менять не рекомендуется. При старте mgcp_dec ищет в конфигурационном файле узел <module>, у которого параметр name=mgcp_dec.

Таблица 11. Параметры конфигурации декодера MGCP


log_path = <путь> Задаёт путь к каталогу, в который пишется файл логов mgcp_dec.log.tmp. При ротации логов файл переименовывается в mgcp_dec.log. По умолчанию равен /var/log/iptel.

port_ca = <число> Указывает номер порта узла Call Autority. По умолчанию равно 2727.

port_gw = <число> Указывает номер порта узла Gateway. По умолчанию равно 2427.

2.8.7. iax_decПараметры работы декодера IAX2 представлены в Таблице 12. Не рассмотренные в Таблице

параметры менять не рекомендуется. При старте iax_dec ищет в конфигурационном файле узел <module>, у которого параметр name=iax_dec.

Таблица 12. Параметры конфигурации декодера IAX2


log_path = <путь> Задаёт путь к каталогу, в который пишется файл логов iax_dec.log.tmp. При ротации логов файл переименовывается в iax_dec.log. По умолчанию равен /var/log/iptel.

to_charset = <набор> Указывает, в какой символьный набор преобразуются имена участников разговора. Должно стоять to_charset=windows-1251, т.к. Phobos рассчитан на эту кодировку.

port = <число> Указывает, какой номер UDP-порта используется обеими сторонами для передачи сообщений сигнализации и звука. Значение по умолчанию равно 4569.

2.9. Менеджер атрибутов

Модуль имеет задачи: вести внутреннюю базу данных с критериями отбора звонков на запись (номер, IP-адрес

участника и др.); анализировать сообщения от декодера протоколов о начале, окончании звонков, об

уточнении сведений о звонках (атрибутов) по ходу их существования; принимать решения о начале или окончании записи звонков в соответствии с накопленными

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

USB-Key через промежуточный сервис vsd_server.Параметры модуля можно посмотреть в Таблице 13

Таблица 13. Основные параметры конфигурации Атрибут-менеджера


log_path = <путь> Путь доступа к каталогу, в который будет записываться файл логов. По умолчанию равен /var/log/iptel. Допускается указывать несуществующий каталог, в этом случае файл логов создаваться не будет.

vsd_server = <ip_адрес>:<порт TCP>

Задаёт расположение в сети компьютера с ключом сервисом vsd_server и ключом лицензирования USB-Key.Допустимый формат:<ip_адрес>:<порт TCP>.По умолчанию равен 127.0.0.1:7777, т.е. предполагается установка ключа на локальном компьютере.

use_snmpd = <число>

Задаёт, должен ли Менеджер атрибутов отвечать на запросы систем сетевого управления по протоколу SNMP. По умолчанию равно 0 = отвечать не должен. Ненулевое значение означает, что отвечать должен.

Модуль может работать в режимах: основной – когда записи ведутся в пределах установленного лицензией количества без

ограничения по длительности работы2; демонстрационный – когда записывать можно не более 1 звонка одновременно; запрещённый – когда ни один звонок не может быть записан.

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

Если ключ защиты изъять или пропадёт связь с сервером лицензирования (на том же или на другом компьютере), модуль начинает работать в демонстрационном режиме не дольше 1 часа. Режим нужем тем, кто достал дистрибутив на тест-драйв на общих условиях. По истечении 1 часа он перейдёт в запрещённый режим.

Из демонстрационного или запрещённого режима модуль переходит в основной в течение нескольких секунд после вставки ключа лицензирования или после восстановления связи в внешним сервером лицензирования.

Можно сделать резервирование съёмников без дополнительных расходов на лицензии, если сделать 2 одинаковых съёмника. Основным будет тот, в котором установлен ключ лицензирования. Если основной выходит из строя, можно переставить ключ лицензирования в резервный – и он станет основным.

2.10. Подстановщик строк в атрибуты

Атрибуты генерируются декодером протокола (рис. 1) в двоичном виде. Между тем в Phobos они должны передаваться в текстовом виде, например: PHONEDEV_NUMBER=600. Подстановщик строк в атрибуты выполняет перевод из двоичного вида в текстовый. Из параметров конфигурации можно отметить лишь log_path из секции <module>, имеющей name=common или name=shared

2.11. Модуль связи с Phobos

Что же делает программа ipc_server? Она, по сути, транзитом передаёт через себя: правила отбора – от станции записи в Менеджер заданий через Подстановщик атрибутов; сообщения о начале и окончании разговоров, звук разговоров, текстовые атрибуты

разговоров – от Менеджера заданий через Подстановщик атрибутов на станцию записи.Параметры командной строки указываются в файле /etc/init.d/ipc_server. Значения параметров – см.

Таблицу 14.Таблица 14. Основные параметры конфигурации Атрибут-менеджера


-l <path> Задаёт полный путь доступа к файлу логов. Тем не менее, логи будут записываться не в указанный файл, а в такой, имя которого указано с приписыванием .tmp на конце. При ротации

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


логов файл будет переименован в заданный этим параметром.Значение по умолчанию: /tmp/ipc_server.log (использовать не рекомендуется)

-p <порт> Номер TCP-порта, к которому привязывается программа как сетевой сервер в ожидании подключения от станции записи. Значение по умолчанию 10230.

-r <число> Во время работы программа периодически пишет в лог сведения об очередном обработанном RTP-пакете. Это значит, что после обработки указываемого числа RTP-пакетов в одном направлении передачи звука в лог будет выведена запись об обработанном пакете. Чем больше это число, тем реже выводятся записи в лог. Значение по умолчанию 100.

-X <число> Задаёт общее число логических каналов. Число чётное. Один записываемый разговор – это 2 логических канала, по 1 каналу на каждое направление передачи RTP. Отсюда следует, что нет смысла указывать число, меньшее, чем удвоенное число одновременно записываемых разговоров согласно лицензии. Если число слишком большое, может иметь место неоправданная излишняя нагрузка на процессор. Значение по умолчанию 2048, т.е. резервируется место под 1024 разговорных канала. Если процессор новее Pentium4, менять параметр нет смысла.

-f <0 | 1> Принуждает использовать системный механизм опроса файлов (poll) на наличие входных данных вместо проведения попыток вычитывания данных из каждого открытого файла. Существенно ускоряет работу при большом количестве одновременно записываемых разговоров (не в смысле лицензионных возможностей, а когда разговоры уже записываются). По умолчанию равно 0 – механизм poll не должен задействоваться. Однако в файле /etc/init.d/ipc_server указано –f1, т.е. предусмотрено включение механизма ускорения.

-R <число> Задаёт период времени в миллисекундах, в течение которого по окончании очередного разговора пакеты RTP будут игнорироваться. По умолчанию значение 0 – функция отключена. Может иметь смысл, если записываются не непосредственно телефонные аппараты, а межстанционные разговоры. Бывают ситуации, когда последующий разговор начинается сразу за предыдущим, при этом IP-адреса и UDP-порты не меняются. Передающий узел может отсылать ещё некоторое время старые пакеты RTP, которые, по идее, не должны попадать в новую запись. Мы можем обеспечить защиту от искажения новой записи старыми данными, если в течение некоторого времени будем помнить, что RTP-пакеты с номерами SSRC от старой сессии считаются недопустимыми и подлежащими игнорированию. Если пишете телефоны, нет нужды использовать параметр.

-S <число> Определяет, должен ли модуль отвечать на запросы систем сетевого управления по протоколу SNMP. Нулевое значение означает, что не должен (по умолчанию). Нулевое значение – должен.

Другие параметры не посоветовавшись лучше вообще не менять.

2.12. Модуль связи с USB-Key

Программа vsd_server обеспечивает связь Менеджера атрибутов с USB-ключом по сети. Благодаря этой программе мы можем разнести съёмник и USB-ключ. Обычно в этом нет особого смысла, но если стоит задача съёмник задублировать или, более того, перенести в «облако», сразу станет понятной решение сразу пойдёт на пользу.

Параметры командной строки не предусмотрено, файлов конфигурации – тоже. При запуске открывает TCP-порт 7777. После того, как Менеджер атрибутов подключится по сети, vsd_server обеспечивает ему обмен данными с USB-ключом.

2.13. Модуль очистки области MFS

Данные, накопленные в области MFS, надо периодически удалять, освобождать занятое место. Обычно попавшие в область данные через несколько миллисекунд уже обрабатываются и больше не нужны – их можно удалить. Программа cleaner запускается сервисом mfs_cleand. Параметры командной строки перечислены в Таблице 15.

Таблица 15. Параметры командной строки модуля очистки MFS


-L <path> Задаёт полный путь доступа к файлу логов. Логи будут записываться в указанный каталог, в файл cleaner.log.tmp. При ротации логов файл будет переименован cleaner.log.Значение по умолчанию /var/log/iptel.

-l <число> Задаёт уровень логирования. Возможны значения от 0 до 3. Чем больше значение, тем больше логов. Значение по умолчанию 3.

-T <число> Задаёт время бездействия, по истечении которого программа проводит очередную итерацию области MFS. Значение по умолчанию минус 1. Это значит, что программа постоянно ищет, чего бы такого удалить. Уж лучше не трогать то значение параметра, какое задано в файле скрипта запуска сервиса /etc/init.d/mfs_cleaner.

-t <число> Задаёт минимальное число секунд, которое должно пройти с момента помещения данных в область MFS, прежде чем данные будут удалены. Данные помещаются в MFS в виде файлов-фрагментов. Последний файл-фрагмент не удаляется вне зависимости от этого таймаута, если поток данных ещё открыт программой-читателем или писателем.

-p <каталог> Задаёт путь доступа к каталогу с областью MFS. Значение по умолчанию /tmp/mfs.

-f Задаёт принудительную очистку области MFS и завершение работы. Используется при старте сервиса iptel в файле /etc/init.d/iptel

3. Что делать, если большие проблемы с «зеркалированием» трафика

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

Бывает, что записывать необходимо «трубки», работающие через WiFi-подключение. И тогда разговор между двумя абонентами, зарегистрировавшимися на одной базовой станции, может вообще не проходить через коммутаторы ЛВС.

Да и просто невозможным бывает создать «зеркальную» копию сетевого трафика нужных телефонов при имеющемся бюджете.

На помощь может прийти активное проксирование телефонного трафика съемником. Благодаря одному из нескольких предустановленных прокси-серверов съёмник начинает вести себя как сетевое устройство. Как правило, для IP-телефона он имитирует работа сигнального сервера (абонентское плечо), а для сигнального сервера - IP-телефон (станционное плечо). Звук также проходит через съёмник, т. к. прокси-сервер подменяет информацию в сообщениях об управлении звуковыми сессиями. Теоретически прокси-серверы при должной настройке может держать до нескольких тысяч телефонов с установленными сессиями. Прокси-серверы могут работать на съёмниках вне зависимости от работы других программ Phobos Iptel на физическом компьютере. Основная задача прокси-серверов – качать связь. Прокси заставляют телефоны посылать звуковые данные на себя, затем пересылают звуковые данные надлежащему получателю. Мы можем установить по комплекту программ на два физических компьютера (см. п. 1.2), создав систему прокси-серверов с тем или иным, но повышенным уровнем надёжности, Причём сэкономим на лицензировании. Ключ USB Key с лицензиями дополнительно можно не покупать, но в случае аппаратного отказа одного прокси-съёмника USB-ключ придётся переставить в другой съёмник. Новые звонки, будут записываться.

3.1. Проксирование SIP-телефонов3.1.1. Параметры файла конфигурации прокси-сервера

SIP-телефоны можно проксировать через средство siproxd, созданное на основе одноименной opensource-утилиты. Параметры работы siproxd задаются в конфигурационном файле /usr/local/opt/iptel/etc/siproxd.conf. Наиболее важные настройки — см. Таблицу 16.

Таблица 16: Основные параметры конфигурации сервиса siproxd


if_inbound Имя сетевого интерфейса, через который идёт обмен SIP-трафиком с телефонами. Для работы без кластеризации следует оставить lan0. Если используем кластеризацию, установим в lan0:0

if_outbound Имя интерфейса, через который идёт обмен SIP-трафиком с IP-ATC. Для работы без кластеризации следует оставить lan0. Если используем кластеризацию, установим в lan0:0

hosts_allow_reg Сеть и число единиц в битовой маске сети. Характеризует множество IP-адресов телефонов, которым разрешается регистрироваться на данном прокси-сервере. Например, если хотим разрешить регистрироваться телефонам с IP-адресами в диапазоне с 20.1.0.1 по 20.1.0.254, параметр надо задать как 20.1.0.1/24

urlmap_size Максимально допустимое число SIP-абонентнов, которое может зарегистрироваться через прокси. По умолчанию равно 128.

rtp_port_low Задаёт начало диапазона номеров UDP-портов, которые будут использоваться для передачи RTP и RTCP-данных телефонов. Конец диапазона номеров портов будет равенrtp_port_low + (4 * urlmap_size).

cluster Данным параметром мы можем задать параметры TCP-соединения, по которому два узла кластеризуются. Формат параметра:cluster = listen@<ip-адрес>:<порт> - если узел является TCP-сервером, т. е. ожидает присоединения к себе другого узла;cluster = connect@<ip-адрес>:<порт> - если узел является TCP-клиентом, т.е. инициирует подключение к другому узлу.По умолчанию параметр отсутствует — кластеризация неактивна. Любое значение допустимо. Подробности настройки и работы кластера — см. п. 3.1.3.

contact_port_low Когда прокси-сервер пересылает запрос REGISTER по адресу регистратора (указывается в теле запроса), прокси определяет контактные данные пользовательского агента и указывает из в модифицированном сообщении REGISTER. Среди контактных данных имеются адрес и UDP-порт. Адрес берётся у интерфейса, указанного в параметре if_outbound, а номер UDP-порта, который берётся из множества[contact_port_low; contact_port_low + urlmap_size].По умолчанию равно 10000.

rtp_timeout Во время разговора прокси-сервер данные RTP- и RTCP– трафиков передаёт от телефона в сторону получателя и от получателя в сторону телефона. Иногда в разговоре могут возникать паузы. Если число секунд паузы превышает число, указанное в этом параметре, освобождаются UDP-порты, задействованные для передачи RTP и RTCP трафика. Не стоит делать этот параметр слишком маленьким, чтобы разговор не мог прерываться из-за кратковременного удержания вызова. Но не стоит его делать и слишком большим, т.к. при массовом пропадании электропитания на телефонах может возникнуть утечка ресурсов – UDP-портов. Восполнение утраченных ресурсов может оказаться неприемлемо затянутым и тогда может случиться, что абоненты иногда не будут слышать друг друга.

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

(rtp_port_low + (urlmap_size * 4)) < contact_port_low;contact_port_low + urlmap_size < 65535;Указанные контрольные соотношения актуальны, если предполагается параметры if_outbound и

if_inbound сделать одинаковыми, т.е. обслуживание запросов телефонов и представление телефонов перед IP-АТС выполнять через один и тот же интерфейс.

3.1.2. Управление работой siproxd

Разрешаем запуск сервиса siproxd при загрузке системы:#rc-update add siproxd default

* service siproxd added to runlevel default

Запустим сервис прямо сейчас:#/etc/init.d/siproxd start* Starting siproxd … [ ok ]

Теперь заходим в меню SIP-телефона, находим в нём поле для указания SIP proxy. Заполняем его адресом того интерфейса съёмника, который указали в параметре if_inbound конфигурационного файла. В качестве транспортного протокола указываем UDP. Сохраняем адрес, перезапускаем SIP-телефон и, если всё сделано правильно, он должен зарегистрироваться. Все последующие звонки с этого телефона звук будет принудительно пропускаться через сетевой интерфейс съёмника, так что у нас появилась возможность получить доступ и к сигнальной, и к звуковой информации.

Если запускать siproxd при загрузке системы нам больше не нужно, запретим это:#rc-update del siproxd default* service siproxd removed from runlevel default

И остановим его прямо сейчас:#/etc/init.d/siproxd stop* Stopping siproxd … [ ok ]

3.1.3. Включаем кластеризацию

Для повышения отказоустойчивости телефонной связи (но не системы записи) можно два съёмника с SIP-прокси связать в кластер. Два узла резервируют друг друга в «горячем» режиме. Переключение трафика между узлами кластеризации должно происходить для пользователя практически незаметно. Однако запись должна прекратиться до тех пор, пока администратор не переставит ключ защиты в узел, ставший активным. Какой узел активный — определяется тем, какой из узлов получил сетевой адрес прокси-сервера, указываемый в настройках телефонных аппаратов. Чтобы при аппаратном отказе активного узла управление трафиком передавалось на резервных. Чтобы восстановившийся узел был способен немедленно перейти в «горячий» резерв и принять на себя нагрузку напарника по части продолжения поддержки голосовых сессий, созданных период как до своего восстановления, так и после.

Для начала нам нужно наладить синхронизацию времени по NTP на обоих узлах, как описано в п. 1.5.

Теперь нам нужно добиться, чтобы один и только один компьютер имел на своём интерфейсе сетевой адрес прокси-сервера. Какой узел получит этот адрес — определяется сервисом ucarp. Его и мы «поднимем».

Сервис ucarp обеспечивает разделение одного IP-адреса между сетевыми интерфейсами разных компьютеров. Настроим его параметры на обоих узлах создаваемого кластера. Откроем файлы /etc/conf.d/ucarp согласно следующей Таблице 17.

Таблица 17: Параметры конфигурации сервиса ucarp


UCARP_INTERFACE Имя сетевого интерфейса, на котором ucarp на данном узле должен прослушивать пакеты с сообщениями о работе парного узла кластера. Оставим его в значении lan0.

UCARP_SOURCEADDRESS IP-адрес сетевого интерфейса, на котором ucarp на данном узле должен прослушивать пакеты с сообщениями о работе парного узла кластера. Перенесём сюда сетевой адрес интерфейса lan0 данного узла.

UCARP_VIRTUAL_ADDRESS Разделяемый узлами кластера IP-адрес регистрации SIP-телефонов.

UCARP_VIRTUAL_PREFIX Сетевая маска для разделяемого узлами кластера IP-адрес регистрации SIP-телефонов.

UCARP_VHID В одной локальной сети может работать до 255 разных кластеров под управлением ucarp. Желательно проконсультироваться с сетевым администратором, чтобы случайно не нарушить работу возможно действующих устройств. Если есть уверенность, что таковых не имеется, параметр можно не менять.


UCARP_PASSFILE Файл паролей, по которому экземпляры ucarp аутентифицируют друг друга. Параметр желательно не менять, но можно поменять пароль в файле /etc/ucarp/ucarp.pass.

UCARP_UPSCRIPT Файл скрипта, который запускается на узле, если согласует с парным узлом, что он должен стать активным узлом. Содержание параметра менять не следует, но можно с осторожностью отредактировать указанный в нём файл, если не устраивает, что адрес кластера присваивается интерфейсу lan0:0.

UCARP_DOWNSCRIPT Файл скрипта, который запускается на узле, если согласует с парным узлом, что он должен стать резервным узлом. Содержание параметра менять не следует, но можно с осторожностью отредактировать указанный в нём файл, если не устраивает, что адрес кластера присваивается интерфейсу lan0:0.

UCARP_OPTS Оставить без изменений. Стоять должно "--shutdown", чтобы запускать скрипт, указанный параметром UCARP_DOWNSCRIPT при остановке сервиса ucarp.

Отредактируем конфигурацию. Запустим на обеих узлах сервис#/etc/init.d/ucarp start* Starting ucarp … [ ok ]

Убедимся, что на одном и только на одном из узлов кластера появился разделяемый адрес регистрации SIP-телефонов, например:# ifconfig lan0:0

lan0:0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500inet 20.1.0.11 netmask 255.255.255.0 broadcast 20.1.0.255ether 00:1c:c0:a3:37:10 txqueuelen 1000 (Ethernet)device interrupt 20 memory 0xe4100000-e4120000

На обоих узлах зададим запуск ucarp при загрузке системы:# rc-update add ucarp default* service ucarp added to runlevel default

Выдернем провод Ethernet из узла - «победителя». Убедимся, что разделяемый адрес регистрации SIP-телефонов переместился на другой узел, который только что был резервным:# ifconfig lan0:0

lan0:0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500inet 20.1.0.11 netmask 255.255.255.0 broadcast 20.1.0.255ether 00:da:b8:f1:56:69 txqueuelen 1000 (Ethernet)device interrupt 20 memory 0xe4100000-e4120000

Вставим обратно провод Ethernet в узел — связь между узлами восстановится.Теперь вернёмся к конфигурационному файлу siproxd.conf. Для совместной работы обоих узлов

кластера надо параметры urlmap_size и rtp_port_low установить одинаковыми. При соединении узлов между собой соответствие этих параметров проверяется и при несоответствии связь разрывается. В поставке для связи узлов в кластере предлагается использовать TCP-порт 2100. Можем проверить, действительно ли узлы соединились:# netstat -antp | grep 2100tcp 0 0 192.168.3.139:58273 192.168.1.43:2100 ESTABLISHED 32/siproxd

Состояние ESTABLISHED указывает, что узлы готовы к совместной работе и шансы на успех у нас максимально велики. Тот из этих узлов, на котором сетевой интерфейс lan0:0 имеет сетевой адрес, считается активным. Попробуем сделать звонок на какого-нибудь абонента. Во время разговора выдернем провод Ethernet из активного узла кластера. В идеале никто из собеседников не заметит прерывания звука. Возможно звук прервётся на несколько секунд – основным виновником будет задержка обновления элемента таблицы ARP на телефонном аппарате. Но не исключено, что звук совсем прервётся из-за отсутствия предусмотренного протоколом ARP обновления.

3.2. Проксирование телефонов с сигнализацией SCCP/SKINNY фирмы Cisco

Для телефонов фирмы Cisco, взаимодействующих с IP-АТС Call Manager и аналогами по фирменному протоколу SCCP (Skinny Client Control Protocol) мы можем задействовать прокси-сервер skinny_proxy.

3.2.1. Конфигурируем skinny_proxy

В каталоге /usr/local/opt/iptel/etc есть XML-подобный файл skinny_proxy.conf. Откроем его. Выглядит он примерно так:

<skinny_proxy> log_path = /var/log/iptel

rtp_start = 16384rtp_end = 32000bind = lan0cm_bind = lan0call_manager = 20.1.0.9real_tftp_server = 192.168.1.3tftp_rewrite_cm_address = 1

</skinny_proxy>Смысл параметров описан в Таблице 18.

Таблица 18: Основные параметры конфигурации сервиса skinny_proxy


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

rtp_start Начало диапазона номеров UDP-портов, которые будут выделяться для приёма-передачи RTP- и RTCP-трафиков между проксируемым телефоном и другими VoIP-устройствами. Рекомендуется использовать значение 16384, оно же установлено по умолчанию.

rtp_end Конец диапазона номеров UDP-портов, которые будут выделяться для приёма-передачи RTP- и RTCP-трафиков между проксируемым телефоном и другими VoIP-устройствами.На каждый телефон будет использоваться по 4 номера портов: 2 чётных и 2 нечётных. Значение по умолчанию 32767. В текущем примере skinny_proxy может управлять (32000-16384) / 4 = 1952 телефонами.

bind Обозначает имя сетевого интерфейса или IP-адрес, который skinny_proxy должен прослушивать в ожидании TCP- и TFTP-запросов от телефонных аппаратов. Именно этот адрес (адрес этого интерфейса) должен быть внесён в качестве TFTP-сервера (см. п. 3.2.2).

cm_bind Необязательный параметр. Можно использовать, если на компьютере имеется несколько сетевых интерфейсов и мы желаем, чтобы skinny_proxy инициировал соединение к CallManager не с того адреса, который указан в параметре bind, а с другого. Этим параметром адрес и определим при желании. Одна их причин, использования данного параметра – желание избегать повторной записи разговора от станционного плеча. Впрочем, сейчас есть и другой способ экономии числа используемых лицензий.

call_manager Значение кажется самоочевидным. Да-да, адрес настоящего CallManager. Их может быть несколько штук. Сначала прокси будет пытаться всё время использовать первый указанный CallManager, затем при недоступности первого – второй и т.д. И так будет по циклу перебирать.

real_tftp_server Ещё один Капитан Очевидность. Именно с этого IP-адреса будут браться TFTP-файлы по запросу телефонов. Так же, как в случае с параметром call_manager, может указываться неоднократно. TFTP-сервера так же будут перебираться - при недоступности очередного будет браться следующий и так по циклу.

tftp_rewrite_cm_address Указывает, должен ли прокси сервер обязательно вносить изменения в конфигурационные файлы всех телефонов с целью заставить работать через себя (ненулевое значение), или в конфигурационные файлы только некоторых телефонов, которые будут указываться со стороны Phobos Server (нулевое значение). По умолчанию равно 1, т.е. все телефоны, запросившие конфигурационный файл через skinny_proxy, будут принуждаться к подключению к CallManager через прокси.

3.2.2. Управление работой skinny_proxy

Разрешаем запуск сервиса skinny_proxy при загрузке системы:

#rc-update add skinny_proxy default* service skinny_proxy added to runlevel default

Запустим сервис прямо сейчас:#/etc/init.d/skinny_proxy start* Starting skinny_proxy … [ ok ]

Теперь простейший способ заставить телефон работать через прокси. Находим в нём адрес TFTP-сервера. Внесём в это поле адрес интерфейса прокси-сервера, который соответствует назначенному параметром bind в файле skinny_proxy.conf. Сохраняем настройки телефона, перезагружаем телефон. Он должен будет запросить у skinny_proxy свой конфигурационный файл SEP<mac-адрес>.cnf.xml. Skinny_proxy скачает этот файл с одного из TFTP-серверов, перечисленных в параметрах real_tftp_server. Далее этот файл skinny_proxy модифицирует или не модифицирует в соответствии с политикой (см. ниже). Если модифицирует, то в нём все перечисленные адреса сервера CallManager будут подменены на адрес интерфейса, указанного в параметре bind, что гарантирует, что телефон своим CallManager будет считать прокси. А прокси, в свою очередь, подключится к CallManager от имени телефона. Если skinny_proxy не модифицирует файл конфигурации телефона, телефон подключается к CallManager как обычно.

Политика модификации адресов CallManager в файлах SEP<mac-адрес>.cnf.xml следующая. Если параметр tftp_rewrite_cm_address в файле skinny_proxy.conf ненулевой, то адрес CallManager переписывается обязательно, причём все его упоминания. Если параметр tftp_rewrite_cm_address в файле skinny_proxy.conf нулевой, то адреса CallManager не будут переписываться, за исключением случаев обращения телефонов с теми MAC-адресами, которые были указаны через Менеджер Заданий системы Vocord Phobos.

Проверить, правильно ли мы научились подключать телефоны через прокси-сервер можно примерно так:#netstat -ant | grep 2000 | grep ESTABtcp 0 0 192.168.1.43:2000 192.168.0.65:51288 ESTABLISHEDtcp 0 0 192.168.1.254:2000 192.168.1.43:56785 ESTABLISHED

Одному телефонному аппарату должно соответствовать 2 TCP-соединения прокси-сервера по порту 2000: абонентское плечо и станционное плечо. Теперь можно сделать пробный звонок. Есть слышимость есть – задача решена.

Если же мы отказались от идеи использовать skinny_proxy, можем запретить#rc-update del skinny_proxy default* service skinny_proxy removed from runlevel default

и остановить сервис прямо сейчас:#/etc/init.d/skinny_proxy stop* Stopping skinny_proxy … [ ok ]

3.2.3. Включаем резервирование

Прочитаем п. 3.1.3 про ucarp - сервис разделения одного IP-адреса между несколькими компьютерами. Ucarp должен перебросить на запасной узел адрес, на который подключаются телефоны. Телефоны подключатся заново через запасной прокси-сервер. Голосовые соединения при отказе активного узла разорвутся. Телефонам придётся восстанавливать связь с IP-АТС заново. Попробуем построить систему с резервированием. Пусть для нашего примера адрес, на который подключаются телефоны, будет снова 20.1.0.11. На обоих съёмниках скорректируем конфигурацию:

bind = 0.0.0.0Здесь мы указываем skinny_proxy принимать соединения на всех доступных адресах. Он и будет

принимать, в том числе на адресе 20.1.0.11, если таковой у него появился на интерфейсе lan0:0 благодаря ucarp. Запускаем ucarp и skinny_proxy на обоих съёмниках. Дожидаемся регистрации телефона. Делаем пробный короткий вызов на другой телефон. Находим съёмник, через который зарегистрировался телефон. Для этого ищем, на каком из съёмников на интерфейсе lan0:0 поднят IP-адрес 20.1.0.11:#ifconfig lan0:0lan0:0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 20.1.0.11 netmask 255.255.255.0 broadcast 20.1.0.255 ether 00:1c:c0:a3:37:10 txqueuelen 1000 (Ethernet) device interrupt 20 memory 0xe4100000-e4120000

На примере выделено жирным шрифтом. Из этого съёмника и выдергиваем провод Ethernet. Не позднее, чем через несколько минут телефон должен перерегистрироваться через skinny_proxy другого съёмника.

3.3. Проксирование телефонов с сигнализацией UNISTIM

С IP-АТС CS-1000, которые производились в разное время компаниями Nortel, LG и Avaya, телефоны могут взаимодействовать по фирменному протоколу UNISTIM через сервис unistim_proxy. Телефоны можно переконфигурировать, в частности, если войти в меню при включении питания. В меню есть параметры, определяющие адреса и порты серверов S0 и S1.

3.3.1. Конфигурируем unistim_proxy

Конфигурацию удобнее рассмотреть на учебном примере:<unistim_proxy> listen_phones = 20.1.0.11:4100 phones_rtp_base = 8000 phones_failover = 0 log_path = /var/log/iptel/ <server> port = 4100 address = 20.1.0.9 </server> <public_interface> bind = 20.1.0.11:6000 </public_interface># <public_interface># bind = 20.1.0.14:6000# </public_interface></unistim_proxy> Изначальная идея была в том, что unistim_proxy объективно скрывает от IP-АТС истинные адреса

телефонов. Разработчик, проанализировав архитектуру протокола Unistim и идеологию взаимодействия между IP-АТС и телефонами, пришел к промежуточным выводам:

что IP-АТС «видит» не настоящие телефоны, а только прокси-сервер, мимикрирующий под телефоны;

что нельзя допускать, чтобы с одного IP-адреса шло взаимодействие с IP-АТС от имени разных телефонов.

В общем, у телефонов не должны повторяться IP-адреса. Сравните с описанием siproxd в подразделе 3.1: ничего подобного там не говорится. Так что перед установкой unistim_proxy надо затребовать у сетевого администратора столько дополнительных IP-адресов, сколько телефонных аппаратов хотим проксировать.

Собственно конфигурация описывается в XML-подобном файле /usr/local/opt/iptel/etc/ unistim_proxy.conf. Основной узел имеет имя < unistim_proxy>, его содержание – см. Таблицу 19.

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

Таблица 19: Основные параметры конфигурации сервиса unistim_proxy



listen_phones Обязательный параметр. Характеризует IP-адрес и UDP-порт, на которых прокси будет прослушивать телефонные аппараты. Указывается в виде:<IP-адрес>[:[port]], или в виде:<Имя_субинтерфейса>[:[port]]


По умолчанию порт равен 4100.Например, допустимыми выражениями могут быть:20.1.0.11:4100 – адрес 20.1.0.11, порт 410020.1.0.11: – адрес 20.1.0.11, порт 4100lan0:0:5100 – адрес на субинтерфейсе lan0:0, порт 5100Но недопустимо:lan0:4100, т.к. непонятно, что имеется ввиду: 4100-й субинтерфейс интерфейса lan0 или порт 4100 и IP-адрес интерфейса lan0;0.0.0.0 – обобщённое множество всех сетевых адресов узла не поддерживается.

phones_rtp_base Необязательный параметр, который определяет начальный номер UDP-порта для обмена RTP-трафиком с подключенным телефоном во время разговора. Должен быть чётным, более 1024. По умолчанию равен 8000. Unistim_proxy на время своей работы будет задействует множество[phones_rtp_base; phones_rtp_base + <число_обслужив_телефонов> * 2] номеров UDP-портов на интерфейсе, к которому подключаются телефоны. Интерфейс определяется параметром listen_phones.

phones_failover Параметр необязателен. Когда unistim_proxy завершает свою работу (например, при перезагрузке системы съёмника), он может рассылать сообщения подключенным телефонам, в которых предлагает переключиться на конкретный другой сервер. Если параметр равен 0, то прокси предложит переключиться на так называемый сервер S1 из конфигурации телефона, т.е. на самого себя. Если прокси у нас пока только один и мы нас не волнует отказоустойчивость, лучше указать 0. Подробности см. в п. Error:Reference source not found

<server> address port</server>

Узел параметров, посвящённый описанию сетевого доступа к IP-АТС или Node.address означает IP-адрес IP-АТС или Node, port – номер UDP-порта. Узнать можно у администратора IP-АТС. Параметр address обязателен в рамках узла server, а параметр port по умолчанию равен 5100. Хотя бы один узел server должен быть описан в конфигурации.Прокси по возможности старается подключаться с одному и тому же адресу IP-АТС или Node. При недоступности одного из адресов IP-АТС или Node прокси-сервер пытается использовать другой из перечисленных адресов. И так по кругу.

<public_interface> bind=</public_interface>

Описывает объекты, каждый из которых описывает, как видится один телефон со стороны IP-АТС. То, как unistim_proxy скрывает от IP-АТС телефоны, описывают параметры listen_phones и phones_rtp_base. Внутренний параметр bind указывает IP-адрес и номер UDP-порта, от имени которых будет вестись обмен сигнальными сообщениями с IP-ATC. Форматы:<IP-адрес>:<port>, или в виде:<Имя_субинтерфейса>:<port>Примеры допустимых выражений для bind:20.1.0.11:6000 – привязка к адресу 20.1.0.11 и порту 6000lan0:3:6000 – привязка к адресу, который закреплён за интерфейсом lan0:3 и к порту 6000.Сколько телефонов предполагается проксировать, столько узлов public_interface должно быть указано в конфигурации. Не допускается назначать привязку на занятые адреса и порты. В случае несоблюдения этого требования в файл логов выводятся диагностические сообщения, а программа завершается.

3.3.2. Вопросы запуска unistim_proxy

Разрешаем запуск сервиса skinny_proxy при загрузке системы:#rc-update add unistim_proxy default* service unistim _proxy added to runlevel default

Запустим сервис прямо сейчас:#/etc/init.d/unistim_proxy start* Starting unistim_proxy … [ ok ]

Войдём в меню телефона. В качестве параметров «IP S1» и «IP S2» вводим адрес сетевого интерфейса lan0 на съёмнике. В качестве параметров «Порт S1» и «Порт S2» указываем 4100. S1 и S2 – наборы сетевых параметров (адрес и порт) для подключения телефонов к IP-АТС.

Сохраняем изменённые настройки, перезагружаем телефон. Если всё сделали правильно, телефон зарегистрируется. Сделаем звонок в город или на мобильник – должна быть слышимость.

Если мы вообще передумали использовать unistim_proxy запретим его работу вообще:#rc-update del unistim_proxy default* service unistim_proxy removed from runlevel default

И остановим его прямо сейчас:#/etc/init.d/unistim_proxy stop* Stopping unistim_proxy … [ ok ]

3.3.3. Повышаем отказоустойчивость

Телефоны имеют внутренние настройки, описывающие механизм поиска узла IP-АТС, к которому надо подключиться. Среди них:

адреса и порты серверов S1, S2, …; число попыток присоединения к очередному серверу перед принятием решения о поиске

нового сервера.На случай аппаратного или программного сбоя мы можем предусмотреть:

переключение на один из узлов «настоящей» IP-АТС; переключение на работу через запасной прокси-сервер.

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

3.3.3.1. Резервирование через IP-АТС или Node

Переконфигурируем телефон так. В качестве сервера S2 укажем адрес и порт IP-АТС или Node. Установим не слишком больное число попыток подключения к серверу S1. Сохраним настройки телефона, перезагрузим его. Телефон должен зарегистрироваться через прокси. Сделаем пробный вызов. Во время разговора выдернем провод Ethernet из съёмника. Испытание считается успешным, если телефон перерегистрировался на IP-ATC.

3.3.3.2. Резервирование через запасной прокси

Создадим второй прокси-сервер в той же сети, что и первый. Потребуется удвоенное количество IP-адресов. Особенности конфигураций прокси-серверов: В первом укажем phones_failover=0, во втором укажем phones_failover=1.

Переконфигурируем телефон так. В качестве сервера S1 укажем адрес и порт, как listen_phones первого прокси-сервера. В качестве сервера S2 укажем адрес и порт, как listen_phones второго прокси-сервера. Сохраним настройки телефона, перезагрузим его. Телефон должен зарегистрироваться через первый прокси.

Сделаем пробный вызов. Во время разговора выдернем провод Ethernet из съёмника. Испытание считается успешным, если телефон перерегистрировался через второй прокси (можно косвенно проверить по содержанию файла логов второго съёмника). Вставим провод Ethernet обратно в первый съёмник.

Сделаем ещё один звонок. Во время разговора отправим в перезагрузку второй съёмник. Разговор должен прекратиться. Испытание считается успешным, если телефон в течение 1 минуты перерегистрировался на первом съёмнике (можно косвенно проверить по содержанию файла логов первого съёмника).

3.4. Проксирование телефонов с сигнализацией HFA/CornetIP фирмы Siemens

Этот подраздел актуален для HFA-телефонов, использующих протокол H.323 для управления голосовыми сессиями. Новые HFA-телефоны могут не использовать протокол H.323 и на них описанное не распространяется.

3.4.1. Конфигурируем cornet_proxy

В каталоге /usr/local/opt/iptel/etc есть файл siemens_proxy.conf. Откроем его. Что мы видим? Нечто похожее на XML, выглядит он примерно так:

<cornet_proxy>log_path = /var/log/iptelreal_pbx_address = 192.168.200.251rtp_start = 16384listen = lan0cornet = lan0:0cornet = lan0:1

</cornet_proxy>Назначение параметров сведено в Таблицу 20.

Таблица 20: Основные параметры конфигурации сервиса cornet_proxy



rtp_start Начало диапазона номеров UDP-портов, которые будут выделяться для приёма-передачи RTP- и RTCP-трафиков между проксируемым телефоном и другими VoIP-устройствами. Рекомендуется использовать значение 16384, оно же установлено по умолчанию. На каждый телефон будет выделяться по 4 номера портов: по 2 чётных (RTP) и по 2 нечётных (RTCP). Нетрудно подсчитать, что при значении параметра «по умолчанию» имеется ресурс номеров портов для более чем 12 тысяч телефонных аппаратов.

real_pbx_address Обязательный параметр, описывает адрес настоящего сервера IP-АТС. Должен совпадать со значением адреса сервера из настроек телефона до того, как мы его изменим.

listen Обязательный параметр. Обозначает IP-адрес, на котором прокси будет прослушивать запросы от телефонных аппаратов. Указывается в виде:<IP-адрес><Имя_субинтерфейса>Например:lan0192.168.0.250

cornet Сколько телефонов предполагается проксировать, столько раз должен быть употреблён этот параметр, означающий имя сетевого интерфейса, IP-адрес которого прокси будет использовать, представляя телефон перед IP-АТС. Допускается также указывать и IP-адрес.Не допускается повторов значений параметра, нельзя допускать, чтобы явно или косвенно выражаемый адрес подразумевал повторное использование этого адреса в другом экземпляре параметра. Так, например, нельзя указывать:сornet = lan0:10сornet = lan0:10Также нельзя:сornet = 10.0.0.4сornet = 10.0.0.4Также, если интерфейс lan0:10 имеет адрес 10.0.0.4, нельзя:сornet = 10.0.0.4сornet = lan0:10

3.4.2. По поводу запуска cornet_proxy

Разрешаем запуск сервиса cornet_proxy при загрузке системы:#rc-update add cornet_proxy default* service cornet_proxy added to runlevel default

Запустим сервис прямо сейчас:#/etc/init.d/cornet_proxy start* Starting cornet_proxy … [ ok ]

Войдём в меню телефона. В качестве параметр «Server Address» вводим адрес, соответствующий параметру listen в файле конфигурации.Сохраняем изменённые настройки, перезагружаем телефон. Если всё сделали правильно, телефон зарегистрируется. Сделаем звонок в город или на мобильник – должна быть слышимость.Если мы вообще передумали использовать cornet_proxy запретим его работу вообще:#rc-update del cornet_proxy default* service cornet_proxy removed from runlevel defaultДа остановим прямо сейчас:#/etc/init.d/cornet_proxy stop* Stopping cornet_proxy … [ ok ]

3.4.3. Вопрос резервирования

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

3.5. Начинаем записывать звонки через прокси-сервер

Изначально сниффер настроен на ввод данных через сетевой интерфейс lan1. Однако прокси-сервер настроен на работу через lan0. Вывод: сниффер не видит трафика. Откроем ему глаза. Найдём в файле iptel.conf описание источника данных:

<eth_if> name = lan1 </eth_if>Простейшее исправление:<eth_if> name = lan0 </eth_if>Перезапускаем съёмник:

#reboot

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

записи с одинаковыми атрибутами. Это может быть объяснено наличием двух плеч у вызова: телефон-прокси и прокси-АТС. Двойная запись означает двойной расход ресурсов: памяти, лицензий. Теперь самое время избавиться от лишних расходов. В числе конфигурационных параметров модулей декодеров протоколов есть такие, с помощью которых мы можем «попросить» декодер «не замечать» сигнальный трафик с участием определённых IP-адресов. Будет логично, если мы заставим декодер игнорировать трафик, в котором адресатом или отправителем будет IP-АТС. В Таблице 21 приведена сводка параметров, которые позволяют игнорировать отдельные IP-адреса в декодерах разных протоколов.

Таблица 21: Параметры для игнорирования IP-адресов для разных протокольных декодеров

Декодер Название параметра

sip_dec.so ignore_ip

h323_dec -x <IP-адрес>

skinny_dec.so ignore_cm

unistim_dec.so ignore_ip

4. Поддержка систем сетевого управления

Сколько разговоров сейчас пишется? Нет ли обрыва SPAN-сессии? – вот какими вопросами задастся рачительный администратор, запустив Phobos Iptel. Разработчики подготовили кое-что ему в помощь. В каталоге /usr/local/opt/iptel/share/mib находится описание объектов базы управляющей информации – файл NET-SNMP-VOCORD-IPTEL-MIB.txt.

Вероятно, наиболее интересными величинами базы будут:

nsviCurrentCallsRecorded; nsviCurrentSessionsRecorded.

При всей смысловой схожести внутренних частей названий между переменными есть разница. За nsviCurrentCallsRecorded отвечает модуль связи с Phobos ipc_server. За nsviCurrentSessionsRecorded отвечает менеджер атрибутов. Попробуем отследить разницу между компетенциями менеджера атрибутов и модулями связи с Phobos по части подсчёта сессий:

Менеджер атрибутов знает, сколько звонков должно записываться на Phobos согласно присланным правилам отбора. Модуль связи с Phobos знает, сколько звонков реально записывается на Phobos.

Всегда справедливо неравенство:nsviCurrentCallsRecorded <= nsviCurrentSessionsRecordedВ идеале эти переменные равны. Но при разрыве соединений между ipc_server и Phobos

переменная nsviCurrentCallsRecorded становится равной 0. При восстановлении связи с Phobos nsviCurrentCallsRecorded начинает увеличиваться вплоть до сравнения с величиной nsviCurrentSessionsRecorded. На переменную nsviCurrentSessionsRecorded разрыв или восстановление связи с Phobos влияния не оказывает, т.к. в Менеджер Атрибутов не знает ничего о потере связи с Phobos.

Можно сделать вывод, что если администратору важнее отслеживать точный расход лицензий, ему лучше отслеживать переменную nsviCurrentSessionsRecorded, а если важнее компромисс между количеством лицензий и непрерывностью записи разговоров, то лучше отслеживать nsviCurrentCallsRecorded.

Выбрав приоритет, можем теперь запустить поддержку SNMP в выбранном модуле или в обоих одновременно. Менеджер атрибутов можно заставить отвечать на SNMP-запросы, если указать в его конфигурации параметр use_snmpd=1. Модуль связи с Phobos можно заставить отвечать на SNMP-запросы, если в файле /etc/init.d/ipc_server указать параметр –S1 в командной строке запуска программы ipc_server.

Указав нужные параметры, включим автоматический запуск сервиса snmpd при загрузке системы и перезагрузим систему:# rc-update add snmpd default# reboot

Попробуем запросить по SNMP интересующие значения переменных, например:# snmpget -v 1 -c public localhost .1.3.6.1.4.1.8072.2.19.1.10230.1NET-SNMP-EXAMPLES-MIB::netSnmpExamples.19.1.10230.1 = Counter32: 1# snmpget -v 1 -c public localhost .1.3.6.1.4.1.8072.2.19.1.2147483646.1NET-SNMP-EXAMPLES-MIB::netSnmpExamples.19.1.2147483646.1 = Counter32: 1

Documents

Iptel длчайников.docx