Sbc oracle acme packet команды

Обновлено: 15.01.2025

В течение последнего времени операторы постепенно переходят от канальных сетей к более гибким, использующим IP-протокол. К настоящему времени у многих операторов уже развёрнуты сети, в которых ядром являются софтсвич. Теперь, с появлением новой инфраструктуры, построенной поверх ip сетей, появились новые проблемы и требования операторов. Возникает 3 основных вопроса у операторов:

Межоператорское взаимодействие.
- Операторы могут использовать разные сигнальные протоколы (SIP/H.323) для пиринга по ip. В рамках одного и того же протокола могут существовать различные «диалекты» от разных производителей, которые часто могут быть не совместимы.
- Часто может потребоваться «подстраиваться» под кодеки, работающие в сети другого оператора. Нужно устройство, которое умеет согласовывать и приоритезировать кодеки или осуществлять транскодинг.
- Актуален вопрос о сокрытии внутренней адресации шлюзов и софтсвичей оператора. Нужна единая точка входа в сеть оператора.
- При использовании распределённой инфраструктуры трудно получить информацию о качестве голоса. В единой точке входа в сеть лучше всего собирать статистику о RTP потоках при помощи возможностей протокола RTCP
Как предоставлять услуги домашним абонентам
- Есть необходимость сопрягать приватные сети операторов, в которых находится ядро голосовой сети с публичными сетями, в которых находятся абоненты.
- Остро стоит проблема преодоления NAT/Firewall абонентскими терминалами. На границе сети оператора нужно устройство, поддерживающее в открытом состоянии порты firewall абонентов
- Нужно контролировать и обеспечивать качество QoS и SLA для абонентов
Как защитить внутреннюю инфраструктуру оператора

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

Пограничный контроллер сессий (Session Border Controller, SBC), работая на пятом уровне модели OSI, позволяет операторам решить перечисленные проблемы и существенно повысить качество предоставления сервисов VoIP, видеоконференцсвязь и других систем реального времени для корпоративных и частных клиентов, а также качество передачи мультимедийного трафика между операторами. Установленный на границе сети SBC обеспечивает прохождение голоса и видео через NAT и межсетевые экраны, контроль за доступной полосой пропускания и управление количеством одновременных вызовов через канал фиксированной пропускной способности, взаимодействие устройств различных производителей, а также другие функции.

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

Продукты компании Acme Packet

Acme Packet, Inc. (NASDAQ: APKT) — мировой лидер в области пограничных контроллеров доступа (Session Border Controller — SBC) операторского класса.

Категория продуктов

Пограничные контроллеры сессий (Session Border Controllers — SBCs) представляют собой новый класс сетевого оборудования, которое предоставляет в распоряжение оператору связи критически важные функции управления для получения возможности предоставления высококачественных интерактивных услуг связи — речевых, видео- или мультмедийных сессий — через границы IP-сетей. Под «сессией» подразумевается любая интерактивная услуга связи (голос, видео, мультимедия), использующая сигнальные протоколы Уровня 5 (Уровня Сессий), такие как SIP, H.323, MGCP/NCS или Megaco/H.248. «Границей сети» является граница между двумя IP-сетями, такая как между оператором и клиентом/абонентом или между сетями двух операторов. Функции «управления» удовлетворяют новые потребности в таких областях, как безопасность, доведение до максимума зоны предоставления услуг, выполнение соглашений об уровне обслуживания (SLA), обеспечение поступления доходов, а также выполнение требований регламентирующих органов.

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

Серия Net-Net 4000

Оборудование серии Net-Net 4000 может быть сконфигурировано для поддержки как интегрированной, так и распределенной модели пограничного контроллера сессий. В качестве интегрированного SBC платформа Net-Net 4000 выполняет функции управления сессиями на границе сети и управления средой передачи данных (шлюза packet-to-packet — пакетного шлюза, осуществляющего преобразование между аудио, видео и мультимедиа-потоками, использующими различные алгоритмы сжатия) с высокой степенью интеграции. Распределенная конфигурация SBC позволяет физически разделить функции управления сессиями на границе сети и функции управления средой передачи данных посредством стандартного интерфейса управления H.248. Конкретные варианты конфигурации включают в себя:

