Resumo

  • A RFC 3624 ampliou a auditoria MGCP, antes limitada a um endpoint por vez, para relatórios em lote que podiam continuar quando a resposta atingia o limite do datagrama.
  • 200 OK não confirmava que toda a faixa solicitada havia sido coberta: BA/NE indicava onde retomar, e BA/EL associava os valores compactos de estado ou conexão aos endpoints correspondentes.

Em 2003, o problema era reconstruir a visão de um gateway após o failover de um agente de chamadas — um equipamento podia ter centenas ou milhares de endpoints. As auditorias do MGCP básico examinavam um por vez. A RFC 3624 acrescentou o pacote Bulk Audit, permitindo consultar um grupo, conhecer seus nomes e obter informações selecionadas de estado e conexão. O documento é Informational; a nota do IESG diferencia MGCP da alternativa Megaco baseada em padrões, descrita na RFC 3015. Trata-se de um mecanismo histórico de recuperação, não de prova sobre a implantação por uma operadora específica. O contexto inclui o MGCP inicial, RFC 2705, e a versão 1.0 posterior, RFC 3435.

O pacote separava perguntas que um curinga amplo poderia misturar. BA/Z solicitava o padrão configurado de nomes; BA/X pedia os endpoints virtuais não persistentes que estavam instanciados naquele momento. Assim, podia existir um padrão conference/* embora só parte, em faixas descontínuas, tivesse sido criada. Tratar o padrão de nomes como inventário transforma uma regra para nomes possíveis em afirmação sobre o estado atual.

Para endpoints existentes, BA/C devolvia a quantidade de conexões em ordem. Um dígito hexadecimal representava de zero a quinze; Z significava mais de quinze, não um número exato. BA/M compactava os modos de conexão. BA/S avaliava condições solicitadas e respondia T, F ou O (fora de serviço). Esse último campo resumiu uma operação lógica “OU” entre condições, não descreveu cada conexão. A RFC diz expressamente que o indicador de estado do endpoint nada informa sobre o estado das conexões. Nenhum desses campos prova que uma chamada se completou, que a mídia fluiu, que o aplicativo funcionou ou que o cliente recebeu o serviço.

O limite do datagrama completa o mecanismo. Se o relatório ultrapassasse o tamanho máximo, o gateway podia retornar menos endpoints do que o pedido, mas tinha de incluir BA/NE, o próximo nome local. O agente poderia usá-lo como ponto de partida BA/SE numa nova solicitação. O código de sucesso valida aquela resposta; o cursor revela que a auditoria maior ainda não terminou. (RFC 3624, §§2.1.1.1 e 2.1.1.7.)

Contagens e estados dependiam ainda de um mapa. BA/EL precisava preceder a lista BA/C ou BA/S e identificar os endpoints de cada posição. Faixas instanciadas de endpoints virtuais podiam ser descontínuas; sem esse mapa, um vetor bem formado ainda poderia ser atribuído ao endpoint errado. Se contagem e estado fossem solicitados juntos, ambos precisavam cobrir o mesmo conjunto. (RFC 3624, §§2.1.1.8 e 2.1.2.)

A RFC 3624 define como retomar uma auditoria extensa, mas não uma fotografia atômica entre requisições. As páginas podem refletir observações de momentos diferentes; o protocolo não lhes dá uma época comum. O agente pode recuperar uma visão útil do plano de controle sem provar que ela é completa, simultânea ou equivalente ao serviço. Como lente analítica declarada — e não como evidência técnica sobre MGCP —, a distinção dialoga com o ensaio de Heng Lu sobre Running-Code Primacy.

A gramática do relatório é deliberadamente limitada: informa o que o gateway retornou, a que nomes os valores pertencem e onde começa a próxima consulta. Não transforma uma observação de controle em teste de ponta a ponta. Conexões, mídia, aplicações e resultados percebidos pelo cliente exigem evidências próprias.