Resumen

  • RFC 5370 permite que un destinatario que no acepta una oferta de medios responda con 302 Moved Temporarily y señale un transcodificador. El llamante todavía debe reconocer esa respuesta y emitir un nuevo INVITE hacia el servicio.
  • El transcodificador opera como B2BUA, no como proxy. Termina una transacción, origina otra y genera una nueva respuesta final de vuelta, aunque normalmente conserve el mismo código de estado recibido del destino.
  • La excepción a las listas de aceptación previa depende de tres límites: un solo INVITE generado, un destino conocido y escrito por el propio llamante, e identidad del llamante presente aguas abajo. Cambiar cualquiera de ellos obliga a revisar la decisión.

La incompatibilidad devolvió una dirección

B recibió una descripción de sesión que no podía aceptar. En el flujo de invocación por el destinatario, RFC 5370 le permite contestar 302 Moved Temporarily. El Contact contiene la URI de T, el transcodificador, y un parámetro ?body= que transporta una lista con la URI de B.

El dato es denso: una respuesta de redirección lleva tanto la ubicación del servicio intermedio como la instrucción que ese servicio necesitará para volver a llegar al destinatario. Pero nada en el 302 obliga a A a seguir el camino.

A debe enviar ACK para cerrar el intento fallido. Después debe crear un nuevo INVITE hacia T. T, si acepta y autoriza la solicitud, crea a su vez un INVITE distinto hacia B.

Por tanto, el primer recibo correcto es “B propuso este camino”. No es “T convirtió los medios”, “B aceptó la llamada” ni “la persona pudo participar”. La cadena conserva decisiones pendientes en cada salto.

Codificar un cuerpo dentro de una URI era una frontera

El Contact del 302 no contiene una referencia abstracta. Incluye un cuerpo recipient-list codificado en el parámetro de la URI. El documento advierte que la sintaxis es compleja y requiere escapar caracteres como retornos de carro y saltos de línea.

Esa complejidad tiene consecuencias de autoridad. Un error de codificación puede alterar la lista, truncarla o impedir que A construya la nueva solicitud. Un parser tolerante puede interpretar un objeto diferente del que B quiso delegar.

Registrar solo la URI del transcodificador pierde el objeto más sensible: la identidad del destinatario que debe recibir el INVITE posterior. El recibo debería conservar el Contact exacto, el cuerpo decodificado, su hash, el resultado del parseo y la URI finalmente usada.

RFC 5370 observa que, para la invocación iniciada por el destinatario, el modelo 3pcc resulta más sencillo. Es una comparación de mecanismos, no una orden universal. La elección depende también de capacidades, política y evidencia disponible.

Seguir una redirección fue una decisión nueva

Un sistema puede automatizar el seguimiento de un 302, pero la automatización no elimina la decisión. Solo la desplaza a una regla configurada de antemano.

Antes de invitar a T, A puede necesitar comprobar que la URI pertenece a un servicio permitido, que el servicio ofrece la transformación requerida, que su jurisdicción y retención son aceptables y que B no ha introducido una dirección inesperada.

El hecho de que B haya elegido T prueba una preferencia o propuesta de B. No prueba que A haya delegado autoridad a cualquier servicio mencionado por un destino remoto.

El registro operativo debe distinguir respuesta recibida, validación de la URI, decisión de seguirla, nueva solicitud enviada, autenticación de T y aceptación efectiva. Fusionar esas fases convierte una pista en una acción consumada.

T no reenviaba el INVITE original

Una vez que A contacta a T, el modelo se parece al de la invocación por el llamante. A establece una sesión con T y le entrega la URI de B en una lista de destinatarios. T usa esa información para originar un INVITE hacia B.

RFC 5370 insiste en que T es un B2BUA, no un proxy. El INVITE de T a B pertenece a otra transacción. T construye una descripción SDP ajustada al servicio de conversión que ofrece.

La nueva transacción significa que las ramas, el diálogo, el contexto de autenticación y la negociación no son una continuidad automática de la solicitud de A. T decide cómo correlacionar dos piernas.

Un identificador global creado por una plataforma puede facilitar la búsqueda, pero no debe reemplazar las identidades nativas de cada transacción. Sin ellas no es posible saber dónde apareció un fallo ni qué autoridad tomó la decisión.

El mismo estado no era el mismo acontecimiento

Cuando T recibe una respuesta final de B, genera una nueva respuesta final para A. La especificación dice que esta respuesta debería usar el mismo código de estado.

Así, un 603 Decline aguas abajo puede producir otro 603 aguas arriba. La coincidencia comunica una clasificación útil, pero no conserva por sí sola la procedencia.

El caso de error de RFC 5370 lo demuestra. Si se pierde el 183 Session Progress que T envió antes, A no puede decidir si T rechazó la solicitud original o si B rechazó la solicitud generada por T.

Dos autoridades distintas pueden emitir los mismos tres dígitos. Para responsabilidad, remediación y experiencia de usuario, esa diferencia importa más que la coincidencia visual.

History-Info completaba la causalidad

RFC 5370 señala History-Info como mecanismo para resolver la ambigüedad entre las dos piernas. La información histórica permite atribuir el resultado sin fingir que existió una sola transacción.

Una plataforma que almacena únicamente el estado final puede tener un registro compacto y, al mismo tiempo, no saber quién rechazó. La pérdida del provisional revela que la evidencia intermedia no era ruido: mantenía separadas admisión del servicio y decisión del destino.

El texto citaba RFC 4244. RFC 7044 revisó después el mecanismo. Esa evolución da contexto actual al estándar, pero no demuestra que una red concreta haya transmitido, preservado o expuesto History-Info.

