Flujo de llamada SIP explicado: guía paso a paso de cada mensaje

Cada llamada VoIP exitosa es una secuencia corta de mensajes SIP intercambiados en un orden estricto. Cuando algo falla (audio en un solo sentido, ausencia de tono de retorno, llamadas que se interrumpen a los cuatro minutos, llamadas que se completan con el códec incorrecto), la respuesta casi siempre es visible en esa secuencia. Leer una traza SIP es una habilidad fundamental para cualquier persona que diseñe, implemente o resuelva problemas en redes de voz, y el primer paso es saber exactamente cómo es cada mensaje, hacia dónde va y qué transporta.

Este artículo recorre cada mensaje en una llamada SIP típica, desde el INVITE inicial hasta el 200 OK de cierre del BYE, incluyendo la oferta/respuesta SDP que negocia la ruta de audio. Luego cubrimos los flujos de falla más comunes que encontrará en trazas de producción (ocupado, desafío de autenticación, CANCEL durante el timbre) y las modificaciones durante la llamada utilizadas para retención, cambios de códec y transferencia. Si prefiere primero una visión conceptual, el artículo complementario Fundamentos de señalización SIP cubre los roles del protocolo y la arquitectura a un nivel más alto.

Las tres fases de una llamada SIP

Cada llamada SIP pasa por tres fases, y cada mensaje que verá en una traza pertenece a una de ellas. Las fases son útiles porque se corresponden directamente con lo que debería estar ocurriendo en la red en un momento dado.

Establecimiento cubre los mensajes que crean el diálogo: INVITE, las respuestas provisionales (100, 180, a veces 183 con medios tempranos), el 200 OK final y el ACK que cierra el intercambio. Aproximadamente el 90 % de los problemas de llamadas aparecen en esta fase.

Intercambio de medios es el período después del ACK durante el cual los paquetes RTP fluyen directamente entre los terminales (o a través de un B2BUA que ancla los medios). No se intercambian mensajes SIP durante esta fase a menos que algo cambie en la sesión.

Desconexión cierra el diálogo con un BYE de cualquiera de las partes y un 200 OK confirmando la recepción. Una vez que ambos mensajes se intercambian, el diálogo deja de existir y cualquier mensaje posterior con el mismo Call-ID será rechazado.

Fase 1: establecimiento de llamada, mensaje por mensaje

Aquí es donde nace la llamada. Alice (en company.com) está llamando a Bob (en provider.com). Examinaremos cada mensaje en la red, encabezado por encabezado, para que pueda relacionar lo que ve en una traza con lo que el protocolo está haciendo realmente.

Paso 1: el INVITE

El teléfono de Alice construye un INVITE y lo envía hacia el dominio de Bob. La primera línea es la línea de solicitud, que nombra el método (INVITE), la URI de destino y la versión SIP. Los encabezados que siguen identifican a las partes, el diálogo, la ruta y el cuerpo.

INVITE sip:bob@provider.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bK776asdhds
Max-Forwards: 70
From: "Alice" <sip:alice@company.com>;tag=1928301774
To: "Bob" <sip:bob@provider.com>
Call-ID: a84b4c76e66710@192.0.2.10
CSeq: 314159 INVITE
Contact: <sip:alice@192.0.2.10:5060>
Content-Type: application/sdp
Content-Length: 142

Varios aspectos merecen atención. El encabezado From tiene un tag generado por el teléfono de Alice; el encabezado To aún no tiene tag porque el diálogo todavía no está establecido (el UAS de Bob agregará un To-tag en la respuesta). El parámetro branch del encabezado Via comienza con z9hG4bK, que es la cookie mágica que marca el mensaje como compatible con RFC 3261. El Call-ID permanece constante durante toda la vida del diálogo. El CSeq comienza en un entero arbitrario y se incrementa con cada nuevo método de solicitud dentro del diálogo.

Paso 2: 100 Trying

