Трансляторы сетевых адресов (NAT) используются для преодоления нехватки адресов IPv4 , скрывая сеть предприятия или даже оператора за одним или несколькими IP-адресами . Устройства за NAT используют частные IP-адреса , которые не маршрутизируются в общедоступном Интернете. Протокол SIP (Session Initiation Protocol ) зарекомендовал себя как фактический стандарт для голосовой связи по IP (VoIP). [1] Чтобы установить вызов, вызывающий абонент отправляет SIP- сообщение, которое содержит его собственный IP-адрес. Вызываемый абонент должен ответить SIP-сообщением, предназначенным для IP-адресов, включенных в полученное SIP-сообщение. Очевидно, что это не сработает, если вызывающий абонент находится за NAT и использует частный IP-адрес.
Вероятно, самой большой ошибкой в разработке SIP было игнорирование существования NAT. Эта ошибка возникла из-за убеждения руководства IETF , что пространство IP-адресов будет исчерпано быстрее и потребует глобального обновления до IPv6 и устранения необходимости в NAT. Стандарт SIP предполагал, что NAT не существует, предположение, которое оказалось неудачным. SIP просто не работал для большинства пользователей Интернета, которые находились за NAT. В то же время стало очевидно, что жизненный цикл стандартизации медленнее, чем тикает рынок: появились контроллеры пограничных сессий (SBC) [2] , которые начали исправлять то, что не смогли сделать стандарты: обход NAT .
В случае, если пользовательский агент находится за NAT, он будет использовать частный IP-адрес в качестве своего контактного адреса в контакте и через заголовки, а также часть SDP . Эта информация будет бесполезна для любого, кто попытается связаться с этим пользовательским агентом из публичного Интернета.
Существуют различные решения для обхода NAT, такие как STUN , TURN и ICE. [3] Какое решение использовать, зависит от поведения NAT и сценария вызова. При использовании SBC для решения проблем обхода NAT наиболее распространенным подходом для SBC является работа в качестве публичного интерфейса пользовательских агентов. [4] Это достигается путем замены контактной информации пользовательского агента на контактную информацию 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 также будет информировать сервер регистрации, когда локальная регистрация истечет или изменится.
Подобно случаю регистрации, SBC также включит себя в путь INVITE и других сообщений-запросов. При получении INVITE от пользовательского агента за NAT, SBC включит заголовок via со своим собственным адресом, заменит информацию в заголовке контакта своим собственным адресом, а также заменит информацию об адресе в теле SDP своим собственным адресом. Таким образом, все сообщения SIP и медиапакеты будут проходить через SBC.
После установления вызова с использованием SIP происходит обмен медиапакетами, а именно голосом, видео или данными, обычно с использованием протокола Real-time Transport Protocol (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 не узнает его адрес и не будет пересылать ему входящие медиаданные.