Resumo

  • A RFC 5124 combina o feedback antecipado de AVPF com o processamento seguro de SAVP no perfil SAVPF.
  • No fluxo RTSP descrito, o cliente escolhe exatamente um perfil por mídia em SETUP e o servidor confirma ou recusa.
  • A mudança posterior de perfil requer TEARDOWN e novo SETUP naquele procedimento histórico.
  • A nova seleção não prova que o fluxo antigo terminou limpo, que novas chaves estão ativas ou que não houve intervalo de serviço.
  • AVPF mantém suas regras de tempo; a camada SAVP acrescenta os campos e transformações de SRTCP.
  • O acréscimo descrito fica em torno de 10 a 20 bytes, com 14 bytes no caso padrão citado.
  • avg_rtcp_size precisa refletir o pacote protegido para não exagerar a frequência possível de feedback.
  • O tamanho maior reduz o número de eventos que cabem no mesmo orçamento e na mesma janela útil.
  • SAVPF selecionado não prova proteção da sinalização contra downgrade, estabelecimento de chave ou aceitação do pacote.
  • Integridade SRTCP é obrigatória, mas criptografia pode ser NULL e autenticação de grupo não individualiza necessariamente a origem.
  • A negociação ocorre por descrição de mídia; um fluxo pode falhar enquanto outro permanece válido.
  • A liderança deve tratar toda troca como migração observável, com recibos de encerramento, criação, chave, tempo, ação e resultado.

O botão que escondia dois fluxos

Uma interface mostra a opção “usar feedback seguro”. O operador a ativa durante uma sessão de streaming. A aparência sugere uma propriedade adicionada ao fluxo em execução. O procedimento de RFC 5124 para RTSP conta outra história: o perfil é escolhido no SETUP; para alterá-lo, o cliente precisa desmontar o fluxo e restabelecê-lo.

O estado anterior inclui transporte, endereço, perfil e contexto criptográfico. O novo estado precisa de nova confirmação e, quando o perfil é seguro, do cabeçalho de gestão de chaves correspondente. Entre os dois há uma transição que pode interromper mídia, deixar pacotes tardios do contexto antigo e criar uma janela em que o painel já mudou, mas o caminho ainda não foi refeito.

Essa observação não afirma que toda implementação contemporânea usa exatamente o RTSP histórico. A RFC 7826 posteriormente substituiu a RFC 2326. O valor analítico é a disciplina: uma troca de perfil altera a semântica de fio e o contexto de segurança. Não deve ser registrada como simples mutação de rótulo.

A composição mantém duas contabilidades

SAVPF nasce da união de AVPF e SAVP. AVPF decide formatos de feedback e modifica o calendário de RTCP. SAVP aplica SRTP e SRTCP. Segundo a RFC 5124, o funcionamento AVPF permanece o mesmo; o componente seguro entra depois que o pacote foi agendado ou recebido.

Todos os pacotes RTCP sob SAVPF usam a encapsulação SRTCP de RFC 3711. Isso acrescenta índice, etiqueta de autenticação e, conforme a configuração, identificador de chave e outros campos. A RFC 5124 estima, para o contexto tratado, algo como 10 a 20 bytes extras e cita 14 bytes no padrão. Transformações ou comprimentos diferentes podem mudar o valor.

O acréscimo altera a agenda. RTCP opera com fração limitada de banda. A frequência depende do tamanho médio, do número de participantes e do orçamento. Por isso avg_rtcp_size deve usar o tamanho SRTCP. Manter o valor do pacote aberto faz o escalonador gastar oportunidades inexistentes.

A aproximação de RFC 4585, N <= B*T/R, é uma forma útil de ler a migração. Dentro do mesmo intervalo T e largura B, aumentar R reduz quantos eventos N podem ser relatados. A nova segurança pode funcionar e, ainda assim, deslocar a sessão de Immediate Feedback para Early RTCP se a margem já era estreita.

O relógio não é reiniciado pelo selo criptográfico

Immediate Feedback pressupõe banda suficiente para quase todo evento relevante. Early RTCP já seleciona eventos, mas ainda pode ajudar o emissor. Regular RTCP indica que feedback individual não é mais útil na escala disponível. Tamanho de grupo, perdas, codec, taxa de pacotes e dimensão média influenciam os limites.

