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 проблемы будут на всей сети.