Resumo

  • No SDP da RFC 3108, forward era o sentido que saía do nó ATM descrito; na sinalização do bearer, forward saía de quem iniciava o setup. No modelo de estabelecimento inverso, o mesmo parâmetro ganhava nomes opostos nas duas camadas.
  • O eecid de quatro bytes juntava uma chamada de serviço a uma solicitação de bearer. Era chave de correlação local, não identidade, autenticação, nome global ou evidência de mídia funcionando.

A seta dependia de onde o desenho começava

Para uma media gateway, o tráfego que se afasta dela é forward. Para o protocolo que monta um circuito, forward começa no equipamento que enviou a solicitação. Se outra gateway iniciou o bearer, o fluxo que sai da primeira pode ser forward em uma descrição e backward no setup. O número é igual; a coordenada é outra.

Esse problema recebeu tratamento explícito na RFC 3108, publicada em maio de 2001 na Standards Track. O texto aplicou a sintaxe SDP da RFC 2327 a conexões ATM e AAL2 e definiu atributos para endereços, camadas de adaptação, tráfego, QoS, tipo de bearer, canais e serviços. As descrições podiam acompanhar SIP, MGCP ou Megaco/H.248.

O ponto central era a independência dos planos. A gateway que originava a chamada de voz ou multimídia não precisava originar a conexão comutada que a carregaria. Para o SDP da RFC 3108, forward sempre se afastava do nó considerado e backward se aproximava dele, sem depender do iniciador da chamada ou do bearer.

Na sinalização ATM/AAL2, forward ia do iniciador do estabelecimento ao receptor. No backward SVC setup, a gateway de origem do serviço recebia a solicitação de bearer. Seu PCR de saída era forward em SDP e backward em ATM. A gateway precisava trocar as direções ao converter os parâmetros.

Uma cópia perfeita podia, portanto, ser semanticamente falsa. Capacidade e limites de qualidade seriam atribuídos ao sentido errado, embora a linha passasse no parser e os valores coincidissem nos registros.

Sintaxe não resolvia a política

Os atributos atmQOSparms e atmTrfcDesc levavam directionFlag com f, b ou fb. O campo direcional era obrigatório. Os demais podiam ser quando não especificados, irrelevantes, implícitos ou conhecidos por outro mecanismo.

Ali estavam taxa de pico, taxa sustentável, tamanho de rajada, variação e atraso de trânsito e perda aceitável. Para interpretar cada valor, era necessário registrar o nó de referência, quem começou a chamada, quem começou o bearer e qual protocolo nomeou a direção. Forward isolado não era um dado completo.

Em alguns parâmetros, $ delegava a escolha ao receptor. A descrição indicava opções permitidas, não a escolha efetiva nem o recurso instalado. Uma expressão válida podia continuar inaplicável ao serviço. Entre texto e execução havia seleção, política, configuração e admissão.

A chave retornava para quem precisava reconhecer

Quando controle de serviço e bearer seguiam caminhos separados, a solicitação ATM podia chegar depois do contexto de chamada. A gateway receptora precisava unir os eventos. Para isso, a RFC 3108 usou eecid, end-to-end connection identifier, sinônimo do bnc-id de quatro bytes nos contextos mencionados.

No estabelecimento forward, a gateway que terminava a chamada escolhia o valor, enviava-o por SDP ao lado de origem e o recebia de volta no setup iniciado por esse lado. No estabelecimento backward, a gateway que originava a chamada escolhia o valor, enviava-o ao lado terminal e o recuperava no setup iniciado de lá.

O nó destinado a receber setup criava, portanto, a chave que reconheceria a solicitação futura. A unicidade só precisava valer dentro desse nó. Quem atribuía controlava liberação e reúso; o documento recomendava manter o valor até o fim da conexão.

Essa chave não dizia quem era o usuário. Não autenticava o peer, não reservava por si só um circuito e não demonstrava áudio ou vídeo. Um match demonstrava correlação. Setup/connect demonstrava estado do bearer. Pacotes e medições demonstravam o serviço.

