Пограничный контроллер сеанса

Пограничный контроллер сеанса ( SBC ) — это сетевой элемент, развернутый для защиты SIP (VoIP) на основе сетей передачи голоса по интернет-протоколу .

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

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

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

Термин «контроллер» относится к влиянию, которое пограничные контроллеры сеансов оказывают на потоки данных, составляющие сеансы, когда они пересекают границы между одной частью сети и другой. Кроме того, пограничные контроллеры сеансов часто предоставляют средства измерения, контроля доступа и преобразования данных для контролируемых ими вызовов.

Функции

SBC обычно поддерживают полное состояние сеанса и предлагают следующие функции:

• Безопасность – защитите сеть и другие устройства от:
  • Вредоносные атаки, такие как атака типа «отказ в обслуживании» (DoS) или распределенный DoS.
  • Мошенничество с междугородной связью через мошеннические медиапотоки
  • Защита от некорректных пакетов
  • Шифрование сигнализации (через TLS и IPSec ) и мультимедиа ( SRTP )
• Возможность подключения – позволяет различным частям сети взаимодействовать с помощью различных методов, таких как:
  • Обход NAT
  • Нормализация SIP с помощью SIP-сообщений и манипулирования заголовками
  • Взаимодействие IPv4 и IPv6
  • VPN-подключение
  • Трансляции протоколов между SIP , SIP-I, H.323
• Качество обслуживания – политика QoS сети и приоритизация потоков обычно реализуется SBC. Он может включать в себя такие функции, как:
  • Дорожная полиция
  • Распределение ресурсов
  • Ограничение скорости
  • Контроль допуска звонков
  • ToS / DSCP Настройка бита
• Нормативно-правовые требования. Во многих случаях ожидается, что SBC обеспечит поддержку нормативных требований, таких как:
  • приоритезация экстренных вызовов и
  • законный перехват
• Медиа-сервисы. Многие SBC нового поколения также оснащены встроенными процессорами цифровых сигналов (DSP), которые позволяют им предлагать пограничный контроль мультимедиа и такие услуги, как:
  • Ретрансляция DTMF и взаимодействие
  • Транскодирование мультимедиа
  • Тоны и объявления
  • Взаимодействие данных и факсов
  • Поддержка голосовых и видеозвонков
• Статистика и информация о выставлении счетов. Поскольку все сеансы, проходящие через границу сети, проходят через SBC, это естественный момент для сбора статистики и информации об использовании этих сеансов.

С появлением WebRTC некоторые SBC также взяли на себя роль шлюза SIP для WebRTC и транслируют SIP. Хотя спецификациями WebRTC не предусмотрен ни один протокол сигнализации, SIP через WebSockets (RFC 7118) часто используется частично из-за применимости SIP к большинству предусмотренных сценариев связи, а также доступности программного обеспечения с открытым исходным кодом, такого как JsSIP . В таком случае SBC действует как шлюз между приложениями WebRTC и конечными точками SIP.

Приложения

SBC вставляются в пути сигнализации и/или мультимедиа между вызывающей и вызываемой сторонами в вызове VoIP, преимущественно в тех, которые используют протокол инициации сеанса (SIP), H.323 и MGCP протоколы сигнализации вызова .

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

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

Чтобы продемонстрировать работу SBC, можно сравнить простую последовательность установления вызова с последовательностью установления вызова с помощью SBC. В простейшей последовательности установления сеанса с одним прокси-сервером между пользовательскими агентами задача прокси-сервера состоит в том, чтобы идентифицировать местоположение вызываемого абонента и переслать ему запрос. Прокси-сервер также добавляет заголовок Via со своим собственным адресом, чтобы указать путь, по которому должен пройти ответ. Прокси-сервер не изменяет никакой идентификационной информации диалога, присутствующей в сообщении, такой как тег в заголовке From, Call-Id или Cseq. Прокси также не изменяют никакой информации в телах сообщений SIP. Обратите внимание, что на этапе инициации сеанса пользовательские агенты обмениваются сообщениями SIP с телами SDP, которые включают адреса, по которым агенты ожидают медиатрафика. После успешного завершения фазы инициации сеанса пользовательские агенты могут обмениваться медиа-трафиком напрямую друг с другом без участия прокси-сервера.

SBC предназначены для множества приложений и используются операторами и предприятиями для достижения различных целей. Даже одна и та же реализация SBC может действовать по-разному в зависимости от ее конфигурации и варианта использования. Следовательно, нелегко описать точное поведение SBC, которое применимо ко всем реализациям SBC. В целом можно выделить определенные особенности, общие для SBC. Например, большинство SBC реализованы как последовательный пользовательский агент. B2BUA — это прокси-сервер, который разделяет транзакцию SIP на две части вызова: на стороне, обращенной к клиенту пользовательского агента (UAC), он действует как сервер, на стороне, обращенной к серверу пользовательского агента (UAS), он действует как клиент. . В то время как прокси-сервер обычно хранит только информацию о состоянии, связанную с активными транзакциями, B2BUA хранит информацию о состоянии активных диалогов, например, вызовов. То есть, как только прокси-сервер получит запрос SIP, он сохранит некоторую информацию о состоянии. Как только транзакция завершится, например, после получения ответа, информация о состоянии вскоре будет удалена. B2BUA будет хранить информацию о состоянии активных вызовов и удалять эту информацию только после завершения вызова.

