Resumen

  • RFC 5133, publicado como Proposed Standard en diciembre de 2007, actualiza RFC 4233.
  • RFC 4129 ya usaba el tipo de gestión 5 para solicitar el estado de DLC en DUA.
  • RFC 4233 reutilizó el tipo 5 para la consulta TEI de IUA.
  • La misma clase 0 y el mismo tipo 5 hacían indistinguibles dos operaciones.
  • RFC 5133 obliga a codificar la consulta TEI con tipo 8.
  • El registro IANA actual asigna 5 a DLC Status Request y 8 a TEI Query Request.
  • La asignación elimina la ambigüedad normativa, no actualiza receptores antiguos.
  • Una asociación SCTP activa no demuestra que el ASP esté activo ni que admita el tipo 8.
  • El PPID 10 ayuda a identificar DUA, pero RFC 4129 permite usar el PPID IUA 1 en despliegues combinados.
  • SCTP no interpreta directamente el PPID, que no autentica al emisor ni obliga a una semántica.
  • ASSIGNED expresa la consideración de Q.921, no la identidad del abonado ni el éxito del servicio.
  • La migración exige pruebas asimétricas, rechazo visible de lo ambiguo y retirada controlada del tipo 5 heredado.

Un rechazo correcto puede ser un fallo de servicio

El error Unsupported Message Type tiene valor. Demuestra que un receptor observó un tipo que no soportaba y respondió mediante el mecanismo definido por IUA. No demuestra por sí solo si el emisor se equivocó, el receptor está obsoleto o una ruta entregó el mensaje a la aplicación equivocada. Para decidirlo hay que vincular el error con la versión de ambos extremos y con la captura exacta.

RFC 5133 resuelve el criterio normativo: la consulta TEI debe ser tipo 8. Un emisor moderno que usa 8 cumple esa regla. El receptor heredado puede seguir aplicando la tabla de RFC 4233, donde la consulta figuraba como tipo 5 y los tipos 6 a 127 estaban reservados. Su rechazo es coherente con su software, aunque incompatible con la red que el operador desea mantener.

El incidente no se corrige diciendo que uno de los lados “tiene razón”. Se corrige convirtiendo el desacuerdo en un inventario verificable: artefacto instalado, perfil habilitado, peer configurado, asociación observada, bytes emitidos, error recibido y acción siguiente.

Cómo nació la ambigüedad

RFC 3057 no incluía una consulta TEI. RFC 4129 extendió la arquitectura para DPNSS/DASS 2 y definió mensajes de estado DLC en la clase de gestión: solicitud 5, confirmación 6 e indicación 7. RFC 4233 añadió después la consulta TEI y le asignó también el 5.

El encabezado común sólo podía decir clase de gestión y tipo 5. Dos preguntas distintas compartían la misma dirección en el espacio de protocolo. La configuración local podía sugerir una lectura, pero no extraer del paquete una distinción que no estaba codificada.

RFC 5133 movió la consulta TEI a 8 e IANA reservó ese valor. La intervención es pequeña porque el problema básico era pequeño y absoluto: un símbolo de protocolo debe tener un significado único dentro de su namespace.

No añadió negociación de capacidades, bit de transición, identificador de consulta ni regla de downgrade. Tampoco declaró cuándo un parque real debía dejar de aceptar 5. Estas ausencias definen el trabajo del despliegue.

El PPID ayuda, pero no decide

DUA dispone del SCTP Payload Protocol Identifier 10 y IUA del 1. RFC 4129 recomienda separarlos. Sin embargo, permite que DUA use el PPID de IUA cuando ambos backhauls comparten una asociación. También explica que SCTP no usa directamente ese valor; algunas entidades pueden usarlo para reconocer la información transportada.

Por tanto, PPID no es una negociación ni una política aplicada por SCTP. Es metadato para la capa superior. Un analizador que confía sólo en él puede equivocarse en un escenario expresamente permitido. Un receptor que confía sólo en su rol configurado puede ocultar una entrega a la aplicación incorrecta.

