Códigos de respuesta SIP: la guía completa de 1xx, 2xx, 3xx, 4xx, 5xx y 6xx

Cada llamada SIP termina con uno de aproximadamente treinta códigos de estado, y el código es la señal más confiable que existe para saber qué ocurrió realmente. Una llamada que falla con 486 Busy Here comunica algo completamente diferente a una que falla con 503 Service Unavailable, aunque el llamante escuche el mismo tono de ocupado rápido en ambos casos. Leer el código es lo primero que hace cualquier ingeniero de voz cuando una llamada no se completa, y la diferencia entre adivinar una falla y encontrarla suele reducirse a conocer qué significa cada código y qué comportamiento desencadena en el resto de la red.

Este artículo es la referencia para cada código de respuesta SIP que es probable encontrar en producción. Se cubren las seis clases (1xx provisional, 2xx éxito, 3xx redirección, 4xx error del cliente, 5xx error del servidor, 6xx falla global), los códigos específicos dentro de cada clase, el comportamiento de retransmisión y reintento que cada uno debe desencadenar, y cómo un controlador de borde de sesión (SBC) normaliza los códigos de respuesta entre fabricantes que no coinciden en qué código enviar. Para los fundamentos del protocolo, Fundamentos de señalización SIP cubre los roles, encabezados y arquitectura.

Las seis clases de códigos de respuesta

Los códigos de respuesta SIP siguen la misma estructura de seis clases que HTTP, definida en RFC 3261. El primer dígito identifica la clase, los dos dígitos restantes identifican el código específico dentro de la clase. La clase es la pieza más importante porque controla cómo se espera que reaccione el resto de la red: si debe seguir esperando, reintentar por una ruta diferente, abandonar por completo o tratar la llamada como completada.

Las respuestas 1xx provisionales confirman que la solicitud se está procesando. No son finales, no terminan la transacción y no se confirman con ACK. El agente de usuario del llamante deja de retransmitir la solicitud una vez que llega un 1xx, pero la llamada aún no se ha resuelto.

Las respuestas 2xx de éxito indican que la solicitud tuvo éxito. Para un INVITE, 2xx significa que la llamada ha sido contestada y debe seguir un ACK para completar el proceso de tres vías. 2xx es la única clase que establece un diálogo.

Las respuestas 3xx de redirección dirigen al llamante a intentar con un URI diferente. La solicitud original no tuvo éxito, pero la respuesta incluye un encabezado Contact que apunta a una ubicación alternativa donde se debe reintentar la llamada.

Las respuestas 4xx de error del cliente indican que la solicitud en sí tuvo un problema que el llamante puede corregir: sintaxis incorrecta, autenticación faltante, un terminal que está ocupado, un número que no existe. La solicitud no debe reintentarse sin cambios en el mismo destino.

Las respuestas 5xx de error del servidor indican que la solicitud era sintácticamente válida pero el servidor no pudo cumplirla. A diferencia de 4xx, la misma solicitud puede tener éxito contra un servidor diferente, por lo que 5xx es la clase que típicamente desencadena el avance de ruta hacia una ruta secundaria.

Las respuestas 6xx de falla global indican que la solicitud no puede ser cumplida por ningún servidor, en ningún lugar. Un código 6xx detiene los intentos de bifurcación en los proxies, termina los grupos de búsqueda paralelos y le indica al llamante que no intente rutas alternativas.

Respuestas provisionales 1xx

Las respuestas provisionales mantienen viva la transacción SIP mientras la red determina qué hacer a continuación. En la mayoría de los casos no tienen cuerpo, nunca activan ACK y sirven principalmente para detener la retransmisión e informar al llamante que algo está ocurriendo. Una llamada no puede completarse solo con un 1xx; siempre debe seguir una respuesta final (2xx a 6xx).

100 Trying es enviado por el siguiente salto SIP en el momento en que acepta el INVITE para su procesamiento. Es estrictamente salto a salto, nunca llega a la pantalla del llamante como un evento y existe por una sola razón: indicar al agente de usuario upstream que deje de retransmitir el INVITE mientras el siguiente salto realiza su trabajo. Si no ve un 100 Trying en una traza UDP, está observando un problema de transporte antes que un problema SIP.

