Resumen

  • RFC 3331 no trasladó un enlace SS7 a un extremo IP. MTP1 y MTP2 siguieron en la pasarela; M2UA transportó la frontera con su usuario MTP3 hasta un controlador distante.
  • La asociación SCTP, la actividad del ASP y el estado de la línea física eran tres hechos distintos. El mapeo del identificador y una auditoría explícita los relacionaban; una conexión verde no bastaba.

El usuario era una capa

En el lenguaje del protocolo, MTP3 es el único usuario de MTP2. En la arquitectura de backhaul, el circuito SS7, MTP1 y MTP2 terminan en un Signalling Gateway Process. MTP3 se ejecuta en un Application Server Process alojado en el Media Gateway Controller. M2UA convierte las primitivas de la frontera MTP2/MTP3 en mensajes que viajan por SCTP.

Una unidad de señalización entra por una línea real en la pasarela y MTP2 resuelve allí las funciones del enlace. El MTP3 remoto no posee una copia virtual de la línea. Recibe datos e indicaciones sobre aquella línea y devuelve solicitudes de establecimiento, liberación, recuperación y transferencia. La congestión y las situaciones de procesador local o remoto fuera de servicio también cruzan ese límite distribuido.

RFC 2719 había descrito el marco SIGTRAN: la pasarela toca la red de señalización conmutada y el controlador puede concentrar la lógica superior en otro lugar de la red de paquetes. RFC 3331 concretó un corte exacto entre capas. Llamarlo simplemente «SS7 sobre IP» borra qué componente siguió siendo dueño de la terminación física.

El cable no se mudó y MTP2 tampoco. Lo que cambió de lugar fue el acceso operativo de MTP3 a la interfaz superior. La flexibilidad del reparto convirtió una frontera local en un sistema de control distribuido y obligó a conservar nuevas pruebas de correspondencia y estado.

Un identificador unía lo fijo con lo dinámico

La pasarela debía mapear un Interface Identifier a una interfaz física, por ejemplo una línea V.35 o una línea T1/E1 y su intervalo de tiempo. También debía mapear ese identificador a una asociación SCTP y a uno de sus streams. La primera relación era provisionada; la segunda cambiaba cuando un ASP se activaba, se desactivaba o cedía su lugar durante una conmutación.

El identificador solo tenía significado local, coordinado entre SG y ASP. Ver el valor 17 en una captura demuestra que el par envió ese valor en una sesión determinada. No demuestra qué puerto o time slot representaba sin la configuración vigente de la pasarela. Convertirlo en nombre global de circuito sería fabricar una certeza que el protocolo no ofrece.

Los streams SCTP permitían aislar tráfico y reducir el bloqueo entre enlaces, pero no sustituían al identificador. Un stream es unidireccional, por lo que el receptor no puede deducir de él cuál es el stream inverso. RFC 3331 puso el Interface Identifier en el encabezado de MAUP. La gestión compartía el stream común y el tráfico de los enlaces debía mantenerse en sus flujos asociados.

La cadena completa enlazaba recurso físico, identificador, Application Server, ASP activo, asociación y stream. Durante un failover, la parte dinámica podía ser inválida por un instante aunque la línea siguiera conectada. La pasarela debía consultar el estado de AS y ASP antes de distribuir cada mensaje.

Había tres máquinas de estado, no una

SCTP informaba si la asociación estaba establecida. M2UA mantenía al ASP como DOWN, INACTIVE o ACTIVE para un Application Server. MTP2 describía el enlace como en servicio, fuera de servicio, congestionado o afectado por una interrupción del procesador remoto. Esos indicadores respondían a preguntas diferentes.

La asociación UP acreditaba alcance entre extremos de transporte. No acreditaba que el ASP estuviera activo para el identificador. ACTIVE acreditaba una selección de tráfico conforme a Override, Loadshare o Broadcast, no que el circuito físico funcionara. Un enlace sano tampoco garantizaba que existiera un ASP preparado para recibir sus mensajes.

