Resumen

  • RFC 3015 definió un Context como la asociación, dentro de una Media Gateway, de varias Terminations y de su topología; no lo convirtió en la identidad universal ni en el expediente completo de una llamada.
  • Una respuesta, una auditoría o la ejecución a lo sumo una vez acreditaban hechos de control acotados. La llegada al otro extremo, la reproducción y el intercambio entre personas exigían comprobaciones distintas.

Una pasarela recibe la orden de unir un circuito telefónico con un flujo RTP. Crea un Context, asigna un identificador, aplica la topología y responde sin error. Desde su propio punto de vista, la conexión existe. Desde el punto de vista de quien espera oír una voz al otro lado, todavía falta casi toda la prueba.

RFC 3015 hizo posible describir esa diferencia sin negar el valor del primer hecho. Publicada en noviembre de 2000, Megaco Protocol Version 1.0 fue texto común con ITU-T H.248 y reguló la interfaz entre una Media Gateway (MG) y su Media Gateway Controller (MGC). La separación física permitía que la inteligencia de control dirigiera recursos de medios especializados. También repartía el conocimiento: cada componente veía una parte.

La unidad de control tenía alcance local

Una Termination originaba o absorbía uno o varios flujos. Un Context asociaba Terminations y describía quién oía o veía a quién, además de las reglas de mezcla o conmutación en asociaciones de más de dos miembros.

El ContextID lo asignaba la MG y solo tenía que ser único dentro de ella. Por eso no era, sin evidencia adicional, un identificador global de llamada, abonado, sesión comercial o conversación. Un servicio podía atravesar varias pasarelas. Un solo Context podía representar una etapa técnica de llamada en espera o de conferencia. El alcance del nombre seguía al custodio que lo emitía.

La duración de los objetos también variaba. Una Termination física podía persistir mientras el canal estuviera provisionado. Una Termination efímera, como la representación de un flujo RTP, solía existir durante su uso. El Context nulo contenía las Terminations físicas que no estaban asociadas con otra. Add podía crear implícitamente un Context nuevo; Move desplazaba una Termination; Subtract la retiraba, destruía las efímeras o devolvía las físicas al Context nulo. Al salir el último miembro, el Context desaparecía.

No se perdía una verdad universal cuando desaparecía aquel objeto. Terminaba una asociación local cuya historia debía conservarse por otros medios si seguía siendo importante.

“Quién oye a quién” era una instrucción de la MG

El descriptor de topología regulaba los flujos entre Terminations del mismo Context. El modo de cada Termination regulaba, de forma separada, el flujo en la entrada o salida de la pasarela. La distinción impedía confundir la relación interna con la observación exterior.

Una topología bidireccional podía estar correctamente instalada mientras el camino IP perdía paquetes, el destino escuchaba otra dirección, el códec fallaba, el dispositivo permanecía silenciado o el audio nunca llegaba a una persona. La MG no podía certificar esos pasos solo porque su matriz local fuese coherente.

SDP describía parámetros de sesión y RTP aportaba números de secuencia, marcas temporales y, cuando estaban disponibles, informes de recepción. Esas fuentes ampliaban la evidencia, pero tampoco heredaban entre sí toda la autoridad. Descripción, configuración, emisión, recepción, reproducción y comprensión eran eventos distintos.

La Transaction organizaba cambios, no toda la historia

Megaco agrupaba Commands en Actions y Actions en Transactions. Cada Action operaba normalmente dentro de un único Context. Los Commands de una misma Transaction se ejecutaban en orden. La TransactionReply devolvía los resultados de los comandos ejecutados y el punto de error.

Ese orden no se extendía automáticamente entre Transactions. El MGC debía preservar la coherencia mediante disciplina propia. Sobre una Termination normalmente debía quedar pendiente como máximo un Add, Modify o Move, salvo que compartieran Transaction. Un Subtract podía llegar en cualquier momento. Una retirada con comodín podía adelantarse a un Add pendiente y obligar después a eliminar las Terminations rezagadas.

