Resumo

  • A RFC8599 obriga o proxy a gerar periodicamente novos valores PURR, mesmo sem mudança dos parâmetros de push, e a conservar os anteriores enquanto os diálogos associados permanecem em curso.
  • PURR é uma referência única no contexto do proxy, não uma identidade global do dispositivo. Escolha por diálogo, rota, registro e autorização do serviço de push têm limites próprios.
  • Renovação e retenção atendem a finalidades diferentes: reduzir a correlação externa e preservar a responsabilidade local por uma dependência ainda ativa.

Antigo não significa encerrado

Há uma armadilha na palavra “antigo”. Em tarefas de manutenção, ela frequentemente indica algo a substituir ou remover. Num diálogo SIP, porém, um valor emitido antes pode continuar sendo o endereço indireto de uma necessidade presente. A idade da referência não demonstra a idade da obrigação, muito menos seu encerramento.

Considere uma situação hipotética. Um agente de usuário inicia um diálogo usando uma referência que chamaremos de P1. Em outro registro, recebe P2. Uma conversa posterior pode anunciar P2, enquanto uma solicitação durante o primeiro diálogo ainda utiliza P1. Os rótulos são explicativos: não são valores capturados em rede, identificadores de produção nem exemplos prontos para envio.

Um proxy que já tenha apagado P1 talvez reconheça P2 perfeitamente. Pode aceitar o registro recente e permitir novas conversas. Mesmo assim, perde a associação necessária para tratar uma solicitação da conversa anterior. O teste da novidade passa; o teste da dependência que sobrevive falharia.

A RFC8599, publicada em maio2019, trata essa diferença como duas obrigações simultâneas. O proxy deve gerar periodicamente uma nova Proxy Unique Registration Reference, PURR, inclusive quando as coordenadas do push não mudaram. Deve também conservar os valores antigos enquanto os diálogos associados a eles estiverem em andamento.

Não é um conflito entre privacidade e serviço que precise ser resolvido escolhendo um lado. A rotação reduz a estabilidade do valor exposto a terceiros. A retenção preserva a capacidade interna de atender a diálogos que ainda usam um valor anterior. O que muda para os próximos interlocutores não cancela automaticamente o que os anteriores podem continuar utilizando.

O push recupera uma condição de disponibilidade

Aplicativos móveis podem ser suspensos. Um registro SIP ainda pode ser válido quando a aplicação não está disponível para receber sinalização continuamente. A RFC8599 permite que o proxy solicite uma notificação ao Push Notification Service, PNS, para acordar o agente de usuário e provocar a atualização do registro.

A notificação não é a própria solicitação SIP. Sua função é contribuir para que o aplicativo volte a uma condição em que a sinalização possa chegar. O provedor aceitar o pedido de push não prova que o agente despertou, que a atualização terminou ou que uma transação em espera ainda consegue produzir o efeito desejado.

O agente obtém do serviço um Push Resource ID, PRID, com formato definido por esse serviço. No registro SIP, informa ao proxy o provedor, o PRID e, quando exigido, um parâmetro adicional. A descoberta do serviço, a inscrição nele e a manutenção dessa relação ficam fora das regras de push que a RFC8599 especifica.

Essa separação impede inventar uma única validade mundial para todos os recursos de notificação. A conta ou inscrição do provedor, o vínculo de registro SIP, o transporte, o diálogo e uma solicitação particular podem terminar em momentos diferentes. “O dispositivo está ativo” é um resumo pobre quando a decisão depende de qual dessas condições permanece válida.

As regras de registro são aplicadas a vínculos individuais. Um agente de usuário pode manter vários, e o despertar leva à atualização de seus registros de acordo com o procedimento. Simplificar tudo para um registro global do aparelho apagaria justamente as fronteiras que permitem distinguir uma associação válida de outra que já foi removida.

A referência protege as coordenadas privadas

O interlocutor de uma conversa precisa enviar sinalização posterior, mas não precisa conhecer todos os dados usados para solicitar push. A RFC8599 proíbe que o agente inclua os parâmetros pertinentes de notificação em solicitações que não sejam REGISTER, com a exceção explícita de pn-purr. Assim, pn-provider, pn-prid e pn-param não são distribuídos como informação normal de diálogo.

O proxy gera PURR e a utiliza para recuperar as informações armazenadas que permitem solicitar uma notificação. A unicidade vale dentro de seu contexto. Não se trata de atribuir um número permanente ao aparelho perante qualquer rede nem de criar uma autoridade central que forneça referências para todos os proxies.

O valor deve ser impossível de forjar, anônimo e não correlacionável por entidades diferentes do proxy. Um espaço suficientemente grande de valores aleatórios seguros é uma alternativa de implementação, não uma escolha de algoritmo imposta universalmente. As propriedades exigidas não determinam uma única forma de armazenar os dados.

