Защита от DOS атак.
Как известно, каждый повар готовит борщ по-своему, и следуя этому утверждению, ниже приводится всего лишь один из рецептов настройки оборудования Acme Packet.
Некоторые из приведенных параметров не относятся напрямую к системе защиты, но приведены в описании просто потому, что эти параметры требовали изучения, проверки
и корректировки.
Итак, если вы купили пакет DDOS, то у вас появляется возможность настраивать защитные механизмы системы Acme Packet.
В системе Acme Packet можно найти следующие ограничения:
- системные ограничения - максимальное число сообщений в секунду, которое может обработать система;
- максимальная длина SIP пакета;
- максимальная длина UDP пакета;
- ограничения по IP адресам и портам;
- ограничения по протоколам;
- ограничения полезного трафика (основаны на понятиях trusted and untrusted traffic).
Мы не будем следовать этому перечислению, а пойдем по пути, который предлагает SD.
Уровень SIP Config
Ограничения на длину пакета:
sip-message-len = 2000
max-udp-length = 2000
Название параметров говорит само за себя, параметр max-udp-length изменяется в поле option.
Уровень Session Agent
Ограничение на количество сессий, налагаемое на конкретное устройство.
max-sessions = 8 - количество сессий для 8-портового шлюза, равно количеству портов на шлюзе
Для контроля за колличеством сессий нужно включить опцию:
constraints enabled
Уровень Media Manager
Если на SBC включена возможность приема ICMP пакетов, то на уровне Media Manager существует системное ограничение в 8Kbs.
max-signaling-bandwidth = 1720000 - максимальное количество сообщений, которое сможет обработать SD, значение приведено для NN3800, это значение аппаратнозависимое и отличается для других SD.
Аппаратнозависимые параметры определяющие емкость ACL.
Меняются лишь при изменении аппаратной платформы.
min-media-allocation = 2000
min-trusted-allocation = 4000
deny-allocation = 64000
arp-msg-bandwidth - полоса разрешенная для ARP запросов (по умолчанию 32000) без необходимости изменять, наверное, не надо.
flow-time-limit = 28800 - 8 часов непрерывной работы сессии (по умолчанию 24 часа)
initial-guard-timer = 4200 - таймер срабатывает, если время между пакетами велико
subsq-guard-timer = 4200 - таймер срабатывает, если время между пакетами велико
tcp-initial-guard-timer = 4200 - таймер срабатывает, если время между пакетами велико
tcp-subsq-guard-timer = 4200 - таймер срабатывает, если время между пакетами велико
Эти таймеры срабатывают при пропадании RTP потока, но также могут сработать, если передача идет лишь в одном направлении, например, при передаче факсимильного сообщения.
Далее опишу свое видение системы ограничений, налагаемых на полезный трафик, проходящий через систему; я не буду придерживаться водопроводной терминологии из документации, при желании Вы можете прочесть ее, что я настоятельно и рекомендую.
При описании модели поведения нужно описать те характеристики и ограничения, в соответствии с которыми она и будет формироваться.
- Если вызов принадлежит доверенному пользователю, этот вызов должен состояться.
- Часть злонамереннных сообщений пройдет через SD.
- Система обеспечивает обе схемы: и peer, и access.
- Схема peer запрещает любой трафик, и для разрешения требуется прописать исключение.
- Контроль за схемой access возложен на сервер регистраций.
- Переход из состояния UNTRUSTED в состояние TRUSTED происходит при удачной регистрации, либо при установлении соединения.
- Расчеты производим для протокола SIP.
- Для схемы peer расчет производится для входящего на шлюз вызова, а для схемы access - для исходящего, при этом учитывается максимальный сигнальный трафик.
- Каждый абонентский порт шлюза может генерировать или получать 1 вызов в секунду при максимальной нагрузке (установка сервиса автодозвон).
Весь трафик, входящий в SBC, делится на TRUSTED, UNTRUSTED и FRAGMENTED.
fragment-msg-bandwidth - полоса для фрагментированных пакетов, если fragment-msg-bandwidth = 0, то все фрагментированные пакеты идут как UNTRUSTED, и только при сборе всего пакета переходит в TRUSTED.
Предположим, что количество фрагментированных пакетов велико, для расчета предположим, что величина этого трафика может достигать половины максимально возможного, результат для NN3800: fragment-msg-bandwidth = 1720000/2 = 860000
Следующие два параметра образуют плавающее окно для UNTRUSTED трафика, окно обеспечивает прохождение сообщений, которые используются для идентификации трафика и перевода его в TRUSTED, например, Register.
max-untrusted-signaling = 6% от max-signaling-bandwidth, это максимальное значение окна в процентах от максимальной полосы, UNTRUSTED трафик не может превышать этого значения. Рекомендуемые значения для схемы peer - 1%, access - 5%, в сумме 6%.
min-untrusted-signaling = 5% от max-signaling-bandwidth, это минимальное значение окна в процентах от максимальной полосы, эта полоса всегда выделена для UNTRUSTED трафика, даже если нагрузка TRUSTED трафика приближается к 100%. Рекомендуемые значения для схемы peer - 1%, access - 4%, в сумме 5%.
Уровень Access Control & Realm
Схема peer
Пример параметров для 8-портового шлюза.
access = permit
average-rate-limit = 45600
trust-level = low
invalid-signal-threshold = 0
maximum-signal-threshold = 2400
untrusted-signal-threshold = 2400
average-rate-limit - ограничение на величину сигнального трафика, расчитывается как
сумма сигнальных сообщений для одного вызова в байтах * количество вызовов с одного порта в течении окна измерения * количество портов на шлюзе + сумма дополнительных сервисных сообщений в байтах * количество портов на шлюзе, и все это поделить на величину окна измерения (по умолчанию 30 секунд)
В установлении вызова участвуют следующие сообщения:
INVITE - 1150
PRACK - 517
ACK for Invite with Authentication - 555
BYE - 495
Сервисные сообщения:
SUBSCRIBE - 916
NOTIFY - 790
OPTIONS - 344
REFER - 977
Допущение - каждый абонентский порт шлюза может генерировать 1 вызов в секунду при максимальной нагрузке (установка сервиса "Автодозвон").
Расчет для 8-портового шлюза:
((1150+517+555+495)*30+916+790+344+977)*8/30= 22543.2 byte/sec
или
(2717*30+3027)*8/30= 22543.2 byte/sec
но такая точность нам ни к чему, несколько вольно округлим и упростим:
(2750+100)*8=2850*8= 22800 byte/sec
Учитывая, что это предельное значение, уножим на 2. Результат для 8-портового шлюза average-rate-limit = 45600 byte/sec.
В результате получаем формулу расчета
average-rate-limit = 5700 * Количество портов
invalid-signal-threshold - порог пакетов с ошибками, устанавливаем 0.
maximum-signal-threshold - максимально возможное количество сигнальных сообщений от пользователя в течении окна измерения (по умолчанию 30 секунд), расчитывается, как максимально возвожное количество вызовов в секунду (max CPS) * окно измерения (tolerance-window) * количество сигнальных сообщений, полученых от внешнего устройства (100 Trying, 183 Session Progress, 200 OK for PRACK, 200 OK for INVITE, 200 OK for BYE), так как при входящем вызове на шлюз генерируется больше сообщений, чем при исходящем, то и рассматриваем этот вариант.
Расчет для 8-портового шлюза:
Допущение - каждый абонентский порт может получать 1 вызов в секунду при максимальной нагрузке (установка сервиса "Автодозвон").
8*1*30*5=1200
Учитывая, что это предельное значение, то для устранения ложных срабатываний умножим это значение на 2, получаем 2400, тем самым будут учтены возможные дополнительные сообщения.
Окончательный вариант расчета для окна 30 секунд:
maximum-signal-threshold = 300 * Количество портов
untrusted-signal-threshold - количество сигнальных сообщений от абонентского устройства до перевода в TRUSTED. Переход из состояния UNTRUSTED в состояние TRUSTED происходит при ответе абонента и установлении первого разговора, то есть по Invite, приходящему на SD. Но, схема peer подразумевает, что абонент является доверенным и переход в TRUSTED не нужен, поэтому, этот параметер приравняем к maximum-signal-threshold. При этом значении не произойдет блокировки абонентского устройства при большом колличестве вызовов на занятого абонента.
Результат для схемы peer:
untrusted-signal-threshold = maximum-signal-threshold
Схема access
Пример параметров для 8-портовой PBX.
access = permit
average-rate-limit = 81600
trust-level = low
invalid-signal-threshold = 0
maximum-signal-threshold = 2880
untrusted-signal-threshold = 4
В этой схеме верны все допущения схемы peer, кроме изменения состояния; переход из UNTRUSTED в состояние TRUSTED происходит при удачной регистрации. Расчет производится для одного зарегистрированного пользователя, но так как этот пользователь может представлять из себя многопортовое устройство (например IP PBX), то и расчет производится по той же методике. Но для расчета нужно определиться с устройством, у которого будет максимальное количество портов во всей сети, скрытое за одной регистрацией, и все расчеты произвести для него.
average-rate-limit - ограничение на величину сигнального трафика, рассчитывается как
сумма сигнальных сообщений для одного вызова в байтах * количество вызовов с одного порта в течении окна измерения * количество портов на PBX + сумма дополнительных сервисных сообщений в байтах * количество портов на PBX, и все это поделить на величину окна измерения (по умолчанию 30 секунд)
В установлении вызова участвуют следующие сообщения:
INVITE - 1150
ACK - 555
INVITE with Authentication - 1400
PRACK - 517
ACK for Invite with Authentication - 815
BYE - 495
Сервисные сообщения:
REGISTER - 564
REGISTER with Authentication - 870
SUBSCRIBE - 916
NOTIFY - 790
OPTIONS - 344
REFER - 977
Допущение: каждый абонентский порт PBX может генерировать 1 вызов в секунду при максимальной нагрузке (установка сервиса "Автодозвон").
Расчет для 8-портовой PBX:
((1150+555+1400+517+815+495)*30+564+870+916+790+344+977)*8/30= 40645.6 byte/sec
или
(4932*30+4461)*8/30= 40645.6 byte/sec
такая точность опять же ни к чему, округлим и упростим:
(4950+150)*8=5100*8= 40800 byte/sec
Учитывая, что это предельное значение, уножим на 2. Результат для 8-портовой PBX average-rate-limit = 81600 byte/sec.
Формула для расчета
average-rate-limit= 10200 * Количество портов
maximum-signal-threshold - максимально возможное количество сигнальных сообщений от пользователя в течении окна измерения (по умолчанию 30 секунд), расчитывается как максимально возвожное количество вызовов в секунду (max CPS) * окно измерения (tolerance-window) * количество сигнальных сообщений, полученых от внешнего устройства (INVITE, ACK, INVITE, PRACK, ACK, BYE).
Допущение: каждый абонентский порт PBX может генерировать 1 вызов в секунду при максимальной нагрузке (установка сервиса "Автодозвон").
Расчет для 8-портовой PBX:
8*1*30*6=1440
Учитывая, что это предельное значение, то для устранения ложных срабатываний умножим это значение на 2, получаем 2880, тем самым будут учтены возможные дополнительные сообщения.
Окончательный вариант расчета для окна 30 секунд -
maximum-signal-threshold = 360 * Количество портов
untrusted-signal-threshold - количество сигнальных сообщений от абонентского устройства до перевода в TRUSTED. Переход из состояния UNTRUSTED в состояние TRUSTED происходит при удачной регистрации, для удачной регистрации требуется лишь два SIP сообщения Register. Учитывая, что это предельное значение, то для устранения ложных срабатываний умножим это значение на 2, получаем 4. Но как показывает практика VoIP абонент может генерировать больше сообщений до момента удачной регистрации. Методом проб и ошибок остановились на значении 8.
Результат для схемы access:
untrusted-signal-threshold = 8
воскресенье, 28 февраля 2010 г.
среда, 24 февраля 2010 г.
Acme Packet - это просто. Часть I.
Старт.
Получив на руки SD NN3800, мы видим специализированный сервер, который по сути ничем не отличается от других. Берем документацию, вооружаемся компьютером и отверткой. И ,приступив к инсталяции, сталкиваемся с некоторыми особенностями (американизмами), а именно: крепеж нестандартный (прикрутить можно только своими винтами), кабель терминала тоже отличается от Cisco кабеля, а мы так к нему уже привыкли. Вот и получается, что для начала нужно взять прямой Ethernet кабель и через прилагаемый переходник соединить COM (RS-232) порт нашего компьютера с консольным портом SBC, который расположен на лицевой панели.
На задней панели расположены Ethernet интерфейсы, слева-направо:
1) Maintenance slot 0 port 0 - Интерфейс управления - прописывается в bootparam
2) Maintenance slot 0 port 1 - резервирование
3) Maintenance slot 0 port 2 - резервирование
4) Media slot 0 port 0 - Media потоки
5) Media slot 0 port 1 - Media потоки
7) Media slot 1 port 0 - Media потоки
8) Media slot 1 port 1 - Media потоки
Итак, мы подключились. Получили приглашение - нужен логин и пароль, ищем их в документации и ничего не находим...
Что ж, вот они:
login: user
password: acme
login: admin
password: packet
Заходим под admin, и если появилось нечто и #, то можно двигаться дальше.
Bootparam
Параметры загрузки живут в bootparam
Здесь нас интересует
inet on ethernet (e) : 192.168.2.2:ffffff00
gateway inet (g) : 192.168.2.1
ffffff00 - это маска сети.
Для изменения интересующего нас параметра вводим новое значение в той же строке.
Сеть для интерфейса управления желательно выбрать отличную от сети сигнального и потокового трафика.
После этого можно подключаться по SSH.
Если у вас планируется установка с резервированием, то те же настройки нужно произвести и на втором сервере, естественно с другим IP адресом и другим host name.
CLI
Перед дальнейшей настройкой требуется описать особенности CLI.
К сожалению, CLI Acme Packet отличается от Cisco, и, как факт, менее удобен для пользователя. В чем отличие - в выборе определенного конфигурационного элемента, то есть, если нужно отредактировать phy-interface wancom1, то нужно дать следующую последовательность:
(а вот тут появляется особенность!)
Команда select определяет конфигурируемый элемент, что не дает пользователю скопировать часть конфигурационного файла и, подправив, сконфигурировать другой элемент методом простой вставки.
Еще одно отличие (опять не в пользу Acme): для конфигурирования следующего элемента нужно закончить конфигурирование текущего командой done или exit, после exit появится запрос save yes/no.
При создании нового элемента команда select не выполняется (ну нечего пока выбирать).
Для полноты картины нужно указать, что дерево CLI сразу разделяется на несколько веток:
Зайдя в одну из веток, мы должны выйти и только затем зайти в другую, т.е. возможность конфигурирования параметра другой ветви не предусмотрена.
В логике такой системе не откажешь, но как-то неудобно...
Redundancy
Теперь конфигурируем систему резервирования (если, конечно, она у вас есть).
Ниже приведен листинг команды sh run:
Заходим на SBC-1 и программируем его.
Т.к. просто скопировать информацию с экрана и вставить ее мы не можем, придется создать всю эту красоту последовательно, руками.
Если про select забыли на консоль будет выведена ошибка и ничего не сохраниться.
Следуя далее в том же ключе, пытаемся привести конфиг к виду выше, благо большая часть параметров идет по умолчанию и не требует корректировки.
Добившись совпадения, выходим на самый верхний уровень CLI и даем команду
save-config
и
activate-config
Соединяем сервера кросс-кабелями
SBC-1 Maintenance slot 0 port 1 - SBC-2 Maintenance slot 0 port 1
SBC-1 Maintenance slot 0 port 2 - SBC-2 Maintenance slot 0 port 2
Заходим на SBC-2 и даем команду
acquire-config 192.168.xx.xx - на месте xx должен быть IP адрес SBC-1
Если все сделано верно, вы получаете зарезервированый SBC Acme Packet!
Далее все изменения достаточно производить лишь на активном сервере.
Посмотреть, какой именно активен, можно командой:
SBC-1# show health
Осталось настроить system-config:
link-redundancy-state - параметр определяющий поведение физических медиа интерфейсов.
Их всего 4, можно использовать каждый интерфейс по отдельности и тем самым увеличить пропускную способность на уровне физических интерфейсов до 2 Gb, но если принять за основу - сначала надежность, потом скорость, то параметр link-redundancy-state позволяет объединить физические интерфейсы попарно с помощью установки виртуального MAC адреса интерфейса. В результате получаем один дублированый 1GB интерфейс во внешнюю сеть и один дублированый 1GB интерфейс во внутреннюю сеть.
Какой куда, Media slot 0 или Media slot 1, определяется инженером, как удобно так нужно делать.
Результат:
Не забудем про часы:
Результат:
Для сохранения, выходим на самый верхний уровень CLI и даем команду
save-config
и
activate-config
Теперь холст готов, можно рисовать картину маслом!
Получив на руки SD NN3800, мы видим специализированный сервер, который по сути ничем не отличается от других. Берем документацию, вооружаемся компьютером и отверткой. И ,приступив к инсталяции, сталкиваемся с некоторыми особенностями (американизмами), а именно: крепеж нестандартный (прикрутить можно только своими винтами), кабель терминала тоже отличается от Cisco кабеля, а мы так к нему уже привыкли. Вот и получается, что для начала нужно взять прямой Ethernet кабель и через прилагаемый переходник соединить COM (RS-232) порт нашего компьютера с консольным портом SBC, который расположен на лицевой панели.
На задней панели расположены Ethernet интерфейсы, слева-направо:
1) Maintenance slot 0 port 0 - Интерфейс управления - прописывается в bootparam
2) Maintenance slot 0 port 1 - резервирование
3) Maintenance slot 0 port 2 - резервирование
4) Media slot 0 port 0 - Media потоки
5) Media slot 0 port 1 - Media потоки
7) Media slot 1 port 0 - Media потоки
8) Media slot 1 port 1 - Media потоки
Итак, мы подключились. Получили приглашение - нужен логин и пароль, ищем их в документации и ничего не находим...
Что ж, вот они:
login: user
password: acme
login: admin
password: packet
Заходим под admin, и если появилось нечто и #, то можно двигаться дальше.
Bootparam
Параметры загрузки живут в bootparam
SBC-1# conf t SBC-1(configure)# bootparam '.' = clear field; '-' = go to previous field; q = quit boot device : eth0 processor number : 0 host name : SBC-1 file name : /code/images/nnSCX610m2p7.gz inet on ethernet (e) : 192.168.2.2:ffffff00 inet on backplane (b) : host inet (h) : gateway inet (g) : 192.168.2.1 user (u) : vxftp ftp password (pw) (blank = use rsh) : vxftp flags (f) : 0x8 target name (tn) : SBC-1 startup script (s) : other (o) :
Здесь нас интересует
inet on ethernet (e) : 192.168.2.2:ffffff00
gateway inet (g) : 192.168.2.1
ffffff00 - это маска сети.
Для изменения интересующего нас параметра вводим новое значение в той же строке.
Сеть для интерфейса управления желательно выбрать отличную от сети сигнального и потокового трафика.
После этого можно подключаться по SSH.
Если у вас планируется установка с резервированием, то те же настройки нужно произвести и на втором сервере, естественно с другим IP адресом и другим host name.
CLI
Перед дальнейшей настройкой требуется описать особенности CLI.
К сожалению, CLI Acme Packet отличается от Cisco, и, как факт, менее удобен для пользователя. В чем отличие - в выборе определенного конфигурационного элемента, то есть, если нужно отредактировать phy-interface wancom1, то нужно дать следующую последовательность:
SBC-1# conf t SBC-1(configure)# system SBC-1(system)# phy-interface SBC-1(phy-interface)#
(а вот тут появляется особенность!)
SBC-1(phy-interface)# select 1: wancom1 2: wancom2 selection: 1 SBC-1(phy-interface)# show phy-interface name wancom1 operation-type Maintenance port 1 slot 0 virtual-mac wancom-health-score 20
Команда select определяет конфигурируемый элемент, что не дает пользователю скопировать часть конфигурационного файла и, подправив, сконфигурировать другой элемент методом простой вставки.
Еще одно отличие (опять не в пользу Acme): для конфигурирования следующего элемента нужно закончить конфигурирование текущего командой done или exit, после exit появится запрос save yes/no.
При создании нового элемента команда select не выполняется (ну нечего пока выбирать).
Для полноты картины нужно указать, что дерево CLI сразу разделяется на несколько веток:
bootparam enter boot parameters media-manager configure media manager components ntp-sync configure time synchronization session-router configure session router components system configure general system components security configure security components
Зайдя в одну из веток, мы должны выйти и только затем зайти в другую, т.е. возможность конфигурирования параметра другой ветви не предусмотрена.
В логике такой системе не откажешь, но как-то неудобно...
Redundancy
Теперь конфигурируем систему резервирования (если, конечно, она у вас есть).
Ниже приведен листинг команды sh run:
phy-interface name wancom1 operation-type Maintenance port 1 slot 0 virtual-mac wancom-health-score 20 phy-interface name wancom2 operation-type Maintenance port 2 slot 0 virtual-mac wancom-health-score 20 network-interface name wancom1 sub-port-id 0 description hostname ip-address pri-utility-addr 169.254.1.1 sec-utility-addr 169.254.1.2 netmask 255.255.255.252 gateway sec-gateway gw-heartbeat state enabled heartbeat 10 retry-count 3 retry-timeout 1 health-score 30 dns-ip-primary dns-ip-backup1 dns-ip-backup2 dns-domain dns-timeout 11 hip-ip-list ftp-address icmp-address snmp-address telnet-address network-interface name wancom2 sub-port-id 0 description hostname ip-address pri-utility-addr 169.254.2.1 sec-utility-addr 169.254.2.2 netmask 255.255.255.252 gateway sec-gateway gw-heartbeat state enabled heartbeat 10 retry-count 3 retry-timeout 1 health-score 30 dns-ip-primary dns-ip-backup1 dns-ip-backup2 dns-domain dns-timeout 11 hip-ip-list ftp-address icmp-address snmp-address telnet-address redundancy-config state enabled log-level INFO health-threshold 75 emergency-threshold 50 port 9090 advertisement-time 500 percent-drift 210 initial-time 1250 becoming-standby-time 180000 becoming-active-time 100 cfg-port 1987 cfg-max-trans 10000 cfg-sync-start-time 5000 cfg-sync-comp-time 1000 gateway-heartbeat-interval 0 gateway-heartbeat-retry 0 gateway-heartbeat-timeout 1 gateway-heartbeat-health 0 media-if-peercheck-time 0 peer name SBC-1 state enabled type Primary destination address 169.254.1.1:9090 network-interface wancom1:0 destination destination-address 169.254.2.1:9090 network-interface wancom2:0 peer name SBC-2 state enabled type Secondary destination address 169.254.1.2:9090 network-interface wancom1:0 destination address 169.254.2.2:9090 network-interface wancom2:0
Заходим на SBC-1 и программируем его.
Т.к. просто скопировать информацию с экрана и вставить ее мы не можем, придется создать всю эту красоту последовательно, руками.
SBC-1# conf t SBC-1(configure)# system SBC-1(system)# phy-interface SBC-1(phy-interface)# name wancom1 SBC-1(phy-interface)# operation-type Maintenance SBC-1(phy-interface)# port 1 SBC-1(phy-interface)# slot 0 SBC-1(phy-interface)# doneЕсли что-то ввели неправильно, для коррекции не забываем про select!
Если про select забыли на консоль будет выведена ошибка и ничего не сохраниться.
Следуя далее в том же ключе, пытаемся привести конфиг к виду выше, благо большая часть параметров идет по умолчанию и не требует корректировки.
Добившись совпадения, выходим на самый верхний уровень CLI и даем команду
save-config
и
activate-config
Соединяем сервера кросс-кабелями
SBC-1 Maintenance slot 0 port 1 - SBC-2 Maintenance slot 0 port 1
SBC-1 Maintenance slot 0 port 2 - SBC-2 Maintenance slot 0 port 2
Заходим на SBC-2 и даем команду
acquire-config 192.168.xx.xx - на месте xx должен быть IP адрес SBC-1
Если все сделано верно, вы получаете зарезервированый SBC Acme Packet!
Далее все изменения достаточно производить лишь на активном сервере.
Посмотреть, какой именно активен, можно командой:
SBC-1# show health
Осталось настроить system-config:
SBC-1# conf t SBC-1(configure)# system SBC-1(system)# system-config SBC-1(system-config)# select SBC-1(system-config)# hostname LAB SBC-1(system-config)# default-gateway 201.00.00.01 SBC-1(system-config)# link-redundancy-state enabled SBC-1(system-config)# done
link-redundancy-state - параметр определяющий поведение физических медиа интерфейсов.
Их всего 4, можно использовать каждый интерфейс по отдельности и тем самым увеличить пропускную способность на уровне физических интерфейсов до 2 Gb, но если принять за основу - сначала надежность, потом скорость, то параметр link-redundancy-state позволяет объединить физические интерфейсы попарно с помощью установки виртуального MAC адреса интерфейса. В результате получаем один дублированый 1GB интерфейс во внешнюю сеть и один дублированый 1GB интерфейс во внутреннюю сеть.
Какой куда, Media slot 0 или Media slot 1, определяется инженером, как удобно так нужно делать.
Результат:
system-config hostname LAB description location mib-system-contact mib-system-name mib-system-location snmp-enabled enabled enable-snmp-auth-traps disabled enable-snmp-syslog-notify disabled enable-snmp-monitor-traps disabled enable-env-monitor-traps disabled snmp-syslog-his-table-length 1 snmp-syslog-level WARNING system-log-level WARNING syslog-server process-log-level NOTICE process-log-ip-address 0.0.0.0 process-log-port 0 collect sample-interval 5 push-interval 15 boot-state disabled start-time now end-time never red-collect-state disabled red-max-trans 1000 red-sync-start-time 5000 red-sync-comp-time 1000 push-success-trap-state disabled call-trace disabled internal-trace disabled log-filter all default-gateway 201.00.00.01 restart enabled exceptions telnet-timeout 0 console-timeout 0 remote-control enabled cli-audit-trail enabled link-redundancy-state enabled source-routing disabled cli-more disabled terminal-height 24 debug-timeout 0 trap-event-lifetime 0
Не забудем про часы:
SBC-1# conf t SBC-1(configure)# ntp-sync SBC-1(configure)# select SBC-1(configure)# server 201.00.00.11 SBC-1(configure)# done
Результат:
ntp-config server 201.00.00.11
Для сохранения, выходим на самый верхний уровень CLI и даем команду
save-config
и
activate-config
Теперь холст готов, можно рисовать картину маслом!
воскресенье, 10 января 2010 г.
Регулятор мощности с малым уровнем помех.
Доработка конструктора мастер кит NM1041.
http://www.masterkit.ru/info/magshow.php?num=13
Идея схемы красива и потому не изменена, изменены детали.
В исходной схеме соединены выходы тригегов (вывод 1 и 13), в КМОП это недопустимо, т.к. при несовпадении скоростей переключения происходит внутреннее короткое замыкание.
Может кому-то и повезет, и схема будет работать, но как долго никто не скажет.
В приведенной схеме это устранено, а ток открывания транзистора в большей степени ограничен мощностью схемы питания устройства, чем мощностью выходных каскадов тригера.
Вторая проблема устройства - перегрев оптрона, т.к. ограничительный резистор выбран с перегрузкой по току. Решение в установке генератора тока, что обеспечивает нормальный режим работы оптрона.
И третья проблема - невозможность получения полной мощности на выходе. На компараторе уровень напряжения на инверсном входе выше необходимого. Решение устанока двух диодов включенных встречно-параллельно.
С учетом этих доработок устройство работает уже несколько лет в качестве регулятора мощности для паяльника.
Доработка конструктора мастер кит NM1041.
http://www.masterkit.ru/info/magshow.php?num=13
Идея схемы красива и потому не изменена, изменены детали.
В исходной схеме соединены выходы тригегов (вывод 1 и 13), в КМОП это недопустимо, т.к. при несовпадении скоростей переключения происходит внутреннее короткое замыкание.
Может кому-то и повезет, и схема будет работать, но как долго никто не скажет.
В приведенной схеме это устранено, а ток открывания транзистора в большей степени ограничен мощностью схемы питания устройства, чем мощностью выходных каскадов тригера.
Вторая проблема устройства - перегрев оптрона, т.к. ограничительный резистор выбран с перегрузкой по току. Решение в установке генератора тока, что обеспечивает нормальный режим работы оптрона.
И третья проблема - невозможность получения полной мощности на выходе. На компараторе уровень напряжения на инверсном входе выше необходимого. Решение устанока двух диодов включенных встречно-параллельно.
С учетом этих доработок устройство работает уже несколько лет в качестве регулятора мощности для паяльника.
вторник, 26 мая 2009 г.
SBC и его место
Построение VoIP сетей постепенно переходит из состояния "лишь бы работало" к состоянию "чтобы работало". Это привело к пересмотру подходов построения сетей. Изменились и требования. И наряду с прокси-серверами, серверами-регистраторами, гейткиперами и т.д. появилась еще одна составляющая сетей SBC (Session Border Controller). Из названия следует, что этот кубик должен осуществлять контроль за VoIP сессиями. Так оно и есть, только есть нюанс: каждый производитель SBC предлагает разную функциональность.
SBC - мост, соединяющий внутреннюю сеть провайдера, которую последний должен контролировать, с неконтролируемой внешней сетью. И задача, налагаемая на SBC, - обеспечить надежное и защищенное соединение между данными сетями.
Соединение сетей подразделяется на две схемы: peer-to-peer и access.
Peer-to-peer
Оконечные устройства обладают информацией друг o друге и могут задать жесткие правила пропуска трафика. Данная схема используется при объединении сетей провайдеров, при построении распределенной сети, при подключении абонентов со статическими настройками.
Access
Информация известна только одной стороне - пользователю услуги. При этой схеме производится аутентификация и авторизация пользовательской стороны на серверной, на основе криптографических алгоритмов с использованием уникальных данных.
В теории обе эти схемы должны быть реализованы на SBC и должны работать в SIP, H.323. Для Megaco, MGCP должна поддерживаться схема peer-to-peer. (Мне не известно ни одного SBC с поддержкой всех этих протоколов.)
Задачи, решаемые SBC в схеме Peer-to-peer
-Проверка подлинности пользователя (IP address, MAC, ...).
-Интервокинг (преобразование протокола установления связи).
-Нормализация протокола (приведение сообщений от пользовательского оборудования к виду, понятному для сервера управления).
-Анализ SDP (анализ схемы сети для проключения RTP трафика).
-Транскодирование (преобразование голосовой информации из одной схемы кодирования в другую).
-Управление RTP сессиями (в вариантах с проксированием и без него).
Задачи, решаемые SBC в схеме Access
-Аутентификация и Авторизация.
-Интервокинг (преобразование протокола установления связи).
-Нормализация протокола (приведение сообщений от пользовательского оборудования к виду, понятному для сервера управления).
-Преодоление NAT.
-Анализ SDP (анализ схемы сети для проключения RTP трафика).
-Транскодирование (преобразование голосовой информации из одной схемы кодирования в другую).
-Управление RTP сессиями (в вариантах с проксированием и без него).
Если суммировать все эти задачи и помножить на количество протоколов, то в результате должна получиться ужасно сложная система.
Оборудование или ПО SBC, производимое сегодня, по выше изложенным причинам поддерживает только часть необходимых функций. Я не знаю наверняка, но, похоже, все производители SBC отказались от реализации протоколов Megaco и MGCP, уменьшив тем самым сложность задачи вдвое. Но на этом они не остановились, чем дальше, тем больше идет отрицание существования протокола H.323, может быть это и правильно, но этот протокол еще работает и работать будет долго. Т.е. в конечном счете, все сведется к реализации протокола SIP.
Свободно распространяемые SBC отказались от H.323 изначально, и предъявить им нечего, и так бесплатны. Коммерческие же SBC заявляют о своей поддержке этого протокола, как в варианте трансляции, так и в варианте интервокинга. Заявление отличное, вот только реализация далека от идеальной. Так тестируемый nCite1000 компании AudioCodes почему-то не может обеспечить интервокинг протокола H.323 в SIP. Есть надежда, что у других производителей дела обстоят лучше, но есть большие сомнения.
Итак:
Свободные SBC - только SIP;
Коммерческие SBC - SIP и H.323.
Определившись с протоколами, перейдем к функциям.
В нашем распоряжении оказались два типа SBC ncite1000 и OpenSBC; я понимаю, что этого мало, но мне кажется, что тенденция одинакова для всех.
OpenSBC
Поддерживает только SIP.
Реализованы обе схемы peer-to-peer и access.
Реализована нормализация SIP протокола, но при этом пользователь не может вносить изменения в формирование сообщений, что делает его заложником данного SBC, и как результат вся сеть подгоняется под SBC.
Алгоритм преодоления NAT реализован, но есть проблемы при пропуске RTP трафика без RTP проксирования на сервере обработки сигнализации, к тому же алгоритм изменяется от версии к версии, что не лучшим образом отражается на поддержании сети.
Транскодирования нет.
Прост в установке и обслуживании, но рассчитан на малый объем RTP трафика.
nCite1000
Заявлены обе схемы peer-to-peer и access для протокола SIP и H.323.
Реализованы обе схемы peer-to-peer и access для SIP.
Для H.323 только peer-to-peer.
Нормализация SIP протокола если и есть, то минимальная, при этом пользователь не может вносить изменения в формирование сообщений, что делает его заложником этого SBC, и, как результат, вся сеть подгоняется под SBC.
Алгоритм преодоления NAT реализован, но есть проблемы при пропуске RTP трафика без RTP проксирования на сервере обработки сигнализации.
Эта проблема решается установкой после SBC маршрутизатора с гигабитными интерфейсами, и прописыванием маршрутов в SBC. Маршрутизаторы делает данное решение слишком дорогим.
Транскодирования нет.
Прост в установке, но сложен в обслуживании. Система управления реализована с упором на красоту визуального восприятия, а не на удобство и гибкость управления (это беда, похоже, всех систем управления от AudioCodes). Серверная часть системы управления устанавливается на выделенный сервер, который устанавливается в том же сегменте, что и управляющий интерфейс nCite. При этом система управления предполагает, что интерфейс клиентского доступа сервера находится на внешних IP адресах. Вся система управления перестает работать, если установить на серверной стороне хотя бы статический NAT. А если клиент запускается из-за NAT, то требует открыть уйму портов, чем повергает в шок любого системного администратора.
Надеюсь, у других производителей дела обстоят лучше...
Нет сомнения, что данный кубик при построении VoIP сети является если не самым главным в системе, то одним из основных, наряду с SIP-сервером, и построение сетей с его использованием должно стать обязательным. Но для достижения этого SBC должен стать образцом для всех типов VoIP оборудования. Его надежность, управляемость, гибкость и функциональность должны быть на порядок выше, чем у SIP-серверов и шлюзов.
Пока же этого нет, оператор, прежде чем заплатить деньги, должен определиться, какая из схем ему ближе. В случае peer-to-peer, оператор теряет промежуточный контроль за сессиями, т.е. вся нагрузка ложиться либо на шлюз, либо на сервер. А в случае с access оператор вынужден поднимать STUN сервер или применять другие методы, т.к. в большинстве случаев STUN сервер просто бесполезен. Все бы не беда, если бы не доступность серверов из внешней сети, что ставит оператора в странное положение: с одной стороны, он должен обеспечить безопасность (устанавливать патчи на системы, делать апгрейд), а с другой - он не может этого сделать из-за лицензионной политики производителей, например компании VocalTec.
Если же оператор решился идти сквозь тернии и купил SBC, он должен понимать, что он будет вынужден подгонять все оставшиеся кубики схемы к кубику SBC. И осознать, что при проблемах на SBC проблемы будут на всей сети.
SBC - мост, соединяющий внутреннюю сеть провайдера, которую последний должен контролировать, с неконтролируемой внешней сетью. И задача, налагаемая на SBC, - обеспечить надежное и защищенное соединение между данными сетями.
Соединение сетей подразделяется на две схемы: peer-to-peer и access.
Peer-to-peer
Оконечные устройства обладают информацией друг o друге и могут задать жесткие правила пропуска трафика. Данная схема используется при объединении сетей провайдеров, при построении распределенной сети, при подключении абонентов со статическими настройками.
Access
Информация известна только одной стороне - пользователю услуги. При этой схеме производится аутентификация и авторизация пользовательской стороны на серверной, на основе криптографических алгоритмов с использованием уникальных данных.
В теории обе эти схемы должны быть реализованы на SBC и должны работать в SIP, H.323. Для Megaco, MGCP должна поддерживаться схема peer-to-peer. (Мне не известно ни одного SBC с поддержкой всех этих протоколов.)
Задачи, решаемые SBC в схеме Peer-to-peer
-Проверка подлинности пользователя (IP address, MAC, ...).
-Интервокинг (преобразование протокола установления связи).
-Нормализация протокола (приведение сообщений от пользовательского оборудования к виду, понятному для сервера управления).
-Анализ SDP (анализ схемы сети для проключения RTP трафика).
-Транскодирование (преобразование голосовой информации из одной схемы кодирования в другую).
-Управление RTP сессиями (в вариантах с проксированием и без него).
Задачи, решаемые SBC в схеме Access
-Аутентификация и Авторизация.
-Интервокинг (преобразование протокола установления связи).
-Нормализация протокола (приведение сообщений от пользовательского оборудования к виду, понятному для сервера управления).
-Преодоление NAT.
-Анализ SDP (анализ схемы сети для проключения RTP трафика).
-Транскодирование (преобразование голосовой информации из одной схемы кодирования в другую).
-Управление RTP сессиями (в вариантах с проксированием и без него).
Если суммировать все эти задачи и помножить на количество протоколов, то в результате должна получиться ужасно сложная система.
Оборудование или ПО SBC, производимое сегодня, по выше изложенным причинам поддерживает только часть необходимых функций. Я не знаю наверняка, но, похоже, все производители SBC отказались от реализации протоколов Megaco и MGCP, уменьшив тем самым сложность задачи вдвое. Но на этом они не остановились, чем дальше, тем больше идет отрицание существования протокола H.323, может быть это и правильно, но этот протокол еще работает и работать будет долго. Т.е. в конечном счете, все сведется к реализации протокола SIP.
Свободно распространяемые SBC отказались от H.323 изначально, и предъявить им нечего, и так бесплатны. Коммерческие же SBC заявляют о своей поддержке этого протокола, как в варианте трансляции, так и в варианте интервокинга. Заявление отличное, вот только реализация далека от идеальной. Так тестируемый nCite1000 компании AudioCodes почему-то не может обеспечить интервокинг протокола H.323 в SIP. Есть надежда, что у других производителей дела обстоят лучше, но есть большие сомнения.
Итак:
Свободные SBC - только SIP;
Коммерческие SBC - SIP и H.323.
Определившись с протоколами, перейдем к функциям.
В нашем распоряжении оказались два типа SBC ncite1000 и OpenSBC; я понимаю, что этого мало, но мне кажется, что тенденция одинакова для всех.
OpenSBC
Поддерживает только SIP.
Реализованы обе схемы peer-to-peer и access.
Реализована нормализация SIP протокола, но при этом пользователь не может вносить изменения в формирование сообщений, что делает его заложником данного SBC, и как результат вся сеть подгоняется под SBC.
Алгоритм преодоления NAT реализован, но есть проблемы при пропуске RTP трафика без RTP проксирования на сервере обработки сигнализации, к тому же алгоритм изменяется от версии к версии, что не лучшим образом отражается на поддержании сети.
Транскодирования нет.
Прост в установке и обслуживании, но рассчитан на малый объем RTP трафика.
nCite1000
Заявлены обе схемы peer-to-peer и access для протокола SIP и H.323.
Реализованы обе схемы peer-to-peer и access для SIP.
Для H.323 только peer-to-peer.
Нормализация SIP протокола если и есть, то минимальная, при этом пользователь не может вносить изменения в формирование сообщений, что делает его заложником этого SBC, и, как результат, вся сеть подгоняется под SBC.
Алгоритм преодоления NAT реализован, но есть проблемы при пропуске RTP трафика без RTP проксирования на сервере обработки сигнализации.
Эта проблема решается установкой после SBC маршрутизатора с гигабитными интерфейсами, и прописыванием маршрутов в SBC. Маршрутизаторы делает данное решение слишком дорогим.
Транскодирования нет.
Прост в установке, но сложен в обслуживании. Система управления реализована с упором на красоту визуального восприятия, а не на удобство и гибкость управления (это беда, похоже, всех систем управления от AudioCodes). Серверная часть системы управления устанавливается на выделенный сервер, который устанавливается в том же сегменте, что и управляющий интерфейс nCite. При этом система управления предполагает, что интерфейс клиентского доступа сервера находится на внешних IP адресах. Вся система управления перестает работать, если установить на серверной стороне хотя бы статический NAT. А если клиент запускается из-за NAT, то требует открыть уйму портов, чем повергает в шок любого системного администратора.
Надеюсь, у других производителей дела обстоят лучше...
Нет сомнения, что данный кубик при построении VoIP сети является если не самым главным в системе, то одним из основных, наряду с SIP-сервером, и построение сетей с его использованием должно стать обязательным. Но для достижения этого SBC должен стать образцом для всех типов VoIP оборудования. Его надежность, управляемость, гибкость и функциональность должны быть на порядок выше, чем у SIP-серверов и шлюзов.
Пока же этого нет, оператор, прежде чем заплатить деньги, должен определиться, какая из схем ему ближе. В случае peer-to-peer, оператор теряет промежуточный контроль за сессиями, т.е. вся нагрузка ложиться либо на шлюз, либо на сервер. А в случае с access оператор вынужден поднимать STUN сервер или применять другие методы, т.к. в большинстве случаев STUN сервер просто бесполезен. Все бы не беда, если бы не доступность серверов из внешней сети, что ставит оператора в странное положение: с одной стороны, он должен обеспечить безопасность (устанавливать патчи на системы, делать апгрейд), а с другой - он не может этого сделать из-за лицензионной политики производителей, например компании VocalTec.
Если же оператор решился идти сквозь тернии и купил SBC, он должен понимать, что он будет вынужден подгонять все оставшиеся кубики схемы к кубику SBC. И осознать, что при проблемах на SBC проблемы будут на всей сети.
четверг, 21 мая 2009 г.
Music on hold
Резистор и конденсатор на выходе нужны, т.к. подключается это устройства на аналоговый порт, вместо телефонного аппарата. И как следствие, требуется нагрузочный резистор, для эмуляции занятия линии. А конденсатор для отсечки постоянного тока.
среда, 20 мая 2009 г.
IP и телефон
Практически весь XX век человек пользовался телефоном, телефоном к которому мы все привыкли, устройство с номеронабирателем и трубкой. Данное устройство настолько просто, что долгое время было механическим, электрическая часть занимала только малую часть объема, к тому же оно было почти не убиваемое. Развитие электроники позволило сильно удешевить телефон и увеличить его надежность, вся механическая начинка исчезла и на смену пришла микросхема. Начинка телефонного аппарата стала помещаться в спичечный коробок, но при этом надежность системы была ничуть не хуже чем прежде, а, мне думается, гораздо лучше. Количество функций, выполняемых самим аппаратом, было минимально. От него требовалось занять линию, передать тональный сигнал в трубку, передать на станцию набранный номер, сформировать передачу голоса и освободить линию. При офисном применении телефон должен обрабатывать клавишу Flash и формировать калиброванный разрыв шлейфа, т.е. кратковременное освобождение линии.
Вся основная работа делалась на АТС, где сидел обслуживающий персонал, станционный отдел, т.е. люди, по долгу службы обеспечивающие качество предоставляемых услуг.
Но вот настали 90-е годы, и появилась мобильная связь. Человек, купивший себе мобильный телефон, больше не привязан проводом, он может ходить, ездить, ползать и т.д. почти везде, где есть присутствие сотового оператора. Роуминг довершил дело - человек стал ездить по миру, не думая о связи. О деньгах речи нет. Но что нам принес прогресс? Абонентское устройство стало не просто сложным, а очень сложным. Часть функций была перенесена со станционного оборудования на абонентское. Для общения устройств стал использоваться сложный протокол. А самое главное, что оператор перестал отвечать за качество предоставляемой услуги на конкретном устройстве. И их девизом стало - не нравится - не пользуйся. И ведь упрекнуть оператора в этом нельзя, он просто не может отвечать за миллионы сотовых трубок, которые технический персонал в глаза не видел. Но, как оказалось, для пользователя это неважно, он готов перебирать сотовые трубки, мириться с плохим качеством разговора, с обрывами разговора и всеми глюками, присущими данному виду связи, и все это в угоду мобильности и кажущейся 24-часовой доступности, а кажущейся, потому как сотовая связь умирает первой при любой нештатной ситуации.
Итак, человек обрел свободу перемещения, оставаясь всегда на связи, и задумался над возможностью таскать за собой и стационарный телефон, и не придумал ничего лучше, как использовать для этого IP сеть. Да, IP сеть - это транспорт, который скоро будет жить в каждом доме и будет такой же неотъемлемой частью каждого жилища, как телевизор. Кто же устоит против такого подарка - не надо строить свои сети - они уже готовы! И все кинулись осваивать эту ниву. Производители ринулись разрабатывать и внедрять разные железки. Стандартизаторы начали выдумывать новые рекомендации. И пошло и поехало. Все стали в один голос кричать, что это связь будущего, что, кто не успеет, тот опаздает, что это лучше, чем старое, и при этом дешевле. Все говорят только о прибылях, которые получит ваша компания, если перейдет на IP. И никто не говорит о том, что сеть IP это слабоконтролируемый сегмент коммуникаций, что он похож на паутину, которую плетут миллионы пауков, у них не всегда все гладко, они ругаются между собой, они рвут свою паутину, используют нитки разной толщины, но, в общем и целом, сеть живет. Но с самого зарождения IP сетей человека приучали, что эта связь может неожиданно пропасть и также неожиданно появиться, что он может ею пользоваться, но бесперебойного сервиса никто не обещает. И вот на эту сеть человек пытается перенести услугу, которая у него работала всегда; мог отключиться свет, вода, газ, но телефон работал, и человек приходил в негодование, если его лишали телефонной связи. Но на это никто не обращает внимания, все как заведенные повторяют утверждения производителей. И вот настал час, когда вдруг оказалось, что станционный отдел должен обеспечить качество связи пользователю, который находится бог знает где, но у него на столе стоит тот самый простой телефон и телефонный номер, тот, что был раньше, и человек привык, что этот телефон всегда работает. Возникло противоречие между тем, к чему мы привыкли, и тем, что несут нам новые технологии. Сотовая связь отличается от традиционной, и люди воспринимают все недостатки данной связи с пониманием, а вот ухудшение качества связи на том же самом аппарате встречается в штыки, что в общем и целом правильно. Но это только полбеды, при традиционной связи обслуживающий персонал знал, как отследить проблему, как ее устранить, и у него была уверенность в том, что проблема будет исправлена. С появлением новых технологий инженер поддержки потерял уверенность в том, что оборудование, за которое он отвечает, работает исправно, что каналы связи обеспечивают требуемую пропускную способность. Большинство проблем стали плавающими. Записывать разговоры нельзя, да и не записать все разговоры. И, стало быть, любой мало-мальски подкованный пользователь может высушить поддержку провайдера. Если ко всему этому добавить, что любой пользователь сети может организовать деструктивное воздействие на сеть, что в сети может появиться вирус, многократно увеличивающий трафик, что мы и имеем на сегодня, то можно с уверенностью сказать, что пока человек будет ждать от телефона бесперебойного качества, IP телефония не будет доминировать. Она будет на уровне игрушки, в которую интересно поиграть, но стоит один раз об нее поцарапаться, как она тут же полетит в угол.
Вся основная работа делалась на АТС, где сидел обслуживающий персонал, станционный отдел, т.е. люди, по долгу службы обеспечивающие качество предоставляемых услуг.
Но вот настали 90-е годы, и появилась мобильная связь. Человек, купивший себе мобильный телефон, больше не привязан проводом, он может ходить, ездить, ползать и т.д. почти везде, где есть присутствие сотового оператора. Роуминг довершил дело - человек стал ездить по миру, не думая о связи. О деньгах речи нет. Но что нам принес прогресс? Абонентское устройство стало не просто сложным, а очень сложным. Часть функций была перенесена со станционного оборудования на абонентское. Для общения устройств стал использоваться сложный протокол. А самое главное, что оператор перестал отвечать за качество предоставляемой услуги на конкретном устройстве. И их девизом стало - не нравится - не пользуйся. И ведь упрекнуть оператора в этом нельзя, он просто не может отвечать за миллионы сотовых трубок, которые технический персонал в глаза не видел. Но, как оказалось, для пользователя это неважно, он готов перебирать сотовые трубки, мириться с плохим качеством разговора, с обрывами разговора и всеми глюками, присущими данному виду связи, и все это в угоду мобильности и кажущейся 24-часовой доступности, а кажущейся, потому как сотовая связь умирает первой при любой нештатной ситуации.
Итак, человек обрел свободу перемещения, оставаясь всегда на связи, и задумался над возможностью таскать за собой и стационарный телефон, и не придумал ничего лучше, как использовать для этого IP сеть. Да, IP сеть - это транспорт, который скоро будет жить в каждом доме и будет такой же неотъемлемой частью каждого жилища, как телевизор. Кто же устоит против такого подарка - не надо строить свои сети - они уже готовы! И все кинулись осваивать эту ниву. Производители ринулись разрабатывать и внедрять разные железки. Стандартизаторы начали выдумывать новые рекомендации. И пошло и поехало. Все стали в один голос кричать, что это связь будущего, что, кто не успеет, тот опаздает, что это лучше, чем старое, и при этом дешевле. Все говорят только о прибылях, которые получит ваша компания, если перейдет на IP. И никто не говорит о том, что сеть IP это слабоконтролируемый сегмент коммуникаций, что он похож на паутину, которую плетут миллионы пауков, у них не всегда все гладко, они ругаются между собой, они рвут свою паутину, используют нитки разной толщины, но, в общем и целом, сеть живет. Но с самого зарождения IP сетей человека приучали, что эта связь может неожиданно пропасть и также неожиданно появиться, что он может ею пользоваться, но бесперебойного сервиса никто не обещает. И вот на эту сеть человек пытается перенести услугу, которая у него работала всегда; мог отключиться свет, вода, газ, но телефон работал, и человек приходил в негодование, если его лишали телефонной связи. Но на это никто не обращает внимания, все как заведенные повторяют утверждения производителей. И вот настал час, когда вдруг оказалось, что станционный отдел должен обеспечить качество связи пользователю, который находится бог знает где, но у него на столе стоит тот самый простой телефон и телефонный номер, тот, что был раньше, и человек привык, что этот телефон всегда работает. Возникло противоречие между тем, к чему мы привыкли, и тем, что несут нам новые технологии. Сотовая связь отличается от традиционной, и люди воспринимают все недостатки данной связи с пониманием, а вот ухудшение качества связи на том же самом аппарате встречается в штыки, что в общем и целом правильно. Но это только полбеды, при традиционной связи обслуживающий персонал знал, как отследить проблему, как ее устранить, и у него была уверенность в том, что проблема будет исправлена. С появлением новых технологий инженер поддержки потерял уверенность в том, что оборудование, за которое он отвечает, работает исправно, что каналы связи обеспечивают требуемую пропускную способность. Большинство проблем стали плавающими. Записывать разговоры нельзя, да и не записать все разговоры. И, стало быть, любой мало-мальски подкованный пользователь может высушить поддержку провайдера. Если ко всему этому добавить, что любой пользователь сети может организовать деструктивное воздействие на сеть, что в сети может появиться вирус, многократно увеличивающий трафик, что мы и имеем на сегодня, то можно с уверенностью сказать, что пока человек будет ждать от телефона бесперебойного качества, IP телефония не будет доминировать. Она будет на уровне игрушки, в которую интересно поиграть, но стоит один раз об нее поцарапаться, как она тут же полетит в угол.
вторник, 19 мая 2009 г.
Тестирование IP телефонов и шлюзов
Nateks VC 115-1,2 (4ёх портовый шлюз):
Общее впечатление:
Много настроек.
Неплохой портал управления.
То что не устраивает:
1. Нет возможности привязки нескольких аккаунтов к одному порту.
2. Факсы практически не работают.
3. Конференции нет.
4. Blind трансфер не работает.
5. Неудовлетворительная работа эхокомпенсации.
Основные претензии к аналоговой части, оборудование требует подключения качественного
телефонного оборудования, с минимальным уровнем эха и помех.
Что работает:
1. Холд работает.
2. Трансфер работает.
3. Качество голоса удовлетворительное.
Телефон Nateks IP 81- P:
1. Спокойный дизайн.
2. 10 клавиш быстрого набора.
3. Работает холд, трансфер, конференция.
4. Не работает Blind трансфер.
5. Качество голоса хорошее.
6. Удалённая настройка только через телнет.
USB-телефон SKYPEMATE USB-P4K
Работает (если это можно назвать работой), только c X-Lite и eyeBeam
X-Lite - трансфера и конференции нет впринципе
eyeBeam - нужно покупать - 34$
трансфер и конференцию в eyeBeam можно активировать только мышкой, с телефона не работает
сам телефон тормознутый, программа обслуживания грузит систему
Для работы в офисе не рекомендуется.
Лучше подключить обычную гарнитуру и работать мышью или с клавиатуры.
VOB 820 (Acetech)
Прост как маузер Макара Нагульного
Чем-то похож на старые системные телефоны от аналоговых панасоников
Трансфер и конференция работают
Есть громкая связь - посредственного качества
Сборка - как все китайское - внутри что-то позвякивает
Но при этом все что заявлено - работает
Примерная стоимость - 63$
Очень простой телефон, но при этом все есть,но работать на нем, что-то не хочется.
VOB 822 (Acetech)
По сути тоже что и VOB 820
Только другой дизайн
На мой взгляд чуть лучше, но не намного
Дисплей поворотный
Трансфер глючит, может быть старая прошивка
Примерная стоимость - 66$
Snom 320
На первый взгляд приличный телефон
По-немецки основательный, чем-то напоминает сименс образца 1995 года
Массивная телефонная трубка
Хороший звук
Громкая связь
Много настроек
Пожалели денег на дисплей - телефон оборудован двух строчным ЖК дисплеем, на который не помещается вся информация
Хотя - дисплей поворотный
Кнопки под дисплеем не совсем соответствуют функциям на дисплее, т.е. кнопки располагаются немного в стороне от функции на дисплее
Настройки поумолчанию очень странные - телефон почти не работает
Кнопки программируются
Трансфер и конференция работают
При прописывании DNS требуется перезагрузка - других странностей софта не обнаружено
Примерная стоимость - 210 евро
Приличный телефон, но уж больно дорогой
Snom 300
Младший брат модели 320
Несколько хуже дизайн
Дисплей уже не поворотный, при этом такой же маленький
Мало кнопок
Трансфер и конференция работают
Кнопки уже не резиновые а пластиковые - сэкономили
Примерная стоимость - 145 евро
Для своей ниши очень дорогой телефон
GrandStrim
Легко можно повесить голосовую сессию на холд и больше ее не снять.
Алгоритм:
1 Принимаем вызов
2 Нажимаем transfer
3 Выбираем вторую линию - двойным нажатием (с первого нажатия выбор не происходит)
4 Отбиваем вторую линию
5 Получаем первую линию на холде и вернуть ее нет никакой возможности
Ну и зачем такой телефон, нет, может когда софт и поправят, но ждать некогда
BW210 (fanvil)
Претензии - убогий дизайн, после конференции нельзя воспользоваться трансфером - нужно разорвать все соединения
Конференция и трансфер работает
Нет софт клавиш и нет клавиш быстрого набора
Не проверялся с голосовой почтой
Есть громкая связь
Есть регулировка громкости
Вполне пригодный телефон.
Несколько простоват.
Примерная стоимость 90-95$
KingTel KTI 2002P
Нет конференции
Не проверялся с голосовой почтой
Нет настроек NTP сервера
Есть громкая связь - но на мой взгляд ужастная
Есть регулировка громкости
Очень простой телефон.
Желания приобрести не появилось.
AddPac
Функциональные клавиши работают только с IP АТС AddPac
Т.е. на нашей системе нет ни конференции, ни трансфера
Странный, во всех отношениях, телефон.
Хотя CLI хорош, придраться можно, но это другая история...
Linksys SPA962
Претензии - не поворачивается дисплей
Конференция и трансфер работают в любых вариантах
Нет софт клавиш и нет клавиш быстрого набора - для этого нужно докупать дополнительный модуль SPA932
Поддерживается до двух модулей SPA932 по 32 клавиши на каждом
Не проверялся с голосовой почтой
Есть громкая связь
Есть регулировка громкости
Функция Call Forward на телефоне отрабатывает, но сообщение 302 , формируемое телефоном, не воспринимается системой ВАХ
Много настроек
Хороший телефон за большие деньги
Поставляется без блока питания
Примерная стоимость - 270$
Примерная стоимость SPA932 - 80$ (нужна проверка с ВАХ)
Linksys SPA922
Очень похож на Linksys SPA962
Софт, надеюсь, похож на софт старшего брата.
Как офисный телефон, на мой взгляд, то что надо.
На борту есть LAN порт.
Примерная стоимость - 130$
Linksys SPA921
То же, что и Linksys SPA922 только без LAN порта и PoE.
Примерная стоимость - 100$
Общее впечатление:
Много настроек.
Неплохой портал управления.
То что не устраивает:
1. Нет возможности привязки нескольких аккаунтов к одному порту.
2. Факсы практически не работают.
3. Конференции нет.
4. Blind трансфер не работает.
5. Неудовлетворительная работа эхокомпенсации.
Основные претензии к аналоговой части, оборудование требует подключения качественного
телефонного оборудования, с минимальным уровнем эха и помех.
Что работает:
1. Холд работает.
2. Трансфер работает.
3. Качество голоса удовлетворительное.
Телефон Nateks IP 81- P:
1. Спокойный дизайн.
2. 10 клавиш быстрого набора.
3. Работает холд, трансфер, конференция.
4. Не работает Blind трансфер.
5. Качество голоса хорошее.
6. Удалённая настройка только через телнет.
USB-телефон SKYPEMATE USB-P4K
Работает (если это можно назвать работой), только c X-Lite и eyeBeam
X-Lite - трансфера и конференции нет впринципе
eyeBeam - нужно покупать - 34$
трансфер и конференцию в eyeBeam можно активировать только мышкой, с телефона не работает
сам телефон тормознутый, программа обслуживания грузит систему
Для работы в офисе не рекомендуется.
Лучше подключить обычную гарнитуру и работать мышью или с клавиатуры.
VOB 820 (Acetech)
Прост как маузер Макара Нагульного
Чем-то похож на старые системные телефоны от аналоговых панасоников
Трансфер и конференция работают
Есть громкая связь - посредственного качества
Сборка - как все китайское - внутри что-то позвякивает
Но при этом все что заявлено - работает
Примерная стоимость - 63$
Очень простой телефон, но при этом все есть,но работать на нем, что-то не хочется.
VOB 822 (Acetech)
По сути тоже что и VOB 820
Только другой дизайн
На мой взгляд чуть лучше, но не намного
Дисплей поворотный
Трансфер глючит, может быть старая прошивка
Примерная стоимость - 66$
Snom 320
На первый взгляд приличный телефон
По-немецки основательный, чем-то напоминает сименс образца 1995 года
Массивная телефонная трубка
Хороший звук
Громкая связь
Много настроек
Пожалели денег на дисплей - телефон оборудован двух строчным ЖК дисплеем, на который не помещается вся информация
Хотя - дисплей поворотный
Кнопки под дисплеем не совсем соответствуют функциям на дисплее, т.е. кнопки располагаются немного в стороне от функции на дисплее
Настройки поумолчанию очень странные - телефон почти не работает
Кнопки программируются
Трансфер и конференция работают
При прописывании DNS требуется перезагрузка - других странностей софта не обнаружено
Примерная стоимость - 210 евро
Приличный телефон, но уж больно дорогой
Snom 300
Младший брат модели 320
Несколько хуже дизайн
Дисплей уже не поворотный, при этом такой же маленький
Мало кнопок
Трансфер и конференция работают
Кнопки уже не резиновые а пластиковые - сэкономили
Примерная стоимость - 145 евро
Для своей ниши очень дорогой телефон
GrandStrim
Легко можно повесить голосовую сессию на холд и больше ее не снять.
Алгоритм:
1 Принимаем вызов
2 Нажимаем transfer
3 Выбираем вторую линию - двойным нажатием (с первого нажатия выбор не происходит)
4 Отбиваем вторую линию
5 Получаем первую линию на холде и вернуть ее нет никакой возможности
Ну и зачем такой телефон, нет, может когда софт и поправят, но ждать некогда
BW210 (fanvil)
Претензии - убогий дизайн, после конференции нельзя воспользоваться трансфером - нужно разорвать все соединения
Конференция и трансфер работает
Нет софт клавиш и нет клавиш быстрого набора
Не проверялся с голосовой почтой
Есть громкая связь
Есть регулировка громкости
Вполне пригодный телефон.
Несколько простоват.
Примерная стоимость 90-95$
KingTel KTI 2002P
Нет конференции
Не проверялся с голосовой почтой
Нет настроек NTP сервера
Есть громкая связь - но на мой взгляд ужастная
Есть регулировка громкости
Очень простой телефон.
Желания приобрести не появилось.
AddPac
Функциональные клавиши работают только с IP АТС AddPac
Т.е. на нашей системе нет ни конференции, ни трансфера
Странный, во всех отношениях, телефон.
Хотя CLI хорош, придраться можно, но это другая история...
Linksys SPA962
Претензии - не поворачивается дисплей
Конференция и трансфер работают в любых вариантах
Нет софт клавиш и нет клавиш быстрого набора - для этого нужно докупать дополнительный модуль SPA932
Поддерживается до двух модулей SPA932 по 32 клавиши на каждом
Не проверялся с голосовой почтой
Есть громкая связь
Есть регулировка громкости
Функция Call Forward на телефоне отрабатывает, но сообщение 302 , формируемое телефоном, не воспринимается системой ВАХ
Много настроек
Хороший телефон за большие деньги
Поставляется без блока питания
Примерная стоимость - 270$
Примерная стоимость SPA932 - 80$ (нужна проверка с ВАХ)
Linksys SPA922
Очень похож на Linksys SPA962
Софт, надеюсь, похож на софт старшего брата.
Как офисный телефон, на мой взгляд, то что надо.
На борту есть LAN порт.
Примерная стоимость - 130$
Linksys SPA921
То же, что и Linksys SPA922 только без LAN порта и PoE.
Примерная стоимость - 100$
Подписаться на:
Сообщения (Atom)