Wireshark: Captura conversaciones VoIP - Protocolo SIP, SDP y RTP - Extracción de audio.

Es posible, tratándose de instalaciones VoIP no seguras, la captura de paquetes VoIP (emisión de voz enpaquetes IP) y la extracción de conversaciones contenidas en este tipo de conexiones.

En este artículo vamos a usar una captura .pcap conteniendo una conversación usando el protocolo SIP(Session Initiation Protocol), un protocolo de señalización, similar a HTML y SMTP, encargado de la localización usuarios, parámetros, modificaciones e iniciar o finalizar una sesión. Los datos de audio serán transportados mediante el protocolo de transporte RTP (Real Time Transport Protocol) usando UDP. SIPencapsula otro protocolo: SDP, que es el encargado de la negociación de las capacidades de los participantes, tipo de codificación usados y otros aspectos. 

Usaremos, como siempre, Wireshark para analizar la captura .pcap e ilustrar todos los aspectos comentados de SIP, SDP y RTP, además de la extracción del audio de las conversaciones.

Breve introducción a SIP, SDP y RTP.

Vamos a ver una breve descripción de SIP, SDP y RTP para la mejor compresión de los datos de las capturas.

SIP (Session Initiation Protocol), como hemos comentado, es un protocolo que provee mecanismos para la creación, modificación y finalización se sesiones, en esta caso VoIp.SIP funciona en combinación con SDP que es el encargado de la negociación de capacidades multimedia de los participantes involucrados, ancho de banda, negociación de los codecs, etc.

Al ser SIP un protocolo solo de señalización, solo entiende del establecimiento, control y la terminación de las sesiones.

Es un protocolo simple, escalable y se integra con facilidad en otros protocolos. SIP puede funcionar sobre UDP o TCP, aunque para VoIP se usará sobre UDP. Una vez establecida la sesión, los clientes intercambian directamente los contenidos multimedia de audio y/o video a través de, en este caso, RTP (Real-Time Transport Protocol).

SIP tiene una estructura parecida a HTML y SMTP. Esto lo vemos, por ejemplo, en que los clientes involucrados en una conexión tiene direcciones del tipo:

usuario@dominio 

SIP contiene una serie de componentes.:

• Agente de Usuario. (user agent client y user agent server)
• Agente de Redirecciones
• Servidor Proxy
• Servidor de Registro.
• Servidor de Localización.

Dentro de las cabeceras SIP, podemos encontrar una serie de mensajes SIP para las sesiones. Están en formato ASCII.

Los mensajes más comunes son:

• INVITE. Tipo Request. Para establecer una sesión entre agentes de usuario. contiene información sobreu suario origen y destino y tipo de datos (audio, video). contiene mucha más información. Lo veremos en las capturas Wireshark.
• ACK. Para la confirmación de un establecimiento de sesión. Un mensaje ACK puede ser, como vemos más abajo, un código 200 Ok de éxito.
• OPTION. Un Request o solicitud de información de capacidades
• BYE. Se usa para la liberación o terminación de una sesión establecida. BYE puede ser emitido tanto por el usuario que genera una llamada o el que la recibe.
• CANCEL. Cancela una petición pendiente sin influir en la sesión o llamada establecida y acpetada.
• REGISTER. Es usado por un user agente o agente usuario para el registro de dirección SIP e IP o dirección de contacto. Relacionado con la ubicación de los usuarios.

De igual forma tenemos una serie de códigos correspondientes a las repsuestas a los mensajes SIP:

• 1xx. Mensajes de información. Provisionales (100 Trying)
• 2xx. Respuesta de Exito. Se recibió el requerimento y es acpetado. (200 Ok)
• 3xx. Respuesta de redirección. Se requiere de otros procesamientos antes de determinar si es posible la llamada. (302 Moved Temporaly) o (305 Utiliza Proxy).
• 4xx. Respuesta de fallo en petición o fallo del cliente. (404 Not Found)
• 5xx. Respesta de fallos en servidor a pesar de tratarse de un requerimiento valido.  (504 Server Time-out) o (503 Servicio no disponible)
• 6xx. Respuesta de fallos globales. (603 Decline)

