Кратко

  • Пустой параметр rport просит сервер отправить ответ на реально наблюдавшиеся IP-адрес и UDP-порт источника. Доставка доказывает возврат одной транзакции через существовавшее тогда отображение NAT.
  • Наблюдаемый tuple, NAT-состояние, flow, регистрация, транзакция, dialog и пользовательский результат живут по разным часам. Общий флаг «доступен» скрывает, какое обещание перестало действовать.

Клиент отправляет REGISTER или INVITE из частной сети. NAT заменяет адрес и порт. Proxy видит внешний tuple и возвращает ответ с того же сокета. Клиент получает пакет. Через некоторое время входящий запрос отправляет другой сервер кластера, но транслятор его не пропускает.

Первый успех остаётся настоящим. Исходящий пакет создал отверстие для известного удалённого узла, а ответ успел им воспользоваться. Входящий вызов потребовал, чтобы отверстие сохранилось и признало новый источник, чтобы регистрация указывала на верный flow и чтобы путь проходил через нужный proxy. RFC 3581 не объединяет эти условия.

Документ вышел в августе 2003 года как Standards Track. Он добавил к Via параметр rport и одновременно описал предел: наблюдение подходит для symmetric response routing, но адресная самокоррекция для будущих запросов остаётся хрупким отдельным применением.

До расширения адрес и порт брались из разных мест

В базовом SIP поверх UDP IP-адрес ответа определялся по источнику принятого пакета, а порт — по sent-by верхнего Via. Схема позволяла серверу публиковать общий порт. Если NAT менял и адрес, и source port, результатом становилась внешняя IP-часть с внутренним портом.

Клиент ставит rport без значения. Он не заявляет публичный порт, которого не знает, а просит получателя использовать собственное наблюдение. Сервер вписывает source port в rport и source address в received, даже когда адрес совпал с sent-by.

Для unreliable unicast без maddr ответ направляется на received:rport. Источником должен быть тот же адрес и порт сервера, куда пришёл запрос. Symmetric NAT может учитывать обе стороны, поэтому серверный socket входит в условие успеха.

Это не доверие к произвольному заголовку. Это привязка ответа к wire-наблюдению конкретной транзакции.

Наблюдение не становится идентичностью

Via может содержать 10.1.1.1:4540, а proxy наблюдать 192.0.2.1:9988. Второй tuple — правильный адрес для ответа сейчас. Он не является именем абонента, Address-of-Record, идентификатором UA instance или постоянной арендой публичного порта.

Пустой rport доказывает только запрос функции. Число в ответе доказывает запись, сделанную сервером. Получение клиентом доказывает прохождение именно этого ответа. Даже последний факт не сообщает срок жизни состояния и не разрешает другому узлу пользоваться тем же направлением.

Полный receipt должен связывать branch, Call-ID, CSeq, исходный и дополненный Via, wire tuple, proxy instance, входной interface, выходной socket, response status и клиентское подтверждение. Поле reachable=true без наблюдателя и интервала ничего не позволяет воспроизвести.

Stateless proxy переносит память в Via

Если сервер слушает на нескольких интерфейсах, ему нужно помнить точку приёма. Stateful proxy сохраняет её до конца транзакции. Stateless proxy может закодировать нужные адрес и порт в собственном Via, а после возврата ответа извлечь их.

Происхождение решения не исчезает. Оно хранится в сообщении вместо локальной памяти. Если журнал оставляет только логическое имя сервиса, реальный socket уже нельзя доказать.

Именно здесь проявляется кластерная ошибка. Балансировщик считает два узла взаимозаменяемыми, а NAT воспринимает их как разных удалённых собеседников. Доступность сервиса, здоровье процесса и сохранность пути конкретной транзакции — разные показатели.

INVITE способен пережить своё NAT-отображение

RFC 3581 требует сохранять binding на протяжении транзакции. Non-INVITE считались достаточно короткими для типичных UDP timeout того периода. INVITE может ждать окончательный ответ произвольно долго, поэтому документ советует продолжать retransmission примерно раз в двадцать секунд даже после provisional response.