La verificación debe leer la traza y la configuración reales. Un campo vacío puede significar ausencia de soporte, supresión por privacidad, pérdida o fallo de captura; no debe rellenarse con una inferencia.

El From visible era una presentación

T debe construir el From saliente a partir del valor recibido de A, condicionado por las exigencias de privacidad. La regla no se aplica al parámetro tag.

Por eso B puede ver una identidad que representa a A mientras recibe una solicitud originada transaccionalmente por T. La presentación y el origen del mensaje no son el mismo hecho.

También hay que separar usuario autenticado por T, autorización para usar el servicio, identidad mostrada y posible afirmación criptográfica sobre el originador. Una interfaz que reduce todo a “caller” borra estas funciones.

RFC 5370 citaba el mecanismo de identidad de RFC 4474; RFC 8224 lo sustituyó posteriormente. La cronología prohíbe usar la referencia histórica como prueba de qué tecnología valida hoy un despliegue.

Una sola URI limitaba la autoridad

El INVITE hacia T contiene SDP y una lista de destinatarios con una única URI. Si la lista tiene más de una, T debería responder 488 e indicar que el máximo es uno.

La restricción define el modelo de transcodificación bipartita. No invalida los mecanismos multiparte de RFC 5366. Aquí asegura que la introducción de T no convierta una llamada en una operación de fan-out.

SDP y lista viajan en el mismo multipart, pero autorizan cosas distintas. SDP propone medios. La lista autoriza a T a generar una solicitud hacia un destino. La integridad debe cubrir el objeto que gobierna la acción.

Proteger codecs mientras se deja mutable la URI conservaría la negociación y perdería el control de destino. El hash de la lista debe quedar ligado a la transacción de entrada y a la de salida.

La excepción de consentimiento era estrecha

Los servicios de listas pueden facilitar solicitudes no deseadas y amplificación. RFC 5370 concluye que este servicio específico no necesita listas de opt-in.

La conclusión descansa en tres hechos: T genera un solo INVITE; A ya conoce y escribe la URI de B; la identidad del llamante aparece en la solicitud enviada a B.

No es una exención permanente asociada a la palabra “transcodificador”. Si una actualización resuelve una identidad hacia varios destinos, sustituye la URI por otra desconocida para A o oculta al invocador, cambia el razonamiento.

La política debería evaluarse como una condición viva: target_count = 1, target_source = caller e identity_present = true. Una etiqueta estática no puede detectar cuándo el producto abandona el modelo que justificó la excepción.

Integridad y autorización no medían la conversión

RFC 5370 hereda las consideraciones de seguridad de los servicios de listas. Recomienda proteger la integridad de la lista mediante mecanismos como S/MIME o TLS y exige que T autentique y autorice usuarios.

Estas garantías controlan instrucción y acceso. No prueban que T haya elegido el SDP correcto, convertido con fidelidad, limitado sus copias, eliminado datos o producido un resultado útil.

Las referencias criptográficas son históricas. RFC 5246 pertenecía al contexto TLS de publicación, y los documentos de identidad y S/MIME también tienen linajes posteriores. Un equipo actual debe declarar el mecanismo que realmente usa.

“Solicitud protegida” no debe convertirse en “servicio seguro” sin precisar qué objeto, qué pierna, qué amenaza y qué comprobación sostienen la frase.

La accesibilidad exigía una última evidencia

RFC 5370 presenta el modelo como apoyo a servicios requeridos por personas sordas, con dificultades auditivas o del habla. Un ejemplo es convertir voz en texto.

Una red puede completar ambas piernas, transportar medios y aun así fallar para la persona. El idioma puede ser incorrecto, la latencia excesiva, la dirección equivocada o la salida incomprensible.

El 302 prueba que B propuso un camino. Los 200 pueden probar admisión de las sesiones. El flujo prueba transporte. Ninguno prueba por separado comprensión o participación equivalente.

La métrica de accesibilidad debe alcanzar el nivel humano y conservar “desconocido” cuando no existe observación. De lo contrario, el éxito del protocolo blanquea un resultado fallido.

La arquitectura elegida compró velocidad con evidencia

El documento consideró que T aceptara primero a A y comunicara el resultado de la invitación a B mediante el paquete de eventos de conferencia. Aquella opción habría separado de forma explícita las dos decisiones.

Fue descartada por mayor complejidad, número de mensajes y demora de establecimiento. El diseño elegido usa menos coordinación visible, pero necesita History-Info para explicar ciertos fracasos.

Esta compensación importa a dirección. Reducir latencia no elimina el coste de observabilidad; lo desplaza. Si después se recorta la historia para ahorrar almacenamiento, se pierden ambos lados del compromiso.

La especificación registra una elección. Un operador debe verificar que su instrumentación conserva la evidencia que esa elección presupone.

El mínimo no era una historia única

La Minimum Initial Specification de Lu Heng funciona aquí como lente declarada. El mínimo útil incluye la redirección exacta, la decisión de seguirla, la lista protegida, el invocador, la privacidad, dos transacciones, el resultado atribuido y la identidad de T.

No hace falta imponer una implementación mundial. Sí hace falta que cada implementación exporte pruebas comparables de esas fronteras.

Reality Layers aporta la otra disciplina: redirección, invitación, estado, identidad presentada, autenticación, medios transformados y experiencia humana son capas distintas. Un evento puede ser real en una capa y todavía no existir en la siguiente.

RFC 5370 no hizo que el 302 significara conversión. Hizo explícitos los actos que aún debían ocurrir y el intermediario autorizado a originarlos.