Resumo

  • Pela RFC 4028, o prazo só avança quando um re-INVITE ou UPDATE dentro do diálogo recebe resposta 2xx. Enviar a requisição, observar tráfego ou receber 422 não renova a sessão.
  • Session-Expires, Min-SE e refresher distribuem frequência, dever de renovação e limpeza de estado. Não comprovam RTP, presença humana, qualidade, consentimento nem legitimidade da cobrança.
  • Uma decisão auditável separa transação, diálogo, mídia, aplicação e estado comercial, preservando a origem e o relógio de cada evidência.

O minuto que existiu só no razão contábil

Considere uma chamada corporativa cuja sinalização passa por um proxy com estado, enquanto o RTP segue outro caminho. O endpoint responsável envia um UPDATE sem SDP; o par devolve 200 OK; o proxy calcula uma nova expiração. Antes disso, porém, uma falha unilateral interrompeu os pacotes de voz. Não há novos relatórios RTCP e a pessoa já abandonou o aparelho, mas a aplicação ainda não enviou BYE.

Se a plataforma de faturamento consome apenas o evento “session refreshed”, ela prolonga a chamada. Todos os registros podem ser autênticos. O 2xx confirma uma transação SIP. O silêncio confirma outro fato. A divergência nasce porque uma camada ganhou autoridade sobre as demais.

A RFC 4028 foi criada para um problema mais limitado: um BYE pode não ser enviado ou pode se perder, deixando proxies call-stateful com estado indefinidamente. Renovações periódicas dão a endpoints e intermediários um limite para abandonar estado SIP obsoleto. A própria especificação distingue isso de mecanismos de vivacidade específicos da sessão, como RTCP.

O temporizador não é, portanto, um batimento universal. É uma regra de validade para estado de sinalização.

Três noções de tempo, não um relógio soberano

O intervalo da sessão é o período máximo permitido entre renovações bem-sucedidas. Seu valor corrente vem de Session-Expires no 2xx mais recente que concluiu a negociação.

O temporizador mínimo é o menor intervalo que um elemento aceita. Requisições dentro do diálogo consomem capacidade; Min-SE impede que um participante imponha renovações excessivamente frequentes.

A expiração é um limite local. O UAS conta a partir do envio do último 2xx; o UAC, do recebimento; cada proxy, do evento que observou ao encaminhar a resposta. Trânsito e processamento fazem esses instantes diferirem. Não existe um carimbo global atestado por todos.

Um registro que diz apenas “1.800 segundos” não revela qual resposta instalou o valor, quando cada nó iniciou a contagem, quem deveria renovar nem se uma resposta posterior desativou o temporizador. Para reconstrução, é preciso guardar o evento de origem e o deadline monotônico local, além do tempo civil usado na correlação.

O caminho participa da negociação

O UAC pode anunciar suporte com a option tag timer e sugerir um intervalo. Proxies que retêm estado têm interesse legítimo na duração. Podem pedir o uso do temporizador, reduzir Session-Expires ou elevar o piso Min-SE, mas não podem empurrar o intervalo abaixo do maior mínimo acumulado.

O UAS devolve no 2xx o valor final e escolhe refresher=uac ou refresher=uas. Na volta, os proxies observam o resultado, sem reescrever o valor final.

Quando a proposta é curta demais, o elemento responde 422 Session Interval Too Small e informa Min-SE. O UAC pode iniciar nova transação com CSeq maior e um intervalo aceitável. Essa troca converge restrições; ela ainda não renovou nada. Só o 2xx desloca a expiração.

Isso cria um risco perto do prazo. Um 422 tardio ensina o próximo valor, mas o novo pedido ainda precisa terminar antes do deadline vigente. Um painel que mostra apenas o 200 eventual apaga justamente o período em que a continuidade esteve ameaçada.

O piso também limita negação de serviço. Uma alta repentina de 422 pode sinalizar rota alterada, nova política, proteção contra sobrecarga, default defeituoso ou tentativa de amplificar trabalho. O código não escolhe sozinho a explicação.

uac e uas são papéis de transação

O parâmetro refresher designa quem deve produzir a próxima renovação. Ele não identifica de forma permanente o originador da chamada, o cliente pagante ou uma pessoa.

UAC e UAS mudam a cada transação. Quem recebeu o INVITE inicial pode tornar-se UAC ao enviar UPDATE. Por isso, a RFC define como preservar o responsável real quando os papéis se invertem.

Um log que guarda apenas refresher=uac é ambíguo. Deve associar o papel ao endpoint daquela transação e conservar Call-ID, tags, método, CSeq e direção.

Forking aumenta o problema: um INVITE pode criar vários diálogos, cada qual com intervalo, responsável e expiração próprios — ou sem temporizador. Renovar um ramo não conserva os irmãos. Também é possível remover o timer no meio do diálogo: se o 2xx mais recente não trouxer Session-Expires, a frase “a chamada tinha timer” já é histórica, não corrente.

A única fronteira que move o prazo

A RFC 4028 é estrita: somente o 2xx que responde a uma requisição de renovação estende a sessão.