El siguiente salto responde casi inmediatamente con un 100 Trying provisional. Este es un acuse de recibo salto a salto, no de extremo a extremo, y su único propósito es detener la retransmisión del INVITE por parte del teléfono de Alice mientras el siguiente salto procesa la solicitud.

SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bK776asdhds
From: "Alice" <sip:alice@company.com>;tag=1928301774
To: "Bob" <sip:bob@provider.com>
Call-ID: a84b4c76e66710@192.0.2.10
CSeq: 314159 INVITE
Content-Length: 0

Observe que Via, From, To, Call-ID y CSeq se copian de la solicitud. El enrutamiento SIP depende de esta consistencia: la respuesta viaja de regreso a través de la misma cadena Via en orden inverso, y los encabezados coincidentes vinculan la respuesta con la solicitud que contesta. Un 100 Trying nunca llega a la pantalla del llamante, y no existe ACK para ninguna respuesta 1xx.

Paso 3: 180 Ringing

Una vez que el INVITE llega al teléfono de Bob, el dispositivo comienza a alertar (el teléfono suena) y envía de vuelta un 180 Ringing. Este es el mensaje que activa el tono de retorno en el lado de Alice.

SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bK776asdhds
From: "Alice" <sip:alice@company.com>;tag=1928301774
To: "Bob" <sip:bob@provider.com>;tag=314259
Call-ID: a84b4c76e66710@192.0.2.10
CSeq: 314159 INVITE
Contact: <sip:bob@198.51.100.20:5060>
Content-Length: 0

El encabezado To ahora tiene un tag agregado por el UAS de Bob (tag=314259). A partir de este punto, la combinación de Call-ID, From-tag y To-tag identifica de forma única el diálogo. Una variante de este paso es 183 Session Progress, que transporta una respuesta SDP y se utiliza para entregar medios tempranos (tono de retorno dentro de banda o anuncios de la red antes de que la llamada sea contestada).

Paso 4: 200 OK

Cuando Bob contesta, su teléfono envía un 200 OK con su propia respuesta SDP. Este es el mensaje más importante de todo el flujo: acepta la llamada y fija los parámetros de medios.

SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bK776asdhds
From: "Alice" <sip:alice@company.com>;tag=1928301774
To: "Bob" <sip:bob@provider.com>;tag=314259
Call-ID: a84b4c76e66710@192.0.2.10
CSeq: 314159 INVITE
Contact: <sip:bob@198.51.100.20:5060>
Content-Type: application/sdp
Content-Length: 139

v=0
o=bob 2890844527 2890844527 IN IP4 198.51.100.20
s=-
c=IN IP4 198.51.100.20
t=0 0
m=audio 49170 RTP/AVP 0 8
a=rtpmap:0 PCMU/8000

El cuerpo después de la línea en blanco es el SDP. La línea m=audio declara que Bob recibirá audio en el puerto UDP 49170 y admite los códecs 0 (PCMU) y 8 (PCMA). La línea c= proporciona la dirección IP. El teléfono de Alice comenzará a enviar RTP a 198.51.100.20:49170 tan pronto como procese este mensaje.

Paso 5: ACK

El teléfono de Alice confirma el 200 OK con una solicitud ACK. El ACK es único en SIP porque es una solicitud que cierra una transacción en lugar de abrir una.

ACK sip:bob@198.51.100.20:5060 SIP/2.0
Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bK4321
Max-Forwards: 70
From: "Alice" <sip:alice@company.com>;tag=1928301774
To: "Bob" <sip:bob@provider.com>;tag=314259
Call-ID: a84b4c76e66710@192.0.2.10
CSeq: 314159 ACK
Content-Length: 0

Dos detalles merecen atención. El número CSeq permanece en 314159 (coincide con el INVITE), pero el método cambia a ACK. La Request-URI ahora es la dirección Contact de Bob del 200 OK en lugar del original sip:bob@provider.com, porque el ACK viaja directamente al terminal de Bob, sin pasar por los proxies que pudieron estar en la ruta original. El diálogo está ahora completamente establecido.

