El material del artículo fue tomado de mi .
Estructura del paquete RTP
En el anterior hemos realizado TShark la captura de paquetes RTP que intercambiaron nuestro receptor y transmisor. En esta, colorearemos los elementos del paquete en diferentes colores y hablaremos sobre su función.
Veamos el mismo paquete, pero ya con los campos coloreados y con las leyendas explicativas:
En la parte inferior del listado están coloreados los bytes que componen el paquete RTP, el cual a su vez es la carga útil del paquete UDP (su encabezado está rodeado por una línea negra). Los bytes del encabezado RTP están señalizados con colores de fondo, y en verde se destaca el bloque de datos que contiene la carga útil del paquete RTP. Los datos se presentan en formato hexadecimal. En nuestro caso, se trata de una señal de audio comprimida por ley u (ley mu), es decir, cada muestra tiene un tamaño de 1 byte. Dado que usamos la tasa de muestreo predeterminada (8000 Hz), a una frecuencia de paquetes de 50 Hz, cada paquete RTP debe contener 160 bytes de carga útil. Esto es lo que veremos al contar los bytes en el área verde, deberían ser 10 líneas.
Según el estándar, la cantidad de datos en la carga útil debe ser un múltiplo de cuatro, o, en otras palabras, debe contener una cantidad entera de palabras de cuatro bytes. Si sucede que su carga útil no cumple con esta regla, se deben agregar bytes con valores cero al final de la carga útil y establecer el bit de Padding (Relleno). Este bit se encuentra en el primer byte del encabezado RTP, que está coloreado en color turquesa. Tenga en cuenta que todos los bytes de la carga útil tienen un valor de 0xFF: así es como se ve el silencio en el formato u-law.
El encabezado del paquete RTP consta de 12 bytes obligatorios, pero en dos casos puede ser más largo:
Cuando el paquete transporta una señal de audio obtenida al mezclar señales de varias fuentes (flujos RTP), entonces, después de los primeros 12 bytes del encabezado, se encuentra una tabla con la lista de identificadores de fuentes cuyas cargas útiles se utilizaron para crear la carga útil de este paquete. En este caso, en los cuatro bits menos significativos del primer byte del encabezado (campo Conteo de identificadores de fuentes contribuyentes) se indica la cantidad de fuentes. El tamaño del campo es de 4 bits, por lo que la tabla puede contener hasta 15 identificadores de fuentes. Cada uno ocupa 4 bytes. Esta tabla se utiliza para organizar conferencias.
Cuando el encabezado tiene extensión. En este caso, el primer byte del encabezado establece un bit. X. En el encabezado extendido, después de la tabla de participantes (si los hay), se coloca el encabezado de extensión de un tamaño de una palabra, seguido de las palabras de extensión. La extensión es un conjunto de bytes que puedes utilizar para transmitir datos adicionales. El estándar no especifica el formato de estos datos, puede ser cualquiera. Por ejemplo, pueden ser configuraciones adicionales para el dispositivo que recibe los paquetes RTP. Sin embargo, para algunas aplicaciones, se han desarrollado estándares de encabezados extendidos. Esto se hizo, por ejemplo, para los medios de comunicación en el estándar ED-137 (Normas de interoperabilidad para componentes de VoIP ATM).
Ahora examinemos los campos del encabezado con más detalle. A continuación se muestra una imagen canónica con la estructura del encabezado RTP, que también he decorado con los mismos colores.
VER — número de versión del protocolo (la versión actual es 2);
P — un flag que se establece en los casos en que el paquete RTP se complementa con bytes vacíos al final;
X — un flag que indica que el encabezado es extendido;
CC — contiene el número de identificadores CSRC que siguen al encabezado fijo (después de las palabras 1..3), en la ilustración la tabla no se muestra;
M — marcador de inicio de cuadro o de presencia de voz en el canal (si se utiliza un detector de pausas en la voz). Si el receptor no contiene un detector de pausas en la voz, este bit debe estar siempre establecido;
PTYPE — indica el formato de la carga útil;
Número de secuencia — número de paquete, se utiliza para restaurar el orden de reproducción de los paquetes, ya que en la realidad los paquetes pueden llegar al receptor en un orden diferente al que fueron enviados. El valor inicial debe ser aleatorio, esto se hace para que, si se aplica cifrado al flujo RTP, sea más difícil descifrarlo. Además, este campo permite detectar pérdida de paquetes;
Timestamp — marca de tiempo. El tiempo se mide en muestras de señal, es decir, si un paquete contiene 160 muestras, la marca de tiempo del siguiente paquete será mayor en 160. El valor inicial de la marca de tiempo debe ser aleatorio;
SSRC — identificador de origen del paquete, debe ser único. Lo mejor es generarlo de forma aleatoria antes de iniciar la transmisión RTP.
Si vas a desarrollar tu propio transmisor o receptor de paquetes RTP, tendrás que revisar tus paquetes varias veces; para aumentar la eficiencia, te recomiendo aprender a usar el filtrado de paquetes en TShark, que permite capturar solo aquellos paquetes que son de interés para ti. En condiciones donde decenas de dispositivos RTP están operando en la red, esto es muy valioso. En la línea de comandos de TShark, los parámetros de filtrado se especifican con la opción "-f". Usamos esta opción cuando quisimos capturar paquetes del puerto 8010:
-f "udp port 8010"
Los parámetros de filtrado son, en esencia, un conjunto de criterios que debe cumplir el paquete "capturado". La condición puede verificar la dirección, el puerto, el valor de un byte específico en el paquete. Las condiciones se pueden combinar usando operaciones lógicas "Y", "O", etc. Es una herramienta muy poderosa.
Si deseas ver la dinámica de los cambios en los campos de los paquetes, necesitarás duplicar la salida TShark en un archivo, tal como se mostró en el artículo anterior, mediante la transmisión de la salida TShark a la entrada tee. Luego, al abrir el archivo de registro con less, vim u otra herramienta capaz de trabajar rápidamente con archivos de texto grandes y realizar búsquedas de líneas, podrás esclarecer todos los matices del comportamiento de los campos de los paquetes en el flujo RTP.
Si necesitas escuchar la señal transmitida por el flujo RTP, entonces debes usar la versión TShark con interfaz gráfica Wireshark. A través de manipulaciones sencillas con el mouse, puedes escuchar y ver la oscilograma de la señal. Pero bajo una condición: si está codificada en formato u-law o a-law.
En la siguiente haremos juntos un dispositivo de intercomunicación dúplex. Consigue un par de auriculares y un interlocutor.
Fuente: habr.com
