Resumo

  • RFC 3525 garantia a execução sequencial dos comandos dentro de uma transação; transações distintas podiam rodar em qualquer ordem ou simultaneamente.
  • TransactionPending, retransmissões, confirmações e mecanismos de execução no máximo uma vez limitavam dúvidas de transporte, sem provar causalidade entre transações ou resultado de mídia.

O protocolo conectava duas autoridades diferentes. O Media Gateway Controller decidia como controlar chamadas e Contexts. O Media Gateway mantinha Terminations e recursos de mídia. A interface precisava transportar decisões sem transformar toda a passarela em uma única fila bloqueante.

RFC 3525 organizou o vocabulário em camadas. A Message carregava Transactions. Cada Transaction trazia Actions. Uma Action operava em um Context e continha Commands. A estrutura era comum; a garantia temporal não atravessava todas as camadas.

Dentro de uma Transaction, os Commands eram executados em sequência. O primeiro Command não opcional que falhasse interrompia os seguintes. Se estivesse marcado Optional, a execução podia prosseguir. O remetente conseguia, portanto, declarar uma cadeia dependente e definir onde um erro deveria quebrá-la.

Entre Transactions, não havia garantia de ordem. Elas podiam ser executadas em qualquer sequência ou ao mesmo tempo. Nem a presença na mesma Message mudava isso. O documento tratava a Message como mecanismo de transporte, sem confirmação própria de aplicação.

Assim, A, B e C podiam sair juntos, enquanto as respostas de A e C voltavam antes de B. O pacote compartilhado economizava transporte; não criava uma transação maior escondida.

Essa liberdade atendia ao sistema real. Commands para Terminations independentes podiam ser enviados em paralelo e processados por threads diferentes. Um atraso local não precisava bloquear todas as demais portas e fluxos.

Quando havia dependência, o MGC precisava assumi-la. Para uma Termination, normalmente deveria existir apenas um Add, Modify ou Move pendente, salvo quando os Commands estivessem na mesma Transaction. Se Modify dependia de Add, proximidade na rede não bastava.

Subtract era a exceção que tornava a corrida observável: podia ser emitido a qualquer momento. Um Modify enviado antes podia ser processado depois da remoção. O MG deveria ignorá-lo e responder com erro. A linha de tempo relevante era a do estado recebido e executado, não a do clique do operador.

Notify também podia atravessar uma mudança de estado. Uma notificação antiga podia chegar após um novo EventsDescriptor. Em UDP, o texto recomendava no máximo um Notify pendente por Termination. RequestID e identidade do evento eram recibos essenciais.

O termo Transaction não prometia rollback total. Quando um Command falhava, o MG deveria restaurar, tanto quanto possível, o estado anterior à tentativa daquele Command. Não havia promessa de desfazer todos os Commands anteriores que já tinham sucesso.

Por isso a TransactionReply listava valores de retorno dos Commands bem-sucedidos e o descritor do erro. O resultado podia ser parcial e ainda assim perfeitamente conforme ao protocolo. Reduzi-lo a uma luz vermelha apagaria o que mudou e o que nunca foi tentado.

Com TerminationID curinga, um Command era aplicado a cada correspondência e gerava resposta individual. Um erro em qualquer correspondência impedia os Commands posteriores. O conjunto podia conter vários sucessos, um erro e uma cauda ausente.

TransactionPending não completava a história. Ele dizia que o processamento estava ativo e reiniciava o temporizador da aplicação. Não indicava o Command corrente, não bloqueava outras Transactions e não prometia sucesso.

Os procedimentos de transporte enfrentavam perda e repetição. TransactionID, respostas retidas, retransmissão e confirmação de resposta davam suporte ao comportamento no máximo uma vez. Reconhecer uma cópia não colocava em ordem duas Transactions diferentes.

Autenticação e integridade tinham limite semelhante. Elas podiam proteger a origem e o conteúdo do controle. Não criavam dependência onde o MGC não a expressou. Duas ordens autênticas ainda podiam competir.

Depois da resposta vinha a execução de mídia. Um Reply demonstrava processamento protocolar; um Audit observava propriedades. Tráfego RTP, decodificação, áudio físico e experiência do assinante continuavam exigindo outros sinais.

Também é preciso preservar a data do texto. RFC 3525 substituiu RFC 3015 em 2003 como resultado do trabalho conjunto IETF Megaco e ITU-T. RFC 5125 o tornou Historic em 2008, porque H.248.1 continuou evoluindo sob a ITU-T. O artigo descreve uma fronteira histórica, não todos os produtos atuais.

O registro IANA Megaco/H.248 continua ativo sob referências posteriores. Ele conserva nomes de packages, erros, razões e profiles. Essa continuidade coordena vocabulário; não identifica a versão implantada nem reconstrói uma corrida de Commands.

A herança de RFC 3525 é uma arquitetura de ordem localizada. O comum deve ser mínimo: Commands dependentes juntos, trabalho independente em paralelo, receipts antes de atravessar fronteiras. A Message descreve transporte. O estado rodando decide a realidade.

Sources