T_max_fb_delay define, para cada aplicação, até quando um retorno vale a pena. Não há um valor universal na RFC 5124. Um NACK autenticado pode chegar depois que o quadro deveria ser exibido. A etiqueta continua válida; a oportunidade de reparo terminou.

Mesmo um retorno pontual não prova recuperação. O emissor pode não ter o pacote, escolher reduzir a taxa, não responder, ou enviar uma retransmissão que também se perde. O decodificador pode não recuperar sua referência. A sequência operacional precisa ligar detecção, agenda, envio, aceitação, reação, chegada de mídia, estado do decodificador e resultado visível.

Uma nova chave não nasce do nome do perfil

SAVPF herda os serviços de SAVP e não cria outro protocolo de chaves. A sessão precisa realmente executar o mecanismo indicado, autenticar a contraparte conforme esse mecanismo e construir o contexto. Algoritmos, chaves, índice SRTCP, janela de repetição, validade e MKI fazem parte desse contexto.

Um pacote do fluxo antigo pode chegar após a troca. Se for avaliado no contexto novo, pode falhar autenticação ou repetição. Isso talvez seja comportamento seguro, não defeito de transporte. Sem identificadores de época e horários de corte, o operador vê apenas “pacote seguro descartado”.

RFC 3711 obriga a integridade SRTCP, mas separa confidencialidade. Existe criptografia NULL. Assim, confirmar SAVPF não basta para declarar que conteúdo estava cifrado. Em grupos com chave compartilhada, uma etiqueta também pode provar apenas que algum membro autorizado produziu o pacote, não qual deles.

A negociação é outro plano de ataque

Oferecer simultaneamente alternativas seguras e não seguras cria risco de bidding down. RFC 5124 recomenda não fazer essa mistura; se ela for necessária, a sinalização de negociação deve ser protegida. A preferência por SAVPF não demonstra que a lista chegou intacta.

SRTCP protege pacotes após seleção e chave. Ele não volta no tempo para autenticar DESCRIBE, SETUP, SDP ou uma oferta SIP manipulada. É preciso conservar a descrição recebida, a escolha enviada, a confirmação e a proteção do canal.

No modelo oferta/resposta, AVP, AVPF, SAVP e SAVPF são alternativas exclusivas para uma descrição de mídia. Se o destinatário não suporta SAVPF, deve rejeitar aquela mídia. Se quer SAVPF e a oferta não o usou, também rejeita e pode apresentar uma contraoferta. Uma mudança silenciosa não constitui acordo.

O fracasso é local à mídia. Áudio pode continuar quando vídeo é recusado. Perfis diferentes podem aparecer em sessões RTP separadas. Uma luz única para “sessão segura” apaga a topologia de decisão e torna rollback perigoso.

Compatibilidade não autoriza mistura arbitrária

Entidades SAVP e SAVPF podem coexistir na mesma sessão RTP segura; AVP e AVPF, na mesma sessão não segura. As famílias segura e aberta não podem ser misturadas na mesma sessão, pois RTP e SRTP não são interoperáveis dessa forma. O limite permite evolução dentro de uma família sem transformar todo formato em equivalente.

Na distribuição não interativa por SAP, página ou correio, não existe resposta para confirmar perfil. O iniciador responde por oferecer alternativas adequadas e proteger parâmetros. A RFC 4568 exige confidencialidade no canal quando chaves inline precisam ficar secretas. Um fluxo SRTCP construído sobre chave exposta não recupera segurança.

RFC 8866 e RFC 7826 representam sucessores documentais para SDP e RTSP; RFC 5763 e RFC 5764 formalizaram o contexto DTLS-SRTP posterior. O registro do RFC Editor, porém, mantém RFC 5124 como Proposed Standard de fevereiro de 2008 sem atualização ou obsolescência declarada. Evolução documental e uso atual são afirmações diferentes.

As fontes não fornecem nome de produto, incidente, participação de mercado, traço de campo nem taxa medida de recuperação. O registro IANA prova coordenação de parâmetros, não execução. Portanto, a conclusão segura é sobre arquitetura de evidência, não adoção.

Fontes