4000 Session Director (SD) — устройство управления сессиями — интегрированный пограничный контроллер сессий с функциями мультипротокольного управления сессиями, маршрутизации, безопасности и управления средой передачи данных
4000 Session Controller (SC) — контроллер сессий —мультипротокольное устройство с функциями управления сессиями на границе сети и безопасности, управляющее пограничными шлюзами или шлюзами packet-to-packet сторонних производителей, по протоколу H.248
4000 Border Gateway (BG)— пограничный шлюз — шлюз packet-to-packet, выполняющий функции внедрения правил и преобразования сетевых адресов и портов, управляемый контроллером сессий или элементами управления сессиями сторонних поставщиков по протоколу H.248
4000 Session Router (SR)— маршрутизатор сессий — прокси-сервер с функциями SIP-маршрутизации и кластерный сервер для использования в конфигурации Net-Net PAC (когда устройства объединяются в стек)

Основные параметры Acme Packet Net-Net 4000:

Оборудование Net-Net 4000 работает под управлением операционной системы Acme Packet’s Net-Net OS, обеспечивающей полную поддержку сигнализации по протоколам SIP, H.323, SIP-H.323 inter-working, MGCP/NCS и H.248.

Оборудование Net-Net 4000 может управляться с помощью системы управления сетевыми элементами Net-Net EMS, представляющей собой приложение клиент/сервер, использующее графический интерфейс пользователя/браузер, поддерживающее управление конфигурированием, обнаружением и устранением отказов, обеспечением производительности и безопасности для нескольких устройств SBC, установленных на нескольких сетях. Другими инструментами управления являются CLI, telnet, FTP, XML, RADIUS, SNMP v2c и syslog.

Серия Net-Net 9000

Оборудование серии Net-Net 9000 может быть сконфигурировано для поддержки как интегрированной, так и распределенной модели пограничного контроллера сессий (SBC). В качестве интегрированного SBC платформа Net-Net 9000 выполняет функции управления сессиями на границе сети и управления средой передачи данных (шлюза packet-to-packet) с высокой степенью интеграции. Распределенная конфигурация SBC позволяет физически разделить функции управления сессиями на границе сети и функции управления средой передачи данных посредством стандартного интерфейса управления H.248. Конкретные варианты конфигурации включают в себя:

9000 Session Director (SD) — устройство управления сессиями — интегрированный пограничный контроллер сессий с функциями мультипротокольного управления сессиями, маршрутизации, безопасности и управления средой передачи данных
9000 Session Controller (SC) — контроллер сессий — мультипротокольное устройство с функциями управления сессиями на границе сети и безопасности, управляющее пограничными шлюзами или шлюзами packet-to-packet сторонних производителей, по протоколу H.248
9000 Border Gateway (BG)— пограничный шлюз — шлюз packet-to-packet, выполняющий функции внедрения правил и преобразования сетевых адресов и портов, управляемый контроллером сессий или элементами управления сессиями сторонних поставщиков по протоколу H.248
9000 Session Router (SR)— маршрутизатор сессий — прокси-сервер с функциями SIP-маршрутизации и кластерный сервер для использования в конфигурации Net-Net PAC (когда устройства объединяются в стек)

Основные параметры Acme Packet Net-Net 9000:

Оборудование Acme Packet Net-Net 9000 представляет собой шасси размером 7U в модульном исполнении, имеющем в своем составе объединительную панель (mid-plane), объединяющую 7 посадочных мест с фронтальной стороны и 6 посадочных мест с тыльной стороны для пяти различных функциональных блоков SBC. Данные блоки включают в себя блоки обработки сигнализации, сетевой обработки, преобразования кодеков, сетевых интерфейсов и интерфейсов управления.

Серия Net-Net 3820

Оборудование серии Net-Net 3820 позиционируется как Session Border Controller для крупных предприятий или небольших операторов связи. Net-Net 3820 может быть сконфигурирован в качестве Session Director (SD) или в качастве Session Router.

Основные параметры Acme Packet Net-Net 3820:

Пропускная способностьсреды передачи данных (media capacity) — до 8 000 медиа-сессий с использованием аппаратных средств генерирования отчетов о качестве обслуживания с задержкой менее 15 мкс
Сетевые интерфейсы — два или четыре 1000 Мбит/c или восемь интерфейсов 10/100 Мбит/с Ethernet
Интерфейсы управления — 3 выделенных интерфейса 10/100 Мбит/c Ethernet для управления и связанных с ним услуг
Высокая доступность — активные/резервные системы с использованием метода анализа контрольных точек состояния (сигнализации, среды передачи данных и конфигурации) на предмет отсутствия перебоев в обслуживании
Исполнение — монтируется в стойку, размер 1 U
Емкость локальной таблицы маршрутизации — до 1000000 направлений