El modelo de oferta/respuesta SDP

SIP solo negocia la llamada. Los medios reales utilizan RTP, y los parámetros de esa sesión RTP se negocian dentro de los cuerpos SDP transportados por los mensajes SIP. El mecanismo se llama oferta/respuesta, definido en la RFC 3264.

El INVITE de Alice transporta una oferta SDP que enumera cada códec que su teléfono admite, en orden de preferencia. El 200 OK de Bob transporta una respuesta SDP que enumera solo los códecs que está dispuesto a utilizar, en el orden que prefiere, más la dirección IP y el puerto donde desea recibir RTP. La intersección de esas dos listas es el códec que la llamada utilizará realmente.

Una oferta simple podría verse así:

m=audio 49172 RTP/AVP 0 8 9 18
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:18 G729/8000
a=sendrecv

Alice ofrece G.711 µ-law (0), G.711 A-law (8), G.722 (9) y G.729 (18). La respuesta de Bob reduce la lista a un solo códec, típicamente la opción de mayor prioridad en la lista de preferencia de Bob que también está en la oferta de Alice. El atributo a=sendrecv indica que los medios son bidireccionales; otros valores incluyen sendonly, recvonly e inactive, que se vuelven importantes durante la retención de llamada.

Dos fallas comunes residen en el SDP. La primera es la ausencia de coincidencia entre las listas de códecs ofrecidos, lo que produce una respuesta 488 Not Acceptable Here y la llamada nunca se conecta. La segunda es un problema de NAT (Network Address Translation) donde la dirección c= dentro del SDP es una IP privada que el otro lado no puede alcanzar, lo que produce una llamada conectada sin audio en una o ambas direcciones. Un SBC resuelve ambos problemas al normalizar el SDP antes de reenviarlo.

Fase 2: flujo de medios sobre RTP

Una vez que se envía el ACK, el diálogo SIP queda en silencio y RTP toma el control. Los paquetes RTP son pequeños datagramas UDP que transportan 20 ms de audio codificado cada uno, fluyendo cada 20 ms en cada dirección. Para una llamada establecida de 30 minutos sin modificaciones, puede esperar aproximadamente 180 000 paquetes RTP en total y exactamente cero mensajes SIP.

RTP se ejecuta junto con RTCP (RTP Control Protocol), que transporta reportes de calidad en un puerto separado (generalmente el puerto RTP + 1). Los paquetes RTCP son la forma en que los terminales intercambian estadísticas de fluctuación de fase (jitter), pérdida de paquetes y retardo de ida y vuelta. Muchos SBC utilizan los datos RTCP para generar puntuaciones MOS y alertas de calidad de llamada, aunque no generen el audio por sí mismos.

Algo que suele sorprender a los ingenieros nuevos es que RTP es solo un protocolo de transporte y no tiene concepto del diálogo SIP. Si un teléfono deja de recibir RTP, no tiene forma a nivel SIP de saber si el otro lado colgó, se congeló o simplemente perdió conectividad de red. Por esta razón, la mayoría de los agentes de usuario implementan un temporizador de sesión (RFC 4028): envían periódicamente un re-INVITE o UPDATE durante llamadas largas para confirmar que el diálogo sigue activo. Si la actualización falla, el lado que detectó la falla termina la llamada con un BYE.

Fase 3: desconexión de la llamada con BYE

Cuando cualquiera de las partes cuelga, ese lado envía un BYE dentro del mismo diálogo.

BYE sip:bob@198.51.100.20:5060 SIP/2.0
Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bK998
Max-Forwards: 70
From: "Alice" <sip:alice@company.com>;tag=1928301774
To: "Bob" <sip:bob@provider.com>;tag=314259
Call-ID: a84b4c76e66710@192.0.2.10
CSeq: 314160 BYE
Content-Length: 0

El CSeq ha avanzado en uno (ahora 314160) porque BYE es una nueva solicitud dentro del diálogo. El otro lado responde con 200 OK confirmando el BYE. RTP se detiene en ambas direcciones, y el estado del diálogo se destruye en ambos terminales. Cualquier mensaje SIP posterior que porte este Call-ID producirá un 481 Call/Transaction Does Not Exist.

