Resumen

  • RFC 3525 ordenaba los comandos dentro de una transacción; dos transacciones diferentes podían ejecutarse en cualquier orden o a la vez.
  • TransactionPending, la retransmisión, el acuse de respuesta y el procesamiento una sola vez resolvían hechos limitados de transporte, no la causalidad completa ni el resultado de los medios.

El caso de Subtract muestra la regla con más claridad que cualquier diagrama. El protocolo permitía emitir esa orden en cualquier momento. Si una Modify pendiente llegaba después, podía encontrar que la Termination ya no existía. La pasarela debía ignorarla y devolver un error.

No era necesariamente una red defectuosa. Era el modelo de concurrencia. RFC 3525 controlaba una pasarela multimedia físicamente descompuesta: el Media Gateway Controller decidía y el Media Gateway mantenía recursos y estado. La interfaz debía permitir trabajo paralelo sin imponer una cola universal.

Por eso el documento construyó una jerarquía precisa. Una transacción contenía acciones; cada acción se limitaba a un Context; las acciones contenían comandos o manipulaciones. Solo una de esas fronteras daba orden fuerte: los comandos de la misma transacción se procesaban secuencialmente.

Ante el primer comando no opcional que fallaba, se detenían los comandos posteriores. Si el comando estaba marcado Optional, el error no detenía la secuencia. La posición y el indicador Optional eran, por tanto, parte de la semántica operativa.

Las transacciones no heredaban ese orden. Podían ejecutarse en cualquier secuencia o simultáneamente. Tampoco ayudaba meterlas en un mismo mensaje: RFC 3525 trataba las transacciones del mensaje como independientes y describía el mensaje como un mecanismo de transporte.

Las respuestas revelaban esa independencia. Un mensaje con A, B y C podía recibir una respuesta conjunta para A y C y otra posterior para B. El diseño separaba el empaquetado eficiente de la causalidad de la aplicación.

La ventaja era práctica. Comandos dirigidos a Terminations distintas podían avanzar en paralelo, incluso bajo procesos o hilos separados. Obligar a esperar a toda la pasarela habría convertido una dependencia local en un cuello de botella global.

El controlador conservaba la responsabilidad de reconocer la dependencia real. Para una misma Termination, RFC 3525 recomendaba normalmente un solo Add, Modify o Move pendiente, salvo que los comandos estuvieran en la misma transacción. Si crear y modificar debían ocurrir en ese orden, había que expresarlo o esperar.

Las notificaciones introducían otro reloj. Un Notify podía retrasarse y llegar después de que el controlador hubiera instalado un EventsDescriptor nuevo. Sobre UDP debía existir normalmente un solo Notify pendiente por Termination. El RequestID y el estado solicitado importaban más que la posición visual del paquete.

El nombre “transacción” tampoco prometía atomicidad de base de datos. Cuando un comando fallaba, la pasarela debía restaurar, en la medida de lo posible, el estado anterior al intento de ese comando. El texto no ordenaba deshacer todos los comandos previos que habían terminado bien.

La TransactionReply preservaba precisamente esa diferencia. Incluía valores de retorno de comandos exitosos y el descriptor de error del comando fallido. Leer solo un estado general habría perdido la frontera entre trabajo aplicado, trabajo fallido y trabajo nunca intentado.

Los comodines ampliaban la superficie. Un comando se intentaba sobre cada TerminationID coincidente y generaba una respuesta por coincidencia. Si alguna fallaba, los comandos siguientes no se ejecutaban. Podían coexistir resultados positivos y negativos antes del corte.

TransactionPending tampoco era una promesa de éxito. Informaba que el receptor seguía procesando y reiniciaba el temporizador. No decía qué comando había alcanzado, ni ordenaba las demás transacciones, ni garantizaba que el estado final sería aceptable.

La protección contra repeticiones atendía una pregunta diferente. Al perderse una respuesta, el emisor podía retransmitir. Identificadores de transacción, respuestas retenidas y acuses permitían aproximarse a “a lo sumo una vez”. Reconocer una repetición no ordenaba dos transacciones legítimamente distintas.

La seguridad del canal también tenía un alcance limitado. Podía autenticar a las partes y proteger el mensaje contra alteración. No añadía una relación causal que el controlador no había expresado. Un comando auténtico podía llegar demasiado pronto.

Después quedaba la realidad de los medios. Una respuesta exitosa probaba procesamiento del protocolo. Un Audit podía comprobar propiedades del Context o de la Termination. Todavía faltaban el trayecto de paquetes, la decodificación y la experiencia humana.

La historia normativa exige otra separación. RFC 3525 sustituyó a RFC 3015 en 2003 como texto compartido del trabajo IETF Megaco y UIT-T. RFC 5125 lo declaró Historic en 2008 porque H.248.1 había seguido cambiando bajo la UIT-T. El mecanismo es historia verificable, no una afirmación sobre cada equipo actual.

El registro IANA de Megaco/H.248 continúa coordinando paquetes, errores, razones y perfiles bajo referencias posteriores. Mantener los nombres no congela la implementación. El registro describe el vocabulario; el rastro operativo describe lo que ocurrió.

El principio duradero es sencillo: el orden común debe ser tan pequeño como la dependencia. Paralelizar lo independiente conserva capacidad. Agrupar o esperar donde hay dependencia conserva causalidad. Un contenedor compartido nunca debe venderse como prueba de un resultado compartido.

Sources