Кратко

  • Прокси обязан периодически выдавать новую PURR, даже при неизменных параметрах уведомления, и сохранять предыдущие значения до окончания связанных с ними действующих диалогов.
  • Уникальность PURR ограничена контекстом прокси. Это не глобальная личность устройства и не универсальное право будить приложение.
  • Выбор для каждого диалога, его маршрут, локальная связь с регистрацией, полномочия службы уведомлений и срок отдельного запроса остаются разными границами.

Кто обязан помнить предыдущую ссылку

Когда приложение получает новый идентификатор, внимание обычно обращают на его свежесть: выдан ли он, принимается ли, позволяет ли начать следующий разговор. Но для действующего SIP-диалога существенна и другая сторона. Его участник мог ранее узнать значение, которое по-прежнему используется в последующих запросах. Новая выдача не доказывает, что этот участник перестал нуждаться в старой связи.

Представим условный диалог, начатый со ссылкой P1. После очередной регистрации приложение получает P2. Другой диалог может объявить P2, а запрос внутри первого все еще содержит P1. Это учебные обозначения и гипотетическая ситуация, а не захваченные пакеты, реальные идентификаторы или готовый пример для отправки.

Если прокси удалил связь с P1, он может прекрасно обслуживать P2 и новые разговоры. Последняя регистрация пройдет проверку, но старый диалог останется без необходимого разрешения ссылки. Причина не в том, что приложение «забыло обновиться». Причина в предположении, будто выдача нового значения сама завершает все зависимости от прежнего.

RFC8599, опубликованный в мае2019, исключает это предположение двумя одновременными требованиями. Раздел6.2.1 обязывает периодически создавать новую Proxy Unique Registration Reference, PURR, даже без изменения параметров push-службы. Он также обязывает сохранять старые значения, пока соответствующие диалоги остаются текущими.

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

Пробуждение восстанавливает не все условия сразу

Мобильная система может приостановить приложение, хотя его регистрационная привязка SIP еще действительна. Наличие регистрации не гарантирует непрерывную готовность приложения принимать сигнализацию. Механизм RFC8599 позволяет прокси запросить уведомление у Push Notification Service, PNS; агент пользователя просыпается и обновляет регистрацию.

Уведомление не является самим запросом SIP. Оно помогает вернуть приложение в состояние, в котором сигнализация может быть доставлена. Принятие уведомления провайдером не доказывает пробуждение, завершение регистрации или успешный прием запроса. Каждый переход требует собственной наблюдаемой информации.

Агент получает у PNS значение Push Resource ID, PRID, с форматом, определяемым конкретной службой. При регистрации SIP прокси получает сведения о провайдере, PRID и дополнительный параметр, если он нужен этой службе. По ним прокси может запросить уведомление.

Обнаружение PNS, регистрация в ней и поддержание отношений с ней не определяются данным механизмом RFC8599. Стандарт не создает общей учетной записи для всех поставщиков и единого срока действия их ресурсов. Действительность SIP-регистрации нельзя автоматически приравнять к действительности ресурса провайдера.

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

Процедуры применяются к отдельным привязкам. У агента пользователя их может быть несколько; пробуждение вызывает обновление регистраций в соответствии с правилами. Выдуманная единая мировая запись устройства упростила бы рисунок, но уничтожила бы нужную точность в вопросе, какая связь еще существует.

Скрывать координаты, а не саму возможность обращения

Удаленному участнику не нужны все частные данные, которыми прокси пользуется для push-запроса. RFC8599 требует не включать соответствующие параметры в запросы, отличные от REGISTER, за исключением pn-purr. Поэтому pn-provider, pn-prid и pn-param не передаются собеседнику как обычные сведения диалога.

PURR дает косвенную ссылку. Прокси создает значение и по нему находит сохраненную информацию, необходимую для уведомления. Уникальность действует в его собственном контексте. Она не означает постоянный номер устройства, узнаваемый любой сетью, и не требует центрального учреждения для выдачи ссылок всем прокси.

Значение должно быть неподделываемым, анонимным и несопоставимым для сущностей, кроме прокси. Большое пространство безопасно сгенерированных случайных значений может быть одним вариантом реализации. Из этого не следует обязательный единый алгоритм, способ кодирования или организация хранения.

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

Однако свойства ссылки не равны анонимности всей SIP-коммуникации. Другие заголовки, поведение приложения или журналы эксплуатации могут содержать сведения. Непрозрачное значение не доказывает анонимности всех записей и отсутствия любого другого способа сопоставления. Обещание должно оставаться в пределах защищаемого объекта.

Нужно также отличать PURR от GRUU. RFC5627 описывает глобально маршрутизируемый URI к определенному экземпляру агента пользователя. Локальный поиск регистрационной информации для уведомления имеет другой смысл. Общая связь с доступностью не делает два инструмента одной и той же идентичностью.

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

Решение относится к конкретному диалогу

Поддержка со стороны прокси не включает все разговоры автоматически. RFC8599 оставляет агенту пользователя выбор по локальной политике: нужен ли данному диалогу push для входящих запросов в его ходе. Решение может учитывать особенности самого диалога или его медиа.

При выборе механизма агент включает pn-purr в соответствующий начальный Contact и использует последнее значение индикатора sip.pnspurr. Без полученного индикатора он не должен изобретать параметр. Собеседник получает ссылку, подкрепленную объявленной возможностью, а не одностороннее обещание о неизвестном посреднике.

RFC6809 определяет Feature-Caps для возможностей сущностей, не представленных URI в Contact. Описание sip.pnspurr в реестре IANA относится к связи запроса внутри диалога с регистрационными сведениями. Оно не предоставляет универсальных полномочий в службе уведомлений.