180 Ringing es la respuesta provisional de extremo a extremo del terminal de destino que indica que se está alertando a la parte llamada. Este es el código que hace que el teléfono del llamante reproduzca el tono de retorno de llamada (ringback). Algunos operadores y PBX prefieren generar el ringback ellos mismos enviando 183 Session Progress con medios anticipados (early media), lo que les permite inyectar anuncios de red (número no disponible, por favor espere) antes de que la llamada sea contestada.

181 Call Is Being Forwarded es una respuesta provisional de cortesía que indica que la llamada ha sido redirigida a un terminal diferente. Rara vez se utiliza en redes modernas porque el reenvío generalmente se maneja de forma transparente mediante redirección 3xx o por un SBC que reescribe el destino.

182 Queued indica al llamante que el destino ha aceptado la llamada pero la ha colocado en una cola, típicamente en un centro de contacto donde todos los agentes están ocupados. Es una forma de mantener vivo el diálogo sin hacer sonar el tono mientras el llamante espera.

183 Session Progress es la respuesta provisional más importante después de 100 y 180. Indica progreso y, de manera crítica, puede incluir un cuerpo SDP que establece medios anticipados (early media) antes de que la llamada sea contestada. Los operadores utilizan 183 con early media para reproducir anuncios, tonos de ringback o retardos post-marcado en banda. Los medios anticipados mal configurados son una fuente común de quejas por audio unidireccional, porque el llamante escucha el anuncio del operador pero el terminal llamado real nunca ve una ruta de medios hasta el 200 OK.

Las respuestas provisionales confiables (PRACK, definidas en RFC 3262) extienden esta clase con confirmaciones para que los mensajes 1xx no se pierdan en enlaces con pérdidas. PRACK es obligatorio para algunas interconexiones (notablemente Microsoft Teams Enrutamiento directo bajo ciertas configuraciones) y opcional en otros casos.

Respuestas de éxito 2xx

Las respuestas de éxito son breves y de gran impacto. Un 2xx a un INVITE establece un diálogo, lo que significa que el estado de enrutamiento debe mantenerse en cada intermediario hasta que la llamada termine con BYE.

200 OK es la respuesta de éxito para casi toda solicitud SIP. Para un INVITE, significa que la llamada ha sido contestada y el cuerpo de la respuesta contiene la respuesta SDP del llamado que completa la negociación de medios. Para un BYE, confirma que el diálogo ha sido terminado. Para un CANCEL, confirma la cancelación en sí, por separado del 487 Request Terminated que se enviará para el INVITE original. Para un OPTIONS, devuelve los métodos y codecs admitidos por el respondedor, que es cómo funciona el monitoreo keepalive de SIP.

202 Accepted indica que la solicitud ha sido aceptada para procesamiento pero el resultado aún no se conoce. Se ve con mayor frecuencia como la respuesta a una solicitud REFER durante la transferencia de llamada: el transferido confirma que intentará la transferencia e informará el progreso a través de mensajes NOTIFY dentro del diálogo.

El comportamiento definitorio de cualquier respuesta 2xx a un INVITE es que debe confirmarse con ACK, y el ACK es de extremo a extremo. A diferencia de cualquier otra solicitud, el ACK para un 2xx viaja en su propia transacción y debe recorrer la misma ruta Record-Route que el INVITE original. Olvidar que Record-Route existe es una fuente común de tickets del tipo “la llamada contesta pero se corta inmediatamente” en el análisis de trazas.

Respuestas de redirección 3xx

Las respuestas de redirección indican al llamante que intente con un URI diferente. La respuesta incluye uno o más encabezados Contact que nombran el nuevo destino, y se espera que el agente de usuario del llamante (o el intermediario que maneja la redirección en su nombre) reintente la solicitud contra esos Contacts.

300 Multiple Choices lista varios posibles destinos y permite al llamante elegir. Es raro en producción porque la mayoría de los agentes de usuario SIP no presentan múltiples opciones al usuario; la llamada tiene éxito contra el primer Contact o falla.