Компания «Инлайн Телеком Солюшнс» имеет большой опыт внедрения оборудования Acme Packet. Мы имеем сертифицированных специалистов по этому оборудованию как в департаменте внедрения и интеграции, так и в службе технической поддержки.

Получив на руки 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 потоки

Итак, мы подключились. Получили приглашение - нужен логин и пароль, ищем их в документации и ничего не находим.
Что ж, вот они:

Параметры загрузки живут в bootparam

Здесь нас интересует
inet on ethernet (e) : 192.168.2.2:ffffff00
gateway inet (g) : 192.168.2.1
ffffff00 - это маска сети.

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

Сеть для интерфейса управления желательно выбрать отличную от сети сигнального и потокового трафика.

После этого можно подключаться по SSH.
Если у вас планируется установка с резервированием, то те же настройки нужно произвести и на втором сервере, естественно с другим IP адресом и другим host name.

Перед дальнейшей настройкой требуется описать особенности CLI.
К сожалению, CLI Acme Packet отличается от Cisco, и, как факт, менее удобен для пользователя. В чем отличие - в выборе определенного конфигурационного элемента, то есть, если нужно отредактировать phy-interface wancom1, то нужно дать следующую последовательность:

(а вот тут появляется особенность!)

Команда select определяет конфигурируемый элемент, что не дает пользователю скопировать часть конфигурационного файла и, подправив, сконфигурировать другой элемент методом простой вставки.
Еще одно отличие (опять не в пользу Acme): для конфигурирования следующего элемента нужно закончить конфигурирование текущего командой done или exit, после exit появится запрос save yes/no.
При создании нового элемента команда select не выполняется (ну нечего пока выбирать).
Для полноты картины нужно указать, что дерево CLI сразу разделяется на несколько веток:

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

Теперь конфигурируем систему резервирования (если, конечно, она у вас есть).
Ниже приведен листинг команды sh run:

Заходим на SBC-1 и программируем его.
Т.к. просто скопировать информацию с экрана и вставить ее мы не можем, придется создать всю эту красоту последовательно, руками.
Если что-то ввели неправильно, для коррекции не забываем про 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

Осталось настроить 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

Теперь холст готов, можно рисовать картину маслом!

6 комментариев:

Молодец, спасибо. Описание толковое. Все понятно изложено!

Спасибо за отзыв!

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

Добрый день.
Наткнулся на вашу статью, сейчас тоже встала задача построить кластер на базе Net 3800.
У меня есть вопросик который меня обескураживает, и на который нигде не могу найти ответа.
В вашей конфигурации следующий кусок :
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) применяются для обеспечения безопасности, надежности и совместимости голосовых сервисов в IP сетях. Устройства устанавливаются на границе между IP-сетью предприятия и сетями операторов связи. Одной из главных функций пограничного контроллера сессий является обеспечение безопасности системы IP-телефонии. Устройство защищает системы телефонии от несанкционированного доступа, краж трафика и различных атак. Также, пограничные контроллеры сессий обеспечивают контроль качества обслуживания, балансируют нагрузку между различными каналами связи (в том числе с целью оптимизации расходов) и обеспечивают непрерывность сервисов. Помимо этого, за счет наличия большого набора сигнализаций и механизмов нормализации трафика, пограничные контроллеры сессий обеспечивают совместимость между устройствами различных производителей. Линейка контроллеров сессий представлена следующими моделями:

Oracle Acme Packet Virtual Machine Edition (VME)

Программная версия контроллера сессий на 25-250 пользователей
Поддержка платформ VMware ESXi и Microsoft HyperV

Oracle Acme Packet 1100

Количество одновременных сессий – от 5до 360
Количество сессий с транскодингом – до 360
Сетевые интерфейсы – 4 интерфейса 10/100 Ethernet
Возможность установки модуля E1 для TDM сетей
Поддержка режима высокой доступности (Active/Standby)
Поддержка балансировки нагрузки

Oracle Acme Packet 3820