El protocolo RTP.

Una vez establecida la sesión, los datos en tiempo real de voz y/o áudio se realiza usando el protocolo RTP. RTP “viaja” sobre UDP para obtener mayor velocidad (estamos hablando de un protocolo para tiempo real). Eso sí, perdemos la fiabilidad que si tieneTCP.

Se encarga de los números de secuencia, marcas de tiempo y origen de los datos y llegada de estos. Provee información para la detección de paquetes perdidos.

La cabecera RTP indica al receptor como reconstruir los datos y
describe como se han codificado el flujo de bits.

No garantiza el envio ni orden de los paquetes ni calidad del servicio. Está encapsulado enUDP.

Contiene información del tipo de carga útil Payload y compresión de los datos, ed decir, codecs de audio/video.

Analizando los paquetes.

Biuen, vamos ahora a abrir el archivo .pcap de captura de una sesión  conversación VoIP y analizar los paquetes SIP / SDP y RTP.

NOTA: Esta captura la he obtenido de un repositorio público de ficheros .pcap

Paquete nº1

El paquete número uno corresponde a un mensaje SIP de tipo Request, concretamenteINVITE que, como ya hemos visto, se refiere al establecimiento de llamada o sesión.

Señalado en un recuadro rojo tenemos el Request-Line o tipo de mensaje. Tipo de mensaje INVITE. Mensaje SIP dirigido a francisco@bestel.com. Vemos también laversión SIP que es SIP/2.0. El puerto de destino es 55060.

Ahora tenemos el Message Header o cabecera que contiene:

• Via. Campo que usado para el registro de ruta.De esta forma la respuesta al  seguirá el mismo camino que el Request o petición INVITE. Contiene también en trasporte usado (SIP/UDP) y el branch o identificación de la transacción.
• From. Cliente que realiza la llamada o petición.
• To. Cliente al que se realiza la petición.
• Call-ID. Identificador únicio de la sesión. Identifica a los mensajes que corresponden a la misma llamada.
• C-Seq. Número de secuencia.
• Contact. URI SIP Contact address. Contiene la IP y puerto donde el realiza la peticiónINVITE espera recibir resupesta.

Message Body o cuerpo del mensaje contiene el Session Description Protocol SDP con los siguientes campos:

• Versión de Session Description Protocol. SDP. En este caso 0
• Propietario/Creador de la sesión o Owner/Creator. Se trata de una identificación formada por:

• Owner username. Usuario.
• Session ID. ID de la sesion. Número aleatorio como identificador único de la sesion.
• Session Version. Versión.
• Network Type. Tipe de red. Siempre IN.
• Address Type. Tipo de dirección. Puede ser IP4 (IPv4) o IP6 (IPv6).
• Address (IP). Dirección IP. (200.57.7.197)
• Session Name. Nombre de la sesión.

• Connection Information. Información sobre la conección. Contiene información ya contenida en los campos anteriores como:

• c= Conection Network Type: (IN)
• Connection Address Type: (IP4 o IPv4)
• Connection Address: (200.57.7.197)

• Time Description, active time. Aquí se indica el inicio y final de la sesión. En este caso tenemos (t): 0 0, es decitstart time= o y stop time = 0. Significa  sesión no limitada y permanente.
• Media Description, name and address (m): audio 40376 RTP/AVP 8 18 4 0. Aquí tenenemos información sobre el tipo de datos que se transporta (audio o sesión telefónica en este caso), el puerto UDP usado (40376), el protocolo usado (RTP  Real Time Transport Protocol /AVP Audio video Profiles). Y por último, los formatos de codecs:
• 8 G.711 PCMA
• 18 G.729
• 4 G.723
• 0 G.711 PCMU
• Media Attribute (a). Se trata de una lista de los formato de codes reseñados más arriba con información de Sample rate o frecuencia de muestreo, Fieldname, etc.
• Media Attribute (a). SendRecv. Modo envio/recepción.