A possibilidade de o proxy fazer a associação é intencional. Ele precisa dela para cumprir a função. Privacidade, neste ponto, significa limitar a capacidade de outros participantes de reconstruírem vínculos a partir do valor. Não significa impedir o responsável local de recuperar a informação necessária.

Também não significa anonimizar toda a sinalização SIP. Outros campos, comportamentos e registros operacionais podem conter informação. Uma referência opaca não prova que todos os logs sejam anônimos, nem que nenhum observador possa inferir características de uma conversa. Uma promessa pública deve respeitar o objeto específico que a regra protege.

A RFC5627 ajuda a marcar outra diferença: uma GRUU fornece uma URI globalmente roteável para alcançar determinada instância de agente de usuário. PURR serve aqui como referência de busca local de registro para push. Ambos participam da comunicação, mas não são o mesmo instrumento de identidade ou de roteamento.

A rotação ganha sentido nesse desenho. Manter sempre o mesmo valor externo facilitaria correlações ao longo do tempo. Emitir novos valores reduz essa oportunidade. Preservar internamente uma associação necessária não obriga a publicá-la nem a convertê-la num índice permanente compartilhado entre operadores.

O agente escolhe em cada diálogo

A disponibilidade da função no proxy não coloca automaticamente todas as conversas sob ela. A RFC8599 deixa ao agente de usuário a decisão, conforme sua política local, sobre permitir push para solicitações recebidas durante um diálogo. Características da conversa ou de suas mídias podem orientar a escolha.

Se optar pelo mecanismo, o agente inclui pn-purr no Contact inicial pertinente, usando o valor mais recentemente recebido no indicador sip.pnspurr. Sem esse indicador, não deve fabricar o parâmetro. O interlocutor recebe uma referência respaldada pela capacidade anunciada, não uma alegação criada unilateralmente pelo aplicativo.

A estrutura Feature-Caps, definida na RFC6809, permite que entidades não representadas pela URI Contact anunciem capacidades. A descrição de sip.pnspurr no registro IANA trata da associação de solicitações de diálogo com informações de registro. Isso não é uma autorização geral de uso do serviço de push.

A participação numa conversa, a passagem pela rota adequada, a resolução no proxy, a validade do registro e a admissão pelo provedor respondem a perguntas distintas. Possuir uma referência não substitui nenhuma das demais verificações. Um indicador de capacidade tampouco dá controle sobre as mídias ou o comportamento do aplicativo.

Essa distribuição mantém a política perto de quem conhece a aplicação. Não exige que uma instituição classifique ou aprove cada diálogo. Ao mesmo tempo, impede usar o sucesso do provedor como desculpa para ignorar uma condição local: push aceito não comprova que a escolha por diálogo ou o registro tenham sido respeitados.

Um valor novo não é uma ata de encerramento

A resposta de um registro posterior pode apresentar P2 sem mostrar que todas as conversas anteriores trocaram as informações de contato que aprenderam no início. Se um diálogo continua dependendo de P1, o proxy ainda precisa reconhecer essa associação. A emissão é um fato; o término da dependência é outro.

Por isso, uma rotina de limpeza não pode usar apenas a novidade do valor como fundamento. A RFC8599 liga a conservação aos diálogos associados que continuam em andamento. Não define um intervalo universal de rotação nem um prazo fixo após o qual todos os valores anteriores possam ser descartados.

A obrigação também não equivale a retenção eterna. Há um limite associado à dependência real. O problema de projeto é explicar o que permanece necessário e como essa necessidade termina. A escolha artificial entre apagar imediatamente ou guardar para sempre encobre esse trabalho.

O dimensionamento de estado pode exigir mais que a contagem dos registros atuais. Frequência de emissão, duração dos diálogos e encerramento das associações podem importar. Trata-se de uma inferência operacional, não de um resultado medido nesta pesquisa ou de uma estrutura de banco de dados prescrita pelo padrão.

A substituição de um proxy evidencia o risco. Transferir o registro mais recente para um novo nó não garante que ele resolva as referências de diálogos iniciados antes. Particionamento, mudança de armazenamento e passagem de responsabilidade precisam considerar esse estado sobrevivente.

A RFC8599 não fornece um protocolo universal de replicação, migração de proxy ou rotação de chaves. A continuidade precisa ser demonstrada pela implementação local pertinente. Adotar a função não é atestar automaticamente qualquer procedimento de manutenção que a envolva.

Esse custo tem um responsável. O proxy que anuncia a capacidade e mantém a associação, junto com seu operador, deve explicar como continua servindo a dependência. O trabalho não prova a necessidade de um catálogo mundial de PURR. Tal catálogo poderia tornar buscas convenientes enquanto amplia a correlação para além do contexto previsto.

Guardar a associação não basta sem a rota

Uma informação preservada num nó não atende ao pedido que passa por outro caminho. Nas condições aplicáveis de estabelecimento do diálogo, o proxy participante deve inserir-se em Record-Route para permanecer no percurso de solicitações posteriores. A RFC3261 fornece o contexto de conjunto de rotas e alvo remoto do diálogo.