301 Moved Permanently indica que la parte llamada tiene una nueva dirección permanente y los cachés deben actualizarse para reflejarla. Es poco común en redes de voz pero aparece en escenarios de registro.

302 Moved Temporarily es por lejos el 3xx más útil en producción. El llamante debe reintentar la solicitud contra el URI del encabezado Contact solo para esta llamada, sin almacenar en caché la nueva dirección. Las integraciones de prevención de fraude y STIR/SHAKEN frecuentemente devuelven 302 para redirigir una llamada de un grupo de troncales a otro basándose en puntuación en tiempo real. Los sistemas de enrutamiento de menor costo (LCR) utilizan 302 para dirigir una llamada a un operador diferente sin que el terminal originante sepa que la ruta ha cambiado.

305 Use Proxy instruye al llamante a reintentar a través de un proxy específico. Casi nunca se ve en redes de operadores en producción.

380 Alternative Service sugiere que la llamada debe intentarse a través de un servicio completamente diferente (por ejemplo, un protocolo distinto). Se utiliza ocasionalmente cuando un terminal SIP no puede aceptar una llamada pero conoce un servicio relacionado que sí puede.

Lo práctico de las respuestas 3xx es que no todos los dispositivos las manejan de la misma manera. Un proxy SIP o B2BUA generalmente consume el 3xx por sí mismo, reintenta la solicitud en nombre del llamante y tiene éxito con un 200 OK o devuelve un código de falla diferente al llamante original. Un agente de usuario simple sin esa lógica simplemente fallará la llamada cuando no pueda seguir la redirección. Esta es una de las razones más comunes por las que las llamadas “funcionan desde el SBC pero fallan desde el terminal” durante las pruebas.

Respuestas de error del cliente 4xx

La clase 4xx cubre todo lo que está mal con la solicitud en sí. La solicitud no tendrá éxito si se reintenta sin cambios contra el mismo destino, pero puede tener éxito si el llamante corrige el problema (agrega credenciales, corrige el URI, cambia el método) o elige un destino diferente.

Autenticación y autorización

401 Unauthorized es enviado por un UAS que requiere que el llamante se autentique antes de procesar la solicitud. La respuesta incluye un encabezado WWW-Authenticate con un realm y un nonce, y se espera que el llamante reintente la misma solicitud con un encabezado Authorization que contenga el digest. Los proveedores de troncales SIP y las PBX que requieren registro desafían los nuevos INVITE con 401.

407 Proxy Authentication Required es el mismo concepto pero emitido por un proxy intermedio en lugar del terminal final. El desafío aparece en un encabezado Proxy-Authenticate y la respuesta regresa como Proxy-Authorization. La causa más común de “el registro funciona pero las llamadas fallan” es una discrepancia de realm en el desafío 407 entre el SBC y el proveedor upstream.

403 Forbidden significa que el llamante está identificado y autenticado pero no tiene permiso para realizar esta solicitud. Las causas comunes incluyen llamar desde una IP que no está en la ACL del operador, intentar marcar un número fuera del rango asignado o fallar la atestación STIR/SHAKEN. 403 es final y el llamante no debe reintentar sin cambiar algo primero.

Problemas de dirección y método

400 Bad Request indica que la solicitud estaba malformada: un encabezado requerido faltante, un URI sintácticamente inválido, un cuerpo que no se puede analizar. Algunos operadores devuelven 400 cuando reciben un encabezado que consideran no conforme, lo cual es una de las razones por las que la normalización SIP es una función fundamental del SBC.

404 Not Found significa que el URI de destino no existe en el servidor que responde. En producción, 404 está sobrecargado: un verdadero “el número no existe” devuelve 404, pero también lo hace una falla de ACL en algunas plataformas, y algunos servicios de prevención de fraude utilizan 404 para indicar “no se detectó fraude, avance a la siguiente ruta.” En ProSBC, el comportamiento predeterminado de detener la llamada en 404 se anula comúnmente a “continuar llamada” específicamente para que los códigos de retorno de prevención de fraude alimenten correctamente la lógica de enrutamiento.