Количество одновременных сессий – до 8 000
Количество сессий с транскодингом – до 7 200
Сетевые интерфейсы – 4 интерфейса 10/100/1000 Ethernet/SFP
Производительность системы – 5 Gb/sec
Поддержка режима высокой доступности (Active/Standby)
Поддержка балансировки нагрузки
Возможность резервирования питания.

Oracle Acme Packet 4600

Количество одновременных сессий – до 80 000
Количество сессий с транскодингом – до 15 000
Сетевые интерфейсы – 4 порта GbE (SFP) либо 2 порта 10 GbE (SFP+)
Производительность системы – 20 Gb/sec
Поддержка режима высокой доступности (Active/Standby)
Поддержка балансировки нагрузки
Возможность резервирования питания.

Oracle Acme Packet 6300

Количество одновременных сессий – до 120 000
Количество сессий с транскодингом – до 60 000
Сетевые интерфейсы – 2 порта 10 GbE (SFP+)
Производительность системы – 40 Gb/sec
Поддержка режима высокой доступности (Active/Standby)
Возможность резервирования питания.
Модули охлаждения с возможностью «горячей» замены

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

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

Растущая заинтересованность в виртуализации приложений и сетевой функциональности только добавляет вопросов типа «возможно ли развернуть SBC в виртуальной среде и не проиграть в функциональности».

Как видно из названия, SBC (Session Border Controller, пограничный контроллер сессий) – это оборудование (или ПО), устанавливаемое на границе сетей и что-то контролирующее.

Контроль, который обеспечивает SBC, в первую очередь касается именно голосового трафика (сигнального и медийного), объемы которого растут в силу перехода от TDM к IP, набирающего обороты день ото дня. Сразу отметим, что этот тип оборудования ничего общего не имеет с файерволами и системами безопасности, работающими на уровне IP в обычных сетях СПД. Скорее наоборот, он дополняет и покрывает те участки, где даже самый продвинутый файервол ничего проконтролировать и тем более защитить не сможет.

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

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

Теперь поедем дальше, обсуждая только SBC и вычеркнув из рассмотрения всяческие ALG.

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

3. Защита сетей
Скрытие топологии – это только один из многих аспектов, о которых приходится говорить во время обсуждения темы защиты голосовых сетей. В большинстве случаев, если не всегда, вопрос организации правильной стратегии защиты наталкивается на стандартную дилемму – защитить сеть и при этом не навредить сервису/бизнесу. Зажать в строгие правила обработки и анализа можно любой трафик, главное при этом обеспечить разумную и корректную работу всех сервисов и не дать повода абоненту/заказчику уйти к вашему конкуренту, который более грамотно настроил свою сеть и обеспечил возможность пользоваться расширенным набором сервисов. Я упоминаю здесь об этом потому, что на практике сплошь и рядом встречаются администраторы сетей, которые такой баланс не соблюдают либо в силу недостаточности знаний, либо по причине отсутствия достаточного внимания этому вопросу. Да и надо честно признать, что профессиональных специалистов в области передачи голоса не так много.

Обозначу основные моменты, на которые стоит обратить внимание при решении вопросов защиты.

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

b) DoS/DDoS VoIP атаки
Задосить незащищенное голосовое оборудование можно легко, нужно только желание. И поверьте, есть масса способов сделать это, даже если применяется супер-пупер дата-файерволл. И снова проблема в том, что никакое СПД-шное оборудование не защитит, например, от безумного количества регистраций, посланных от имени корректного и легитимного абонента. Или от неимоверного количества попыток установления вызова на легитимного абонента. А все дело в том, что любой файерволл ОБЯЗАН пропусть весь этот трафик без ограничений, потому что он предназначается абсолютно легимному абоненту, а значит, должен быть обработан.

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

c) Некорректные голосовые пакеты
Под посылкой некорректных голосовых пакетов можно понимать несколько разных неприятных моментов, например:

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

f) Возможность задавать произвольные правила анализа и проверки (классификация трафика)
Нормальный SBC должен уметь и позволять настраивать не только шаблонные часто использующиеся правила анализа трафика, но и любые разумные «хотелки/проверялки». В качестве примера, немного утрируя, приведу такое «идиотское» правило проверки: если входящий INVITE содержит более двух заголовков Via, а третий заголовок Via содержит IP адрес вида 172.х.х.100, и при этом поле From в части user part имеет набор букв XYZ, то разрешить (или запретить) обработку такого трафика. Надеюсь, понятно, что такая возможность добавляет гибкости при использовании SBC.