Não se deve confundir isso com Path. A RFC3327 registra os intermediários relevantes para alcançar o agente inscrito. Record-Route trata da continuidade de caminho de um diálogo estabelecido. Uma inscrição com informações corretas não demonstra, por si, que o proxy detentor da referência receberá a sinalização intermediária.

A RFC5626 trata de fluxos iniciados pelo agente, manutenção de conexões e múltiplas conexões diante de NATs e firewalls. São outras condições de alcance. Mesmo uma associação que pareça utilizável não prova que o aplicativo móvel esteja pronto para receber sinalização sem ser despertado.

No processamento intermediário correspondente, pn-purr pode estar na Request-URI ou numa URI de Route, conforme a construção do conjunto de rotas. Quando o proxy recupera os dados necessários, coloca a solicitação em espera e pede a notificação. A resposta2xx da transação REGISTER associada permite retirar e encaminhar a solicitação do diálogo.

Nesse caso não se faz a comparação de URI do parágrafo5.3 usada em outros procedimentos. A solicitação intermediária não carrega pn-prid, pn-provider e pn-param. A associação passa pelo PURR relacionado à resposta de registro, em vez de tentar recuperar do interlocutor as coordenadas deliberadamente ocultadas.

Essa sequência é a do parágrafo6.2.3. Solicitações iniciais têm suas próprias condições, inclusive diferenças relacionadas ao transporte. Não seria correto dizer que toda solicitação SIP, em qualquer circunstância, aguarda necessariamente uma resposta REGISTER2xx.

A continuidade continua tendo limites

Quando o proxy é informado de que um vínculo de registro expirou ou foi removido, a RFC8599 exige que ele não solicite mais push com o PRID correspondente. Uma referência antiga continuar num diálogo não reativa esse vínculo. Também não torna válido um recurso do provedor que já perdeu validade.

A transação em espera mantém seu prazo. O solicitante pode considerar a operação fracassada enquanto o proxy ainda aguarda notificação, registro e resposta. O padrão alerta para isso e recomenda selecionar uma resposta de erro que afete principalmente a transação em questão, sem prejudicar desnecessariamente todo o diálogo.

Retenção, portanto, não significa disponibilidade permanente ou garantia de que toda tentativa dará certo. Significa tratar corretamente uma associação ainda relevante, dentro das condições de registro, provedor e tempo que realmente existem. A obrigação de continuidade não cria uma suspensão infinita dos limites das outras partes.

A segurança específica do PNS permanece em sua própria especificação. A RFC8599 exige sinalização SIP protegida e contenção dos parâmetros privados. Notificações de eventos de registro também podem vazar esses parâmetros, de modo que verificar apenas o Contact inicial não encerra a análise de divulgação.

A RFC8030 documenta a segurança de HTTP Web Push, mas não decide a política do aplicativo SIP para cada diálogo. Admissão pelo provedor, resolução pelo proxy e participação na conversa são fatos diferentes. Somá-los num “direito de acordar o aparelho” genérico torna mais difícil atribuir o custo de despertares desnecessários e tráfego adicional.

As fronteiras precisam sobreviver juntas: uma dependência ativa não deve ser esquecida por causa da emissão de um novo valor; uma autorização encerrada não deve ser prolongada por causa de uma dependência antiga. Não há necessidade de escolher entre destruir todo o estado e permitir qualquer uso dele.

O alcance da documentação é menor que o de uma auditoria

O manual do registrar OpenSIPS3.6, usado como documentação de uma versão específica, descreve pn_enable_purr, pn_process_purr e o limite configurável pn_refresh_timeout. Isso dá forma concreta às operações de anunciar capacidade, encontrar uma referência e manter uma solicitação em espera.

As explicações de2020 sobre suporte ao mecanismo abordam registro e solicitações durante o diálogo. São fontes históricas de implementação. Não demonstram como um conjunto atual de nós conserva referências antigas ou transfere suas associações. Nenhuma rede SIP em produção foi testada para esta pesquisa.

Os errata exigem a mesma precisão. O8136 é editorial e verificado: corrige sip.pnsreq para sip.pnsreg no parágrafo4.1.4. O7136 é técnico e reportado, sobre exemplos de Request-URI em REGISTER; não constitui uma revisão normativa aceita. Não é necessário inventar um exemplo executável para explicar a obrigação.

Assim, há evidência da regra e de formas documentadas de implementá-la, mas não uma certificação de instalações específicas. Confundir essas escalas pode produzir uma confiança que as fontes não sustentam. Uma lista de opções de configuração não é prova de continuidade de um diálogo antigo durante a troca de nós.

A conclusão vai além de “renove os identificadores”. Renove a referência exposta quando a proteção exige isso, mas não apague o caminho local de uma conversa que ainda a utiliza. A autoridade pertinente é limitada e distribuída; não é um centro que aprova a próxima mensagem de cada participante.

Fontes