405 Method Not Allowed indica que el respondedor no es compatible con el método SIP que se solicitó. La respuesta incluye un encabezado Allow que lista los métodos admitidos, lo cual es útil para diagnóstico. Un REGISTER enviado a un servidor que solo acepta INVITE devolverá 405 con Allow listando INVITE, ACK, BYE y CANCEL.

415 Unsupported Media Type generalmente significa que el cuerpo SDP ofreció un codec o tipo de medio que el respondedor no puede manejar. La respuesta incluye un encabezado Accept que lista lo que sería aceptable, permitiendo al llamante intentar nuevamente con una oferta SDP más reducida.

Tiempo de espera y estado del terminal

408 Request Timeout se devuelve cuando la red ha estado reteniendo la solicitud el tiempo suficiente como para que cualquier respuesta razonable ya debería haber regresado. Es generado por intermediarios cuando no se recibe respuesta downstream dentro del intervalo del temporizador SIP (Timer B, típicamente 32 segundos para UDP), e indica al llamante que el destino fue inalcanzable por alguna razón no especificada.

410 Gone indica que la dirección de destino solía existir pero ya no está en servicio de forma permanente. Algunos operadores lo usan en lugar de 404 para distinguir “sabemos que este número funcionaba antes” de “este número es desconocido.”

480 Temporarily Unavailable es enviado por el terminal llamado cuando no desea tomar la llamada en este momento pero la dirección es válida. Es la respuesta estándar cuando expira el temporizador de no-respuesta (el teléfono sonó y sonó sin ser contestado) y la llamada se abandona antes de ser respondida. 480 significa que la llamada llegó al terminal y el terminal la rechazó según su propia política, lo cual es diferente de 408 donde la llamada nunca llegó tan lejos.

484 Address Incomplete indica al llamante que el número marcado parece ser una cadena de dígitos parcial. El llamante debe recopilar más dígitos y reintentar. Es en gran medida un legado del marcado en bloque de pasarelas TDM-a-SIP.

486 Busy Here es la respuesta “estoy en otra llamada” del terminal llamado. El diálogo termina inmediatamente y el agente de usuario del llamante típicamente reproduce un tono de ocupado. 486 es un código de terminal único: la parte llamada está ocupada, pero un terminal diferente para el mismo usuario (una segunda línea, un celular vinculado) podría seguir siendo alcanzable.

487 Request Terminated es la respuesta a un INVITE que ha sido cancelado antes de ser contestado. Es la contraparte SIP de una solicitud CANCEL: cuando Alice cuelga mientras aún escucha ringback, el lado de Bob envía un 200 OK al CANCEL en sí y un 487 al INVITE original. Interpretar erróneamente 487 como una llamada fallida en lugar de una llamada abandonada es una fuente común de métricas ASR (Answer-Seizure Ratio) incorrectas en el análisis de CDR sin procesar.

488 Not Acceptable Here indica que el terminal llamado entendió la solicitud pero no puede aceptar la sesión como se ofreció, casi siempre debido a un problema de SDP: una lista de codecs incompatible, un tipo de medio que el terminal no admite, un rango de puertos que no puede usar. Es la falla de negociación de codec que se observa con mayor frecuencia entre operadores que ejecutan diferentes órdenes de codec predeterminados.

491 Request Pending maneja una condición de carrera donde ambos lados de un diálogo envían un re-INVITE casi al mismo momento. El lado perdedor devuelve 491, espera un intervalo aleatorio breve y reintenta.

Respuestas de error del servidor 5xx

La clase 5xx es la aliada del especialista en resolución de problemas: significa que la solicitud en sí estaba bien pero el respondedor no pudo cumplirla, lo que implica fuertemente que un servidor diferente podría tener éxito. La mayoría del comportamiento de avance de ruta y failover en producción está impulsado por códigos 5xx.

500 Server Internal Error es el código genérico de “algo está mal conmigo.” El respondedor aceptó la solicitud pero encontró un problema que no puede describir más específicamente. Un 500 persistente desde un solo operador generalmente apunta a una falla de software en el switch de ese operador.

501 Not Implemented indica que el método de solicitud es reconocido pero el servidor no lo implementa. Un REFER enviado a un operador que no admite transferencia de llamadas devolverá 501.