Когда SBC включен в путь вызова, SBC действует как B2BUA, который ведет себя как сервер пользовательского агента по отношению к вызывающему абоненту и как клиент пользовательского агента по отношению к вызываемому абоненту. В этом смысле SBC фактически завершает вызов, сгенерированный вызывающей стороной, и начинает новый вызов вызываемой стороне. Сообщение INVITE, отправленное SBC, больше не содержит четкой ссылки на вызывающего абонента. INVITE, отправленное SBC прокси-серверу, включает заголовки Via и Contact, которые указывают на сам SBC, а не на вызывающую сторону. SBC часто также манипулируют идентификационной информацией диалога, указанной в тегах Call-Id и From. Кроме того, если SBC настроен также для управления медиатрафиком, тогда SBC также изменяет информацию адресации мультимедиа, включенную в строки c и m тела SDP. Таким образом, через SBC будут проходить не только все сообщения SIP, но и все аудио- и видеопакеты. Поскольку INVITE, отправленное SBC, устанавливает новый диалог, SBC также манипулирует порядковым номером сообщения (CSeq), а также значением Max-Forwards. Обратите внимание, что список манипуляций с заголовками, приведенный здесь, представляет собой лишь подмножество возможных изменений, которые SBC может внести в сообщение SIP. Более того, некоторые SBC могут не выполнять все перечисленные манипуляции. Если не ожидается, что SBC будет контролировать медиатрафик, возможно, нет необходимости что-либо менять в теле SDP. Некоторые SBC не меняют идентификационную информацию диалога, а другие могут даже не менять адресную информацию.

SBC часто используются корпорациями вместе с межсетевыми экранами и системами предотвращения вторжений (IPS) для обеспечения возможности вызовов VoIP в защищенную корпоративную сеть и из нее. Поставщики услуг VoIP используют SBC, чтобы разрешить использование протоколов VoIP из частных сетей с подключением к Интернету с использованием NAT, а также для реализации строгих мер безопасности, необходимых для поддержания высокого качества обслуживания. SBC также заменяют функции шлюзов уровня приложений . На более крупных предприятиях SBC также можно использовать в сочетании с SIP-транками для обеспечения управления вызовами и принятия решений о маршрутизации/политике в отношении того, как вызовы маршрутизируются через LAN/WAN. Часто достигается огромная экономия средств, связанная с маршрутизацией трафика через внутренние IP-сети предприятия вместо маршрутизации вызовов через традиционную телефонную сеть с коммутацией каналов.

Кроме того, некоторые SBC могут разрешать установку вызовов VoIP между двумя телефонами с использованием разных протоколов сигнализации VoIP (например, SIP, H.323, Megaco /MGCP), а также выполнять перекодирование медиапотока, когда используются разные кодеки. Большинство SBC также предоставляют функции межсетевого экрана для трафика VoIP ( защита от отказа в обслуживании , фильтрация вызовов, управление полосой пропускания). Нормализация протокола и манипулирование заголовками также обычно предоставляются SBC, обеспечивая связь между различными поставщиками и сетями.

С точки зрения архитектуры IP Multimedia Subsystem (IMS) или 3GPP ( Проект партнерства 3-го поколения ) SBC представляет собой интеграцию P-CSCF и IMS- ALG на плоскости сигнализации и шлюза доступа IMS на медиаплоскости на стороне доступа. . На стороне соединения SBC сопоставляется с IBCF, IWF на плоскости сигнализации и TrGW (переходный шлюз) на плоскости мультимедиа.

С точки зрения архитектуры IMS/ TISPAN SBC представляет собой интеграцию функций P- CSCF и C-BGF на стороне доступа, а также функций IBCF, IWF, THIG и I-BGF на стороне пиринга. Некоторые SBC могут быть «разложены», что означает, что функции сигнализации могут быть расположены на отдельной аппаратной платформе, чем функции ретрансляции мультимедиа - другими словами, P-CSCF может быть отделен от C-BGF или IBCF/IWF может быть отделен. от I-BGF функционирует физически. Протокол, основанный на стандартах, такой как профиль H.248 Ia, может использоваться платформой сигнализации для управления медиа-одной, в то время как несколько SBC используют собственные протоколы.

Споры

В зачаточном состоянии концепция SBC вызывала споры у сторонников сквозных систем и одноранговых сетей, потому что:

