A conexão caiu. A sessão não: como o RTSP guardou estado além do TCP

Resumo

• Um SETUP aceito criava o contexto de controle no servidor e devolvia um identificador Session; nem uma descrição SDP nem uma conexão TCP aberta faziam esse trabalho.
• O contexto podia atravessar a troca da conexão de controle, mas o identificador não substituía a URI correta, o estado do método, a autenticação ou um caminho de mídia alcançável.
• A memória durava somente enquanto o servidor conservasse o estado e recebesse sinais válidos de atividade. TEARDOWN, timeout ou outra ação final podiam transformar a tentativa seguinte em 454 Session Not Found.

O controle remoto não era o fio

O vídeo contínuo e o comando que o controla vivem em ritmos diferentes. PLAY e PAUSE são mensagens breves. A entrega pode durar minutos ou horas. A conexão usada por um desses comandos pode cair, enquanto o servidor ainda precisa lembrar quais pistas foram preparadas, por qual transporte e sob qual linha de tempo.

Em 1998, o RFC 2326 resolveu essa diferença com uma formulação radical: não havia a noção de uma conexão RTSP. A sessão mantida pelo servidor tinha um identificador próprio e era independente de conexões de transporte como TCP. O cliente podia abrir e fechar mais de uma conexão confiável durante o mesmo contexto de apresentação.

Isso não dispensava TCP. Comandos ainda precisavam chegar, respostas voltar e a mídia podia ser intercalada no canal de controle. A separação dizia algo mais preciso: a vida do estado lembrado não era a vida do socket que por acaso transportou uma solicitação. Perder o fio impedia o próximo botão; não ordenava ao aparelho que esquecesse o que já estava preparado.

Uma descrição não reservava nada

Antes de controlar uma apresentação, o cliente costumava obter sua descrição. O SDP do RFC 4566 representa tipos de mídia, formatos, endereços e outros metadados. Ele é uma forma de descrição, não um protocolo que cria transporte ou executa controle.

A palavra sessão aparece nos dois domínios, o que facilita uma inferência errada. Um documento SDP pode enumerar áudio e vídeo e oferecer referências de controle. Ainda assim, não prova que o servidor reservou portas, escolheu um transporte, alocou buffers ou criou estado para um determinado espectador.

O SETUP atravessava essa fronteira. O cliente nomeava um recurso e oferecia alternativas de Transport. Ao aceitar, o servidor escolhia parâmetros, armazenava o resultado e o devolvia. O RFC 7826, que definiu o RTSP 2.0 em 2016, chamou esse resultado de contexto de sessão RTSP. A descrição dizia o que podia existir; o SETUP aceito dizia o que aquele servidor realmente se comprometeu a manter.

A segunda identificação apontava para memória, não para conteúdo

A URI de mídia identificava o objeto controlável. O valor no cabeçalho Session distinguia um contexto de entrega aceito de outro, inclusive quando duas sessões usavam a mesma URI. O RTSP 1.0 exigia uma cadeia opaca e aleatória de pelo menos oito octetos. O RTSP 2.0 fixou de 8 a 128 caracteres, geração criptograficamente aleatória e cerca de 128 bits de entropia recomendada.

A referência ao RFC 4086 protegia contra previsibilidade. Se um valor é fácil de adivinhar, um terceiro tem mais chance de localizar estado alheio. Mas aleatoriedade forte não transformava a cadeia em identidade ou permissão. O RFC 7826 advertia que, sem confidencialidade entre cliente, servidor e proxies confiáveis, o identificador não impedia o sequestro da sessão.

A autenticação respondia a outra pergunta. O Digest do RFC 7616, por exemplo, usava desafio, credenciais, nonce e controles de repetição. Session localizava um registro guardado. A autenticação avaliava o solicitante em um domínio de proteção. Os dois campos podiam acompanhar a mesma mensagem porque nenhum conseguia assumir a função do outro.

Conhecer Session não autorizava qualquer URI

Depois de aprender o identificador, o cliente o enviava em PLAY, PAUSE, TEARDOWN e outras solicitações ligadas ao contexto. Isso permitia encontrar o estado por uma conexão TCP posterior. Não eliminava a URI da solicitação.