El Application Server tenía su propia máquina de estados y un estado PENDING durante la recuperación. Una lista podía contener procesos activos e inactivos para permitir respaldo. La especificación aconsejaba que solo un SGP prestara el servicio de terminal para un enlace SS7 y que, dentro de una pasarela, un único SGP actuara como propietario activo de ese recurso. Duplicar la propiedad no aportaba redundancia; podía crear dos visiones incompatibles del mismo hilo.

El error operativo aparece cuando un panel resume todo como «disponible». El transporte puede sobrevivir mientras el enlace físico cae. El proceso puede estar activo pero no haber reconstruido el estado tras un reinicio. La línea puede funcionar mientras el controlador permanece inactivo. Cada combinación exige una respuesta distinta.

La auditoría creaba un punto de reconciliación

STATUS_AUDIT permitía al ASP preguntar por el estado actual del enlace. La pasarela podía indicar fuera de servicio, en servicio, congestión o interrupción del procesador remoto. Tras reiniciar una asociación o sospechar la pérdida de eventos, el MTP3 remoto obtenía una base explícita en vez de confiar en el último dato de memoria.

La auditoría no reconstruía toda la historia. Era una observación fechada que podía quedar vieja con el siguiente evento. Una investigación debe unir solicitud, respuesta, hora, Interface Identifier, asociación, estado ASP y las indicaciones posteriores. Sin esa secuencia, «la auditoría dijo que estaba en servicio» se convierte en una afirmación sin límites temporales.

El registro dinámico añadía otra prueba. Una Link Key autorizada podía recibir un identificador. El resultado favorable demostraba que el SGP aceptó el mapeo, no que la línea estuviera sana, el ASP activo o el tráfico circulando. Autorización, activación y disponibilidad eran recibos diferentes.

M2UA no reemplazaba MTP2 entre pares

RFC 4165 explica la diferencia con M2PA. En M2PA, ambos extremos tienen MTP3 y M2PA reemplaza MTP2 entre pares. En M2UA, el MTP3 del controlador utiliza el MTP2 real de la pasarela mediante primitivas transportadas. Que ambos usen SCTP no iguala su arquitectura ni sus fallos.

M3UA en RFC 4666 e IUA en RFC 4233 compartían encabezados y gestión ASP. Esa familia común no convierte en intercambiables las fronteras adaptadas. Para comprender una incidencia hay que identificar qué capa quedó local y cuál se hizo remota.

RFC 9260 es la especificación SCTP actual. No prueba que una instalación M2UA antigua se haya actualizado. IANA mantiene el identificador de payload SCTP 2 para M2UA y las clases MAUP e IIM. El registro demuestra la asignación de números y referencias, no adopción, volumen o conformidad.

La seguridad también requiere una prueba aparte. SCTP no autentica por sí solo el significado físico de un identificador local. RFC 3788 desarrolló las consideraciones de seguridad SIGTRAN. El operador aún debía autorizar pares, proteger el transporte y controlar quién podía asociar un proceso a una línea. Conectar no equivalía a tener permiso para operar.

La historia útil está en separar las pruebas

M2UA distribuyó una interfaz sin borrar su ancla física. Por eso conviene conservar cinco recibos: asociación y stream SCTP; estado AS/ASP; mapeo provisionado del identificador; estado MTP2 del enlace; y mensaje de frontera que contenía la orden o indicación. Cuando se discute autoridad, hay que añadir la política de seguridad y registro.

RFC 3331 hizo posible el control remoto porque nombró con precisión qué permanecía, qué cruzaba IP y qué los relacionaba. Si esas distinciones se funden, una conexión IP parece demostrar un servicio telefónico inexistente. Si se mantienen, el failover y la auditoría pueden explicarse sin fingir que la red de paquetes trasladó la línea.

Fuentes