502 Bad Gateway significa que el servidor recibió una respuesta inválida de un servidor downstream. En una cadena de SBC y proxies, un 502 del upstream generalmente significa que el downstream devolvió algo que no se pudo analizar o que violó el contrato.

503 Service Unavailable es la pieza fundamental del failover. Indica al llamante que el servidor está temporalmente sobrecargado o en mantenimiento y que la misma solicitud debe reintentarse en otro lugar. La mayoría de las limitaciones de tasa del lado del operador devuelven 503 una vez que se alcanza el límite de sesiones, que es exactamente la señal que el SBC del llamante necesita para avanzar a una troncal de respaldo.

504 Server Time-out indica que el servidor no recibió una respuesta oportuna de un servidor del que dependía. Es el equivalente de 408 en sistemas encadenados.

505 Version Not Supported indica que la versión SIP en la línea de solicitud no es compatible. Prácticamente una pieza de museo: SIP 2.0 ha sido la única versión implementada durante dos décadas.

La razón por la que los códigos 5xx importan para el diseño de rutas es que casi siempre justifican el avance de ruta. Un SBC correctamente configurado debe mapear las respuestas 5xx recibidas de cualquier operador individual a una decisión de “intentar la siguiente ruta”, mientras que las respuestas 4xx generalmente no deben avanzar (la solicitud en sí fue rechazada, reintentarla contra un operador diferente rara vez tendrá éxito). La excepción es el caso del 404 sobrecargado mencionado anteriormente.

Respuestas de falla global 6xx

Una respuesta 6xx es la forma más contundente de “no” en SIP. Indica al llamante que la solicitud no puede ser cumplida por ningún servidor en ninguna ubicación, por lo que tanto el avance de ruta como la bifurcación paralela deben detenerse. En una configuración de grupo de búsqueda o balanceo de carga que normalmente intentaría varios destinos en secuencia, un 6xx recibido de cualquiera de ellos termina toda la búsqueda.

600 Busy Everywhere significa que el usuario llamado está ocupado en todos los terminales que tiene registrados. A diferencia de 486 Busy Here, que es por terminal, 600 es por usuario. Un proxy que está bifurcando un INVITE a un teléfono de escritorio, un celular vinculado y un softphone detendrá la bifurcación en el momento en que cualquiera de ellos devuelva 600.

603 Decline indica que la parte llamada rechazó afirmativamente la llamada (presionó el botón de rechazar). El llamante no debe reintentar. 603 también es comúnmente utilizado por servicios de prevención de fraude para indicar “esta llamada debe ser bloqueada”; en ese contexto, el SBC debe terminar la llamada en lugar de avanzar a una ruta de respaldo. El comportamiento predeterminado de ProSBC de “continuar llamada” en 603 se anula explícitamente en implementaciones integradas con sistemas antifraude para que un 603 del servicio de puntuación detenga correctamente la llamada.

604 Does Not Exist Anywhere indica al llamante que la dirección de destino no está en servicio en ningún lugar de la red que responde. Es raro en SIP moderno porque 404 ha absorbido efectivamente su caso de uso.

606 Not Acceptable es la contraparte de falla global de 488 Not Acceptable Here. Indica que la sesión descrita en la solicitud no puede ser aceptada por ningún servidor, frecuentemente porque el codec o los parámetros de sesión están completamente fuera de lo que la red que responde admite.

En la práctica, las respuestas 6xx son más raras que las 4xx y 5xx. Cuando aparece una, debe tratarse como autoritativa: la solicitud no tendrá éxito en ninguna ruta de reintento.

Lectura de códigos de respuesta en una traza de producción

El comportamiento de retransmisión y reintento asociado a cada clase es lo que determina cómo se comporta realmente una llamada SIP en producción. Memorizar los códigos es la parte fácil; predecir cómo reaccionará el resto de la red a cada uno es la habilidad más difícil, y es la diferencia entre hacer resolución de problemas e ir a ciegas.