h) Статические черные/белые списки и access листы
Ну а как же без этого? Пример: вы обнаружили злокачественный трафик, имеющий характерные признаки и причиняющий вред вашей сети. Например потому, что ваш администратор «забыл» или не подумал сконфигурировать и задать поведение SBC для какого-то сценария. Для быстрой блокировки просто закрываете поток зла, сразу весь, возможно и с частью полезного трафика. А потом начинаете думать и создавать то самое правило, которого не хватало.

Наверняка можно привести еще много примеров и задач, связанных с темой защиты. Мы рассмотрели самые основные. Для большинства ситуаций описанных возможностей SBC должно хватить.

8. Взаимодействие с сетями, имеющими стык с SS7 (поддержка SIP-I/SIP-T)
Тоже важная тема. Особенно сейчас, когда становится все более доступной возможность организации прямых межоператорских стыков с использованием SIP. Да и при подключении корпоративных клиентов тема тоже остается весьма актуальной, поскольку требуется конвертация SIP-I в обычный SIP.

Здесь речь идет о способности обрабатывать SIP трафик, в котором в SDP части передается контекст сигнализации ОКС-7, который может существенно повлиять на корректность отработки некоторых сервисов, например трансферов/форвардов, или даже прохождению базового вызова на границе двух операторов. Чтобы корректно решать эти проблемы, требуется возможность модификации некоторых полей в SDP части при прохождении транзитного вызова, или корректная конвертация SIP-I в обычный SIP. И это уже абсолютно точно функциональность профессиональных SBC, особенно если вспомнить количество различных вариантов и стандартов сигнализации ISUP. А как раз о ней и идет речь, когда мы говорим о передаче контекста ОКС-7 через SIP.

9. SIPREC для стыка с внешними система записи трафика
Тут вроде как все просто. Бывают задачи, когда требуется запись разговоров. Сразу оговоримся, что это не СОРМ (хотя иногда может применяться как workaround для СОРМ). Это запись разговоров. И речь тут о стыке со специализированными системами и решениями, которые такую задачу выполняют. Выполняется она посредством протокола Session Recording Protocol (SIPREC). Детали можно найти здесь.

Эта тема важна для части бизнес-задач. Сложность в том, что в задачах записи сессий существуют уникальные требования, которые не решены в существующих спецификациях протокола SIP. Речь идет о некоторых технических особенностях реализации решений, а также о вопросах безопасности и сохранения личных данных. Кроме этого, есть требование извещать абонента о том, что его разговор записывается. Для решения всех этих вопросов и был разработан SIPREC. Реализован далеко не у всех.

10. Разделение типов трафика по различным интерфейсам
Немного писал уже об этом. Сформулируем по-другому. Вариантов внедрения может быть много. Разделение внешнего и внутреннего трафика по различным физическим интерфейсам – это только часть. Порой нужно чтобы разный тип трафика был разделен по разным физическим интерфейсам. Например, сигнализация на одном, медиа на другом, управление на третьем. А может, нужно комбинировать. В общем, вариантов много. Полная поддержка добавляет гибкости.

11. Обеспечение взаимодействия IPv4 <-> IPv6
Тут все вроде бы просто, особых комментариев не требуется. Внедрения IPv6 уже есть, чем дальше, тем больше. Раз уж SBC стоит на границе голосовых сетей, то это его прямая обязанность – выполнять конвертацию.

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

a) Конвертация TCP <-> UDP, TCP <-> TLS, UDP <-> TLS, динамическое изменение протокола транспортного уровня.
SIP поддерживает не только UDP. Существуют и другие варианты. На стыке сетей сплошь и рядом встает задача такой конвертации. И конечно же удобно, если это выполняется не только в фиксированной конфигурации, которая чаще всего встречается при подключении SIP транка, а и динамически. Ну представьте хотя бы абонентов, которые регистрируются на вашей голосовой платформе. Одни используют UDP, другие – TCP или вообще TLS. Как вы заранее поймете, как поступать с конкретным абонентом? Конечно лучше выполнять эту задачу динамически.

b) Конвертация RTP <-> SRTP
Тут тоже понятно и достаточно часто встречается. Конвертация RTP в SRTP и наоборот нужна несомненно.

