По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Session Border Controller (контроллер граничных сессий) - сетевое устройство, которое может обеспечить безопасность VoIP, а так же соединять несовместимые (разнородные) сигнальные протоколы и медиа потоки, поступающие от различных устройств. SBC – устройства используются в корпоративных сетях и сетях провайдеров услуг и, как правило, развертываются на границе сети (точка входа провайдера в корпоративный контур).
В основном, несмотря на способность устройств поддерживать H.323, SCCP и прочие, фокус работы SBC сделан на обеспечении безопасности SIP – протокола, а так же сопряжении различных версий SIP.
Основная идея
SBC защищает от атак сеть телефонии и соответствующие сервера, выполняя роль B2BUA (back-to-back user agent), схожую по типу работы с SIP прокси – сервером. Контроллер терминирует каждую сессию (завершает), а затем заново ее инициирует, выступая в роли агентского сервера UAS (User Agent Server) и агентским клиентом UAC (User Agent Client), работая с каждым из «плеч» вызова по отдельности.
На базе собственных мощностей SBC реализует списки контроля доступа ACL, ограничение DDOS атак, а так же анализ пакетов на предмет искажения информации с целью нанести ущерб. Анализируя SIP, SBC анализирует заголовки и поле полезной нагрузки. Особенно это актуально в SDP – сообщениях, к которым может применяться множество правил модификации.
Помимо сигнальной информации, SBC обрабатывает RTP потоки, тем самым, обеспечивает не только шифрование медиа, но и выполняет функции транскодинга (преобразования потока из одного кодека в другой) в случаях, когда две стороны SIP – коммуникации не могут согласовать параметры передачи данных в сообщениях SDP. Кстати, на SBC обычно реализуют так называемый SIP forking, который позволяет дублировать сессию на третье устройство, например, такое как система записи телефонных разговоров.
В современных версиях SBC, сигнальная информация и потоки изолированы друг от друга (с точки зрения обработки устройством) – это обеспечивает высокие параметры масштабирования.
Давайте рассмотрим на примеры схемы ниже принцип работы SBC:
Предыдущая статья из цикла про популярные приложения TCP/IP тут.
Установление TCP-соединения происходит до того, как любая из других функций TCP сможет начать свою работу. Установление соединения относится к процессу инициализации полей "Sequence" и "Acknowledgment" и согласования используемых номеров портов. На рисунке 5 показан пример процесса установления соединения.
Этот трехсторонний процесс установления соединения (также называемый трехсторонним рукопожатием) должен завершиться до начала передачи данных. Соединение существует между двумя сокетами, хотя в заголовке TCP нет единственного поля сокета. Из трех частей сокета подразумеваются IP-адреса на основе IP-адресов источника и назначения в IP-заголовке. TCP подразумевается, потому что используется заголовок TCP, как указано значением поля протокола в заголовке IP. Следовательно, единственные части сокета, которые необходимо закодировать в заголовке TCP, - это номера портов.
TCP сообщает об установлении соединения, используя 2 бита в полях флагов заголовка TCP. Эти биты, называемые флагами SYN и ACK, имеют особенно интересное значение. SYN означает "синхронизировать порядковые номера", что является одним из необходимых компонентов при инициализации TCP.
На рисунке 6 показано завершение TCP-соединения. Эта четырехсторонняя последовательность завершения проста и использует дополнительный флаг, называемый битом FIN. (FIN - это сокращение от "finished", как вы могли догадаться.) Одно интересное замечание: перед тем, как устройство справа отправит третий сегмент TCP в последовательности, оно уведомляет приложение о том, что соединение прерывается. Затем он ожидает подтверждения от приложения перед отправкой третьего сегмента на рисунке. На случай, если приложению потребуется некоторое время, чтобы ответить, ПК справа отправляет второй поток на рисунке, подтверждая, что другой ПК хочет разорвать соединение. В противном случае ПК слева может повторно отправить первый сегмент.
TCP устанавливает и завершает соединения между конечными точками, а UDP - нет. Многие протоколы работают в рамках одних и тех же концепций, поэтому термины "ориентированный на соединение" и "без установления соединения" используются для обозначения общей идеи каждого из них. Более формально эти термины можно определить следующим образом:
Протокол, ориентированный на соединение: протокол, который требует обмена сообщениями до начала передачи данных или который имеет требуемую предварительно установленную корреляцию между двумя конечными точками.
Протокол без установления соединения: протокол, который не требует обмена сообщениями и не требует предварительно установленной корреляции между двумя конечными точками.
Восстановление после ошибок и надежность
TCP обеспечивает надежную передачу данных, что также называется reliability or error recovery. Для обеспечения надежности TCP нумерует байты данных, используя поля "Sequence" и "Acknowledgment" в заголовке TCP. TCP обеспечивает надежность в обоих направлениях, используя поле Sequence Number одного направления в сочетании с полем Acknowledgment в противоположном направлении.
На рисунке 7 показан пример того, как поля TCP Sequence и Acknowledgment позволяют ПК отправлять 3000 байтов данных на сервер, при этом сервер подтверждает получение данных. Сегменты TCP на рисунке расположены по порядку, сверху вниз. Для простоты все сообщения содержат 1000 байтов данных в части данных сегмента TCP. Первый порядковый номер - красивое круглое число (1000), опять же для простоты. В верхней части рисунка показаны три сегмента, каждый из которых на 1000 больше предыдущего, что указывает на первый из 1000 байтов сообщения. (То есть в этом примере первый сегмент содержит байты 10001999; второй - байты 20002999, а третий - байты 30003999.)
Четвертый сегмент TCP на рисунке - единственный, который возвращается от сервера к веб-браузеру - подтверждает получение всех трех сегментов. Как? Значение подтверждения 4000 означает: "Я получил все данные с порядковыми номерами на единицу меньше 4000, поэтому я готов принять ваш байт 4000 следующим". (Обратите внимание, что это соглашение о подтверждении путем перечисления следующего ожидаемого байта, а не номера последнего полученного байта, называется прямым подтверждением.)
Однако этот пример не исправляет никаких ошибок; он просто показывает основы того, как хост-отправитель использует поле порядкового номера для идентификации данных, а хост-получатель использует прямые подтверждения для подтверждения данных. Более интересное обсуждение вращается вокруг того, как использовать эти же инструменты для восстановления ошибок. TCP использует поля "Sequence" и "Acknowledgment", чтобы принимающий хост мог заметить потерю данных, попросить отправляющий хост повторно отправить, а затем подтвердить, что повторно отправленные данные прибыли.
Существует множество вариантов того, как TCP выполняет исправление ошибок. На рисунке 8 показан только один такой пример, детализация которого аналогична предыдущему. Веб-браузер снова отправляет три сегмента TCP, снова по 1000 байт каждый, снова с легко запоминающимися порядковыми номерами. Однако в этом примере второй сегмент TCP не может пройти через сеть.
Рисунок указывает на три набора идей, лежащих в основе того, как думают два хозяина. Во-первых, справа сервер понимает, что он не получил все данные. Два полученных сегмента TCP содержат байты с номерами 10001999 и 30003999. Очевидно, сервер не получил байты, пронумерованные между ними. Затем сервер решает подтвердить все данные вплоть до потерянных, то есть отправить обратно сегмент с полем подтверждения, равным 2000.
Получение подтверждения, которое не подтверждает все данные, отправленные на данный момент, заставляет хост-отправитель повторно отправить данные. ПК слева может подождать несколько секунд, чтобы убедиться, что другие подтверждения не поступят (используя таймер, называемый таймером повторной передачи), но вскоре решит, что сервер сообщает: "Мне действительно нужно 2000 - отправьте его повторно". ПК слева делает это, как показано на пятом из шести сегментов TCP на рисунке.
Наконец, обратите внимание, что сервер может подтверждать не только повторно отправленные данные, но и любые предыдущие данные, которые были получены правильно. В этом случае сервер получил повторно отправленный второй сегмент TCP (данные с порядковыми номерами 20002999), и сервер уже получил третий сегмент TCP (данные с номерами 30003999). Следующее поле подтверждения сервера подтверждает данные в обоих этих сегментах с полем подтверждения, равным 4000.
Управление потоком с использованием окон
TCP реализует управление потоком, используя концепцию окна, которая применяется к количеству данных, которые могут быть ожидающими подтверждения в любой момент времени. Концепция окна позволяет принимающему хосту сообщать отправителю, сколько данных он может получить прямо сейчас, давая принимающему хосту способ замедлить или ускорить отправляющий хост. Получатель может перемещать размер окна вверх и вниз (это называется скользящим окном или динамическим окном), чтобы изменить объем данных, который может отправить хост-отправитель.
Механизм раздвижного окна имеет больше смысла на примере. В примере, показанном на рисунке 9, используются те же основные правила, что и в примерах на нескольких предыдущих рисунках. В этом случае ни один из сегментов TCP не содержит ошибок, и обсуждение начинается на один сегмент TCP раньше, чем на предыдущих двух рисунках.
Начнем с первого сегмента, отправленного сервером на ПК. Поле Acknowledgment должно быть вам знакомо: оно сообщает ПК, что сервер ожидает следующий сегмент с порядковым номером 1000. Новое поле, поле окна, установлено на 3000. Поскольку сегмент передается на ПК, это значение сообщает ПК, что ПК может послать не более 3000 байтов по этому соединению до получения подтверждения. Итак, как показано слева, ПК понимает, что может отправлять только 3000 байтов, и прекращает отправку, ожидая подтверждения, после отправки трех 1000-байтовых сегментов TCP.
Продолжая пример, сервер не только подтверждает получение данных (без потерь), но и решает немного увеличить размер окна. Обратите внимание, что второе сообщение, идущее справа налево на рисунке, на этот раз с окном 4000. Как только ПК получает этот сегмент TCP, ПК понимает, что он может отправить еще 4000 байтов (окно немного больше, чем предыдущее значение).
Обратите внимание, что хотя на последних нескольких рисунках показаны примеры с целью объяснения того, как работают механизмы, из этих примеров может сложиться впечатление, что TCP заставляет хосты сидеть и долго ждать подтверждения. TCP не хочет заставлять хост-отправитель ждать отправки данных. Например, если подтверждение получено до того, как окно будет исчерпано, начинается новое окно, и отправитель продолжает отправлять данные до тех пор, пока текущее окно не будет исчерпано. Часто в сети, где мало проблем, мало потерянных сегментов и небольшая перегрузка, окна TCP остаются относительно большими, а узлы редко ждут отправки.
Закрепим самое важное про TCP и UDP в следующей статье.
Мир VoIP (Voice over IP) многогранен. На рынке существует целое множество решений для построения корпоративных систем связи – IP – АТС. Нас интересуют программные «open source» решения, поэтому, сегодня мы сравним две популярные телефонные платформы и ответим на вопрос: что круче, FreeSWITCH или Asterisk? :)
Про Asterisk
Давайте немного теории: Asterisk - программная автоматическая телефонная станция (АТС) на базе протокола IP, которая способна предложить богатый, с точки зрения телефонии, инструментарий для офиса. Asterisk, будучи одной из первых программных IP-АТС был создан в 1999 году как решение с открытым кодом (open source). При поддержке компании Digium в 2005 году IP – АТС увидела свет и была выпущена в «продакшн». Реализация происходит под двумя лицензиями: GNU GPL (General Public License) и патентная лицензия для разработки собственных решений на базе Asterisk, рассчитанных на дальнейшую продажу. Более миллиона пользователь радуются IP – АТС Asterisk каждый день по всему миру :)
Но не все так гладко (удар молнии за окном). Исторически, Asterisk имеет ряд проблем, связанных с масштабируемостью, нестабильностью работы при повышении нагрузки. С учетом особенностей лицензирования, многие пользователи (в том числе компании - разработчики) искали новый продукт.
Про FreeSWITCH
В 2006 году группа бывших разработчиков Asterisk приняли решение разработать альтернативное решение – на свет появился FreeSWITCH. Вдохновленные модульной структурой веб – сервера Apache, команда разработчиков преследовала цель улучшить параметры масштабируемости и стабильности работы на разных платформах.
FreeSWITCH создан по модели состояний, вследствие чего, каждый вызов(канал) работает по отдельному потоку данных. Для построения структуры, использовались компоненты open – source решений, такие как, например, Sofia SIP – SIP UA с открытым исходным кодом, созданный компанией Nokia.
Что под капотом?
Asterisk – модульная структура. Во время работы, Asterisk использует общие ресурсы, включая программные потоки – это главная проблема при большой интенсивности вызовов.
Несмотря на сложность и многогранность программного кода, на котором написан Asterisk, он находит огромное множество применений в сети. С другой стороны, FreeSWITCH написан на C, структура которого более понятна и прозрачна. Потоки процессов выполняются последовательно и отдельно для каждого канала, что безусловно отличает Фрисвитч от Asterisk. При этом, как правило, по этой причине FreeSWITCH требует больший объем оперативной памяти (RAM)
Отметим, что FreeSWITCH имеет хорошо документированный API (Application Programming Interface), сегментированный по ролям. Такая структура обеспечивает безопасное подключение к API в отличие от Asterisk, где более открытая конструкция API допускает вероятность внесения багов и ошибок.
Asterisk базируется на текстовых конфигурационных файлах, в то время как FreeSWITCH использует файлы формата .xml. Безусловно, с точки зрения работы с конфигами для админа, файлы текстового формата проще редактировать, однако, плюсы формата .xml всплывают на этапе автоматизации различных процессов.
Требования к железу
Оценить общие требования к IP – АТС достаточно сложно, так как в каждой инсталляции используется разный набор фичей и целей эксплуатации. Однако, в таблице ниже сконцентрированы минимальные требования к серверу, на котором будет развернут Asterisk и FreeSWITCH для работы 15 телефонными аппаратами и 5 одновременными вызовами. Сравните их:
Параметр
FreeSWITCH
Asterisk
CPU
Одно ядро, частота процессор 1 гГц
Одно ядро, частота процессор 700 мГц
RAM
1 ГБ
512 МБ
HDD
10 ГБ
10 ГБ
OS
Linux, 32/64 бит
Linux, 64 бит
Как видно, FreeSWITCH потребляет больше RAM. О причине этого мы писали ранее – это связано с архитектурой.
Функционал
С точки зрения базового набора функций, АТС идентичны. Голосовая почты, IVR, маршрутизация, intercom и другие опции доступны для обоих лагерей пользователей.
Рассмотрим преимущества, которые интересны для профессионального и более глубокого использования платформ. Начнем, пожалуй, с возможности FreeSWITCH создавать мульти – площадки. Фрисвич нативно (из коробки) умеет сегментировать площадки пользователей, разные домены и суб – домены. Это означает, что пользователи одной площадки не смогут дозвониться до пользователей другой по внутренним номерам. Другими словами, обеспечивается полнофункциональная сегрегация пользователей.
Так же, безусловным преимуществом FreeSWITCH стоит отметить возможность кластеризации (объединения нескольких серверов), где каждый хост в кластере будет выполнять свою определенную роль.
Итог
Подведем итоги. Мы составили таблицу с результатами, чтобы вам было проще ориентироваться:
Функция
FreeSWITCH
Asterisk
Малое потребление ресурсов сервера, включая ресурсы процессора и оперативной памяти
✕
✓
Документация и поддержка: решение проблем, форму, гайды, сильное комьюнити проекта
✕
✓
Богатый базовый функционал: конференции, видеозвонки, IVR, голосовая почта и так далее
✓
✓
Возможность реализации функций мульти - площадок (поддержка отдельных телефонных доменов с полной сегрегацией пользователей)
✓
✕
Внутренние механизмы устойчивости к повышению нагрузки, связанной с повышением количества одновременных вызовов
✓
✕
Объединение серверов в кластер, с последующим разделением ролей
✓
✕