Cómo leer un SIP trace: guía práctica

Un SIP trace es el único registro honesto de lo que su red de voz realmente hizo. Los CDR mienten por omisión, los dashboards tienen retraso y los reportes de usuarios finales son de segunda mano. El trace es de primera mano, byte por byte. Sin embargo, la mayoría de los ingenieros abren uno y se quedan mirando 8 000 líneas de tráfico UDP durante media hora antes de encontrar el mensaje que explica la falla, mientras que un lector metódico llega al mismo punto en tres minutos.

Esta guía es un flujo de trabajo para profesionales, no una referencia de protocolo. Asume que usted ya sabe qué es un INVITE y qué significa un 486. Si no es así, el artículo complementario Flujo de llamada SIP explicado paso a paso recorre cada mensaje en una llamada típica, y Códigos de respuesta SIP: la guía completa cubre cada código en detalle. Lo que este artículo abarca es todo lo que sucede entre “abrir la captura” y “encontré la causa raíz”: de dónde provienen los traces, las herramientas que los hacen legibles, el método de cuatro pasos que lo lleva al mensaje decisivo rápidamente, los patrones que conviene reconocer primero y cómo empaquetar lo que encuentre en un ticket que el operador realmente resuelva.

Qué es realmente un SIP trace

La expresión “SIP trace” se usa para tres cosas diferentes, y confundirlas es lo que más tiempo desperdicia al inicio de una investigación. Un PCAP completo contiene cada byte en el cable, incluyendo encabezados TCP/UDP, RTP, RTCP y cualquier otra cosa que comparta la misma interfaz; es lo que producen tcpdump y Wireshark. Un SIP-only trace son los mismos datos filtrados para incluir solo los mensajes SIP, a menudo almacenados como un flujo HEP hacia una base de datos central, capturados por el registrador interno del SBC o exportados desde Wireshark con los frames no SIP eliminados. Un SIP log es una representación textual que una aplicación produjo desde su propio stack SIP, típicamente con marcas de tiempo y encabezados decodificados pero sin los paquetes subyacentes; útil para el estado pero no para patología a nivel de protocolo.

Para la mayoría de las fallas, el SIP-only trace es el artefacto adecuado: captura cada mensaje de señalización, permite correlacionar entre legs y evita la penalización de tamaño de los paquetes de audio. Para problemas de medios (audio en una sola dirección, voz entrecortada, DTMF en banda faltante), necesita el PCAP completo porque es el único lugar donde realmente vive el RTP. Para “no puedo determinar qué hizo el SBC”, el trace interno del propio SBC es imbatible, porque muestra el mensaje tal como el SBC lo recibió en un leg, las modificaciones aplicadas en el medio y el mensaje tal como salió por el otro leg, todo en un solo archivo.

El corolario es que cuando alguien le entrega un trace y le pide que lo revise, la primera pregunta es “¿qué tipo de trace y desde dónde en la ruta?” Una exportación SIP-only desde un softswitch nunca le mostrará un problema de RTP faltante, sin importar cuánto tiempo la observe.

Dónde capturar y con qué herramienta

Elegir el punto de captura importa más que elegir la herramienta. Capture donde se sospecha el problema, no donde sea conveniente. Si el operador insiste en que la llamada salió de su red limpiamente, capture en la interfaz del SBC que mira hacia el operador y demuestre el mensaje que llegó. Si una llamada de Teams Direct Routing está fallando en el ringback, capture en el leg del SBC que mira hacia Teams y observe qué envió Teams.

En Linux, tcpdump es el motor de captura predeterminado y escribe PCAP que cualquier herramienta puede leer. Un comando típico para un SBC con mucho tráfico es tcpdump -i any -s 0 -w trace.pcap, que captura tanto SIP sobre UDP como sobre TLS, además del rango RTP que el SBC tiene configurado. La bandera -s 0 deshabilita el truncamiento de snaplen para que se escriban paquetes completos; sin ella, un INVITE de 1500 bytes se recorta a 96 bytes y el cuerpo se pierde. En el propio SBC, la captura nativa casi siempre es preferible: ve el mensaje en la capa de aplicación, no solo en el cable, lo que significa que el SIP cifrado ya está descifrado y la correlación de legs B2BUA es automática.

