Resumen

  • RFC 3624 convirtió la auditoría MGCP, antes limitada a un terminal por vez, en un informe masivo que podía continuarse al alcanzar el límite de tamaño del datagrama.
  • 200 OK no certificaba que se hubiera cubierto todo el rango pedido: BA/NE marcaba dónde reanudar y BA/EL vinculaba los valores compactos de estado o conexión con sus terminales.

En 2003, el problema era concreto: después de una conmutación por fallo, un agente de llamadas podía necesitar reconstruir su vista de una pasarela con cientos o miles de terminales. Las auditorías del MGCP base examinaban uno a uno. RFC 3624 añadió el paquete Bulk Audit para consultar grupos, averiguar nombres y recuperar determinados estados o datos de conexión. El documento era Informativo. Su nota del IESG distinguía MGCP de la alternativa Megaco, basada en estándares, descrita en RFC 3015. Es una interfaz histórica de recuperación, no prueba del despliegue de un operador concreto. (RFC 3624, sobre el MGCP inicial de RFC 2705 y el MGCP 1.0 posterior de RFC 3435.)

El paquete separaba preguntas que un comodín amplio podía confundir. BA/Z solicitaba el patrón de nombres configurado. BA/X pedía los terminales virtuales no persistentes que estaban instanciados en ese momento. Podía existir un patrón como conference/* aunque solo estuviera creada una parte dispersa. Confundir ambos resultados convertía una convención para nombres posibles en una afirmación sobre el estado presente.

Para los terminales existentes, BA/C devolvía el número de conexiones en orden. Un dígito hexadecimal codificaba de cero a quince; Z quería decir más de quince, no una cifra exacta. BA/M compactaba los modos de conexión. BA/S evaluaba las condiciones solicitadas y devolvía T, F u O (fuera de servicio). Es un resumen de tipo O lógico entre criterios, no una descripción de cada conexión. La RFC dice expresamente que el indicador de estado del terminal no informa del estado de sus conexiones. Ninguno de esos valores prueba que una llamada se completara, circulara el audio, funcionara una aplicación o llegara el servicio al cliente.

Después aparecía el límite del datagrama. Si el informe excedía el tamaño máximo, la pasarela podía responder por menos terminales de los solicitados, pero debía incluir BA/NE, el nombre local del siguiente. El agente podía usarlo en BA/SE para continuar. El código positivo confirmaba esa respuesta; el cursor advertía que la auditoría general aún no había terminado. (RFC 3624, §§2.1.1.1 y 2.1.1.7.)

Los recuentos y estados necesitaban otra frontera: la correspondencia. BA/EL debía anteceder a una lista BA/C o BA/S e identificar qué terminal correspondía a cada posición. Esto era decisivo cuando los rangos de terminales virtuales instanciados estaban separados. Un vector podía estar bien formado y aun así asignarse al objeto equivocado si se perdía su mapa. Si se solicitaban recuento y estado juntos, ambos debían abarcar los mismos terminales. (RFC 3624, §§2.1.1.8 y 2.1.2.)

RFC 3624 permite reanudar una auditoría grande, pero no define una instantánea atómica entre solicitudes. Las páginas pueden reflejar observaciones de momentos distintos; el protocolo no les asigna una época común que las congele. Durante la recuperación, el agente obtiene una vista útil del plano de control, no necesariamente una vista completa, simultánea ni equivalente al servicio. Como lente analítica —no como evidencia de implementación MGCP—, la idea enlaza con el ensayo de Heng Lu sobre la primacía del código en ejecución.

La gramática era modesta y justamente útil: decía qué había informado la pasarela, a qué nombres correspondían los valores y desde dónde debía arrancar la siguiente solicitud. No convertía una consulta del plano de control en una prueba integral. Todavía había que verificar por separado conexiones, medios, aplicaciones y resultados para el usuario.