Paquete nº2

El paquete nº 2 corresponde a un mensaje de respuesta de información de estado. Se informa, tal como dice su código 100, de que se está tratando la información:

Se observa el Status-Code: 100

En el Message Header tenemos la misma información que el Message Header del paquete número 1.

Paquete nº3

En el paquete nº 3 tenemos un mensaje también de mensaje de respuesta de información de estado. Se informa que el INVITE fue recibido por la otra parte. Digamos que se está Rinnging (llamando) y se espera a que atienda la llamada:

Vemos que en los paquetes 2 y 3, en el campo To, hay un Tag=298852044 que no estaba en el paquete nº 1.  Es el mismo e identifica a la sesión.

===========================

Bien, aún nos quedan algunos paquetes más por ver. Lo veremos en la siguiente y última parte. Ahora vamos a ver como con Wireshark podemos extraer la información de audio y otros datos de la captura.

Extracción del audio con Wireshark.

Si establecemos como filtro el protocolo rtp, veremos solo los paquetes correspondientes a dicho protocolo. Ya hemos visto más arriba para que sirve RTP.

Observamos uno de estos paquetes (lo veremos con más profundidad más adelante):

Vemos en el campo Payload Type o tipo de carga que se trata de  de ITU-T G.711 PCMA (8), es decir usa el códec audio G.711, estandarizado por ITU (International Telecom. Union). Frecuencia de muestreo 8KHz y usa para comprimir/descomprimir PCMA.

Nos situamos sobre este paquete y en el menú Telephony > VoIP Calls, nos aparece una ventana:

Se trata de una lista de las llamadas incluidas en la captura. Tenemos una serie decolumnas con información de cada llamada:

• Start Time. Marca de tiempo en inicio de la llamada.
• Stop Time. Marca de tiempo de inde de llamada.
• Initial Speaker. Dirección IP del que inicia la llamada.
• From. Campo From del que realiza la petición INVITE.
• To. Campo To de la petición INVITE.
• Protocol. Protocolo usado. (SIP en nuestro caso)
• Packets. Número de paquetes correspondientes a la llamada.
• State. Estado de la llamada. En nustre caso tenemos IN CALL (llamada en curso) yCALL SETUP (llamada en estado de proceso o setup. En este caso trámites deINVITE, etc.)
• Comments. Comentarios.

Nos situamos en el segudo item correspondiente al CALL SETUP y pulsamos Graph:

Aquí, como veis,  tenemos un análisis gráfico de la conversación mantenida entre quien realiza la petición INVITE y las dos respuestas correspondentes a los paquetes 1 y 2 que ya hemos visto.

Si hacemos lo mismo con el primer Item  correspondiente al IN CALL, vereis, a parte de los paquetes 1,2 y3 , la conversación RTP de transporte del audio de la conversación. Es este itrem el que nos interesa.

Cerramos la ventena de análisis gráfico y sobre la ventana VoIP Calls, pulsamos el botón Player en el Item 1. Sobre la ventana que nos aparece pulsamos Decode y obtenemos:

Tenemos dos pistas de audios que corersponden a cada uno de los usuarios involucrados en la conversación. Si marcamos una pista uno y pulsamos Playoiremos el audio de la conversación. Pulsando ambas pistas escucharemos toda la conversación.

====

Hasta aquí por hoy. En el próximo capitulo veremos los paquetes RTP en profundidad  y otros paquetes SIP como REGISTER.

Fuente: https://seguridadyredes.wordpress.com/2010/04/05/wireshark-captura-conversaciones-voip-protocolo-sip-sdp-y-rtp-extraccion-de-audio/

Angel J. Reynoso
kp01 
Tel.: 829-997-4870
kp01aj@gmail.com