Resumo

  • Na RFC 3015, um Context era a associação local de Terminations dentro de uma Media Gateway, incluindo topologia e parâmetros de mídia; não era a identidade universal de uma chamada.
  • Resposta de transação, auditoria e execução no máximo uma vez eram provas com escopo. Entrega pelo caminho externo, reprodução no destino e comunicação humana continuavam fora delas.

Uma controladora pede à gateway que associe uma porta de circuito a um fluxo RTP. A gateway cria o Context, devolve um identificador e confirma o Add. O fato operacional é importante: a associação local existe. A frase “a chamada conectou”, porém, acrescenta observações que a resposta não realizou.

Publicada em novembro de 2000, a RFC 3015 definiu o Megaco Protocol Version 1.0 em texto comum com a recomendação ITU-T H.248. O protocolo ligava uma Media Gateway Controller (MGC) a uma Media Gateway (MG) fisicamente decomposta. A MGC cuidava da intenção de conexão; a MG realizava mídia e sinais em recursos próprios. Essa divisão permitia escala e diversidade, mas não fundia o conhecimento de todas as partes.

Um objeto com endereço local

A Termination originava ou recebia um ou mais fluxos. Um Context associava várias Terminations e descrevia quem ouvia ou via quem, além de mistura e comutação quando havia mais de dois membros.

O ContextID era atribuído pela MG e precisava ser único apenas dentro dela. Portanto, o valor não identificava sozinho uma chamada mundial, um cliente, uma cobrança ou uma conversa. Uma chamada de sinalização podia atravessar várias gateways; um Context podia representar só a fase de espera ou uma perna de uma conferência.

As durações também eram diferentes. Terminations físicas, como canais TDM provisionados, podiam persistir. Terminations efêmeras que representavam fluxos RTP normalmente duravam enquanto fossem usadas. O Context nulo guardava as Terminations físicas sem associação com outra. Add podia criar um Context implicitamente; Move transferia uma Termination; Subtract removia a associação, destruía uma Termination efêmera ou devolvia a física ao Context nulo. A saída do último membro apagava o Context.

Esse desaparecimento não tornava o estado ilusório. Mostrava sua natureza: era estado corrente de um executor, não uma ata permanente de tudo que ocorreu no serviço.

Topologia não era testemunho do receptor

A RFC separou a topologia do Context do modo da Termination. A topologia dizia como a mídia circulava entre membros internos; o modo dizia como ela fluía na entrada ou saída da MG.

Quando o modelo dizia que uma Termination podia ouvir outra, ele programava a gateway. Não entrevistava o ouvinte remoto. A MG podia comutar corretamente e emitir pacotes que depois fossem descartados. O destino podia receber os pacotes, mas rejeitar o codec, permanecer mudo, reproduzir em outro dispositivo ou não ter ninguém presente.

SDP descrevia parâmetros de sessão. RTP acrescentava sequência, tempo e relatórios de recepção. Essas fontes eram complementares, não intercambiáveis. Descrição, configuração, emissão, entrega, decodificação, reprodução e compreensão continuavam sendo recibos diferentes.

A ordem tinha um dono

Commands eram agrupados em Actions, e Actions em Transactions. Uma Action normalmente trabalhava em um Context. Dentro da mesma Transaction, os Commands eram executados em ordem. A TransactionReply informava resultados de comandos bem-sucedidos e o erro onde o processamento falhava.

Entre Transactions diferentes, a MGC precisava impor coerência. Em uma Termination deveria haver, em condições normais, no máximo um Add, Modify ou Move pendente, salvo se compartilhassem a mesma Transaction. Subtract podia intervir. Uma remoção com curinga podia passar à frente de adições pendentes, deixando à controladora a obrigação de limpar membros que sobrevivessem.

Logo, a MG tinha autoridade sobre o que executou localmente, enquanto a MGC tinha autoridade sobre a sequência que pretendeu. Uma resposta positiva não demonstrava que outro processo controlador possuía o mesmo modelo nem que uma ordem posterior preservaria a associação.

TransactionPending só dizia que o trabalho ainda estava ativo e incompleto. Reiniciava o temporizador do solicitante e diminuía retransmissões indevidas. Não reservava o caminho externo, não prometia sucesso e não observava mídia.

Auditoria não suspendia mutações

AuditValue devolvia valores atuais de propriedades, eventos, sinais e estatísticas. AuditCapabilities devolvia valores possíveis. Capacidade não era configuração atual; configuração atual não era resultado de serviço.

Quando a consulta usava curingas, a resposta podia trazer a união de valores de várias Terminations. A compactação economizava mensagens, mas removia atribuição individual. Uma possibilidade presente no conjunto não autorizava concluir que todos os membros a ofereciam ou a usavam.

O limite mais importante era temporal: AuditValue e AuditCapabilities não estavam sujeitos a sequenciamento. Se um Modify permanecesse em curso, a auditoria poderia observar corretamente o estado anterior ou posterior. A palavra “atual” não transformava a leitura local em um instante global linearizado com todas as Transactions.

Ao executar Subtract, a MG podia retornar estatísticas da participação da Termination no Context. Elas preservavam um vestígio antes de a associação sumir. Ainda assim, eram contadores locais; não confirmavam recepção remota, áudio inteligível ou conversa concluída.

No máximo uma vez não significava chamada exatamente uma vez

UDP podia perder a solicitação ou a resposta. Muitos Commands não eram idempotentes, e repetir Add sem proteção podia tornar o estado imprevisível. A RFC exigiu, por isso, funcionalidade de execução no máximo uma vez.

As entidades guardavam respostas recentes e Transactions em andamento. Comparavam TransactionID e identidade do emissor com essa memória. Para uma duplicata concluída, repetiam a resposta em vez de executar novamente. Para uma duplicata ainda ativa, suprimiam a nova execução e podiam enviar TransactionPending. Um reconhecimento permitia liberar a resposta, mas o identificador continuava retido por LONG-TIMER para descartar cópias atrasadas.

A garantia dependia da unicidade do identificador, da memória, da janela e da época de execução. Depois de expiração ou reinício, o histórico antigo não seguia disponível por magia. Mesmo durante a janela, a afirmação era apenas sobre uma Transaction da gateway. Não provava que a mídia tocara uma vez, que a pessoa falara uma vez ou que uma cobrança estivesse correta.

TCP não removia falhas em torno de quedas de processo e reconexões. A própria RFC recomendava tratamento de Transaction em nível de aplicação. Entrega ordenada de bytes não recuperava o Context perdido por uma reinicialização.

Segurança do controle não era prova de experiência

Commands não autorizados podiam criar chamadas ou interferir nas legítimas. A RFC exigia proteção para conexões do protocolo em IP e indicava IPsec. Autenticação de origem, integridade, antirrepetição e confidencialidade defendiam a relação MGC–MG. Não autenticavam o que o terminal remoto reproduziu.

A RFC 3525 substituiu a RFC 3015 em 2003. A RFC 3435 manteve o MGCP na trilha informativa e apontou Megaco/H.248 como abordagem padronizada. A sequência documental não prova implementação de um produto, adoção de uma operadora, interoperabilidade nem taxa de sucesso.

O mérito histórico da RFC 3015 foi definir bem um objeto limitado. Ela ofereceu linguagem comum para criar, mover, auditar e remover uma associação local, ordenar mudanças no lugar certo e conter repetição de Commands. O Context podia estar conectado e, justamente por isso, devia ser apresentado como Context — não como toda a chamada.

Fontes