Codigos de respuesta SIP 5xx: que significan y como los gestiona un SBC

Cuando una llamada SIP falla, el codigo de respuesta indica quien fallo y que hacer al respecto, y la clase 5xx es la que decide si una llamada obtiene una segunda oportunidad. Un 5xx significa que la solicitud era perfectamente valida pero el servidor no pudo cumplirla, por lo que esa misma llamada a menudo tendra exito contra un servidor diferente. Esa propiedad es la razon por la que los codigos 5xx impulsan casi todo el comportamiento de conmutacion por error (failover) y avance de ruta en una red de voz en produccion. Si la gestion es correcta, un problema con un operador se convierte en un redireccionamiento invisible; si es incorrecta, se convierte en una llamada caida y un ticket de soporte.
La clase 5xx es la familia de “error del servidor” en SIP, definida en RFC 3261 junto con las otras cinco clases. En este articulo recorreremos cada codigo 5xx en terminos de produccion, que buscar en una captura de paquetes y como un controlador de borde de sesion (SBC) convierte un error del servidor en un failover limpio en lugar de una llamada fallida. Si desea el diccionario completo que cubre desde 1xx hasta 6xx, la Guia completa de codigos de respuesta SIP es la referencia para tener abierta junto a esta pagina. Esta pagina profundiza exclusivamente en los 5xx.
![]()
Que significa 5xx y en que se diferencia de 4xx
Toda la clase 5xx se reduce a una decision de enrutamiento: intentar en otro lugar. Un 5xx dice que la solicitud era sintacticamente valida pero el servidor que respondio no pudo completarla, lo que implica fuertemente que un servidor diferente podria hacerlo. Eso es lo opuesto a la mayoria de los codigos 4xx, donde la solicitud en si era incorrecta y reintentarla sin cambios contra otro servidor a menudo fallara de la misma manera. Un 4xx generalmente significa detenerse; un 5xx generalmente significa avanzar a la siguiente ruta.
La otra propiedad util es que un 5xx generalmente se genera salto a salto, por un intermediario a lo largo de la ruta (un proxy, un B2BUA o un conmutador de operador) en lugar del terminal llamado. Eso indica que la llamada nunca llego al extremo remoto y proporciona un punto de partida para determinar que elemento investigar. Para la taxonomia completa de las seis clases de respuesta y como interactuan, consulte la guia completa; el resto de esta pagina se mantiene dentro de la familia 5xx.
Los codigos 5xx, uno por uno
Para cada codigo a continuacion: que elemento lo emite normalmente, como se ve en una captura, que efecto tiene en la llamada ascendente y lo primero que se debe verificar.
500 Server Internal Error
500 Server Internal Error es el codigo generico de “algo fallo de mi lado”. El servidor que respondio acepto la solicitud y luego encontro un fallo que no puede describir con mayor precision, a menudo un error de software, una busqueda interna fallida o un recurso agotado en un conmutador de operador o servidor de aplicaciones. En una captura, llega como una respuesta final a su INVITE sin un cuerpo util, a veces con un encabezado Warning que contiene una pista de una linea. Un solo 500 suele ser transitorio; 500 persistentes de un operador apuntan a un fallo de software en el equipo de ese operador, no a su configuracion. Primera verificacion: ¿es un par o todos? Un solo par significa abrir un ticket con ese operador y dejar que el SBC haga failover mientras tanto.
501 Not Implemented
501 Not Implemented significa que el servidor reconocio el metodo SIP pero no es compatible con el. El disparador clasico es un REFER enviado a un operador que no ofrece transferencia de llamadas, o un INFO o UPDATE que el lado remoto nunca implemento. La respuesta deberia incluir un encabezado Allow que liste los metodos que el servidor admite, que es la forma mas rapida de confirmar lo que aceptara. Primera verificacion: lea el encabezado Allow y luego deje de enviar el metodo no admitido o gestione la funcion localmente en el SBC en lugar de retransmitirla.
502 Bad Gateway
502 Bad Gateway dice que el servidor que respondio recibio una respuesta invalida de un servidor mas adelante en la cadena. En una cadena de SBC y proxies, un 502 del siguiente salto a menudo significa que el problema se origino mas adelante en la cadena descendente. Es un indicador, no un destino. Primera verificacion: capture en el lado remoto del siguiente salto si es posible, porque la falla real esta mas alla de quien le envio el 502.
503 Service Unavailable
503 Service Unavailable es el codigo de trabajo de toda la clase, y tiene su propia seccion mas adelante porque conlleva la mayor cantidad de matices. En resumen, significa que el servidor esta lo suficientemente sano para responder pero no puede aceptar la solicitud en este momento, porque esta sobrecargado, con limite de tasa, alcanzando un tope de sesiones o en mantenimiento. Es la senal sobre la que un SBC mas quiere actuar, porque un 503 de una troncal es casi siempre una razon clara para hacer failover a otra. Primera verificacion: confirme que su comportamiento de avance de ruta realmente hace failover en 503 y busque un encabezado Retry-After.
504 Server Time-out
504 Server Time-out es el primo de sistemas encadenados del 408 Request Timeout. La diferencia es de quien se agoto el temporizador. Un 408 significa que su propio temporizador de transaccion expiro esperando cualquier respuesta. Un 504 significa que el servidor que le respondio estaba a su vez esperando a otro servidor ascendente que nunca respondio a tiempo. Entonces, 504 le dice que el servidor que respondio esta activo y comunicandose, pero algo de lo que depende no lo esta. Primera verificacion: el servidor que devuelve el 504 es alcanzable, asi que la falla esta mas alla de el; persiga la dependencia que agoto su tiempo en lugar del par que reporto el 504.
505 Version Not Supported
505 Version Not Supported significa que la version de SIP en la linea de solicitud no es compatible. En la practica, es una pieza de museo, porque SIP/2.0 ha sido la unica version implementada durante dos decadas. Si alguna vez ve uno, sospeche de una linea de solicitud malformada o una herramienta de prueba enviando datos invalidos, no de una negociacion de version real.
513 Message Too Large
513 Message Too Large significa que la solicitud excedio el tamano que el servidor acepta en el transporte actual. Este codigo aparece en el mundo real mas de lo que su oscuridad sugiere, casi siempre en UDP, cuando un INVITE crece mas alla del limite del datagrama debido a un cuerpo SDP grande, un conjunto extenso de encabezados o un encabezado Identity voluminoso con un PASSporT de STIR/SHAKEN. La solucion rara vez es reducir el mensaje; es mover ese par a TCP o TLS, donde los mensajes grandes no tienen la misma restriccion. Primera verificacion: ¿este par usa UDP con INVITE grandes? Cambie el transporte.
580 Precondition Failure
580 Precondition Failure proviene de RFC 3312 y significa que las precondiciones SDP en la oferta no pudieron cumplirse, normalmente una reserva de recursos de calidad de servicio que la red no pudo garantizar antes de conectar la llamada. Es poco comun, y solo lo encontrara en interconexiones que condicionan el establecimiento de la llamada a la reserva de recursos. Primera verificacion: si las precondiciones son realmente necesarias en este tramo, porque muchas implementaciones las negocian cuando no las necesitan.
503, Retry-After y control de sobrecarga
503 merece su propio tratamiento porque es el unico codigo 5xx con un comportamiento de gestion integrado en su diseno. Es la forma estandar para que un servidor diga “estoy bien, pero estoy lleno o en mantenimiento, asi que vuelva mas tarde o vaya a otro lugar”. Tratar cada 503 como un fallo definitivo descarta todo el proposito del codigo.
La pieza clave es el encabezado Retry-After, definido en RFC 3261 seccion 20.33. Cuando un servidor incluye Retry-After, le indica al llamante cuantos segundos esperar antes de reintentar contra ese servidor especifico. Un SBC bien configurado lo respeta despriorizando temporalmente esa ruta durante el intervalo indicado, en lugar de golpear a un servidor que explicitamente pidio un respiro. Ignorar Retry-After y reintentar inmediatamente tiende a empujar a un servidor ya cargado aun mas alla del limite.
Mas alla del Retry-After por mensaje, SIP define una forma estandarizada para que un servidor ocupado solicite al ascendente que reduzca el trafico antes de tener que empezar a rechazar todo. RFC 5390 establece los requisitos para el control de sobrecarga SIP, y RFC 7339 define el mecanismo: parametros de control de sobrecarga transportados en el encabezado Via que permiten a un elemento descendente indicar a su vecino ascendente que reduzca un porcentaje del trafico. Cuando ambos lados lo implementan, la congestion se gestiona de forma gradual y las tormentas de 503 nunca comienzan. Sin embargo, muchos pares no lo implementan y simplemente emiten 503 una vez que alcanzan su limite, por lo que la reaccion de su SBC ante un 503 simple sigue siendo importante.
Las conclusiones practicas son simples. Un 503 de un primario sano deberia hacer failover limpiamente a una ruta de respaldo. Una oleada repentina de 503 es una senal de capacidad o interrupcion a nivel de troncal, no un defecto por llamada, y deberia leerse como “este operador tiene problemas” en lugar de “esta llamada fue mala”.
Un 503 se genera en el proxy de borde del Operador A y viaja salto a salto de regreso al SBC, no desde el nucleo del operador detras de el. El SBC lee el Via superior para ver que elemento fallo y luego avanza la llamada a un operador de respaldo. Haga clic para ampliar.
Como se ve un 5xx en una captura de paquetes
Leer un 5xx en una traza consiste principalmente en responder una pregunta: ¿que elemento lo envio? La pila del encabezado Via es donde se encuentra la respuesta. La entrada Via superior asociada con el procesamiento de la respuesta identifica el salto que la genero, por lo que un 503 cuyo Via superior es el proxy de borde del operador fue emitido alli, no por el conmutador de destino detras de el. Eso le indica inmediatamente hasta donde llego la llamada.
La naturaleza salto a salto de la mayoria de los codigos 5xx es en si misma una pista. Dado que un intermediario genero la respuesta, no llevara el contexto de extremo a extremo que se veria del lado llamado, lo cual confirma que la llamada nunca llego al extremo remoto. Busque tambien un encabezado Warning, definido en RFC 3261, que a menudo contiene una explicacion corta legible por humanos, y un encabezado Reason de RFC 3326, que puede transportar un valor de causa Q.850 cuando la falla se esta puenteando desde una red TDM. Esos dos encabezados son donde normalmente se oculta el “por que”.
Un comportamiento mas que vale la pena conocer para la lectura de trazas: el ACK para respuestas finales no-2xx se genera dentro de la transaccion INVITE y sigue la ruta de senalizacion existente, a diferencia del ACK de extremo a extremo que requiere un 200 OK. Si ve un 5xx sin un ACK correspondiente, la transaccion no se cerro correctamente, y eso es un problema aparte a investigar. Para el metodo general de lectura de cualquier traza SIP, una guia dedicada de trazas cubre los puntos de captura y las herramientas, y el articulo de flujo de llamada SIP muestra donde aparecen estos codigos en una llamada completa; esta seccion es solo la parte especifica de 5xx.
Como gestiona un SBC los codigos 5xx
La razon por la que un SBC se ubica en el borde de una red multioperador es precisamente para que el error de un solo servidor no se convierta en la llamada caida de su cliente. Un SBC con arquitectura B2BUA termina el tramo entrante y origina un tramo saliente independiente, lo que significa que ve el 5xx en un lado y decide, en sus propios terminos, que deberia escuchar el otro lado. El mismo control que impulsa la manipulacion de encabezados SIP y la senalizacion SIP en cada tramo le permite reescribir un codigo de respuesta o cambiar que decision de enrutamiento activa.
El comportamiento central es el avance de ruta. El SBC mapea un 5xx a “avanzar a la siguiente ruta” para que un error del servidor en un operador haga failover de la llamada a una ruta de respaldo, mientras que un 4xx generalmente se deja para detener la llamada, porque reintentar una solicitud rechazada en otro lugar rara vez ayuda. Respetar Retry-After es la siguiente capa: cuando un 503 lo incluye, el SBC marca esa ruta como inactiva durante el intervalo indicado en lugar de reintentar contra un muro. Los 503 repetidos del mismo par pueden sacarlo de la rotacion completamente hasta que los keepalives OPTIONS muestren que se ha recuperado, de modo que un operador degradado deja de atraer trafico automaticamente.
Las redes reales son lo suficientemente complejas como para que estas decisiones necesiten configurarse por grupo de troncales en lugar de globalmente, porque el 503 de un operador podria significar congestion genuina mientras que el de otro senala una interrupcion que se quiere escalar de inmediato. ProSBC gestiona esto con control por tramo en hasta 1,024 puntos de acceso a la red (grupos de troncales), de modo que el comportamiento de avance de ruta y codigo de causa para cada par puede coincidir con lo que ese par realmente hace. Con mas de veinte anos de implementacion de SIP en operadores y capacidad para hasta 60,000 sesiones por servidor, ese control por par es lo que mantiene la gestion de 5xx coherente cuando docenas de operadores se comportan de manera diferente a gran escala.
La ultima pieza es la visibilidad. Una tasa creciente de 5xx en una troncal es la senal mas temprana legible por maquina de una interrupcion del lado del operador, generalmente visible para su monitoreo antes de que un solo cliente lo note. Presentar los conteos de 5xx por ruta en un panel, con umbrales de alerta, convierte los mismos codigos que impulsan el failover automatico en un sistema de alerta temprana para los humanos de guardia.
Preguntas frecuentes
¿Un 503 es una falla de llamada?
No realmente. Un 503 es una senal de “reintentar en otro lugar”, y si su SBC hace failover correctamente, la llamada aun se completa. Filtre los eventos de 503-luego-failover de sus metricas brutas de falla y reportelos como failovers exitosos, o sus paneles exageraran cuantas llamadas realmente fallaron.
¿Deberia reintentar un 5xx contra el mismo servidor?
Solo despues del intervalo en un encabezado Retry-After, o con un retroceso razonable. Un reintento inmediato contra el mismo servidor generalmente produce el mismo 5xx, y durante una sobrecarga lo empeora.
¿Cual es la diferencia entre 408 y 504?
De quien se agoto el temporizador. Un 408 Request Timeout significa que su propia transaccion se agoto esperando cualquier respuesta. Un 504 Server Time-out significa que el servidor le respondio pero estaba esperando a otro servidor ascendente que nunca respondio. Con un 504, el par con el que habla esta activo; la dependencia detras de el no lo esta.
¿Por que recibo un 503 de un operador que claramente esta activo?
Casi siempre es capacidad, no salud. Los topes de sesion, los limites de tasa y el control de sobrecarga se manifiestan como 503 desde un conmutador perfectamente sano. Significa “lleno”, no “averiado”.
¿Por que los INVITE grandes regresan con un 513?
El mensaje excedio el limite de tamano del transporte, que en la gran mayoria de los casos es una restriccion de datagrama UDP. Mueva ese par a TCP o TLS y el INVITE sobredimensionado, a menudo inflado por un SDP grande o un encabezado Identity de STIR/SHAKEN, pasara sin problema.
Conclusion
La clase 5xx es pequena pero de alto valor: errores del lado del servidor que generalmente son reintentables en otro lugar, y el motor detras de casi cada failover limpio en una red de voz. Saber que elemento emitio el codigo, si un Retry-After esta adjunto y si la causa es salud o capacidad es lo que convierte un error del servidor en una llamada redirigida en lugar de una llamada perdida. Tenga la guia completa de codigos de respuesta a mano para las otras cinco clases, y trate los 5xx como su kit de herramientas de avance de ruta.
Convierta cada error del servidor en un failover limpio con ProSBC
Como B2BUA completo, ProSBC termina y re-origina cada tramo de llamada, de modo que puede convertir cualquier 5xx de un par en la decision de enrutamiento que su red realmente necesita: avanzar a un operador de respaldo, respetar un intervalo Retry-After, mantener un par sobrecargado fuera de rotacion hasta que se recupere y alimentar la tasa de 5xx directamente al monitoreo.
Su motor de enrutamiento basado en reglas y controlado por API permite failover multiruta basado en prioridad, y el control por NAP en hasta 1,024 grupos de troncales significa que el uso idiosincratico de 503, 500 y el resto por parte de cada operador puede gestionarse en sus propios terminos en lugar de con una unica regla global general.
¿Prefiere evaluar por su cuenta primero? Inicie su prueba gratuita de 30 dias.