Совет показывает отсутствие гарантии. В tuple нет expiry. Успешный предварительный ответ не является lease. Тишина, перезапуск NAT, новая политика или failover удаляют путь, не меняя SIP-идентичность.

RFC ссылался на алгоритм определения lifetime из RFC 3489 и предупреждал о ненадёжности результата. RFC 5389 объявил RFC 3489 устаревшим, а RFC 8489 позднее заменил RFC 5389. Историческое предположение нельзя выдавать за современное измерение. Нужны фактический последний трафик, cadence, бюджет и неопределённость.

Публичный tuple не переносит скрытые условия

Пара received+rport сообщает клиенту, как его видит сервер. Её можно попытаться записать в Contact или Record-Route и ожидать будущие запросы. RFC 3581 относит это к UNSAF и подробно перечисляет хрупкость.

Для поддержания mapping могут понадобиться регистрации почти в сто раз чаще обычного периода. При symmetric NAT пакеты принимаются только от исходного сервера. Другой узел кластера читает тот же Contact, но остаётся снаружи. Если REGISTER принимал proxy, а registrar находился дальше, будущий запрос должен пройти через первый proxy; RFC 3327 Path фиксирует это требование.

В числе rport нет разрешённого remote peer, срока, edge-proxy и cluster affinity. Копирование числа в каталог не копирует условия его применимости.

Выходная стратегия RFC 3581 требовала использовать установленный клиентом connection/flow, учитывать кластеры и не создавать чрезмерную нагрузку. RFC 5626 определил SIP Outbound: registration binding связывается с клиентским flow, поддерживаются несколько потоков, keepalive и failure detection. RFC 6314 рекомендует этот подход для NAT traversal.

Поздние механизмы тоже не взаимозаменяемы. RFC 6223 отделяет keepalive от connection reuse. RFC 5923 задаёт обратные запросы на connection-oriented transport. RFC 5627 предоставляет стабильный GRUU для экземпляра UA. Pong не выбирает регистрацию; flow token не выдаёт полномочия; стабильный URI не доказывает звонок, ответ и media.

Защита байтов не продлевает смысл

Наблюдаемые адрес и порт могут быть чувствительными, поэтому RFC 3581 упоминает SIP over TLS. TLS защищает сигнализацию. На TCP/TLS rport главным образом сообщает видимый порт; UDP-механика возврата не является причиной доставки.

Посредник может удалить rport и сорвать ответ клиенту за NAT. Integrity protection препятствует изменению, но не доказывает владельца публичного tuple и не сохраняет binding. Регистрация параметра IANA координирует синтаксис, но не подтверждает реализацию и доступность.

Для каждого уровня нужен свой источник: authentication для идентичности, wire observation для tuple, socket provenance для ответа, Path/flow для будущего, registrar state для выбора, Route set для dialog и отдельные результаты для alerting, answer, media и приложения.

Граница доказательств

Статья не называет оператора, PBX, SIP-провайдера, UA, proxy, registrar, NAT-продукт, кластер, абонента, вызов, инцидент или результат media. Статус Standards Track не показывает внедрение.

RFC 3261 задаёт Via и транзакции, RFC 3327 — Path, RFC 3424 — рамки UNSAF. RFC 3489 используется только как исторический контекст; RFC 5389 и RFC 8489 показывают развитие STUN. RFC 5626, RFC 6314, RFC 5923, RFC 6223 и RFC 5627 разделяют Outbound, практику NAT, reuse, keepalive и стабильную маршрутизацию UA. IANA не заменяет running evidence.

Running-Code Primacy и Minimum Initial Specification Хэнга Лу — явно обозначенные редакционные линзы. Они требуют проверять работающий путь и ограничивать общее правило необходимым минимумом. Они не доказывают намерение авторов RFC или deployment.

Итог не нужно расширять: ответ дошёл на один порт в один момент. Это сильный факт. Входящий вызов всё равно требовал отдельного маршрута.

Источники