Resumen

  • La RFC 3372 dividió el interfuncionamiento en dos tareas: encapsular ISUP para conservar la señalización heredada y traducir algunos datos a SIP para que los intermediarios pudieran encaminar la petición.
  • Los dos registros debían verificarse por separado. Un cuerpo intacto no demostraba una ruta correcta; una ruta correcta no demostraba reconstrucción fiel, medios establecidos ni la función percibida por el usuario.

SIP-T nació de una asimetría. La red telefónica pública expresaba una llamada mediante ISUP y sus variantes. La red IP intermedia tomaba decisiones con URI y cabeceras SIP. Reducir un mundo al otro habría eliminado precisamente la información que permitía a una pasarela distante continuar una función telefónica.

La RFC 3372 apareció en septiembre de 2002 como BCP 63. No definió un protocolo nuevo: reunió prácticas para las fronteras PSTN–SIP. Su aportación decisiva fue reconocer que una llamada necesitaba dos representaciones simultáneas.

La primera era el ISUP encapsulado en el cuerpo SIP mediante los tipos MIME de la RFC 3204. Allí viajaba el contexto heredado, incluso parámetros sin equivalente limpio en SIP. La segunda era la petición SIP visible. La pasarela traducía datos seleccionados, como el número llamado, a elementos que un proxy pudiera examinar para decidir el siguiente salto.

El documento llamó transparencia de funciones a la conservación y encaminabilidad a la traducción. No eran dos nombres para el mismo éxito. El cuerpo podía superar todos los saltos mientras una cabecera errónea elegía una salida equivocada. La petición podía llegar a la salida correcta mientras el cuerpo faltaba, estaba dañado o pertenecía a una variante ISUP que la pasarela no entendía.

La pasarela terminadora tampoco reproducía ciegamente el contenido. Podía usarlo como plantilla, sobrescribir valores procedentes de las cabeceras SIP y añadir parámetros impuestos por su política local. Cuando no había cuerpo, podía partir de una plantilla canónica configurada. Por eso el mensaje SS7 de salida era el resultado de una transformación, no un recibo automático del original.

El origen no sabía necesariamente dónde terminaría la llamada. Si provenía del PSTN, podía acabar en otro gateway o en un teléfono SIP. Este último normalmente ignoraba ISUP, aunque debía manejar correctamente cuerpos multipart y tipos desconocidos según el marco MIME de la RFC 2046 y SIP de la RFC 3261. Un teléfono SIP que iniciaba la llamada no tenía por qué inventar ISUP para un futuro destino aún desconocido.

La señalización durante la llamada añadía otra discontinuidad. Algunos mensajes ISUP no modificaban el estado de la sesión SIP. La RFC 3372 recurrió al método INFO de la RFC 2976 para transportarlos. Que INFO llegara no probaba que el receptor aplicara el significado ni que la función apareciera ante el abonado.

TRIP, en la RFC 3219, y ENUM, en la RFC 2916, ofrecían contexto para localizar destinos telefónicos. No sustituían la carga ISUP. S/MIME, basado entonces en la RFC 2633, podía firmar o cifrar el contenido; una firma válida seguía sin certificar una traducción correcta, una política autorizada, el establecimiento del audio o un cargo correcto.

La RFC 3398 desarrolló la correspondencia detallada entre SIP e ISUP. La RFC 3326 permitió adjuntar causas de diferentes espacios de protocolo, sin convertir la explicación en la acción. Las RFC 3331 y 3332 abordaron la adaptación de SS7 sobre SCTP. Esas historias son contiguas, no repetidas: hablan de dónde vive el estado SS7; esta habla de por qué una llamada necesitó una copia preservada y otra operable por SIP.

No existe en estas fuentes un censo de despliegue ni la prueba de una llamada comercial. Sí existe una lección histórica verificable. La interoperabilidad no era un embudo que transformaba una verdad completa en otra. Era una custodia doble, destinada a actores con capacidades diferentes.

Los ensayos de Lu Heng ayudan a no exagerar. “Minimum Initial Specification” favorece un núcleo común pequeño y decisiones locales visibles. “On Reality Layers” obliga a separar señal recibida, objeto encapsulado, cabecera traducida, ruta, reconstrucción, medios y experiencia. RFC 3372 convirtió esa separación en una arquitectura práctica. Internet no absorbió la telefonía borrando su semántica; la transportó y, al mismo tiempo, fabricó una superficie distinta para decidir el camino.

Fuentes