En transporte UDP, el agente de usuario del llamante retransmite el INVITE con un backoff exponencial (Timer A, comenzando en 500 ms) hasta que llega una respuesta provisional o final. El 100 Trying que envía el siguiente salto es lo que detiene la retransmisión. Si ve el mismo INVITE siete veces en una traza sin respuesta, está observando un problema de alcanzabilidad de transporte, no un problema SIP; el siguiente salto ni siquiera está procesando la solicitud. El transporte TCP y TLS no retransmiten porque la capa de transporte se encarga de la entrega, por lo que una llamada atascada en TCP se ve completamente diferente en una traza que una llamada atascada en UDP.

Las respuestas finales a un INVITE siempre requieren ACK. La forma del ACK depende de la respuesta: un ACK para un 2xx es de extremo a extremo y va en su propia transacción, mientras que un ACK para un 3xx a 6xx es salto a salto y forma parte de la transacción INVITE original. Un ACK faltante después de 200 OK es la razón más común del síntoma “la llamada contesta pero se corta después de unos segundos”, porque el terminal llamado terminará el diálogo cuando sus retransmisiones del 200 OK no sean confirmadas.

Las respuestas provisionales nunca requieren ACK. Un 1xx que queda sin respuesta no causa daño por sí solo, pero un 1xx que va seguido de silencio (sin respuesta final, sin más provisionales) es una señal fuerte de que algo downstream ha dejado de procesar. PRACK es la excepción en entornos que lo habilitan: un 1xx confiable (un 1xx con un encabezado Require: 100rel) sí necesita ser confirmado con PRACK.

La interacción entre 4xx y 5xx determina el avance de ruta. Un script de enrutamiento bien diseñado en un SBC trata los 5xx como “intentar la siguiente ruta”, trata la mayoría de los 4xx como “detenerse, esta llamada no puede tener éxito” y aplica excepciones por código para los casos complicados del mundo real (404 usado como autorización de fraude, 503 usado como rechazo por capacidad de un operador saludable, 603 usado para bloquear una llamada fraudulenta). Configurar correctamente estas excepciones es lo que marca la diferencia entre una implementación con un 5 % de llamadas fallidas pero reintentables y una con 0.1 %.

Cómo un SBC normaliza los códigos de respuesta entre dialectos

Cada operador y cada fabricante de PBX devuelve códigos de respuesta ligeramente diferentes para la misma condición subyacente. Un operador envía 503 cuando se alcanza el límite de sesiones; otro envía 486. Una PBX devuelve 480 cuando un usuario ha cerrado sesión; otra devuelve 404. Los terminales downstream de estas inconsistencias generalmente no son lo suficientemente inteligentes como para tratarlos como equivalentes, por lo que las llamadas fallan cuando deberían haber avanzado, y las llamadas que deberían haberse detenido avanzan y acumulan minutos contra destinos fraudulentos.

Esta es la parte de la interoperabilidad SIP donde un SBC demuestra su valor. Un SBC B2BUA como ProSBC ve la respuesta en el tramo entrante y genera una respuesta nueva en el tramo saliente, lo que significa que puede reescribir el código, cambiar qué decisión de enrutamiento desencadena y agregar o eliminar encabezados Reason según sea necesario. La función Reason Cause Mapping permite que cada NAP (grupo de troncales) anule el comportamiento predeterminado por código: 404 puede configurarse como “continuar llamada” para que la respuesta de autorización de un servicio de puntuación de fraude avance a la siguiente ruta; 603 puede configurarse como “detener llamada” para que la respuesta de bloqueo del mismo servicio de puntuación efectivamente la detenga; 302 puede configurarse como “procesar enrutamiento de llamada” para que una redirección de LCR sea consumida por el SBC en lugar de ser reenviada upstream; 503 puede configurarse como “continuar llamada” en una troncal primaria saludable para que un rechazo por capacidad realice el failover correctamente.

El mismo mecanismo maneja la traducción de dialectos entre fabricantes en la dirección más simple. Un 503 Service Unavailable downstream puede traducirse a un 486 Busy Here upstream cuando el sistema upstream maneja mejor el 486. Un 488 Not Acceptable Here puede normalizarse a un 415 Unsupported Media Type cuando una PBX más antigua espera 415. Un encabezado X propietario del fabricante que transporta información de causa adicional puede eliminarse, o a la inversa, puede inyectarse un encabezado Reason con un valor de causa Q.850 al hacer puente desde una pasarela TDM para que el operador SIP upstream vea el contexto completo de falla PSTN.