Uma sessão agregada torna a distinção concreta. Áudio e vídeo podem compartilhar uma linha de tempo, de modo que um PLAY controle ambos. Mesmo pertencendo ao mesmo Session, uma operação de conjunto precisa usar a URI de controle agregado, não necessariamente a URI de uma pista. A URI orienta proxies, delimita o recurso e preserva o escopo do registro.

O identificador pode localizar uma estrutura interna. Ele não decide se o método é válido naquele estado nem se deve atuar sobre uma pista ou sobre o conjunto. Por isso o protocolo separava sessão inexistente, método inválido no estado atual e operação agregada no escopo errado. Um índice conveniente não virava atalho para colapsar identidade do recurso, máquina de estados e autorização.

Havia também proteção contra mudanças parciais. Quando um SETUP tentava adicionar um recurso ao contexto existente e falhava, o RTSP 2.0 exigia que a sessão e o Transport anteriores permanecessem como se aquela tentativa não tivesse ocorrido. A falha não podia reescrever silenciosamente o acordo já aceito.

Várias sessões por conexão, várias conexões por sessão

O RTSP 2.0 obrigava servidores a suportar conexões TCP persistentes e transitórias. Um cliente podia fazer SETUP e PLAY, fechar o canal e abrir outro mais tarde para PAUSE. Um par capaz de usar conexões transitórias sobrevivia à perda causada, por exemplo, pela expiração de um mapeamento NAT.

O inverso também era permitido: uma conexão persistente podia levar comandos de várias sessões. Logo, o socket não identificava o contexto. Em um instante, cada agente usava apenas uma conexão para determinada sessão, para que o destino de solicitações iniciadas pelo servidor não ficasse ambíguo. Era escolha do canal atual, não uma nova união entre o tempo de vida do socket e o estado.

O caminho de mídia continuava separado. RTP podia seguir por portas UDP negociadas ou ser intercalado com o controle. Mesmo com contexto válido, NAT e firewall podiam bloquear a entrega. O RFC 7825 adaptou ICE à mídia de datagrama controlada por RTSP justamente para obter evidência de alcance dos candidatos. Session dizia qual estado alterar; ICE testava se pacotes podiam atravessar a rede.

Estado retido cobrava sinais de vida

Nenhum servidor podia guardar para sempre contextos abandonados. A resposta Session podia anunciar quanto tempo aguardaria entre solicitações ou outros sinais aceitos; sem outro valor, o padrão era 60 segundos. No RTSP 2.0, o parâmetro timeout aparecia somente na resposta e sua duração não podia mudar no meio da sessão estabelecida.

Qualquer solicitação RTSP que referisse o contexto podia renovar a atividade. Para keep-alive puro, recomendava-se um SET_PARAMETER vazio. Em implantações RTP, o RTCP também podia contribuir. Os relatórios de emissor e receptor do RFC 3550 forneciam informação sobre fontes e recepção; quando associados às fontes e ao tuplo de rede pertinentes, podiam indicar que o lado cliente ainda estava presente.

Essa evidência era estatística. Relatórios RTCP são periódicos e podem se perder. Eles não provam que alguém assistiu, que um quadro foi decodificado, que PLAY concluiu uma transação comercial ou que o assinante continuou autorizado. O sinal justificava reter estado de protocolo. Não era recibo da experiência de mídia.

O texto podia sobreviver ao objeto que nomeava

TEARDOWN encerrava normalmente a entrega. No escopo agregado, podia destruir o contexto comum; quando permitido por mídia, podia remover uma pista e encerrar a sessão ao retirar a última. O servidor também podia expirar o contexto, terminar após REDIRECT ou desistir diante de falha irrecuperável.

Depois desse limite, repetir o identificador não ressuscitava a memória. A resposta 454 Session Not Found cobria Session ausente, inválido ou expirado. O cliente podia conservar os mesmos caracteres com perfeição e, ainda assim, não existir registro vivo correspondente no servidor.

Essa é a lição durável do desenho. O identificador não carregava a sessão dentro de si; apontava para estado revogável sob controle do servidor. Continuidade da conexão, posse da cadeia, escopo da URI, autenticação, alcance da mídia e atividade ofereciam evidências distintas. Nenhuma podia fingir ser todas as outras.