Resumen

  • RFC 3326 permitió que una solicitud SIP llevara el motivo de su emisión, con una causa SIP o una causa Q.850 procedente de la interconexión telefónica.
  • El encabezado no altera el procesamiento SIP. CANCEL sigue cancelando; Reason puede explicar que otra rama ya completó la llamada.

Una rama respondió; las demás aún debían detenerse

Un proxy envía un INVITE por varias ramas. Un destino responde 200 OK, pero los otros teléfonos quizá continúen sonando. El proxy les envía CANCEL. Las alertas cesan por el método SIP CANCEL, no porque un encabezado describa lo ocurrido.

RFC 3326, publicado en diciembre de 2002, ofreció una forma de adjuntar esa explicación: Reason: SIP;cause=200;text="Call completed elsewhere". El servicio receptor podía distinguir una llamada atendida en otra rama de una abandonada antes de responder. Esa diferencia podía cambiar el registro de llamadas perdidas o la interfaz, aunque la acción protocolaria inmediata fuera la misma.

Esa separación es la decisión central de diseño. SIP ya disponía de códigos de estado para las respuestas, pero una misma solicitud puede emitirse por motivos distintos y no suele llevar la respuesta que la provocó. Reason vinculó la causa con la solicitud que actuaba sobre ella. Era metadato explicativo, no un segundo canal de órdenes.

La causa tenía un espacio de nombres

RFC 3326 calificó los valores por protocolo. SIP indica que el parámetro cause contiene un código de estado SIP. Q.850 identifica un valor decimal de causa del sistema de señalización telefónica de la UIT-T. Así, una pasarela podía preservar una causa de liberación de la red telefónica al traducirla a un mensaje SIP. El número aislado no bastaba: el protocolo decía qué sistema de numeración lo originó.

El parámetro text era legible para una persona, pero no tenía autoridad sobre el procesamiento. La causa pertenecía al vocabulario del protocolo nombrado; el método, el estado y el contexto transaccional seguían definidos por el mensaje. Interpretar cause=200 como una respuesta o una causa Q.850 como estado SIP confundiría dos superficies de control.

Tampoco había garantía de comprensión universal. RFC 3326 permitía ignorar valores desconocidos y afirmaba expresamente que Reason no afectaba al procesamiento protocolario. La solicitud seguía las reglas de SIP aunque el extremo descartara la explicación. La extensión podía ayudar a los servicios sin convertirse en requisito oculto para mantener el estado de una llamada.

Una respuesta que el bifurcado podía ocultar

La especificación también relacionó Reason con el problema de las respuestas de error heterogéneas en solicitudes bifurcadas. Un INVITE puede recibir fallos finales distintos en cada rama. Como el proxy suele esperar los resultados antes de decidir qué respuesta enviar hacia arriba, un error útil puede quedar oculto mientras otra rama sigue pendiente. RFC 3326 señaló como posible uso de Reason encapsular el estado final dentro de una respuesta provisional.

La precisión importa: era un mecanismo candidato, no una prueba de que cada bifurcación expusiera todos los errores ni de que un servicio desplegado resolviera el problema. El encabezado ofrecía un contenedor para una causa; no definía una política universal para priorizar fallos ni reemplazaba el manejo de respuestas SIP.

Las ampliaciones conservaron el límite

RFC 8606 añadió después un parámetro de ubicación ISUP para causas Q.850, de modo que la señalización pudiera preservar el punto de origen de la liberación cuando estuviera disponible. RFC 9366 flexibilizó más tarde la regla de una sola instancia por protocolo, pero únicamente cuando el protocolo registrado define el significado de múltiples valores. En ambos casos, la estructura adicional precisó la procedencia; no convirtió Reason en la operación.

La distinción también aclara la historia. RFC 3087 exploró el Request-URI como contexto local para seleccionar un servicio; RFC 3326 adjuntó una causa a una acción SIP ya elegida. Uno seleccionaba el destino de una solicitud; el otro explicaba por qué se había enviado. Ninguno demuestra autenticación, autorización, historial completo de llamada ni resultado posterior.

Fuentes

  1. https://www.rfc-editor.org/rfc/rfc3326.html
  2. https://www.rfc-editor.org/info/rfc3326/
  3. https://www.rfc-editor.org/rfc/rfc3261.html
  4. https://www.rfc-editor.org/rfc/rfc9366.html
  5. https://www.rfc-editor.org/rfc/rfc8606.html
  6. https://www.rfc-editor.org/rfc/rfc5411.html
  7. https://www.rfc-editor.org/rfc/rfc4411.html