• SBC могут значительно увеличить длину медиа-пути (путь медиа-пакетов через сеть). Длинный медиа-тракт нежелателен, так как увеличивает задержку голосовых пакетов и вероятность потери пакетов. Оба эффекта ухудшают качество голоса/видео. Однако во многих случаях между сторонами вызова возникают препятствия, такие как брандмауэры, и в этих случаях SBC предлагают эффективный метод направления медиапотоков по приемлемому пути между вызывающим и вызываемым абонентом; без SBC среда вызова была бы заблокирована. Некоторые SBC могут определять, находятся ли концы вызова в одной и той же подсети , и освобождать контроль над мультимедиа, позволяя ему передаваться напрямую между клиентами, это антитромбонизация или медиа-выпуск. Кроме того, некоторые SBC могут создать путь мультимедиа, существование которого в противном случае не было бы разрешено (благодаря различным межсетевым экранам и другим устройствам безопасности между двумя конечными точками). Наконец, для конкретных моделей сетей VoIP, в которых сетью владеет поставщик услуг, SBC могут фактически уменьшить путь мультимедиа за счет сокращенной маршрутизации. Например, поставщик услуг, предоставляющий транкинговые услуги нескольким предприятиям, обычно выделяет каждому предприятию VPN. Часто желательно иметь возможность подключения VPN через SBC. SBC с поддержкой VPN может выполнять эту функцию на границе сети VPN, вместо того, чтобы отправлять весь трафик в ядро.
• SBC могут ограничивать поток информации между конечными точками вызовов, потенциально снижая сквозную прозрачность. Телефоны VoIP могут не иметь возможности использовать новые функции протокола, если они не понятны SBC. Однако SBC обычно способны справиться с большинством новых и непредвиденных функций протокола.
• Иногда сквозное шифрование невозможно использовать, если у SBC нет ключа, хотя некоторые части информационного потока в зашифрованном вызове не шифруются, и эти части могут использоваться и влиять на SBC. Однако новые поколения SBC, обладающие достаточной вычислительной мощностью, способны разгрузить эту функцию шифрования от других элементов сети путем завершения SIP- TLS , IPsec и/или SRTP . Более того, SBC действительно могут выполнять вызовы и другие сценарии SIP, когда они не могли этого сделать раньше, выполняя «нормализацию» или «исправление» определенного протокола.
• В большинстве случаев прохождение удаленного или размещенного NAT можно выполнить без SBC, если телефоны VoIP поддерживают такие протоколы, как STUN , TURN , ICE или Universal Plug and Play (UPnP).

Большая часть разногласий вокруг SBC связана с тем, должно ли управление вызовами оставаться исключительно за двумя конечными точками в вызове (обслуживая их владельцев) или, скорее, оно должно распределяться между другими сетевыми элементами, принадлежащими организациям, управляющим различными сетями, участвующими в соединении двух вызовы конечных точек. Например, должно ли управление вызовами оставаться за Алисой и Бобом (два вызывающих абонента) или управление вызовами должно быть передано операторам всех IP-сетей, участвующих в соединении VoIP-телефонов Алисы и Боба вместе? Дебаты по этому поводу носили энергичный, почти религиозный характер. Те, кто хотел неограниченного контроля только на конечных точках, также были сильно разочарованы различными реалиями современных сетей, такими как межсетевые экраны и фильтрация/регулирование. С другой стороны, сетевые операторы обычно обеспокоены общей производительностью сети, совместимостью и качеством и хотят обеспечить ее безопасность.

Законный перехват и CALEA

Законный перехват регулируется в Америке Законом о коммуникационной помощи правоохранительным органам (CALEA).

SBC может предоставлять сеансовых носителей (обычно RTP ) и сигнализации (часто SIP ) услуги прослушивания , которые могут использоваться провайдерами для обеспечения выполнения запросов на законный перехват сетевых сеансов. Стандарты перехвата таких услуг предоставлены , среди прочего, ATIS , TIA , CableLabs и ETSI .

История и рынок

По словам Джонатана Розенберга, автора RFC 3261 (SIP) и множества других связанных с ним RFC, Dynamicsoft разработала первый работающий SBC совместно с Aravox, но продукт так и не завоевал долю рынка. Newport Networks была первой компанией, которая провела IPO на AIM Лондонской фондовой биржи в мае 2004 года (NNG), тогда как акции Cisco торгуются публично с 1990 года. В октябре 2006 года акции Acme Packet разместились на NASDAQ. Поскольку в результате приобретения сфера деятельности сузилась, NexTone объединилась с Reefpoint и стала Nextpoint, которая впоследствии была приобретена в 2008 году компанией Genband . В то же время появился «интегрированный» SBC, в котором функция пограничного контроля была интегрирована в другое периферийное устройство. В 2009 году межсетевой экран Ingate Systems стал первым SBC, получившим сертификацию ICSA Labs, что стало важной вехой в сертификации возможностей безопасности VoIP SBC.

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

См. также

• Долгосрочное развитие 3GPP (LTE)
• Брандмауэр (вычисления)
• H.323 гейткипер
• IP-мультимедийная подсистема (IMS)
• Протокол инициации сеанса (SIP)
• SIP-транкинг
• Универсальная система мобильной связи (UMTS)