c) Конвертация T.38 <-> G.711
Классика жанра. Давно и долго кричат все про смерть факсимильной связи. Но это далеко от реалий. Этот вид связи как использовался, так и продолжает использоваться. Конечно, современные системы уже в большинстве случаев экономят бумагу и отправляют факс на электронную почту в виде файла. Но от этого механизм передачи факса не меняется. Два самых распространенных формата передачи несовместимы друг с другом и требуется преобразование, если два абонента посылают факс друг другу, используя разные методы.

d) DTMF транскодинг (RFC2833 <-> inband <-> SIP INFO)
Тоже классическая проблема. Сигналы DTMF могут передаваться по-разному. Это зависит от настроек и возможностей/функциональности конкретного абонентского оборудования и голосового решения, предоставляющего конечный сервис. Но факт, что DTMF должен дойти из конца в конец. А что на пути и какой метод используется, это больной вопрос. Конвертация между различными методами крайне важна.

e) Транскодинг кодеков
Современный мир телекома движется вперед очень быстро. Ну вот пример некоторых типов кодеков, которые достаточно часто встречаются в последнее время:

G.723; G.729; G.728; NETCODER; GSM-FR; GSM-EFR; AMR; EVRC-QCELP; G.727; ILBC; EVRC-B; AMR-WB; G.722; EG.711; MS_RTA; SILK; SPEEX; OPUS.

На межоператорском стыке вопрос транскодирования в основном ограничивается транскодингом G.711 и G.729, хотя бывают и более экзотические случаи. Но при подключении корпоративных заказчиков или небольших операторов зачастую возникает задача совсем нетривильная, связанная с использованием так называемых «тяжелых» кодеков, применяющихся в специфических услугах и сервисах. Использование современных веб-сервисов или некоторых мобильных приложений также предполагает использование кодеков, отличных от общепринятых.

f) Ptime транскодирование.
Его правильнее было бы назвать по-другому, поскольку собственно транскодинга тут и как такового нет. Есть изменение времени пакетизации в рамках одного и того же кодека. Ответ на вопрос «зачем» очень прост – экономия полосы в канале. Для некоторых применений это очень важная задача и решается таким способом, позволяя экономить полосу и вычислительные мощности оборудования.

13. Поддержка REST
Многим это не нужно и они даже не заморачиваются на эту тему. Однако поддержка REST API позволяет гибко и очень просто решать многие и многие задачи. Интеграция со сторонними решениями, управление и безболезненная переконфигурация системы проводится очень быстро и не вызывает сложностей. В технологии NFV (Network Function Virtualization) протокол REST используется подавляющим большинством оркестраторов для целей контроля и управления NVF-элементов (Network Virtual Function element).

14. WebRTC и поддержка так называемых web-кодеков (например, OPUS)
WebRTC – также отдельная тема, позволяющая добавлять оператору много новых современных услуг и захватывать те ниши, на которые ранее и даже мысли не приходило обращать внимание. В основе своей WebRTC — это бесплатная open-project технология выполнения звонков, видео, чатов, передачи файлов в интернет без установки дополнительного оборудования или программного обеспечения (типа flash плейра, плагинов и пр.), напрямую из браузера персонального компьютера, с помощью Javascript API. Привлекательность и применимость очевидна. Техническая реализация требует использования WebRTC шлюза, поскольку применяется тут вовсе не SIP.

15. Маршрутизация SIP трафика на основе IP адресов, А и Б номеров, времени суток, доступности оборудования, стоимости минуты трафика и т.д. и т.п
О необходимости выполнять гибкую маршрутизацию на SBC можно говорить долго. Она нужна, и чем гибче возможности, тем больше выгоды для оператора, особенно для тех, кто использует I-SBC для пиринга. Для A-SBC задача гибкой маршрутизации также важна, особенно в случае предоставления услуг виртуальной АТС.

16. Возможность перемаршрутизации трафика на основе ответа оконечного оборудования
Эту задачу выделил отдельно, для I-SBC при пиринге она критически важна.

17. QoS для приоритезации трафика на определенном IP направлении или для определенного пользователя/клиента
Функциональность тоже, на мой взгляд, не требует детального описания и обсуждения. Подключаемые клиенты и операторы вправе заботиться о качестве и часто просят его обеспечить. А некоторые, так вообще требуют отчетов по качеству передаваемого трафика. В итоге побеждает тот, у кого качество выше.
В идеале, конечно, выигрывает тот, чей SBC умеет сохранять статистику о качестве любого звонка, которые он обработал. Это такие параметры как джиттер, потери пакетов, задержки, эхо, MOS, причины завершения вызова, инициатор завершения вызова, и многое другое. Иными словами, SBC одновременно выступает в качестве пробника трафика на сети.