Wireshark es el estándar con interfaz gráfica, y a pesar de la pronunciada curva de aprendizaje, es el visor más poderoso una vez que se conocen tres menús. sngrep es la herramienta correcta cuando solo se tiene SSH y una terminal; su interfaz ncurses muestra el tráfico SIP en vivo y diagramas de escalera sin necesidad de copiar un PCAP de vuelta a su computadora portátil. HOMER es la respuesta correcta para retención y búsqueda a través de una infraestructura: cada SBC y proxy envía SIP vía HEP a un nodo de captura central, y una sola interfaz web permite encontrar una llamada de ayer por número de teléfono, IP o Call-ID. ProSBC incluye un SIP trace integrado, una función de captura en vivo compatible con Wireshark y puntuación MOS por llamada, por lo que el propio SBC es el primer punto de captura para cualquier llamada que lo haya atravesado.

El flujo de trabajo de cuatro pasos para la lectura

Toda sesión productiva de lectura de traces sigue los mismos cuatro pasos en el mismo orden. Saltarse un paso generalmente lo deja adivinando.

Paso 1: delimitar al único dialog que le interesa

Un PCAP típico de un SBC en una ventana de cinco minutos puede contener cientos de dialogs. Intentar leer el archivo de principio a fin es el error más común. Filtre agresivamente. Si tiene el Call-ID, filtre directamente: en Wireshark, sip.Call-ID == "a84b4c76e66710@192.0.2.10". Si solo tiene un número de teléfono, sip.from contains "+15145551234" or sip.to contains "+15145551234" lo ubicará en segundos en la llamada. Una vez que tenga un paquete del dialog, haga clic derecho y seleccione “Follow” en la conversación SIP para extraer todo el intercambio en su propia ventana.

Si la llamada atravesó un B2BUA, este paso le da solo un leg. El leg complementario tiene un Call-ID diferente. Puede encontrarlo haciendo coincidir ambos por tiempo y número de teléfono, por el encabezado Contact que el SBC insertó, o revisando el trace interno del SBC donde la relación está registrada explícitamente.

Paso 2: clasificar la fase de la falla

Antes de leer cualquier mensaje en detalle, determine qué fase de la llamada falló. Las tres opciones son: establecimiento (cualquier cosa desde el INVITE inicial hasta el ACK final que confirma la conexión), mitad de llamada (después de que la sesión de medios está completamente establecida pero antes de un colgado intencional) y cierre (BYE y su respuesta). Las fallas de establecimiento son con diferencia las más comunes, y el diagrama de escalera le indica la fase de un vistazo: si nunca ve un 200 OK al INVITE, está en establecimiento; si ve 200 OK seguido de RTP y luego un BYE antes de lo esperado, está en mitad de llamada; si el BYE ocurre en el momento correcto pero la llamada aparece como fallida en el CDR, está en cierre o contabilidad posterior a la llamada.

Paso 3: leer el encabezado o código decisivo

Las fallas de establecimiento se resuelven con una de tres cosas casi siempre: el código de respuesta final, el cuerpo SDP del 200 OK (o su ausencia) y los encabezados de autenticación en cualquier 401 o 407. Un 488 Not Acceptable Here lo dirige al SDP; un segundo 401 o 407 consecutivo, o un 407 seguido de ningún segundo INVITE, apunta a un desajuste de autenticación o credenciales; un 408 sin ninguna respuesta provisional apunta al transporte. Las fallas de mitad de llamada se resuelven con el encabezado Reason del BYE o su ausencia, el timing del RTP y cualquier re-INVITE intermedio. Las fallas de cierre son inusuales; cuando ocurren, la numeración CSeq y los tags From/To le indicarán si está viendo el mismo dialog que el CDR cree que se cerró.