Haga clic para ampliar.

Cuando la llamada no se conecta: escenarios de falla

La mayoría de las llamadas en el mundo real son exitosas, pero cuando fallan, el modo de falla generalmente sigue uno de cuatro patrones comunes. Reconocer el código de respuesta en la red le indica inmediatamente qué investigar.

Desafío de autenticación: 401 o 407

Si el siguiente salto requiere autenticación (un proveedor de SIP Trunking, una PBX empresarial con registro obligatorio), responde al primer INVITE con un 401 Unauthorized (cuando el propio terminal desafía) o 407 Proxy Authentication Required (cuando un proxy intermediario desafía). El desafío incluye un encabezado WWW-Authenticate o Proxy-Authenticate que contiene un realm y un nonce.

El agente de usuario del llamante entonces envía un segundo INVITE con el mismo Call-ID pero un CSeq incrementado, portando un encabezado Authorization que contiene un digest calculado a partir del nonce, la URI y el secreto compartido. Si el digest se verifica correctamente, el flujo continúa normalmente con 100 Trying, 180 Ringing y 200 OK. Si falla, un 403 Forbidden termina el diálogo. Las cadenas de realm que no coinciden entre el SBC y el proveedor upstream son una de las causas más comunes de los tickets “el registro funciona pero las llamadas fallan”.

Ocupado: 486

Un 486 Busy Here significa que el terminal llamado está en otra llamada y no puede aceptar esta. El diálogo termina inmediatamente, y el agente de usuario del llamante típicamente reproduce un tono de ocupado. Un 600 Busy Everywhere indica que el usuario está globalmente no disponible, lo que termina los intentos de bifurcación en cualquier proxy de reenvío.

Sin respuesta: 408 o 480

Si Bob nunca contesta, la llamada termina de una de dos maneras. Un 480 Temporarily Unavailable es enviado por el propio teléfono de Bob cuando el temporizador de timbre expira (generalmente después de 30 a 60 segundos). Un 408 Request Timeout es generado por la red si no llega ninguna respuesta de ningún tipo dentro del Timer B (32 segundos por defecto para UDP). Cada uno cuenta una historia diferente: 480 significa que la llamada llegó al terminal y fue rechazada por la política del terminal; 408 significa que la llamada nunca obtuvo una respuesta utilizable de ningún elemento downstream.

CANCEL: el llamante cuelga mientras suena

Si Alice cuelga mientras todavía escucha el tono de retorno (antes de que el teléfono de Bob conteste), su agente de usuario envía un CANCEL que referencia el mismo parámetro branch del INVITE original. CANCEL es una solicitud, no una respuesta. El lado de Bob responde con dos mensajes: un 200 OK al CANCEL mismo, y un 487 Request Terminated al INVITE original. El agente de usuario de Alice confirma el 487 con un ACK, y el diálogo se destruye antes de haberse establecido completamente. Interpretar erróneamente un flujo CANCEL como una llamada fallida es una fuente frecuente de métricas ASR incorrectas en el análisis de CDR sin procesar.

Cambios durante la llamada: re-INVITE, UPDATE y REFER

Una vez que el diálogo está establecido, la llamada no queda congelada. Cualquiera de las partes puede enviar una nueva solicitud dentro del diálogo existente para modificar la sesión. Tres métodos realizan la mayor parte del trabajo.

Un re-INVITE es el caballo de batalla. Utiliza el mismo Call-ID, From-tag y To-tag que el INVITE original, pero transporta una nueva oferta SDP. El uso más común es la retención de llamada: la parte que retiene envía un re-INVITE con la línea de medios modificada (a=sendonly, o la IP de conexión configurada a 0.0.0.0 en implementaciones más antiguas), la parte retenida devuelve un 200 OK con la respuesta correspondiente, y el audio se detiene en una dirección hasta que un segundo re-INVITE lo restaura. Los re-INVITE también se utilizan para la renegociación de códec (cambiar de G.711 a G.729 cuando las condiciones de la red se degradan) y para el cambio SIP de voz a T.38 cuando se detecta un fax.