O envio do UPDATE não basta. Resposta provisória não basta. 401, 407 e 422 não bastam. Uma gravação bem-sucedida no socket ou a observação do proxy tampouco. Uma tentativa autenticada posterior pode concluir, mas não retroage sucesso à primeira.

Se a renovação expira ou retorna 408 ou 481, o UA renovador envia BYE conforme as regras. Outros erros podem admitir uma repetição limitada, não uma série infinita que encubra a falha.

O não renovador tem dever diferente. Se não observar renovação, deve enviar BYE pouco antes do vencimento; a antecedência recomendada é o menor valor entre 32 segundos e um terço do intervalo. A margem evita chegar ao instante em que firewall ou NAT ALG já fechou o caminho.

O proxy possui autoridade ainda menor. Ao atingir seu deadline local, pode apagar seu estado e liberar recursos, mas não deve originar BYE. Ele administra seu livro interno; não fala em nome do endpoint.

Assim, mídia pode continuar depois que um proxy esqueceu o diálogo; um BYE pode sair de um lado e se perder; deadlines locais podem divergir. Produzir depois um único “horário de desligamento” transforma desacordo observável em precisão fictícia.

Uma renovação pode alterar muito mais

Re-INVITE e UPDATE não viram pings neutros só porque também renovam o timer. A RFC 3311 permite que UPDATE mude informações da sessão e o torna target-refresh. A RFC 3261 liga re-INVITE às regras de diálogo, alvo remoto e offer/answer.

Para uma renovação pura, a RFC 4028 recomenda UPDATE sem oferta quando o par o suporta. Um re-INVITE normalmente contém oferta, ainda que o SDP seja equivalente. Uma requisição enviada para hold, retomada ou mudança de mídia também pode renovar incidentalmente.

Logo, o mesmo 2xx pode acompanhar novo Contact, oferta e resposta SDP, mudança de direção, codec, endereço, autenticação ou resolução de corrida. A RFC 6141 trata re-INVITE, 491 e restauração de offer/answer justamente porque não são heartbeats triviais.

O registro precisa dizer se a intenção era timer-only, se havia SDP, se versão, portas ou direções mudaram, se Contact mudou e qual resposta concluiu. A etiqueta “refresh success” oculta efeitos relevantes.

Sinalização viva, mídia morta

A RFC 3264 negocia fluxos sendrecv, sendonly, recvonly, inactive ou rejeitados. Esses estados descrevem intenção e permissão, não entrega de pacotes.

A RFC 3550 deixa claro que RTP não garante entrega nem qualidade. RTCP fornece relatórios de recepção, tempo e participantes; é evidência forte para fluxo e desempenho, mas não prova que alguém ouviu, compreendeu, consentiu ou recebeu valor.

Uma arquitetura responsável conserva ao menos cinco planos: transação SIP; diálogo e timer; RTP/RTCP; aplicação e ação humana; contrato, cobrança e conformidade. O 2xx é forte nos dois primeiros e quase silencioso nos três últimos.

É possível ter SIP fresco e mídia ausente, mídia fluindo sob partição de sinalização, stream intencionalmente inativo ou software renovando uma sessão abandonada. A distinção de Heng Lu entre poder simbólico e realidade prática aparece aqui em forma operacional: o log não é falso, apenas menor que a realidade que tentam fazê-lo governar.

Integridade por salto também tem limite

Proxies modificam legitimamente os campos de temporização. Por isso, S/MIME ponta a ponta não consegue proteger um campo que intermediários precisam alterar. A RFC 4028 recomenda integridade hop-by-hop com TLS nos saltos relevantes e uso de SIPS.

Essa proteção reduz adulteração por terceiros, mas vale apenas onde a cadeia está protegida. Ela não transforma o intervalo em atestado de mídia, presença ou cobrança.

O registro de errata da RFC 4028 contém correções verificadas de linguagem UAC/UAS. Uma errata relatada em maio de 2026 discute o comportamento de proxy quando o UAC pede explicitamente refresher=uas; permanece Reported. Deve orientar testes de interoperabilidade, não ser citada como norma já alterada.

Um rastro capaz de sobreviver à contestação

O registro defensável associa cada transação ao diálogo e aos endpoints reais. Guarda método, CSeq, branch, route, campos de timer antes e depois dos intermediários, timestamps, deadlines calculados e o 2xx exato que os moveu.

Também preserva efeitos laterais: presença e hash de SDP, versão offer/answer, direções, Contact, desafios de autenticação e retries. BYE precisa de origem e causa — usuário, falha do renovador, timeout do par ou política.

Mídia e aplicação continuam independentes, embora correlacionáveis. Mensagens SIP expõem identidade e topologia; o original pode ficar em repositório restrito, enquanto telemetria comum usa projeções compactas ou hashes vinculáveis.

Testes devem cobrir 422 perto do prazo, 401 seguido de sucesso, 408, 481, timeout no não renovador, limpeza do proxy sem BYE, falha de mídia com refresh contínuo, mídia após perda de sinalização, diálogos bifurcados, remoção do timer, UPDATE sem oferta, re-INVITE com SDP alterado, target refresh, failover que perde estado e salto sem integridade esperada.

O resultado não é um único indicador verde. É uma cronologia que explica qual camada continuou, qual falhou e com que autoridade cada agente atuou.

Fontes