Нужно различать участие диалога, правильный маршрут, разрешимую ссылку, действительную привязку и допуск провайдера. Ни один факт не заменяет остальных. Найденная PURR не доказывает, что регистрация не удалена; принятый push не доказывает соблюдение политики приложения.

Это распределение сохраняет решение рядом с тем, кто знает приложение. Не требуется учреждение, одобряющее каждый разговор. Одновременно оператор не может сослаться на успешный ответ провайдера вместо объяснения своих локальных условий маршрутизации и регистрации.

Старое значение живет не по календарю выдачи

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

RFC8599 привязывает сохранение к продолжающимся связанным диалогам. Он не устанавливает общего мирового интервала смены или фиксированного количества часов, после которого все прежние значения разрешено удалить. Удобное расписание уборки само по себе не доказывает завершения разговора.

Это не требование бесконечно копить каждую ссылку. Основание и предел хранения дает реальная зависимость. Полезный вопрос — какие диалоги еще нуждаются в связи и как эта нужда заканчивается. Выбор между немедленным стиранием и вечным архивом не охватывает все варианты.

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

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

RFC8599 не определяет универсального протокола репликации или миграции прокси и общей процедуры смены ключей. Местная реализация должна отвечать за непрерывность сама. Поддержка функции не является доказательством корректности любой смены узлов.

Сложность передачи не обосновывает автоматически всемирный каталог PURR. Такой каталог мог бы облегчить поиск и одновременно объединить сведения из разных локальных контекстов. Удобство — возможный выигрыш, но не доказательство необходимости расширять область знания и контроля.

Ссылка должна попасть к тому, кто ее разрешает

Правильная связь бесполезна для запроса, который проходит мимо ее владельца. В применимой процедуре начального диалога поддерживающий прокси включает себя в Record-Route, чтобы оставаться на пути дальнейших запросов. RFC3261 описывает набор маршрутов и удаленную цель диалога, на которых это основано.

Path из RFC3327 решает соседнюю, но другую задачу: фиксирует посредников, через которых достигается зарегистрированный агент. Record-Route сохраняет путь установленного диалога. Корректные данные регистрации не доказывают сами по себе, что запрос разговора посетит держателя PURR.

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

В обработке запроса внутри диалога pn-purr может находиться в Request-URI или URI поля Route в зависимости от маршрута. Если прокси находит нужные сведения, он помещает запрос в ожидание и запрашивает уведомление. Ответ2xx связанной транзакции REGISTER позволяет извлечь и передать соответствующий запрос агенту.

Здесь не выполняется сравнение URI из раздела5.3. Такой запрос не несет частных pn-prid, pn-provider и pn-param. Связь устанавливается по PURR, относящейся к регистрационному ответу. Косвенная ссылка меняет правило сопоставления, а не только скрывает названия параметров.

Описание относится именно к разделу6.2.3. Для начальных запросов предусмотрены свои условия, в том числе зависящая от транспорта последовательность. Было бы неверно распространять ожидание REGISTER2xx на любую SIP-операцию во всех обстоятельствах.

Сохранение не восстанавливает истекшее право

Когда прокси получает сведения, что регистрационная привязка истекла или удалена, он не должен запрашивать дополнительные уведомления с соответствующей PRID. Присутствие старой PURR в диалоге не оживляет удаленную привязку и не исправляет недействительный ресурс провайдера.

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

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

Аутентификация и авторизация конкретной PNS остаются в ее спецификации. RFC8599 требует защищать SIP-сигнализацию и удерживать частные параметры от раскрытия другим пользователям и недоверенным сущностям. Событийные уведомления о регистрации тоже могут быть каналом утечки; проверки только начального Contact недостаточно.

RFC8030 описывает безопасность HTTP Web Push, но не выбирает политику SIP-приложения для каждого диалога. Допуск уведомления, разрешение ссылки и действующий разговор — разные факты. Объединение в общее «право будить» затрудняет определение ответственного за лишние пробуждения, расход батареи и ненужную сигнализацию.

Нужно удержать обе границы: новое значение не заканчивает живую зависимость, а старая зависимость не продлевает полномочие, которое завершилось. Хранение и использование не должны превращаться в один грубый переключатель активности.

Что подтверждено источниками

Документация registrar выбранной версии OpenSIPS3.6 описывает pn_enable_purr, pn_process_purr и настраиваемый pn_refresh_timeout. Она показывает конкретные поверхности объявления способности, поиска ссылки и ожидания. Это не проверка какого-либо действующего кластера.

Две публикации OpenSIPS2020 года исторически объясняют регистрацию и запросы внутри диалога. Они не доказывают сохранение всех старых значений или правильную передачу состояния в определенном развертывании. Для этой работы не отправлялись запросы оператору SIP и не измерялось поведение работающей сети.

Статус исправлений тоже ограничивает выводы.8136 — проверенное редакционное исправление sip.pnsreq на sip.pnsreg в разделе4.1.4.7136 — сообщенная техническая ошибка примеров REGISTER Request-URI; она не является принятой нормативной поправкой. Придумывать исполнимый пример ради убедительности здесь не требуется.

Наличие правила, документированной реализации и доказанного выполнения в эксплуатации — разные уровни. Перечень параметров не заменяет последний. Такая честная граница делает материал полезнее для решения, чем оптимистическая догадка о ненаблюдаемом состоянии.

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

Вывод не требует центра разрешений для каждого разговора. Внешние значения меняются ради меньшей сопоставимости; нужные старому диалогу связи остаются у ответственного прокси. Новая выдача подтверждает обновление, но не отменяет того, на что текущий разговор еще вправе опираться.

Источники