A codificação dentro do protocolo de bearer continuava fora do domínio do SDP. A RFC citava formas de transportar o identificador, mas preservava a autoridade de cada sinalização. Compartilhar a chave não transformava descrição e setup no mesmo registro.

Conexão descrita, conexão criada e mídia observada

Nos fluxos de exemplo, os controladores trocavam informações de serviço e instruíam gateways. Depois uma gateway mandava o setup ATM com o eecid; a outra encontrava o contexto e respondia connect. Só após a sequência o bearer podia carregar mídia.

Cada evidência tinha alcance limitado. SDP mostrava o que foi descrito. O ack de controle mostrava instrução aceita. Setup mostrava tentativa. Connect mostrava estado lógico. Nenhum deles, sozinho, mostrava pacotes nos dois sentidos, perda real, atraso ou experiência da aplicação.

O atributo chain mantinha separadas descrições de camadas diferentes da mesma conexão, como IP e ATM, e as distinguia de alternativas. Ele declarava relação entre documentos. Não dizia que as camadas tinham sido materializadas ou estavam transportando tráfego.

Também é preciso respeitar a cronologia. A RFC 3264 formalizou offer/answer em 2002; RFC 4566 e RFC 8866 atualizaram SDP posteriormente. A linhagem não prova implementação da RFC 3108 nem autoriza ler todos os intercâmbios de 2001 pelo modelo posterior.

Segurança não nascia de uma linha SDP

A RFC 3108 reconheceu que a criptografia de bearers ATM/AAL2 e a autenticação de sua sinalização não tinham convenções equivalentes às de payload RTP. A linha k= podia representar uma chave ou como obtê-la, sem provar que havia proteção ativa.

Uma descrição podia vir de equipamento em instalações não confiáveis do assinante. A segurança dependia do protocolo que encapsulava SDP ou de camadas inferiores. SIP, MGCP e Megaco podiam usar autenticação IPsec e criptografia opcional. Possibilidade de projeto não era fato de operação.

Por isso a cadeia de evidência separa SDP original, remetente e nó descrito; papéis da chamada e do bearer; tradução de direção; origem, escopo e vida do eecid; setup/connect/release; associação de segurança; QoS instalada; contadores; tráfego de ida e volta e resultado da aplicação.

Palavras também precisam de proveniência

O ATM envelheceu, mas o defeito continua atual. Sistemas distribuídos compartilham palavras como local, ativo, primário, dono e forward, embora cada camada adote sua própria origem. A assinatura de uma mensagem pode garantir integridade e ainda preservar perfeitamente o sentido errado.

A gateway da RFC 3108 não resolvia o conflito escolhendo uma autoridade superior. Cada convenção era legítima em seu plano. A solução era traduzir, guardar contexto e usar a correlação sem apagar a distinção. Só o estado em execução e a mídia observada fechavam a cadeia.

As duas camadas diziam forward. O fio não mudava; mudava o lugar de onde cada uma começava a medir. A disciplina histórica foi manter a seta ligada ao seu mapa.

Fontes

  1. https://www.rfc-editor.org/rfc/rfc3108.html
  2. https://www.rfc-editor.org/info/rfc3108
  3. https://datatracker.ietf.org/doc/rfc3108/
  4. https://www.rfc-editor.org/rfc/rfc2327.html
  5. https://www.rfc-editor.org/info/rfc2327
  6. https://datatracker.ietf.org/doc/rfc2327/
  7. https://www.rfc-editor.org/rfc/rfc2543.html
  8. https://www.rfc-editor.org/info/rfc2543
  9. https://www.rfc-editor.org/rfc/rfc2705.html
  10. https://www.rfc-editor.org/rfc/rfc2805.html
  11. https://www.rfc-editor.org/rfc/rfc3015.html
  12. https://www.rfc-editor.org/rfc/rfc3264.html
  13. https://www.rfc-editor.org/rfc/rfc4566.html
  14. https://www.rfc-editor.org/rfc/rfc8866.html