Paso 4: confirmar en los medios si es necesario

Si el trace indica que la llamada se conectó pero el usuario no escuchó nada, la señalización SIP es inocente y el RTP es el culpable. Abra Telephony → RTP → Stream Analysis en Wireshark, seleccione el stream para el leg en cuestión y observe el conteo de paquetes, el jitter y el delta. Cero paquetes recibidos con paquetes enviados distintos de cero es audio en una sola dirección causado por un problema de NAT. Paquetes constantes con ráfagas de delta de 60ms o más es jitter causado por buffering en algún punto anterior. Un stream que dura dos segundos y luego se detiene es un media gateway que falló a mitad de llamada. La señalización se ve bien en los tres casos.

Wireshark en la práctica

Tres menús llevan casi todo el peso analítico: VoIP Calls, Flow Sequence y la barra de display filter. Todo lo demás es decoración.

Telephony → VoIP Calls escanea la captura en busca de diálogos SIP y H.323 y los lista en una tabla con hora de inicio, duración, estado y códec. Este es el primer lugar al que ir con cualquier PCAP nuevo porque en cinco segundos le indica cuántas llamadas hay en el archivo, cuáles tuvieron éxito y cuáles fallaron. Al seleccionar una llamada y hacer clic en “Flow Sequence” se genera un diagrama de escalera que muestra cada mensaje SIP y stream RTP en orden cronológico, con marcas de tiempo y dirección de flechas. Esta vista por sí sola resuelve la mayoría de las preguntas de “¿qué pasó durante esta llamada?”.

El display filter es la palanca que convierte capturas de 8 000 paquetes en capturas de 30 paquetes. Los filtros que realmente valen la pena:

• sip muestra solo paquetes SIP.
• sip.Call-ID == "..." aísla un solo dialog.
• sip.Method == "INVITE" lista cada intento de llamada en el archivo.
• sip.Status-Code >= 400 lista cada falla.
• rtp muestra solo paquetes RTP; rtcp muestra los reportes de calidad.
• tcp.analysis.retransmission revela retransmisiones TCP cuando SIP corre sobre TCP.
• frame.time >= "2026-05-25 14:30:00" recorta por tiempo absoluto cuando se sabe aproximadamente cuándo ocurrió la falla.

Para análisis de RTP, Telephony → RTP → RTP Streams lista cada stream de audio que Wireshark detectó, con conteo de paquetes, jitter, paquetes perdidos y estimaciones MOS derivadas de esas métricas. Al hacer clic derecho en un stream y elegir “Analyze” se obtienen los valores de jitter y delta por paquete; “Play Streams” decodifica el audio cuando el códec es G.711, que es la forma más rápida de confirmar si el audio que llegó era realmente inteligible.

sngrep cuando solo tiene una terminal

Cuando lo único que lo separa del SBC es una sesión SSH, sngrep es la herramienta correcta. Ejecute sngrep sin argumentos y captura SIP en vivo desde todas las interfaces; ejecute sngrep -I trace.pcap y abre un archivo capturado previamente. La interfaz muestra una lista de dialogs en la parte superior, un diagrama de escalera para el dialog seleccionado en la parte inferior, y permite presionar Enter en cualquier mensaje para ver los encabezados completos. Todo el flujo de trabajo anterior (delimitar, clasificar, decidir el encabezado decisivo) funciona dentro de sngrep tan bien como en Wireshark, y la ventaja de latencia de trabajar directamente en el SBC es significativa cuando la alternativa es copiar un PCAP de varios gigabytes a través de una WAN.

La única limitación son los medios. sngrep es exclusivamente de señalización, por lo que cuando se necesita una investigación de RTP, hay que recurrir a un PCAP. La mayoría de los flujos de trabajo en producción utilizan ambos: sngrep para triaje rápido en el SBC, Wireshark para análisis más profundo una vez que se ha identificado una llamada específica.

