RFC: 3027
Оригинал: Protocol Complications with the IP Network Address Translator
Категория: Информационный
Дата публикации:
Авторы: ,
Перевод: Мельников Дмитрий Анатольевич

RFC 3027, Страница 13 из 19

4.5. Протокол SIP

Протокол инициирования сеанса связи (Session Initiation Protocol — SIP, RFC-2543) способен функционировать и с ТСР- и с UDP-протоколом и, по умолчанию, использует ТСР/UDP-порт с номером «5060».

Когда SIP-протокол функционирует совместно с UDP-протоколом, то тогда ответ на SIP-запрос не поступает на UDP-порт источника запроса, то есть откуда был передан SIP-запрос. Было бы правильнее, если бы SIP-сообщение содержало номер порта транспортного уровня, на который должен быть отправлен ответ. В SIP-протоколе используется номер ICMP-порта для ответного сообщения об ошибке, связанной с невозможностью достичь IP-узла, на который было передан запрос. Сообщения-запросы обычно передаются на уже используемый порт. Если ответы передаются на порт источника запроса, указанный в этом запросе, то тогда прикладной процесс, передавший запрос, должен «слушать» (контролировать) тот порт, через который передал свой запрос. Однако, если разрешить передавать ответы на одиночный порт транспортного уровня, то тогда вместо «прослушивания» порта можно использовать только один прикладной процесс.

Сервер может размещать в сообщении номер каждого активного порта источника сообщения. Затем каждый прикладной процесс может раздельно контролировать активные порты на предмет поступления на них ответных сообщений. Так как номер порта для ответного сообщения может не совпадать с номер порта источника запроса, а SIP-протокол, как правило, не взаимодействует с NAT-модулем, то в такой ситуации будет необходим SIP-ALG-субмодуль.

SIP-сообщения доставляют в поле полезной нагрузки самые различные данные, которые определяются своим MIME-типом (Multipurpose Internet Mail Extensions, RFC 2045). В период проведения многопротокольных (multimedia) сеансов связи, обычно, используется протокол определения сеанса связи (Session Description Protocol — SDP, RFC-2327). SDP-протокол может определять IP-адреса или номера портов транспортного уровня, которые используются для информационного обмена в период многопротокольных сеансов связи. Эти IP-адреса или номера портов могут терять смысл, если multimedia-сообщения транслируются через NAT-модуль. Следовательно, в такой ситуации может понадобиться SIP-ALG-субмодуль, который будет распределять и транслировать данные по соответствующим виртуальным соединениям.

SIP-сообщения доставляют в полях «Contact», «To» и «From» URL-идентификаторы, которые определяют адреса сигнализации/синхронизации процедур. Такие URL-идентификаторы могут содержать IP-адреса или DNS-имена (как часть идентификационного блока, определяющего порт IP-узла). Эти IP-адреса или DNS-имена могут потерять свой смысл, так как будут преобразованы, если SIP-сообщения транслируются через NAT-модуль.

Как альтернатива SIP-ALG-субмодулю, SIP-протокол может назначить уполномоченный сервер (proxy server), который может быть «совмещен» с NAT-модулем и функционировать с таким же глобальным IP-адресом (транспортнымпортом), как и у NAT-модуля. Такой proxy-сервер может иметь собственную специфическую настройку.

Страница 13 из 19

2007 - 2022 © Русские переводы RFC, IETF, ISOC.