Resumo

  • O SDP tem duas versões diferentes: v=0 identifica a versão do formato, enquanto sess-version, em o=, avança quando muda a descrição de uma sessão identificada.
  • O número só ordena dentro do tuple de origem. Compará-lo entre origens ou interpretar seu formato de timestamp como hora autenticada elimina a evidência de continuidade.

Um failover não cria uma régua mundial

Em uma troca de controladores, o nó reserva pode começar com uma versão maior ou menor que a do nó anterior. Cada ferramenta controla sua alocação. O RFC não define um contador compartilhado por todos os produtores de SDP, e a mudança de endereço altera justamente a identidade que delimita a comparação.

O atalho session_id + max(version) parece eficiente. Ele também mistura três fatos: ordem declarada pelo criador, momento de chegada e autorização para suceder outra origem. Uma mensagem recebida depois pode ser velha; uma versão maior pode pertencer a outra linhagem; uma migração aprovada ainda pode não ter sido aceita pela contraparte.

v=0 não é a revisão zero da chamada

RFC 8866 começa a descrição com v=0. Esse valor informa a versão do próprio Session Description Protocol, sem versão menor. Acrescentar vídeo, mudar codec ou trocar destino de mídia não cria v=1.

A linha obrigatória o= leva username, session ID, session version, network type, address type e unicast address. É nela que sess-version marca a revisão da descrição. A ferramenta deve aumentar o valor quando modifica o documento; o texto recomenda usar timestamp para alocá-lo.

Confundir os campos abre duas falhas. Incrementar v= inventa outro formato de protocolo. Alterar bytes sem mexer em sess-version chama dois estados de uma mesma revisão. Um registro correto guarda ambos e aplica a cada um seu alcance.

A identidade vem antes da ordenação

O RFC atual diz que username, session ID, network type, address type e unicast address formam juntos o identificador globalmente único da sessão. Um session ID igual em outra máquina não transporta a história. Um username não autentica uma pessoa. Um novo endereço não recebe continuidade automaticamente.

RFC 2327 explicitava a razão do contador. Handley e Van Jacobson disseram que ele ajudava anúncios proxy a descobrir qual, entre várias publicações da mesma sessão, era mais recente. A comparação começa depois de demonstrar “a mesma sessão”, não antes.

Se a operação planeja alterar o tuple durante o failover, precisa registrar a migração: origem velha, origem nova, autoridade, instante efetivo, estado transferido e regra de retorno. O maior decimal não concede esse mandato.

No offer/answer, versão repetida exige conteúdo repetido

RFC 3264 estabelece uma regra mais forte. Uma oferta que modifica a sessão mantém a linha o= anterior, exceto pela versão, que aumenta em um. Se a versão não aumentar, o SDP precisa ser idêntico ao documento que já usava aquele valor. A repetição é um no-op, embora o answerer ainda produza uma resposta válida.

Assim surge um teste objetivo: mesma origem, mesma versão e bytes diferentes formam conflito, não retransmissão comum. O receptor deve preservar os dois hashes, marcar a linhagem e seguir sua política de erro. “Último recebido vence” apaga a inconsistência.

Versão nova também não é prova de mídia nova. Ela mostra que o criador declarou modificação. Aceitação do answerer, chegada de RTP e qualidade para o usuário são resultados separados.

O formato de relógio não autentica o relógio

RFC 8866 recomenda segundos desde 1º de janeiro de 1900 UTC para o session ID e aconselha timestamp para sess-version. Isso ajuda um criador a gerar valores distintos e crescentes. Não certifica sincronização, horário de recebimento nem autoridade institucional.

O próprio RFC exige outra base para confiança: a descrição precisa chegar de fonte conhecida e confiável por transporte autenticado e protegido em integridade. O recibo operacional deve unir o tuple declarado, o principal autenticado e o resultado da proteção. A linha não autentica a si mesma.

SAP guarda outra marca de mudança

RFC 2974 dá ao Session Announcement Protocol seus próprios originating source e message identifier hash. Uma mudança no hash manda reexaminar o anúncio. O SDP dentro do payload continua com origin e session version próprios. Sinal de distribuição e linhagem do documento são evidências diferentes.

Essa fronteira combina com o propósito do SDP: formato de descrição, não protocolo de transporte, e não negociador autônomo de conteúdo ou encoding. SIP offer/answer usa SDP em negociação limitada; SAP, HTTP e email podem carregá-lo. Entrega, identidade, decisão negociada e resultado de mídia se relacionam sem se tornarem sinônimos.

Mark Handley dentro de uma obra coletiva

RFC 2327 lista Mark Handley e Van Jacobson. RFC 4566 lista Handley, Jacobson e Colin Perkins. O atual RFC 8866 é assinado por Ali Begen, Paul Kyzivat, Perkins e Handley. A história é coletiva, e creditar um inventor único apagaria a própria procedência que o mecanismo ensina a preservar.

A Royal Society descreve Handley como Professor of Networked Systems na UCL, autor de muitos padrões da Internet e ex-integrante do Internet Architecture Board. A ACM SIGCOMM concedeu a ele o prêmio de 2019 por contribuições a multimídia, multicast, controle de congestionamento, redes multipath e padronização de protocolos.

A alegação que o contador sustenta

Com identidade completa, bytes exatos e aquisição confiável, sess-version sustenta uma frase limitada: este criador marcou a descrição como revisão posterior da mesma sessão. No escopo de RFC 3264, também revela conteúdo divergente sob a mesma versão ou mudança sem incremento.

Ele não comprova sucessão entre origens, relógio correto, autorização do remetente, aceitação da oferta, chegada de pacotes ou sucesso do serviço. Migração, transporte, negociação, observação e resultado precisam de provas próprias.

Fontes