Resumen

  • RFC 3326 permitió que una petición explicara qué respuesta, rama o mensaje externo la había provocado, sin crear un método distinto para cada causa.
  • Reason podía ignorarse y no modificaba el procesamiento SIP; para usarlo como evidencia había que conservar protocolo, causa, creador, copias, traducción e integridad por separado.

Una causa podía cruzar de un diálogo a otro

El ejemplo del control de llamada por un tercero muestra la necesidad con especial claridad. El controlador intenta conectar a A con B. Mantiene un diálogo con A mientras abre otro hacia B. Si B responde 486 Busy Here, el controlador debe cerrar el lado de A con BYE. El BYE describe la acción local, pero no contiene necesariamente el hecho remoto que la desencadenó.

Reason permitió incluir la causa SIP 486 en ese BYE. Así, el dispositivo o servicio del lado de A podía entender que la terminación no había surgido de una decisión arbitraria dentro de su propio diálogo. Una respuesta observada en otra conversación se convertía en contexto para una nueva petición.

El patrón también aparecía en la bifurcación. Un proxy enviaba INVITE a varios destinos; uno respondía 200 OK y el proxy cancelaba los restantes. Los teléfonos perdedores dejaban de sonar igual que si el llamante hubiese abandonado. Sin Reason, la interfaz podía anotar una llamada perdida aunque la persona ya hubiera contestado en otro aparato. Con una causa SIP 200 y el sentido de «completada en otro lugar», podía distinguir ambos relatos.

La cabecera servía asimismo cuando un cliente recibía una oferta inaceptable en una respuesta exitosa: confirmaba con ACK y terminaba con BYE, llevando 488 como explicación. En un gateway, el disparador podía proceder de ISUP y viajar como causa Q.850. RFC 3326 unificó el contenedor, no los sistemas de significado.

Reason podía aparecer en cualquier petición dentro de un diálogo, en CANCEL y en respuestas cuyo código lo autorizara de manera expresa. Esta amplitud no lo convertía en obligatorio. Documentaba la causa cuando un actor decidía conservarla.

La cabecera informaba, pero no gobernaba

El documento dejó una reserva decisiva: clientes y servidores podían ignorar Reason, y la cabecera no afectaba al procesamiento del protocolo. BYE terminaba, CANCEL cancelaba y las máquinas de estado continuaban según SIP. La explicación podía cambiar una interfaz, un servicio o un registro, no la validez básica de la petición.

Por eso una cabecera presente no es un recibo de ejecución. Demuestra qué bytes llegaron a un punto de observación. No prueba que el evento descrito ocurriera, que el emisor final lo viera directamente ni que el receptor actuara sobre él. La decisión derivada necesita su propio registro.

Cada valor comenzaba con el nombre de un protocolo. SIP y Q.850 eran los primeros espacios definidos. El parámetro cause era numérico, pero su significado dependía del espacio. Conservar solo el número mezcla códigos que pertenecen a lenguajes distintos. El texto entre comillas ayudaba a leer, aunque no reemplazaba el valor estructurado ni garantizaba una traducción uniforme.

El registro de IANA importa precisamente por ese motivo. Define los protocolos Reason y los parámetros reconocidos. Un sistema analítico debe guardar el identificador de protocolo, la causa, el texto y cada extensión. Convertir todo en una columna llamada «error» pierde la autoridad que asigna significado al número.

RFC 9366 corrigió otra simplificación. La norma original exigía protocolos distintos cuando había varios valores. Desde la actualización, un mismo protocolo puede repetirse solamente si su registro define qué significa la multiplicidad. Para los demás, continúa la regla de un valor por protocolo. La sintaxis de una lista no autoriza al receptor a inventar cómo combinarla.

Traducir un motivo no conserva automáticamente su origen

RFC 3398 describió la correspondencia entre ISUP y SIP. Si una liberación llegaba desde la red telefónica, el gateway podía generar una petición SIP y poner en Reason la causa Q.850 recibida. La cancelación dejaba de ser un punto final sin contexto.

RFC 6432 amplió el uso de causas Q.850 a las respuestas SIP salvo 100 Trying. RFC 8606 añadió location para conservar, cuando estuviera disponible, la zona lógica de la red ISUP donde se produjo la liberación. Los valores distinguen ámbitos como red local, de tránsito o remota; no revelan la ubicación física de quien llama o recibe.

El dato adicional no elimina la incertidumbre. Un gateway puede aplicar una tabla de correspondencia distinta, recibir una causa nacional, copiar un valor anterior o crear uno local. Una captura SIP al final de la ruta no identifica por sí sola al observador original. Hacen falta el mensaje de entrada, la versión del mapeo, el nodo que lo ejecutó y las transformaciones posteriores.

History-Info de RFC 7044 conserva el historial de redirección, mientras RFC 5806 documentó un mecanismo de desvío. Son piezas vecinas, no sustitutos. Saber por qué se emitió una petición no enumera todas las URI por las que pasó; conocer las URI no certifica la causa de terminación.

La copia era necesaria y peligrosa

Cuando un proxy recibía un CANCEL con Reason y generaba otro CANCEL hacia adelante, debía copiar la cabecera. La regla mantenía unida la causa a la acción mientras esta atravesaba la red. Sin ella, el último teléfono solo vería la orden de dejar de sonar.

Pero una copia es testimonio indirecto. El proxy final puede no saber si la rama realmente terminó, ni si la causa fue traducida correctamente. Un intermediario que suprima o falsifique Reason puede alterar el comportamiento visible sin cambiar el CANCEL. Las auditorías deben marcar si un valor fue observado, creado, traducido o simplemente retransmitido.

El problema HERFP hizo tangible el riesgo. En una invitación bifurcada, un error final de una rama podía no llegar al cliente mientras otras ramas seguían. Encapsular información final en una respuesta provisional era uno de los usos previstos. Si alguien quitaba o falsificaba la causa, el cliente podía no actualizar su petición y el establecimiento de sesión podía fracasar. De ahí la recomendación de proteger la integridad.

Una firma o protección válida limita la afirmación a que determinados bytes no cambiaron entre extremos conocidos. No convierte una causa en hecho histórico ni verifica la tabla de traducción. La lección de RFC 3326 es más sobria: cuando una acción borra las diferencias visibles entre sus desencadenantes, conviene transportar el motivo, pero también conservar la procedencia que permite juzgarlo.

Fuentes