Cinco patrones que conviene reconocer antes de leer encabezados

La mayoría de las fallas en producción coinciden con una de cinco firmas en el trace. Reconocer la firma primero ahorra el tiempo que de otro modo se gastaría leyendo cada encabezado en secuencia.

La tormenta de retransmisión aparece como solicitudes SIP idénticas repetidas con el mismo parámetro branch e intervalos de tiempo crecientes (500ms, 1000ms, 2000ms, 4000ms, 8000ms, 16000ms, 32000ms antes de que se active Timer B). Significa que el siguiente salto nunca envió una respuesta provisional. O el siguiente salto está caído, o un firewall está descartando silenciosamente la solicitud, o el siguiente salto la recibió pero no puede enrutarla.

La caída por Timer B a los 32 segundos es la consecuencia de la tormenta de retransmisión. El agente de usuario originante se da por vencido exactamente 32 segundos después del primer INVITE y devuelve 408 Request Timeout a la aplicación. Las llamadas que “timbran durante 32 segundos y luego fallan” sin llegar nunca al terminal llamado son casi siempre este patrón.

El bucle de autenticación aparece como INVITE, 401 Unauthorized (o 407 Proxy Authentication Required), segundo INVITE con un encabezado Authorization, seguido inmediatamente por una segunda respuesta 401 o 407 consecutiva. El destinatario está rechazando la credencial digest. Casi siempre se debe a una cadena de realm que no coincide entre el SBC y el proveedor upstream, o a un desfase de reloj que invalida el nonce.

El desajuste de códec aparece como INVITE con un SDP offer que lista varios códecs, 488 Not Acceptable Here, sin medios. Los dos lados no pudieron acordar un códec. O el SDP offer lista códecs que el destinatario no admite, o el destinatario está configurado para aceptar solo un códec que el originante no ofreció. La capacidad de transcodificación de un SBC correctamente configurado oculta este problema a ambos lados.

El audio en una sola dirección con señalización limpia aparece como una secuencia INVITE-200-ACK completa, RTP fluyendo en una dirección, sin RTP en la otra, y un BYE entre 30 y 90 segundos después cuando uno de los lados se da por vencido. El SIP trace es inocente. La causa casi siempre es un problema de NAT en la línea c= del SDP, un firewall asimétrico o una ruta de medios que nunca se abrió realmente en un lado.

Traces cifrados y el archivo key-log

Una llamada que corre sobre TLS en el puerto 5061 no es legible en Wireshark sin claves de descifrado. Hay tres formas de recuperar la legibilidad. La primera es capturar en un SBC que descifra el SIP en la capa de aplicación, lo que hace que el cifrado sea invisible para la herramienta de captura. La segunda es capturar en el cable y descifrar después usando un archivo TLS key-log, configurado mediante la variable de entorno SSLKEYLOGFILE en un cliente que lo soporte; Wireshark lee el log en Preferences → Protocols → TLS → “Pre-Master-Secret log filename”. La tercera es inspeccionar el punto intermedio no cifrado en un SBC B2BUA, que termina TLS en el ingreso y puede reiniciar TLS en el egreso; el trace del registrador interno del SBC ve el texto plano en el medio.

SRTP sigue el mismo principio. El intercambio de claves ocurre ya sea en el cuerpo SDP (SDES, donde la clave maestra está incrustada en texto plano dentro del mensaje SIP) o a través de DTLS-SRTP en la ruta de medios. Con SDES, un SIP trace no cifrado más la captura RTP correspondiente le dan todo lo necesario para decodificar el audio. Con DTLS-SRTP, sin key log no hay decodificación, y la captura interna del SBC es nuevamente el camino de menor resistencia.

La trampa del B2BUA: una llamada, dos traces