Este mismo control sobre los códigos de respuesta es lo que hace que la manipulación de encabezados SIP y la arquitectura B2BUA sean la respuesta correcta para interconexiones multi-vendor, Microsoft Teams Enrutamiento directo, y cualquier entorno donde tres o más operadores, dos o más fabricantes de PBX y una plataforma UCaaS necesiten interconectarse a través del mismo borde.

Referencia rápida de resolución de problemas

Los códigos que se encuentran con mayor frecuencia en la práctica, lo que realmente significan en producción y lo primero que se debe verificar cuando aparece cada uno:

401 / 407 (desafío de autenticación) significa que la solicitud necesita credenciales. Si el reintento con las credenciales aún falla, verifique que el realm en el desafío coincida con lo que el llamante está configurado para autenticar, y que el algoritmo de digest SIP (MD5 o SHA-256) sea compatible en ambos lados.

403 Forbidden después de la autenticación significa que una ACL o política está bloqueando la llamada. Verifique la IP de origen contra la ACL en el respondedor, y verifique la atestación STIR/SHAKEN si el operador requiere niveles mínimos de atestación.

404 Not Found significa que el número no existe o que el respondedor está usando 404 como una señal de “sin coincidencia.” Confirme que el número está aprovisionado y, si el respondedor es un servicio de puntuación de fraude, que 404 está mapeado a “continuar llamada” en el SBC.

408 Request Timeout significa que nada downstream respondió. Verifique primero la alcanzabilidad de transporte (¿está realmente abierto UDP/5060?) antes de asumir un problema a nivel SIP.

480 Temporarily Unavailable significa que el terminal existe y está rechazando la llamada en este momento. Verifique el temporizador de no-respuesta, el estado de no molestar o el estado de registro del destino.

486 Busy Here significa que el terminal llamado está en otra llamada. Si 486 aparece a escala en una sola troncal, sospeche que se están alcanzando los límites de sesiones y el operador está devolviendo 486 en lugar del más preciso 503.

487 Request Terminated no es una falla: es la contraparte de un CANCEL. Filtre 487 de las métricas de falla; repórtelo en llamadas abandonadas.

488 Not Acceptable Here es un problema de codec o SDP. Compare la lista de codecs ofrecidos con los codecs admitidos por el respondedor, y verifique si el SBC está forzando un codec que el downstream no admite.

503 Service Unavailable en el borde de una troncal casi siempre significa que el operador está sobrecargado o limitando la tasa. Confirme que el comportamiento de avance de ruta del SBC está configurado para hacer failover en 503; si no lo está, esta es la primera corrección.

603 Decline de un servicio de puntuación de fraude es una decisión de bloqueo. Confirme que el Reason Cause Mapping del SBC para 603 está configurado como “detener llamada” en ese NAP para que el bloqueo efectivamente termine la llamada.

Conclusión

Los códigos de respuesta SIP son un vocabulario pequeño y estructurado que transporta casi toda señal que un ingeniero de voz necesita para leer una llamada. Seis clases, menos de treinta códigos en uso regular en producción, y un conjunto coherente de reglas sobre cuáles códigos desencadenan retransmisión, cuáles requieren ACK, cuáles justifican avance de ruta y cuáles terminan la llamada definitivamente. Los códigos en sí son estables; lo que varía entre implementaciones es exactamente qué código devuelve cada fabricante para cada condición subyacente, y esa variación es precisamente donde el mapeo de códigos de respuesta de un SBC hace el trabajo de hacer que una red multi-vendor se comporte como un solo sistema coherente.

Para ingenieros de voz que construyen interconexiones de troncales SIP, implementan Teams Enrutamiento directo o resuelven problemas de llamadas fallidas en un entorno multi-operador, la fluidez en estos códigos (qué significa cada uno, qué comportamiento desencadena, cuándo un operador lo está usando de forma idiomática) es la base sobre la que se construye todo lo demás. El recorrido del flujo de llamada SIP complementario muestra los códigos en el contexto de una traza completa; este artículo es el diccionario que se mantiene abierto junto a él.