Resumen

  • La RFC 3351 pidió que texto, voz, vídeo, servicios de relevo y preferencias personales pudieran formar parte de una sesión SIP que cambia sin reiniciar la llamada.
  • Era un documento informativo de requisitos, no una extensión SIP estandarizada ni una prueba de que los dispositivos y proveedores ofrecieran esos servicios.

La frase más reveladora de la RFC 3351 es una decisión de arquitectura: cualquier agente de usuario de la conversación, incluidos los servicios de transcodificación, debería poder añadir o quitar un flujo multimedia sin finalizar y restablecer la llamada. Una conversación de voz podría sumar texto; un servicio de relevo podría entrar, convertir un medio y retirarse. Cambiar la forma de comunicarse no tendría por qué borrar la conversación en curso.

Publicada en agosto de 2002, la RFC trasladó la accesibilidad desde la categoría del dispositivo hacia el diseño de la sesión. Define el perfil de usuario como las capacidades y preferencias que SIP debería comunicar y que, a su vez, deberían determinar cómo se gestiona la sesión. Texto, audio y vídeo pueden recibirse y enviarse en diferentes combinaciones. Un flujo puede pasar por un servicio de conversión y una pasarela puede conectar un agente SIP con un teléfono de texto antiguo. La sesión es el punto donde esas opciones se encuentran.

Pero hay que leer también el estado del documento. La RFC 3351 es Informativa y dice expresamente que no establece un estándar de Internet. Sus palabras «MUST» y «SHOULD» expresan los requisitos que proponen sus autores; no convierten el documento en una extensión SIP normalizada. No certifica implementaciones ni mide cuántos proveedores hicieron realidad las escenas descritas. Son casos de diseño, no un censo de despliegue.

El perfil encierra una tensión de privacidad. Puede ayudar a adaptar una llamada, pero también revelar información sobre quien llama. La RFC plantea que el destinatario no tenga que saber que participa una persona sorda solo porque hay un servicio de relevo. Pide que los intermediarios publiquen sus políticas de confidencialidad e invita a los proveedores a permitir que las capacidades y preferencias no se hagan públicas en cada transacción. La pregunta de accesibilidad incluye qué aprende, conserva y divulga el servicio, además de si transporta texto.

El costo y la elección aparecen con una precisión poco habitual. Un agente de usuario debería poder identificar el contenido de un flujo, comparar servicios de transcodificación por capacidad y política, y conocer alternativas. La RFC incluso sugiere mostrar el precio por minuto y el cargo mínimo antes de iniciar la sesión. En un ejemplo, una emisora no ofrece texto y un proveedor de transcodificación rechaza convertir su audio porque teme quedarse sin recursos. La cadena tiene un límite operativo: la señalización no garantiza que el servicio vaya a aceptar la solicitud.

Los escenarios no se reducen a subtítulos. En uno, una conversación de voz sigue abierta mientras un relevo convierte las palabras en texto y devuelve en voz las respuestas escritas. En otro, una conferencia combina conversión de voz a texto, texto a lengua de signos y lengua de signos a texto según las preferencias de varias personas. Un sistema telefónico activado por voz recibe una vía textual mediante un intermediario. Son ideas ambiciosas, pero cada conversión añade un proveedor, una política, un posible cobro y otro punto por el que pasan datos personales.

La secuencia posterior de RFC muestra especificación, no éxito universal. La RFC 4103 definió un formato RTP para texto T.140 en tiempo real y recomendó redundancia para recuperar algunos caracteres perdidos. La RFC 5194 elaboró después un marco SIP/IP con requisitos más concretos para texto, transcodificación, presentación e interfuncionamiento; cita la RFC 3351 como antecedente para activar relés. La RFC 4504 recomendó que los teléfonos SIP atendieran esos requisitos. Más tarde, la RFC 8865 especificó texto T.140 sobre canales de datos WebRTC fiables y ordenados, y la RFC 9071 abordó el texto RTP en conferencias y actualizó la RFC 4103.

Cada paso precisa una parte de la ruta; ninguno demuestra que todos los terminales, proveedores o servicios de emergencia la ofrezcan.

Esa diferencia define el legado. Una sesión puede admitir nuevos medios mientras el servicio real sigue siendo inaccesible, incompatible, demasiado caro o sujeto al rechazo de un proveedor. Un perfil puede facilitar la comunicación y exponer datos sensibles al mismo tiempo. Un relevo puede unir formatos y, además, imponer condiciones. La RFC 3351 llevó estas decisiones de control, precio y privacidad a la conversación de diseño: cambiar de medio no debería exigir empezar una llamada nueva, y la persona debería conservar capacidad de elección. No afirmó que el equilibrio estuviera ya conseguido.

Fuentes: RFC 3351 · Ficha RFC 3351 · Registro Datatracker de RFC 3351 · RFC 2119 · RFC 8174 · SIP: Session Initiation Protocol, RFC 3261 · Modelo oferta/respuesta SDP, RFC 3264 · Texto conversacional en RTP, RFC 4103 · Marco para texto en tiempo real sobre SIP, RFC 5194 · Requisitos de dispositivos SIP, RFC 4504 · Texto T.140 en canales WebRTC, RFC 8865 · Mezcla RTP de texto en conferencias, RFC 9071 · Especificación inicial mínima, decisión futura localizada y adopción voluntaria · Primacía del código en ejecución