Un SBC B2BUA divide una sola llamada en dos diálogos SIP completamente independientes. El leg de ingreso tiene su propio Call-ID, From-tag, To-tag, contador CSeq y cadena Via; el leg de egreso tiene valores diferentes para cada uno de esos campos. Para Wireshark, los dos legs son diálogos no relacionados que casualmente comparten una ventana de tiempo y un número de teléfono.

Leer correctamente un trace de B2BUA significa correlacionar los legs explícitamente. Las señales que los vinculan son el encabezado Contact que el SBC inserta (la misma dirección del SBC aparece en ambos legs), el timing (el INVITE del segundo leg siempre sigue al INVITE del primer leg en unos pocos milisegundos) y los números de teléfono en las URI From y To. La fuente de correlación más limpia, cuando está disponible, es el log propio del SBC, que registra los Call-ID de ingreso y egreso uno al lado del otro y vuelca ambos legs en un solo archivo de trace. Una captura tomada en un solo leg aislado engañará a cualquier investigador que no esté familiarizado con la arquitectura, porque la mitad de la llamada parece faltar.

El mismo principio aplica a la manipulación de encabezados SIP: un encabezado que existe en el leg de ingreso puede haber sido reescrito, añadido o eliminado antes de aparecer en el leg de egreso. Si un sistema downstream afirma que nunca recibió un encabezado que usted puede ver en el trace de ingreso, el trace de egreso es el que resuelve la discusión.

Empaquetar evidencia para un ticket con el operador

La mitad del tiempo invertido en un SIP trace es para alguien más: el operador que abre un ticket P2, el equipo de soporte del proveedor de plataforma, el administrador de firewall que necesita pruebas de que su equipo está descartando tráfico. El formato de la evidencia determina si el ticket se resuelve hoy o queda en una cola durante una semana.

El artefacto correcto es un PCAP filtrado que contenga solo el dialog en cuestión. En Wireshark, el flujo de trabajo es File → Export Specified Packets, con “Marked packets only” o “Displayed packets” seleccionado después de que un display filter haya reducido la vista a un solo Call-ID. El archivo resultante típicamente pesa unos cientos de kilobytes, se abre limpiamente en cualquier herramienta compatible con SIP y no contiene nada que el destinatario no necesite.

Un buen adjunto de ticket incluye tres cosas. Primero, el PCAP filtrado a un solo dialog. Segundo, una anotación en texto plano que nombre el salto sospechoso, el mensaje sospechoso y el comportamiento sospechoso, en la forma “INVITE en el paquete 47 contiene códec G.729 en el SDP; la respuesta 488 en el paquete 49 indica que el operador no lo aceptó; por favor confirme si G.729 está soportado en este trunk.” Tercero, la hora, zona horaria y CDR ID de la llamada, para que el destinatario pueda correlacionar contra sus propios logs sin adivinar.

Anonimice cuando sea apropiado. Los números de teléfono y direcciones IP en traces reales de clientes son frecuentemente datos regulados, y un PCAP reenviado a un tercero lleva todo lo que la captura original vio. Herramientas como tcprewrite y los plugins de anonimización de Wireshark pueden reemplazar números y direcciones sin romper la estructura del mensaje SIP.

Preguntas frecuentes

Conclusión

Leer un SIP trace es principalmente cuestión de delimitar agresivamente, clasificar la fase de la falla antes de leer cualquier encabezado y reconocer las cinco firmas comunes para que el mensaje decisivo sea el tercero o cuarto que revise, no el cuadringentésimo. La herramienta que use importa menos que la disciplina del flujo de trabajo. Wireshark en una estación de trabajo, sngrep en un SBC, el trace integrado del propio SBC y una implementación central de HOMER para retención, todos leen los mismos datos subyacentes, y un operador con confianza se mueve entre ellos dependiendo de si la pregunta inmediata es sobre medios, señalización, historial o una disputa con un proveedor.