Resumo

  • A linha o= do SDP combina uma identidade de sessão com um sess-version separado; uma nova descrição pode continuar pertencendo à mesma sessão.
  • O SDP geral exige aumento da versão quando há mudança. No Offer/Answer, uma oferta alterada conserva o restante de o= e soma exatamente um; versão repetida exige SDP idêntico.
  • Uma revisão maior ajuda a recusar material antigo, mas não autentica o remetente, aceita a proposta, autoriza mídia nem prova consentimento ou entrega.

Uma sessão durava mais que sua descrição

Conferências mudam de horário. Chamadas ganham vídeo, suspendem áudio e mudam o endereço de recepção. Se cada edição ganhasse nova identidade, os participantes perderiam a continuidade. Se a identidade nunca mudasse e não houvesse revisão, uma cópia atrasada poderia voltar como atual.

O SDP colocou as duas respostas na origem:

o=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address>

Username, session ID, tipos de rede/endereço e endereço de origem formam o lineage. sess-version ordena descrições dentro dele. Só depois de validar o tuple completo faz sentido comparar versões. O mesmo sess-id em origens diferentes não funde sessões distintas.

Origem não significava credencial

O username pode ser um login ou apenas . A especificação atual permite nome arbitrário e endereço privado por privacidade, desde que o tuple continue globalmente único. A origem, portanto, é namespace, não comprovação de pessoa, empresa ou equipamento.

O endereço de o= também não precisa ser o destino da mídia. O gerador escolhe sess-id localmente. Um timestamp no formato da época NTP foi recomendado para evitar colisões, mas não atesta relógio correto, instante de criação ou posse do endereço.

Esses limites deixam uma tarefa para o protocolo externo: autenticar quem enviou, proteger a integridade e decidir se aquela fonte pode propor a mudança.

Cada receptor podia julgar a revisão

Quando a descrição muda, sess-version aumenta. O receptor guarda origem, versão e fingerprint do texto aceito; ao receber outra cópia, evita que uma revisão antiga substitua a mais nova.

Não existe registrador central de versões. A comparação é local e relativa. O SDP geral exige crescimento, não necessariamente +1; um valor com aparência temporal não vira hora civil; números de origens diferentes não pertencem à mesma sequência.

O registro útil não é “vi 40”, mas “nesta origem e neste contexto de sinalização, recebi estes bytes como versão 40 e tomei esta decisão”.

Offer/Answer apertou o contrato

O SDP nasceu como formato de descrição. O modelo Offer/Answer definiu como dois agents formam uma visão comum e deixou transporte, contexto, ordem, rejeição e resolução de ofertas simultâneas para um protocolo superior como SIP.

Se um agent modifica sua oferta, a nova linha o= permanece idêntica à anterior, exceto por versão incrementada em um. As coordenadas estáveis dizem “mesmo lineage”; o passo único diz “próxima revisão deste agent”.

Se a versão não avançar, o SDP precisa ser idêntico ao texto associado àquela versão. Repetir uma oferta igual como no-op é permitido e ainda exige uma answer válida. Esconder bytes novos sob um número antigo não é.

Para auditoria, dois corpos diferentes sob o mesmo (origin, version) são evidências conflitantes. A ordem de chegada não transforma o último em verdade.

Offer/Answer também restringe ID e versão a inteiro assinado de 64 bits, com versão inicial abaixo de 2^62 - 1, evitando rollover. É uma regra desta aplicação, não aritmética circular universal do SDP.

Revisão maior continuava sendo proposta

O número não aceita a mudança. O answerer pode aceitar streams compatíveis, rejeitar outros ou usar a sinalização para rejeitar tudo. Com rejeição, o estado descritivo anterior volta a valer.

Concorrência também não se decide pelo maior valor. Um agent não emite nova oferta enquanto aguarda resposta ou deve responder ao peer. Duas ofertas simultâneas geram glare, resolvido acima do SDP. A versão não é lock distribuído.

Uma answer válida comprova acordo descritivo, não efeito. Não prova chegada de pacotes, funcionamento de codec, passagem no firewall, consentimento humano, legalidade de gravação, cobrança ou conclusão do serviço.

Frescor não produzia confiança

Um atacante também escolhe um número enorme. Por isso, Offer/Answer depende do protocolo de sinalização para autenticação fim a fim e integridade. O receptor mantém decisão local de admissão e consentimento.

Autenticação nomeia a fonte reconhecida; integridade protege o trânsito; origin declara lineage; versão declara revisão; Offer/Answer registra proposta e decisão; telemetria registra efeito. Misturá-los concede ao contador uma autoridade que ele nunca recebeu.

O mérito histórico do SDP foi modesto e forte: separar identidade e mudança para que cada ponta pudesse detectar material velho sem pedir licença a um servidor global, preservando ao mesmo tempo o direito local de rejeitar a nova proposta.

Fontes e limites da evidência

A base normativa está em RFC 2327, RFC 4566, RFC 8866 e RFC 3264. Os documentos fixam gramática e Offer/Answer; não medem produtos atuais, identificam um remetente real nem provam entrega de mídia.