Resumen

  • TGREP registra rutas de pasarelas dentro de un dominio y puede alimentar después a TRIP.
  • La pasarela trabaja en modo Send Only y no ejecuta la selección de ruta.
  • Su base de anuncios puede proceder de configuración manual, fuera del alcance del RFC.
  • TotalCircuitCapacity es un techo aprovisionado, no una reserva para la siguiente llamada.
  • AvailableCircuits es una observación local y dinámica que no debe propagarse.
  • Reducir la carga de UPDATE mediante ventanas grandes sacrifica actualidad instantánea.
  • CallSuccess resume intentos pasados y resultados clasificados por la propia pasarela.
  • Llegar a Alerting y encontrar al llamado ocupado puede contar convencionalmente como éxito.
  • El mapa exacto de causas de desconexión a éxito o fracaso queda a discreción del emisor.
  • La consolidación une rutas del mismo destino; la agregación resume destinos distintos.
  • Una asociación IPsec protege origen e integridad, no la corrección semántica de la ruta.
  • Registro, muestra, transformación, decisión, señalización y resultado necesitan recibos separados.

El selector terminó su trabajo antes de que empezara la prueba

Un proxy recibe una llamada y vuelve a ejecutar su proceso de decisión. Entre varias rutas, una anuncia más capacidad restante y una proporción histórica mejor. El selector produce un ganador. En los registros internos aparece una decisión correcta según la información disponible.

Esa corrección es condicional. El dato de circuitos puede haber envejecido; otra llamada puede haber consumido el último recurso; la proporción histórica puede usar una definición de éxito distinta de la que espera el cliente. El final del algoritmo no es el final de la llamada.

TGREP existe porque TRIP no cubría dos piezas locales: cómo entran las rutas desde las pasarelas y cómo un proveedor escoge una pasarela concreta. El sender de TGREP reúne información del gateway y la entrega al Ingress LS. El receptor puede pasar una proyección al Egress LS y este incorporarla a TRIP. Cada paso cambia quién observa, quién transforma y quién decide.

La pasarela anuncia, pero no delibera

En el OPEN, el gateway declara la capacidad Send Only. Después envía su alcance completo y los atributos asociados en UPDATE. No mantiene equivalentes de Adj-TRIBs-In ni Loc-TRIB, no aprende las rutas de otros gateways y no aplica selección ni agregación.

Cuando recibe un UPDATE estando Established, lo descarta en silencio y mantiene el estado. Por eso, una sesión activa no prueba que la pasarela haya recibido o ejecutado una orden del servidor. La salud del canal y la adopción de una decisión son hechos diferentes.

Existe un Adj-TRIB-GW-Out por peer LS. El RFC deja fuera cómo se llena y menciona la configuración manual. La procedencia no empieza entonces en el paquete protegido: debe incluir quién o qué escribió la ruta, su autoridad sobre el destino, la fecha, la condición de retirada y el sistema de origen.

La capacidad total y la disponible no comparten alcance

TotalCircuitCapacity representa el número total de llamadas posibles bajo condiciones estables, un límite aprovisionado que cambia poco. Puede variar cuando se retiran trunks por mantenimiento. Por su estabilidad relativa, el LS puede propagarlo; dentro de un ITAD, ciertas rutas al mismo prefijo pueden sumar sus totales al agregarse.

AvailableCircuits representa los circuitos que quedan en una ruta en el momento observado. Puede cambiar con cada llamada y participar en una decisión llamada por llamada. No se agrega y no debe salir del vínculo entre la pasarela y el LS que la administra.

RFC 5140 recomienda reducir el tráfico de actualizaciones y usar una ventana suficientemente grande. El sistema compra escalabilidad con una pérdida controlada de inmediatez. Si guarda solo el entero, elimina el precio de ese acuerdo. Debe guardar también instante, ventana, umbral de actualización y volumen de llamadas ocurrido después.

Ni siquiera un total agregado es fungibilidad. Sumar techos de varios gateways no demuestra que los circuitos compartan política, fallo, destino o condición comercial. Un techo describe posibilidad; una muestra describe estado observado; ninguno aparta un recurso para el intento futuro.

