Resumen

  • RFC 3435 asignaba a cada punto final una sola NotifiedEntity, pero ese valor elegía el destino de los comandos originados por la pasarela; las respuestas seguían volviendo al origen de cada comando.
  • El agente de respaldo podía cambiar el puntero sin obtener resolución de conflictos entre controladores, transferencia completa de estado ni prueba de que el audio continuó.

Un destino no era un traspaso

Pensemos en una pasarela cuyo agente de llamada deja de responder. Un respaldo envía una nueva NotifiedEntity y la pasarela ya sabe dónde entregar la próxima notificación. Aún no sabe si ambos agentes comparten la misma historia de conexiones, si el primero volverá con otra versión ni si el plano de medios sigue funcionando.

RFC 3435, publicada en enero de 2003, hizo visible esa frontera. El texto plano, el registro del RFC Editor, la página del Datatracker, el historial, las referencias y las erratas fijan el documento, pero no prueban una implantación o una conmutación exitosa.

MGCP separaba la inteligencia de llamada del trabajo del medio. RFC 2705, sustituida por RFC 3435, ya suponía que los agentes se sincronizarían sin definir cómo. RFC 2805 recogió requisitos generales de control y reconciliación. RFC 3015 describió Megaco/H.248, la vía basada en estándares señalada por la nota del IESG. RFC 3435 era informativa: detalle normativo interno no equivalía a adopción universal.

Qué guardaba NotifiedEntity

Cada punto final tenía una entidad notificada corriente. La última recibida prevalecía; si nunca llegó una, se usaba el valor aprovisionado. Cuando ambos faltaban y el campo estaba vacío, caso desaconsejado, el origen del último comando no auditor pasaba a ser el destino. Un comando de auditoría no podía apropiarse del puntero por sí solo.

Las respuestas obedecían otra regla: volvían al origen del comando, con independencia de la entidad notificada. Además, la pasarela podía recibir comandos desde cualquier origen. Por eso eran hechos distintos el destino para los comandos de la pasarela, la dirección que envió una petición, la respuesta entregada a esa dirección y la autoridad del controlador. RFC 2119 y la gramática de RFC 2234 hacían preciso el intercambio, no la legitimidad del relevo.

DNS no replicaba la memoria

El agente se identificaba mediante nombre de dominio y puerto opcional. Un nombre podía resolver a varias interfaces o máquinas. La pasarela debía probar alternativas y no depender del orden DNS. Eso aportaba alcance, pero no demostraba que las máquinas compartieran conexiones, eventos o política de autoridad. Resolver, alcanzar, sincronizar y autorizar eran recibos diferentes.

Si el agente completo seguía caído, los puntos finales acababan desconectados. Un respaldo podía contactarlos con una entidad notificada nueva. RFC 3435 suponía comunicación y sincronización entre agentes al devolver el control. Sin embargo, reconocía que no incluía resolución de conflictos de relevo entre agentes separados. AuditEndpoint podía mostrar el puntero actual; no reconstruía todas las decisiones ni decidía quién tenía el derecho de mandar.

Auditar y borrar no eran lo mismo

La desconexión llegaba tras retransmisiones, retroceso exponencial, otras direcciones, nuevas consultas DNS y límites T-MAX y T-HIST. Demoras aleatorias evitaban que todos los puntos finales reiniciaran a la vez. El primer intercambio no auditor debía comunicar la desconexión.

El controlador podía entonces auditar el punto final o borrar todas sus conexiones. Auditar buscaba reconciliar estado visible; borrar imponía convergencia destruyéndolo. Una respuesta satisfactoria no aseguraba conversación audible ni ausencia de pérdida. RFC 3661 aclaró después los códigos de retorno, pero no los convirtió en certificados de resultado humano.

RFC 3991 añadió redirección y reinicio; RFC 3992 acotó un modo lockstep. Los registros de IANA de paquetes MGCP y LocalConnectionOptions prueban vocabulario coordinado, no ejecución correcta.

La lección que permanece

La entidad notificada resolvía una necesidad real: elegir dónde mandar el siguiente hecho. No resolvía la autoridad, la sincronización ni la continuidad. La lectura posterior de Heng Lu sobre capas de realidad ayuda a no atribuir al puntero evidencias ausentes. La primacía del código en ejecución separa diseño y resultado. La especificación inicial mínima muestra cómo un núcleo común puede coordinar una ruta dejando fuera el arbitraje. Son aplicaciones editoriales retrospectivas, no intenciones atribuidas al RFC.

Fuentes