Resumo

  • RFC 3388 transformou linhas de mídia de SDP em membros identificáveis de relações executáveis, mas invalidava toda a camada de agrupamento quando uma única linha não tinha identidade completa e estável.
  • Sua compatibilidade com implementações antigas deixava uma incerteza deliberada: uma resposta SIP bem-sucedida não provava que o par havia entendido, aceitado ou executado o grupo.

Um ofertante envia áudio e vídeo como um grupo de sincronização. O respondente antigo não reconhece a=group nem a=mid, ignora ambos como atributos SDP desconhecidos e aceita a sessão. A sinalização termina normalmente. Há áudio. Há vídeo. Nada nessa troca confirma que o receptor vai reproduzi-los em conjunto.

RFC 3388 não criou um cabeçalho SIP Require para transformar essa incerteza em falha obrigatória. O par antigo podia tratar os membros de FID como fluxos independentes, operar como misturador, rejeitar a sessão por outra razão ou levar o ofertante a tentar uma descrição mais simples. O sucesso do diálogo era um recibo para a sessão básica, não para a relação acrescentada.

Publicado na Standards Track em dezembro de 2002, o RFC enfrentou uma limitação do Session Description Protocol. SDP conseguia listar várias linhas m=, mas não tinha uma maneira padronizada de declarar que duas delas precisavam de reprodução sincronizada ou que vários destinos representavam uma única instância lógica de mídia.

A extensão adicionou uma chave local e uma aresta. O atributo de mídia a=mid dava a cada linha um token único dentro da descrição. O atributo de sessão a=group reunia tokens segundo uma semântica registrada. As duas semânticas iniciais eram LS, para lip synchronization, e FID, para flow identification.

LS não era uma legenda explicativa. Ele mandava a aplicação recuperar a relação temporal original e sincronizar a reprodução. Em RTP, informações RTCP podiam relacionar relógios de timestamps diferentes a uma referência comum; outros transportes precisavam de outro mecanismo. O grupo declarava a obrigação. Não fornecia amostras de relógio nem provava o resultado percebido pela pessoa.

FID alterava decisões de envio. Um terminal celular podia anunciar portas distintas para codecs associados a bearers de rádio diferentes. Um componente podia receber voz enquanto outro recebia eventos DTMF. Se mais de um membro suportasse o codec em uso, o remetente precisava enviar cópias às sessões RTP correspondentes.

Por isso, a relação tinha autoridade operacional. Uma aresta errada podia duplicar conteúdo ou mudar seu destino. A seção de segurança advertia que a modificação de um grupo FID podia obrigar participantes a enviar mídia para um destino arbitrário. Integridade da sinalização não era apenas proteção do texto; era proteção da decisão de encaminhamento que o texto ativava.

As condições para essa autoridade eram deliberadamente rígidas. Cada mid tinha de ser único na descrição. Um grupo que mencionasse um token inexistente era ignorado por inteiro, como se aquela linha de grupo não existisse. E, quando qualquer agrupamento era usado, todas as linhas de mídia precisavam carregar mid, inclusive as que não apareciam naquele grupo.

Esse último requisito impedia uma conclusão cômoda. Uma linha sem nome talvez fosse independente. Também poderia ser vestígio de truncamento, erro do gerador ou perda da chave de junção de uma relação. O receptor não tinha evidência para distinguir essas histórias. Portanto, uma única lacuna anulava todos os grupos, preservando as descrições básicas sem inventar associações parciais.

O modelo offer/answer adicionava estabilidade temporal. RFC 3264 alinhava a primeira linha m= da oferta à primeira da resposta, a segunda à segunda e assim por diante. mid não substituía essa regra ordinal. Na resposta, o rótulo de cada posição tinha de coincidir com o da oferta. Se mudasse, a aplicação ignorava todos os atributos mid e group.

O RFC recusava novamente a reparação por intuição. Trocar dois rótulos podia parecer um erro óbvio e reversível, mas confiar nos nomes reescreveria a correspondência negociada pelas posições. Confiar nas posições e manter as relações produziria outra contradição. O protocolo mantinha a sessão básica e retirava autoridade da camada inconsistente.

A resposta servia como recibo positivo de associação. Um respondente que entendesse a semântica devolvia o mesmo conjunto de membros ou um subconjunto. Se recusasse uma linha ao colocar sua porta em zero, precisava retirar seu mid do grupo retornado. A relação usada pela sessão era a presente na resposta, não toda a ambição da oferta.

O respondente também não podia inventar um novo grupo na própria resposta. Como a sequência terminava ali, não receberia confirmação de que o ofertante aceitara aquela relação. Para propor outra associação, precisava originar uma nova oferta. O limite não privilegiava um participante; exigia uma sequência de mensagens capaz de produzir aceitação observável.

Havia ainda uma restrição de cardinalidade. Uma linha podia participar de grupos com semânticas diferentes, mas RFC 3388 não permitia que ela aparecesse em mais de um grupo com a mesma semântica. RFC 5888 substituiu o documento e removeu essa proibição depois da experiência de implementação. A mudança separou dois assuntos: completar a identidade continuava essencial, enquanto limitar relações legítimas demais não era.

A primazia do código em execução de Lu Heng ajuda a localizar a regra comum. O padrão podia testar localmente unicidade, cobertura de todas as linhas, referências existentes, estabilidade entre posições e conjunto aceito na resposta. Não precisava decidir a arquitetura interna, o algoritmo de sincronização ou a política de fallback de cada aplicação.

A especificação inicial mínima acrescenta outra fronteira: padronizar o identificador, as semânticas registradas e o recibo de aceitação, deixando a implementação futura evoluir localmente. Um registro de semântica facilita cooperação; não prova que o mecanismo rodou nem que o usuário viu o efeito prometido.

O valor histórico de RFC 3388 está nesse recuo controlado. Linhas de mídia válidas podiam sobreviver a uma relação inválida. Uma chamada aceita podia conservar a incerteza de compatibilidade. O sistema preferia perder a automação do grupo a aplicar uma instrução correta ao objeto errado.

Um único rótulo ausente anulava todos os grupos porque a relação só podia agir quando o conjunto de nomes estava completo. Sem esse fechamento, sucesso de transporte e plausibilidade visual ainda não eram consentimento para executar as associações.

Fontes