UPDATE es similar al re-INVITE pero está diseñado para modificar la sesión antes de que esté completamente establecida (durante el estado de diálogo temprano después de un 180 Ringing). Es ampliamente utilizado por algunos operadores para actualizar temporizadores de sesión y detalles SDP sin esperar a que la llamada sea contestada.

REFER implementa la transferencia de llamada. La parte que transfiere envía un REFER al otro lado que contiene un encabezado Refer-To con el nombre del destino de transferencia. El lado receptor envía un NOTIFY de vuelta a medida que la transferencia progresa, indicando si la nueva llamada se conectó. Tanto la transferencia atendida (consultar primero, luego transferir) como la transferencia ciega (transferir inmediatamente) utilizan REFER; la diferencia es simplemente si el que transfiere ya ha establecido un segundo diálogo con el destino.

Lo que hace un SBC en cada paso

Un SBC se ubica en el medio de este flujo como un B2BUA, lo que significa que la llamada que se ve en un lado no es el mismo diálogo SIP que la llamada en el otro lado. Para Alice, el SBC parece ser Bob; para Bob, el SBC parece ser Alice. Existen dos diálogos independientes, cada uno con su propio Call-ID, From-tag, To-tag y contador CSeq, unidos por la lógica de enrutamiento interna del SBC.

Esta arquitectura cambia lo que cada mensaje del flujo puede hacer. En el INVITE, el SBC puede reescribir encabezados para coincidir con las expectativas del sistema downstream (aquí es donde reside la manipulación de encabezados SIP), eliminar direcciones IP privadas de Via y Contact para la ocultación de topología, y aplicar limitación de tasa o reglas contra fraude antes de reenviar. En el 200 OK, el SBC reescribe el SDP para que los medios fluyan a través del SBC en lugar de directamente entre los terminales, lo que le da la capacidad de transcodificar códecs (G.711 a G.729, o AMR a G.711 en interconexiones de móvil a fijo), aplicar cifrado SRTP y monitorear la calidad de cada paquete RTP.

En los flujos de falla, el SBC puede traducir códigos de respuesta entre dialectos: un 503 Service Unavailable downstream podría traducirse a un 486 Busy Here upstream para mantener un comportamiento de reintento razonable. En los re-INVITE para retención o cambios de códec, el SBC puede optar por pasarlos, terminarlos en su propio lado y absorber el cambio, o activar ajustes de transcodificación. En un CANCEL, el SBC propaga la cancelación downstream para que la parte llamada deje de alertar, y luego limpia ambos tramos.

El resultado práctico es que un SBC correctamente configurado elimina la mayor parte de la variabilidad que de otro modo vería entre implementaciones SIP. Dos proveedores que no pueden interconectarse directamente lo harán a través del SBC, porque el SBC normaliza el flujo de llamada en cada tramo para coincidir con lo que ese tramo espera.

Conclusión

El flujo de llamada SIP es corto, determinista y visible. Cinco mensajes llevan una llamada desde la marcación hasta la conversación (INVITE, 100 Trying, 180 Ringing, 200 OK, ACK), dos mensajes la desconectan (BYE, 200 OK), y un puñado de respuestas de falla cubren casi todos los problemas del mundo real. Dentro de los cuerpos, la oferta/respuesta SDP maneja la negociación de medios, y el audio mismo fluye sobre RTP en un canal separado que SIP nunca toca.

Saber qué transporta cada mensaje, en qué orden, y qué cambia entre solicitud y respuesta es la diferencia entre adivinar una traza SIP y leerla. Para ingenieros que integran troncales SIP, resuelven fallas durante la llamada, o diseñan interconexiones multi-proveedor, esta fluidez es el fundamento sobre el que se construye todo lo demás.