El nombre CallSuccess no fija su significado

El atributo contiene dos contadores de cuatro octetos: terminaciones consideradas exitosas e intentos totales para el mismo destino y ventana. La significación estadística puede crecer con las muestras. Cuando el contador de intentos da la vuelta, el de éxitos se reinicia para conservar la alineación, y el receptor debe consultar con frecuencia suficiente.

La clasificación se apoya en la causa de desconexión. El RFC considera convencionalmente exitoso un intento que llega a Alerting y no conecta porque el llamado está ocupado o no disponible. Considera fracaso una desconexión por falta de circuito o recurso. Pero deja el mapeo exacto a la pasarela que informa.

Eso significa que el numerador lleva una política local. Para la red, éxito puede ser «alcanzó correctamente al extremo». Para ventas, puede ser «hubo conversación». Para soporte, «no falló nuestra infraestructura». Una cifra sin tabla de causas, ventana, denominador, época y composición de tráfico no permite comparar autoridades distintas.

El propio protocolo limita la pretensión: la estadística puede aumentar la probabilidad de una buena terminación al escoger alternativas. No se agrega, no se propaga y no conoce la próxima llamada.

Consolidar conserva opciones y también crea una proyección

El receptor TGREP puede oír a varias pasarelas para el mismo destino. La consolidación combina esas rutas para expresar capacidades colectivas. Un ejemplo une valores Carrier de dos gateways; otro une listas de prefijos. Los detalles para cada atributo y familia quedan en la implementación.

Después, la agregación puede resumir destinos diferentes mediante reglas TRIP, reduciendo información. La secuencia es importante: primero consolidar rutas del mismo destino; luego agregar destinos aptos para resumen.

El candidato que ve el Egress LS puede no haber existido en ningún emisor. Es una declaración nueva, construida por el receptor. Debe conservar el grafo constituyente: gateway, sesión, ruta original, valores, tiempo, regla de unión, exclusiones y versión. Sin él, una capacidad colectiva parece una promesa simultánea de una sola pasarela y un resumen oculta diferencias por destino.

Las familias E.164, de números de enrutamiento, TrunkGroup y Carrier estructuran el alcance. Una sesión no debe mezclar las tres categorías de familias. RFC 4904 y RFC 4694 afinan sintaxis relacionadas. Nada de ello demuestra autoridad comercial actual, control de un trunk o disponibilidad física.

Una sesión autenticada no autentica el futuro

RFC 5140 repite la seguridad de TRIP. AH o ESP pueden dar autenticación de origen, integridad y protección antirrepetición; ESP también confidencialidad. Esas garantías pertenecen al transporte entre peers.

No verifican una ruta cargada manualmente, la vigencia del inventario, la tabla de causas, el derecho a hablar por un Carrier ni el resultado PSTN. La criptografía establece quién envió bytes protegidos. La operación debe establecer qué observó, con qué autoridad, cómo se transformó, por qué se eligió y qué sucedió después.

La cadena mínima une identidad y ámbito del gateway; UPDATE original; hora de observación y publicación; ventana y época; validación y proyección del receptor; política y alternativas del proxy; intercambio de señalización; disposición PSTN; y resultado humano o comercial cuando se afirme uno.

TGREP ayuda a elegir bajo incertidumbre. No elimina la incertidumbre pronunciando el nombre de una ruta.

Fuentes

  1. RFC 5140, HTML
  2. RFC 5140, texto
  3. Registro del RFC Editor
  4. IETF Datatracker
  5. Historia del documento
  6. Búsqueda de erratas de RFC 5140
  7. Parámetros TRIP de IANA
  8. RFC 2871: marco de enrutamiento telefónico
  9. RFC 3219: TRIP
  10. RFC 3261: SIP
  11. RFC 4904: Trunk Groups en URI tel/SIP
  12. RFC 4694: parámetros de portabilidad
  13. RFC 4301: arquitectura IPsec
  14. RFC 4302: AH
  15. RFC 4303: ESP
  16. RFC 4306: IKEv2
  17. RFC 4835: requisitos de algoritmos ESP/AH
  18. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  19. On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
  20. Running-Code Primacy