La prueba sólida conserva ambos niveles: PPID del DATA chunk y clase/tipo del encabezado IUA. Después conserva la decisión del parser. Incluso esa tríada se detiene antes de identidad y resultado. Un paquete bien etiquetado puede venir de un peer no autorizado; un mensaje bien decodificado puede obtener una respuesta incompleta.

SCTP arriba, ASP abajo

RFC 4233 distingue varios estados. SCTP puede estar asociado mientras el Application Server Process está inactivo y el tráfico de aplicación está detenido. El mapeo de un identificador de interfaz a una asociación y stream cambia con el estado del ASP y puede ser temporalmente inválido durante failover.

Por eso, un health check de puerto o asociación no es una prueba RFC 5133. Sirve para excluir una clase de fallos de transporte. Todavía quedan la disponibilidad del ASP, la activación de la aplicación, el mapeo de interfaz, la compatibilidad del tipo y la respuesta de gestión.

Un registro de cambio debe preservar: peer y asociación, stream, PPID, versión, clase, tipo, longitud, dirección, timestamp, build emisor, build receptor, error o indicaciones, y estado posterior. Si falta una dimensión, la conclusión debe conservar esa incertidumbre.

Consultar TEI no autentica al terminal

La consulta TEI se envía desde el ASP a la Signaling Gateway. El DLCI del encabezado IUA debe ser ignorado. Este mandato evita que un campo reutilizado adquiera una función imaginaria en la operación. Un dashboard que indexa la consulta por ese DLCI está fabricando precisión.

Las indicaciones de estado dicen ASSIGNED o UNASSIGNED: Q.921 considera el TEI asignado o no asignado. No hay en esa palabra una credencial de dispositivo, un nombre de persona, un contrato, una prueba de presencia física ni un recibo de tráfico actual.

El estado permite tomar decisiones útiles. Puede preparar al ASP para señalización o indicar si vale la pena solicitar el establecimiento del enlace de datos. La frase correcta es “Q.921 consideró asignado este TEI en esta interfaz y momento”. “Terminal verificado” añade hechos ausentes.

Para llegar al servicio hay que observar el conjunto completo de indicaciones, su contexto y frescura; después el establecimiento del enlace, la señalización y el resultado en la aplicación. Si una etapa no se midió, sigue desconocida.

El fallback que resucita el defecto

Tras el rechazo de tipo 8, reintentar con tipo 5 puede devolver una respuesta de un peer antiguo. También puede presentar una consulta TEI como solicitud de estado DLC. El riesgo aumenta cuando DUA usa PPID 1. El fallback modifica la semántica del paquete; no es sólo una segunda oportunidad de transporte.

Una excepción heredada sólo es defendible para peers nominados, en un contexto demostrado como IUA-only, con contador de usos, captura de canario, alarma y fecha de eliminación. Las asociaciones DUA o combinadas deben quedar fuera. Los tests deben asegurar que tipo 5 jamás entra en el handler TEI donde existe posibilidad de colisión.

La compatibilidad invisible altera incentivos. El proveedor antiguo deja de sentir presión; el operador nuevo carga indefinidamente con dos dialectos; el equipo de incidentes recibe un mismo byte con significados dependientes de configuración. Un alivio local se convierte en dependencia estructural.

Qué se puede afirmar

Los registros oficiales prueban que RFC 5133 actualiza RFC 4233 y que IANA asigna actualmente el tipo 8 a TEI Query Request. RFC 4129 prueba los tipos DLC y las opciones de PPID. RFC 4233 prueba los procedimientos, errores y estados IUA. Los RFC de SCTP delimitan el transporte.

No prueban la versión de un fabricante concreto, el resultado de una consulta de producción, la identidad de un terminal ni la continuidad del servicio. Esas preguntas requieren código, inventario, configuración, trazas y resultados actuales. La norma hace la prueba posible; no la sustituye.

Sources