18. Call Admission Control, ограничения по количеству сессий, полосы пропускания, др. параметрам
Ну а эта функциональность очень часто граничит с задачей экономии денег. Ну потому что нужно и важно контролировать ресурсы своего решения, практически грамотно и рационально ограничивая вашего заказчика или абонента от «поглощения» всех или большей части доступных ресурсов, ограничивая и контролируя нагрузку на ядро сети (SIP сервер, софтсвитч и т.д.)

19. Балансировка трафика (load balancing)
Функциональность важна, когда сложность сети позволяет организовывать и выстраивать гибкие схемы отработки услуг и трафика. Причем работает в обе стороны. У кого-то есть, например, резервные каналы и их использование приветствуется для организации не только отказоустойчивых схем, но и для распределения нагрузки на сеть или распределения сервисов по элеменам ядра сети.

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

21. Возможность обеспечения одновременной обработки трафика для режимов access (доступ с регистрацией для услуг типа виртуальной АТС) и peering (обеспечение стыка по SIP транкам)
Часто можно встретить такое ограничение, когда SBC может работать только в каком-то одном режиме. Или только пиринг, или только на доступе. Иногда применение только одного из режимов на самом деле обусловлено схемой и задачей применения SBC. Но возможность работы только в одном режиме накладывает существенные ограничения на планирование и работу сервисов на сети, вынуждая покупать второе устройство для реализации полной схемы для одновременного использования SIP транков и абонентского трафика с регистрацией абонентов на SIP сервере. Поэтому возможность работать одновременно в двух режимах важно.

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

"Основы конфигурирования пограничного контроллера сессий Oracle Rel.6" (CAB-C) является базовым курсом, направленным на выработку навыков конфигурирования и эксплуатации пограничного контроллера сессий Net-Net 4000. Курс охватывает основы протокола SIP, необходимые для успешного освоения методов конфигурации Net-Net 4000 в средах межсетевого взаимодействия и взаимодействия между пользователем и сетью. Курс предусматривает ознакомление слушателей с различными рекомендованными сценариями внедрения Net-Net 4000 ("Best Current Practice"), а также применение полученных знаний на практике. Существенная часть времени курса отведена практическим аспектам администрирования Net-Net 4000, включая управление доступом пользователей, резервирование, восстановление конфигураций.

Курс предназначен для технических специалистов, по роду своей деятельности вовлеченных в настройку и администрирование пограничных контроллеров сессий Net-Net 4000.

Требования к подготовке слушателей:

Слушатели курса должны иметь общее представление о следующих темах:

Программа курса:

Модуль 0: Представление компании Acme Packet и обзор курса

Модуль 1: Ознакомление с понятием Session Border Controller (SBC)

Основные функции SBC;
Определение основных компонент Net-Net OS;
Ознакомление с аппаратным обеспечением Net-Net 4000;

Модуль 2: Начальное конфигурирование

Навигация в CLI
Режимы работы и сокращенные команды
Восстановление фабричной настройки Net-Net SD
Базовая конфигурация Net-Net SD
Сохранение и активирование изменений в конфигурации
Контроль над версиями конфигураций
Лабораторная работа № 1

Модуль 3: Администрирование системы

Модуль 4: Обозрение Net-Net 4000 Session Director

Обозрение аппаратного обеспечения
Концепции Net-Net 4000 Session Director
Архитектура SIP
Архитектура H.323

Модуль 5: Введение в Session Initiation Protocol (SIP)

Модуль 6: Конфигурирование SIP в среде межсетевого взаимодействия

Рекомендованные сценарии настройки Net-Net 4000
Конфигурирование различных рекомендованных сценариев
Проверка правильности конфигурации
Лабораторная работа № 4

Модуль 7: Конфигурирование SIP в среде взаимодействия между пользователем и сетью

Рекомендованные сценарии настройки Net-Net 4000
Конфигурирование различных рекомендованных сценариев
Проверка правильности конфигурации
Лабораторная работа № 5

Модуль 8: Настройка Net-Net 4000 в режиме High Availability (HA)

Читайте также: