Контроллер сеансовой связи: защита и управление VoIP-сетями

Введение

Сетевое устройство, развернутое в сетях VoIP.

Контроллер границ сеанса (SBC) – это сетевой элемент, развернутый для защиты сетей голосовой связи по протоколу SIP (VoIP). Первоначальные развертывания SBC были сосредоточены на границах между сетями двух операторов связи в условиях пиринга. Эта роль теперь расширилась и включает в себя значительные развертывания между сетью доступа оператора связи и магистральной сетью для предоставления услуг домашним и/или корпоративным пользователям. 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 реализуются как back-to-back user agent (B2BUA). B2BUA – это прокси-подобный сервер, который разделяет транзакцию SIP на два отрезка вызова: со стороны, обращенной к клиенту пользовательского агента (UAC), он действует как сервер, а со стороны, обращенной к серверу пользовательского агента (UAS), – как клиент. В то время как прокси обычно хранит только информацию о состоянии активных транзакций, B2BUA хранит информацию о состоянии активных диалогов, например, вызовов. То есть, как только прокси получает запрос SIP, он сохраняет некоторую информацию о состоянии. После завершения транзакции, например, после получения ответа, эта информация о состоянии вскоре удаляется. B2BUA сохраняет информацию о состоянии активных вызовов и удаляет ее только после завершения вызова. Когда SBC включен в путь вызова, он действует как B2BUA, выступая в роли сервера пользовательского агента по отношению к вызывающему абоненту и клиента пользовательского агента по отношению к вызываемому абоненту. В этом смысле SBC фактически завершает вызов, инициированный вызывающим абонентом, и начинает новый вызов к вызываемому абоненту. В сообщении INVITE, отправленном SBC, больше нет прямой ссылки на вызывающего абонента. В сообщении INVITE, отправленном SBC прокси, содержатся заголовки Via и Contact, указывающие на сам SBC, а не на вызывающего абонента. SBC часто также изменяют информацию об идентификации диалога, указанную в Call-Id и теге From. Кроме того, если SBC настроен на управление медиа-трафиком, он также изменяет информацию об адресах медиа, содержащуюся в строках c и m тела SDP. Таким образом, все сообщения SIP и все аудио- и видеопакеты проходят через SBC. Поскольку сообщение INVITE, отправленное SBC, устанавливает новый диалог, SBC также изменяет порядковый номер сообщения (CSeq) и значение Max-Forwards. Следует отметить, что список манипуляций с заголовками, приведенный здесь, представляет собой лишь часть возможных изменений, которые SBC может внести в сообщение SIP. Кроме того, некоторые SBC могут не выполнять все перечисленные манипуляции. Если SBC не должен контролировать медиа-трафик, может не потребоваться вносить изменения в тело SDP. Некоторые SBC не изменяют информацию об идентификации диалога, а другие могут даже не изменять информацию об адресах. SBC часто используются корпорациями совместно с брандмауэрами и системами предотвращения вторжений (IPS) для обеспечения возможности совершения VoIP-вызовов в защищенную корпоративную сеть и из нее. Поставщики услуг VoIP используют SBC для обеспечения возможности использования протоколов VoIP из частных сетей с подключением к Интернету через NAT, а также для реализации надежных мер безопасности, необходимых для поддержания высокого качества обслуживания. SBC также заменяют функциональность шлюзов прикладного уровня.

SBCs are inserted into the signaling and/or media paths between calling and called parties in a VoIP call, predominantly those using the Session Initiation Protocol (SIP), H.323, and MGCP call signaling protocols. In many cases the SBC hides the network topology and protects the service provider or enterprise packet networks. The SBC terminates an inbound call and initiates the second call leg to the destination party. In technical terms, when used with the SIP protocol, this defines a back to back user agent (B2BUA). The effect of this behavior is that not only the signaling traffic, but also the media traffic (voice, video) is controlled by the SBC. In cases where the SBC does not have the capability to provide media services, SBCs are also able to redirect media traffic to a different element elsewhere in the network, for recording, generation of music on hold, or other media related purposes. Conversely, without an SBC, the media traffic travels directly between the endpoints, without the in network call signaling elements having control over their path. In other cases, the SBC simply modifies the stream of call control (signaling) data involved in each call, perhaps limiting the kinds of calls that can be conducted, changing the codec choices, and so on. Ultimately, SBCs allow the network operators to manage the calls that are made on their networks, fix or change protocols and protocol syntax to achieve interoperability, and also overcome some of the problems that firewalls and network address translators (NATs) present for VoIP calls. To show the operation of an SBC, one can compare a simple call establishment sequence with a call establishment sequence with an SBC. In the simplest session establishment sequence with only one proxy between the user agents the proxy’s task is to identify the callee’s location and forward the request to it. The proxy also adds a Via header with its own address to indicate the path that the response should traverse. The proxy does not change any dialog identification information present in the message such as the tag in the From header, the Call Id or the Cseq. Proxies also do not alter any information in the SIP message bodies. Note that during the session initiation phase the user agents exchange SIP messages with the SDP bodies that include addresses at which the agents expect the media traffic. After successfully finishing the session initiation phase the user agents can exchange the media traffic directly between each other without the involvement of the proxy. SBCs are designed for many applications and are used by operators and enterprises to achieve a variety of goals. Even the same SBC implementation might act differently depending on its configuration and the use case. Hence, it is not easily possible to describe an exact SBC behavior that would apply to all SBC implementations. In general it is possible to identify certain features that are common to SBCs. For example, most SBCs are implemented as back to back user agent. A B2BUA is a proxy like server that splits a SIP transaction in two call legs: on the side facing the user agent client (UAC), it acts as server, on the side facing user agent server (UAS) it acts as a client. While a proxy usually keeps only state information related to active transactions, B2BUAs keep state information about active dialogs, e. g., calls. That is, once a proxy receives a SIP request it will save some state information. Once the transaction is over, e. g., after receiving a response, the state information will soon after be deleted. A B2BUA will maintain state information for active calls and only delete this information once the call is terminated. When an SBC is included in the call path, the SBC acts as a B2BUA that behaves as a user agent server towards the caller and as user agent client towards the callee. In this sense, the SBC actually terminates that call that was generated by the caller and starts a new call towards the callee. The INVITE message sent by the SBC contains no longer a clear reference to the caller. The INVITE sent by the SBC to the proxy includes Via and Contact headers that point to the SBC itself and not the caller. SBCs often also manipulate the dialog identification information listed in the Call Id and From tag. Further, in case the SBC is configured to also control the media traffic then the SBC also changes the media addressing information included in the c and m lines of the SDP body. Thereby, not only will all SIP messages traverse the SBC but also all audio and video packets. As the INVITE sent by the SBC establishes a new dialog, the SBC also manipulates the message sequence number (CSeq) as well the Max Forwards value. Note that the list of header manipulations listed here is only a subset of the possible changes that an SBC might introduce to a SIP message. Furthermore, some SBCs might not do all of the listed manipulations. If the SBC is not expected to control the media traffic then there might be no need to change anything in the SDP body. Some SBCs do not change the dialog identification information and others might even not change the addressing information. SBCs are often used by corporations along with firewalls and intrusion prevention systems (IPS) to enable VoIP calls to and from a protected enterprise network. VoIP service providers use SBCs to allow the use of VoIP protocols from private networks with Internet connections using NAT, and also to implement strong security measures that are necessary to maintain a high quality of service. SBCs also replace the function of application level gateways.