La MG, por tanto, era autoridad sobre la ejecución que realizaba. El MGC era autoridad sobre la secuencia de estados que pretendía crear. Una respuesta correcta no probaba que dos procesos de control hubieran conciliado su intención ni que la siguiente orden mantuviera el estado.

TransactionPending era una señal útil de progreso, pero decía exactamente eso: el trabajo seguía activo y no había concluido. Reiniciaba el temporizador del solicitante. No garantizaba admisión de recursos, resultado final ni transporte de medios.

La auditoría podía cruzarse con el cambio

AuditValue solicitaba los valores actuales de propiedades, eventos, señales y estadísticas. AuditCapabilities solicitaba los valores posibles. Una lista de capacidades no era una lectura del estado presente. Una lectura presente no era la prueba de que el servicio alcanzara su finalidad.

Con comodines, la pasarela podía devolver la unión de valores de muchas Terminations. Era una compresión útil, pero la unión ocultaba qué posibilidad pertenecía a qué miembro. Si un controlador necesitaba atribución individual, debía conservar un alcance más fino.

La limitación decisiva estaba en la secuencia: las auditorías de valores y capacidades no quedaban ordenadas con los demás comandos. Si una modificación seguía pendiente, una auditoría podía tomar una fotografía válida antes o después de ella sin que el nombre de la consulta resolviera la carrera. El operador necesitaba hora, Transaction, estado pendiente y época de la MG para interpretar “actual”.

Subtract podía devolver estadísticas acumuladas durante la presencia de una Termination en el Context. Esa última cuenta era evidencia local importante. No confirmaba qué recibió la otra pasarela, qué reprodujo el terminal ni si una persona entendió el mensaje.

El reintento seguro dependía de memoria

Sobre UDP podían perderse tanto la petición como la respuesta. Como muchos Commands no eran idempotentes, repetir un Add podía volver imprevisible el estado. RFC 3015 requirió funcionalidad de ejecución a lo sumo una vez.

Los pares retenían respuestas recientes y Transactions en curso. Comparaban el TransactionID y la identidad del emisor con ambas listas. Si la operación ya había terminado, reenviaban la respuesta guardada sin ejecutar de nuevo. Si seguía en curso, evitaban el duplicado y podían enviar TransactionPending. El acuse de la respuesta permitía liberar parte del contenido, pero se conservaba el identificador durante LONG-TIMER para reconocer copias tardías.

La frase “a lo sumo una vez” no era eterna. Dependía de que el emisor asignara identificadores únicos, de la duración de la memoria, del temporizador y de que la entidad no hubiera reiniciado. Después de una nueva época, el pasado no podía inferirse de la ausencia de una coincidencia.

Y aun dentro de la ventana, la propiedad solo cubría la ejecución de la Transaction. No decía que los paquetes se hubieran reproducido una vez, que la conversación ocurriera una vez ni que la facturación fuese correcta. La unidad protegida era el comando de control.

TCP ofrecía una entrega de bytes distinta, pero no eliminaba pérdidas de Transaction alrededor de fallos de procesos y conexiones. El propio texto recomendaba mantener lógica de aplicación. Un transporte fiable no podía resucitar el estado que una MG había olvidado.

Autenticar control no era observar audio

Quien pudiera inyectar Commands podría establecer llamadas no autorizadas o interferir en las legítimas. La RFC exigía mecanismos de seguridad y señaló IPsec para entornos IP. Autenticación de origen, integridad, antirrepetición y confidencialidad protegían la conversación entre MGC y MG. No certificaban el resultado de la conversación entre usuarios.

RFC 3525 reemplazó RFC 3015 en 2003. RFC 3435 mantuvo MGCP como especificación informativa y señaló Megaco/H.248 como la vía basada en estándares. Esta genealogía no permite afirmar qué equipo implementó qué edición, si hubo interoperabilidad real o cuántas llamadas funcionaron.

El legado útil de RFC 3015 fue una limitación bien construida. Dio a la pasarela un lenguaje común para crear una asociación, programar la topología, secuenciar cambios locales, consultar estado y contener duplicados. Precisamente porque el objeto era ejecutable y local, no necesitaba fingir que era toda la llamada.

Fuentes