Ключевые слова:voip, zaptel, asterisk, (найти похожие документы)
From: Хелик Михаил <mixel.net{at}gmail.com>
Date: Mon, 3 Sep 2006 14:31:37 +0000 (UTC)
Subject: Построение TDM access сервера на базе open-source технологий.
Copyright (C) 2006 Хелик Михаил mixel.net{at}gmail.com
Публикация данного материала допускается только с указанием имени
автора и ссылки на оригинальную статью http://quasar.sourceforge.net/articles/zaptel_router.html
Обычно подсистему Zaptel справедливо рассматривают как низкоуровневую
часть open source проекта Asterisk. Однако кроме передачи голосовых и
сигнализационных данных с интерфейсов цифровых и аналоговых телефонных
линий связи в высокоуровневую часть Asterisk, zaptel предоставляет ряд
возможностей, позволяющих рассматривать его в качестве программного
ядра сервера доступа к TDM каналам. С помощью Zaptel можно
использовать таймслоты TDM потоков для передачи данных с инкапсуляцией
в HDLC или PPP протоколы.
По мере развития проекта Asterisk появляется всё большее количество
относительно недорогих устройств с интерфейсами E1, имеющих поддержку
работы с zaptel. При использовании Zaptel, open source коллектора
статистики типа ipcad и недорогой интерфейсной платы может быть
создана система более дешёвая, чем устройства с аналогичными
параметрами от известных брендов.
Подсистема Zaptel имеет модульную архитектуру. Ядро системы - модуль
zaptel.ko, предоставляющий интерфейс для стыковки остальных модулей,
отвечающих за взаимодействие с аппаратной частью.
Несколько слов об устройствах, которые можно использовать совместно с
zaptel для создания access сервера. На данный момент существует два
класса таких устройств. Наиболее распространены интерфейсные платы с
одним или несколькими TDM портами, подключаемые к PCI шине, типичные
представители - плата производства Digium TE410P или Quasar от
Parabel. Другой класс - это внешнее оборудование, подключаемое к
серверу по Ethernet, например: RedFone Communications foneBridge.
Такие устройства являются конверторами TDM потока в Ethernet. Сервер и
конвертор обмениваются Ethernet пакетами с данными, используя
несложный протокол, реализующий концепцию TDMoE. В сетевом стеке
сервера эти пакеты перехватываются модулем ztd-eth.ko и передаются для
обработки модулю ztdynamic.ko, который в свою очередь стыкуется с
zaptel.ko. В терминах Zaptel интерфейсы, подключенные через
ztdynamic.ko, называются dynamic spans.
Постоянно дополняемый список zaptel совместимых устройств можно найти
на странице http://voip-info.org/wiki/view/Asterisk+hardware
Перейдём к практической части нашей статьи. Здесь нами будет показано,
как сконфигурировать Zaptel для работы с интерфейсной платой и создать
hdlc интерфейсы для передачи данных в заданных таймслотах. Автор
использовал Debian Etch систему с ядром 2.6.15, восьмиканальную
интерфейсную плату Quasar производства Parabel, svn\trunk версию
zaptel.
Предпочтительно использовать свежую версии zaptel из svn, получаемую
по команде:
svn checkout http://svn.digium.com/svn/zaptel/trunk zaptel
Для создания с помощью zaptel сетевых hdlc интерфейсов, необходимо
перед компиляцией проекта найти и раскомментировать в файле zconfig.h
строку:
#define CONFIG_ZAPATA_NET
После этого как обычно выполняются в каталоге с исходными текстами
make и make install.
Далее собирается zaptel драйвер для интерфейсной платы. Драйвера для
плат Digium находятся в директории с кодом проекта и собираются вместе
с zaptel. Исходный код драйвера для платы Quasar скачивается с сайта
проекта http://quasar.sourceforge.net , компилируется и устанавливается
совместно с zaptel согласно инструкции.
Теперь загружаем драйвер.
modprobe qua-zap
При помощи команды lsmod убеждаемся, что также произошла загрузка
модулей zaptel, hdlc, crc_ccitt и т.д.
Теперь приступаем к конфигурации.
Для конфигурации zaptel используется конфигурационный файл
zaptel.conf, который по умолчанию находится в /etc директории.
Предварительно необходимо создать или отредактировать этот файл. В
данной статье нами не будут рассматриваться опции zaptel.conf,
используемые для работы с голосовыми данными.
Прежде чем описывать синтаксис конфигурационного файла, дожна быть
оговорена система нумерации TDM интерфейсов (spans) и таймслотов
(zaptel channels), принятая в Zaptel.
TDM интерфейсы нумеруются последовательно с единицы. Если в системе
присутствует несколько zaptel устройств, то интерфейсы устройства,
зарегистрированного ранее, имеют номера меньшие, чем интерфейсы
последующих, зарегистрированных для работы с zaptel устройств.
Zaptel channels нумеруются по правилу, аналогичному для spans,
последовательно с единицы с возрастанием по мере увеличения номера
интерфейса. Для иллюстрации правил нумерации рассмотрим систему, в
которой установлены две интерфейсные платы Quasar c восьмью E1
каналами.
Таблица соответствия Канал zaptel/span - Номер Платы/Номер интерфейса/номер таймслота.
---------------------------------------------------------------------------
Номер zaptel | Номер span. | Номер | Номер E1 | Номер таймслота |
канала. | | интерфейсной | интерфейса | E1 интерфейса |
| | платы | на плате. | |
---------------------------------------------------------------------------
1 1 1 1 1
31 1 1 1 31
32 2 1 2 1
... ... ... ... ...
248 8 1 8 31
249 9 2 1 1
... ... ... ... ...
496 16 2 8 31
Примечание: Доступ к нулевому таймслоту E1 не предусмотрен.
Синтаксис:
Строки, начинающиеся с #, игнорируются конфигуратором.
В первую очередь описываются параметры E1 интерфейсов:
span=<span num>,<timing>,<LBO>,<framing>,<coding> [, optional ]
- span num
номер E1 канала в соответствии с соглашением;
- timing
при передаче отличного от нуля значения в данном параметре,
будет разрешено использовать сигналы с данного E1 интерфейса для
синхронизации внутренней частоты платы. Для плат Digium чем меньше
передаваемая цифра, тем выше приоритет источника синхронизации. Для
используемой платы Quasar Parabel при разрешении синхронизироваться от
нескольких E1 интерфейсов плата синхронизируется с интерфейсом,
имеющим меньший номер. В случае неполадок на данном интерфейсе плата
автоматически пересинхронизируется со следующим разрешённым
интерфейсом, имеющим меньший номер.
- LBO (line build out)
это параметр, в платах Digium использующийся для указания параметров
линии. Допустимые значения можно найти в файле zaptel.conf.sample.
Для плат Parabel Quasar значения данного параметра игнорируются. E1
фреймеры автоматически определяют оптимальные параметры для
передачи.
- Framing
в случае E1 допустимые значения cas и ccs, при передаче
параметра cas 16 таймслот данного E1 интерфейса будет использован как
выделенный сигнальный канал, с помощью которого передаются значения
четвёрки ABCD битов для каждого из оставшихся таймслотов. Чтобы
использовать 16 таймслот для передачи данных, необходимо передать
значение cсs
- Coding
в случае E1 допустимые значения: ami, hdb3.
- Optional
данный параметр является опциональным и может
использоваться для включения CRC4 мультифрейма на данном
E1 интерфейсе, для чего необходимо передать значение crc4.
Допустимые значения некоторых параметров таких, как framing, coding
могут различаться для интерфейсных плат. Например, некоторые платы не
поддерживают ami кодирование, чего нельзя оставить без внимания при
выборе платы.
После того как E1 интерфейсы сконфигурированы, можно приступать к
конфигурации таймслотов (таймслоты в терминах zaptel каналов):
<device> = <channel list>[:options]
channel list - список каналов, в списке могут использоваться символы
"-", "," и ":".
Допустимые значения device:
- nethdlc
объединить таймслоты перечисленные channel list в hdlc
канал. В качестве параметра можно передать имя, которое получит данный
сетевой интерфейс;
- clear
объединить таймслоты, перечисленные в channel list в
неструктурированный поток данных, данный режим может использоваться
для передачи потока на обработку в PPP стек;
- unused
таймслоты, перечисленные в channel list, не используются;
- dacs
коммутация таймслотов, перечисленных в channel list до символа
":" в таймслоты начиная с первого после двоеточия.
Пример: dacs=1-20:45
В приведённом примере канал один будет коммутирован с каналом 45,
канал 2 с 46 и т.д.
Данная функция может поддерживаться не всеми интерфейсными платами.
- dacsrbs
коммутация таймслотов с учётом поканальной сигнализации.
Будем использовать zaptel.conf следующего содержания:
#Конфигурируем первый E1 интерфейс, разрешаем использовать сигнал с
него для #синхронизатора платы, выключаем ccs мультифрейм,
устанавливаем тип кодирования #сигнала hdb3, включаем проверку crc4.
span=1,1,0,ccs,hdb3,crc4
#Конфигурируем второй E1 интерфейс:
span=2,0,0,ccs,ami,crc4
#Переходим к назначению таймслотов:
#Cобираем в hdlc интерфейс pri-hdlc таймслоты первого E1 канала.
nethdlc=1-31:pri-hdlc
#Собираем в hdlc интерфейс sec-hdlc 1,2,5 таймслоты второго E1 интерфейса.
nethdlc=32,33,36:sec-hdlc
#Остальные тайслоты второго E1 интерфейса не используются, хотя можно
#это и не указывать:
unused=34,35,37-62
Если все необходимые модули загружены, файлы устройств, необходимые
для конфигурации Zaptel (располагаются в /dev/zap) созданы, файл
zaptel.conf не содержит ошибок, то после выполнения команды
#ztcfg
система Zaptel должна успешно стартовать. Для того чтобы убедиться в
этом выполняем несколько раз команду cat /proc/interrupts : плата
должна генерировать тысячу прерываний в секунду. Плата Quasar в списке
источников прерываний значится, как e1_N, где N порядковый номер платы
в системе в соответствии с позицией на PCI шине.
Теперь выполняем команду
#ifconfig -a
После чего видим два новых hdlc интерфейса pri-hdlc, sec-hdlc.
Для настройки этих интерфейсов нужно использовать утилиту sethdlc.
Пример:
sethdlc pri-hdlc cisco
sethdlc sec-hdlc hdlc
ifconfig pri-hdlc 10.0.0.1 pointopoint 10.0.0.2
ifconfig sec-hdlc 10.0.0.3 pointopoint 10.0.0.4
ifconfig
В результате:
pri-hdlc Link encap:(Cisco)-HDLC
inet addr:10.0.0.1 P-t-P:10.0.0.2 Mask:255.255.255.255
UP POINTOPOINT NOARP MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:60 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:50
RX bytes:0 (0.0 b) TX bytes:1440 (1.4 KiB)
sec-hdlc Link encap:UNSPEC HWaddr
00-00-FF-FF-FF-FF-00-00-00-00-00-00-00-00-00-00
inet addr:10.0.0.3 P-t-P:10.0.0.4 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:50
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Если устройства на другом конце линий сконфигурированы верно, то можно
устанавливать соединение и тестировать линию связи.
Поговорим о проблемах, которые могут возникнуть:
> ztcfg возвращает сообщения об ошибках.
Ещё раз проверяем содержимое zaptel.conf, убеждаемся в том, что
отсутствуют синтаксические ошибки в конфигурации и что zaptel был
скомпилирован с опцией CONFIG_ZAPATA_NET. Проверяем наличие
специальных файлов устройств, необходимых для конфигурации Zaptel в
директории /dev/zap.
> После выполнения ztcfg компьютер завис.
Такое может случиться на машине с медленным процессором, поскольку при
запуске нескольких E1 каналов в некоторых конфигурациях может
потребоваться достаточно много ресурсов.
> Связь установлена, однако линия нестабильна, счётчик ошибок на hdlc
> интерфейсе периодически инкрементируется.
Наличие ошибок может быть связано с потерей данных из-за задержек на
PCI шине или из-за отключения какой-либо подсистемой ядра на
относительно длительный период обработки прерываний.
Для минимизации задержек на PCI шине можно предпринять следующее:
Назначить интерфейсной плате выделенное прерывание на PCI шине с
помощью, например, настроек BIOS, отключения неиспользуемых устройств
и выбора PCI слота. Снизить загрузку PCI шины со стороны HDD
устройств, например, разместить ОС на RAMDISK и отказаться от HDD.
На production сервере обязательно отключение системы Xfree.
Кроме того, такая ситуация может возникнуть из-за отсутствия
синхронизации на E1 линии, следует проверить конфигурацию master-slave
на E1.
На системе автора с двумя восьмиканальными E1 платами после отключения
"X-ов" ошибки не наблюдались. Тестирование проводилось при
интенсивном обмене данными на двух Ethernet интерфейсах.
>"На production сервере обязательно отключение системы Xfree."
>why?!!
Есть большая вероятность, что какой-либо из драйверов отнясящийся подсистеме X сервера на длительное время отключит прерывания, соответсвенно потеряете несколько кадров. Например, при переходе из консольного режима в графический или обратно, данные теряются почти 100%.
