Войти
Преобразователи сетевых адресов (NAT) используются для устранения недостатка IPv4 доступность адреса, скрывая сеть предприятия или даже оператора за одним или несколькими IP-адресами. Устройства за NAT используют частные IP-адреса, которые не маршрутизируются в общедоступном Интернете. Протокол инициирования сеанса (SIP) зарекомендовал себя как стандарт де-факто для связи голос по IP (VoIP). Для установления вызова вызывающий абонент отправляет сообщение SIP, которое содержит его собственный IP-адрес. Предполагается, что вызываемый абонент ответит SIP-сообщением, адресованным IP-адресам, включенным в полученное SIP-сообщение. Очевидно, это не сработает, если вызывающий абонент находится за NAT и использует частный IP-адрес.
Вероятно, самая большая ошибка в дизайне SIP заключалась в игнорировании существования NAT. Эта ошибка возникла из-за убеждения руководства IETF в том, что пространство IP-адресов будет исчерпано быстрее и потребует глобального обновления до IPv6 и устранения необходимости в NAT. Стандарт SIP предполагал, что NAT не существует, предположение, которое оказалось неудачным. SIP просто не работал у большинства интернет-пользователей, находящихся за NAT. В то же время стало очевидно, что жизненный цикл стандартизации медленнее, чем движется на рынке: Пограничные контроллеры сеанса (SBC) родились и начали исправлять то, что не удалось сделать стандартам: Обход NAT.
Если пользовательский агент находится за NAT, он будет использовать частный IP-адрес в качестве своего контактного адреса в контакте и через заголовки, а также часть SDP. Эта информация будет бесполезна для всех, кто пытается связаться с этим пользовательским агентом из общедоступного Интернета.
Существуют различные решения для обхода NAT, такие как STUN, TURN и ICE. Какое решение использовать, зависит от поведения NAT и сценария вызова. При использовании SBC для решения проблем прохождения NAT наиболее распространенным подходом для SBC является выступление в качестве открытого интерфейса пользовательских агентов. Это достигается заменой контактной информации пользовательского агента на информацию SBC.
Обработка прохождения NAT с помощью SBC во время установления вызова Чтобы пользовательский агент был доступен через общедоступные интерфейсы SBC, SBC будет манипулировать регистрационной информацией пользовательского агента. Пользователь включает свой частный IP-адрес в качестве контактной информации в запросы REGISTER. Вызовы на этот адрес не будут выполнены, поскольку он не является общедоступным. SBC заменяет информацию в заголовке контакта своим собственным IP-адресом. Это информация, которая затем регистрируется у регистратора. Вызовы, адресованные пользователю, будут перенаправлены на SBC.
Чтобы SBC знал, с каким пользовательским агентом на самом деле связываются, SBC может хранить локальную копию регистрации пользовательского агента. Локальная копия включает частный IP-адрес и пользовательский SIP URI, а также общедоступный IP-адрес, включенный в IP-заголовок, который был назначен сообщению SIP посредством NAT.
В качестве альтернативы SBC может хранить эту информацию в пересылаемых SIP-сообщениях. Это показано на рисунке здесь. Контактная информация пользователя объединяется в специальном формате и добавляется в качестве дополнительного параметра в заголовок контакта. Контактная информация включает частный IP-адрес пользователя и SIP URI, а также общедоступный IP-адрес в IP-заголовке сообщения SIP. Когда регистратор получает запрос для пользователя, регистратор возвращает полную контактную информацию на прокси-сервер, который будет включать эту информацию в SIP-сообщение. Затем SBC может получить эту информацию из запроса SIP и использовать ее для правильной маршрутизации запроса пользователю.
Добавление контактной информации пользовательского агента к зарегистрированной контактной информации имеет много преимуществ. Поскольку SBC не должен хранить локальную регистрационную информацию, это решение легко реализовать и не требует памяти для хранения информации. Кроме того, запросы, адресованные пользовательскому агенту, не обязательно должны проходить через SBC, который обработал сообщения регистрации пользовательского агента. Любой SBC, который может связаться с пользовательским агентом, может правильно маршрутизировать сообщения, предназначенные пользовательскому агенту, на основе информации, включенной в запрос SIP. Однако это преимущество применяется только в некоторых случаях. В случае, если NAT, используемый перед пользовательским агентом, принимает трафик только с IP-адресов, с которыми пользовательский агент связывался ранее, тогда только SBC, который обработал запросы REGISTER пользовательского агента, сможет связаться с пользовательским агентом.
Другой вариант - сохранить локальную копию регистрационной информации, что, однако, может увеличить требования к обработке на SBC. SBC должен будет управлять локальной регистрационной базой данных. Помимо требований к памяти, SBC должен будет реплицировать эту информацию в систему резервного копирования, чтобы обеспечить высокую доступность. Это еще больше увеличит требования к обработке SBC и увеличит потребление полосы пропускания.
Однако хранение локальной копии регистрационной информации также имеет свои преимущества. При получении сообщения от пользовательского агента транслятор сетевых адресов привязывает частный IP-адрес пользовательского агента к общедоступному IP-адресу. Эта привязка будет оставаться активной в течение определенного периода времени. В случае, если пользовательский агент не отправляет и не принимает никаких сообщений в течение периода времени, превышающего период привязки, NAT удалит привязку, и пользовательский агент больше не будет доступен извне. Чтобы привязка оставалась активной, пользовательский агент должен будет регулярно ее обновлять. Это достигается путем отправки запросов REGISTER через интервалы времени короче периода привязки. Поскольку сообщения REGISTER должны быть обычно аутентифицированы, необходимость иметь дело с сообщениями REGISTER, отправляемыми с высокой частотой, приведет к снижению производительности инфраструктуры оператора. SBC могут помочь снять эту нагрузку. Когда пользовательский агент отправляет первый запрос REGISTER, SBC пересылает запрос REGISTER на серверы регистрации оператора. После того, как регистрация была успешно аутентифицирована и принята оператором, SBC сохранит локальную копию регистрационной информации. Вместо пересылки каждого входящего запроса REGIETER на серверы регистрации оператора, SBC будет отправлять запросы REGISTER на серверы регистрации только через довольно большие интервалы времени (в диапазоне часов). На запросы регистрации, поступающие от пользовательского агента, которые не изменяют информацию о регистрации контента, будет отвечать сам SBC. SBC также проинформирует сервер регистрации об истечении срока локальной регистрации или ее изменении.
Прохождение NAT с SBC во время регистрации пользователя Как и в случае регистрации, SBC также будет включать себя в путь INVITE и другие сообщения-запросы. При получении INVITE от пользовательского агента за NAT, SBC будет включать заголовок via со своим собственным адресом, заменять информацию в заголовке контакта своим собственным адресом, а также заменять информацию об адресе в SDP тело с собственным адресом. Таким образом, все сообщения SIP и медиапакеты будут проходить через SBC.
После установления вызова с использованием SIP происходит обмен медиапакетами, а именно голосом, видео или данными - обычно с использованием в реальном времени Транспортный протокол (RTP) Хотя прохождение NAT-сообщений SIP может показаться сложным, еще более сложной задачей является обеспечение прохождения медиа-адресов NAT. Исходная постановка проблемы такая же. Если устройства SIP за NAT объявляют свои IP-адреса, их узлы на другой стороне NAT не могут направлять к ним трафик. Решение SBC просто игнорирует способ работы SIP. Вместо отправки мультимедиа на IP-адрес и номер порта, объявленные в телах SIP SDP, SBC отправляют мультимедиа для пользовательского агента симметрично обратно туда, откуда агент отправил свои собственные мультимедиа. Эта симметричная связь обычно работает, потому что это модель трафика, к которой производители NAT использовали до появления VoIP.
. Важно знать, что, хотя это в основном работает, у него есть несколько ограничений. Прежде всего, он работает только с клиентами, построенными «симметрично», то есть они используют один и тот же порт для отправки и получения мультимедиа. К счастью, сегодня это большая часть доступного оборудования.
Другим заметным недостатком является «треугольная маршрутизация»: SBC должен ретранслировать весь трафик VoIP для вызова, чтобы сделать пути SBC-вызывающий и SBC-вызываемый симметричными. На самом деле это довольно накладные расходы для оператора VoIP. С наиболее распространенным кодеком, G.711, ретранслируемый вызов потребляет четыре потока со скоростью 87,2 кбит / с: два исходящих, два входящих.
Могут возникнуть и другие неприятные ограничения. Например, если устройство SIP использует обнаружение голосовой активности (VAD) и изначально не может отправить какие-либо голосовые пакеты, SBC не узнает его адрес и не будет пересылать ему входящие мультимедийные данные.
