O material do artigo está tirado do meu .
Estrutura do paquete RTP
No último estamos usando TShark realizou a captura de paquetes RTP que foron intercambiados entre o noso receptor e transmisor. Pois ben, neste pintaremos os elementos do paquete de diferentes cores e falaremos do seu propósito.
Vexamos o mesmo paquete, pero con marxes de cores e etiquetas explicativas:
Na parte inferior da lista, os bytes que compoñen o paquete RTP están tintados, e esta á súa vez é a carga útil do paquete UDP (a súa cabeceira está rodeada de negro). Os fondos de cores indican os bytes da cabeceira RTP e o bloque de datos que contén a carga útil do paquete RTP resáltase en verde. Os datos alí preséntanse en formato hexadecimal. No noso caso, trátase dun sinal de audio comprimido segundo a lei u (lei mu), é dicir. unha mostra ten un tamaño de 1 byte. Dado que utilizamos a frecuencia de mostraxe predeterminada (8000 Hz), cunha taxa de paquetes de 50 Hz, cada paquete RTP debe conter 160 bytes de carga útil. Veremos isto contando os bytes na zona verde, debería haber 10 liñas deles.
Segundo o estándar, a cantidade de datos na carga útil debe ser un múltiplo de catro ou, noutras palabras, debe conter un número enteiro de palabras de catro bytes. Se ocorre que a carga útil non coincide con esta regra, debes engadir bytes de valor cero ao final da carga útil e establecer o bit de recheo. Este bit está situado no primeiro byte da cabeceira RTP e ten cor turquesa. Teña en conta que todos os bytes de carga útil son 0xFF, que é o que parece o silencio u-law.
A cabeceira do paquete RTP consta de 12 bytes obrigatorios, pero en dous casos pode ser máis longo:
-
Cando un paquete leva un sinal de audio obtido mesturando sinais de varias fontes (fluxos RTP), despois dos primeiros 12 bytes da cabeceira hai unha táboa cunha lista de identificadores de fontes cuxas cargas útiles foron usadas para crear a carga útil deste paquete. Neste caso, nos catro bits inferiores do primeiro byte da cabeceira (campo Os identificadores de fonte contribuíntes contan) indícase o número de fontes. O tamaño do campo é de 4 bits, polo que a táboa pode conter ata 15 identificadores de orixe. Cada un deles leva 4 bytes. Esta táboa úsase cando se organiza unha conferencia telefónica.
-
Cando o título teña a extensión . Neste caso, o bit establécese no primeiro byte da cabeceira X. Na cabeceira ampliada, despois da táboa de participantes (se hai), hai unha cabeceira de extensión dunha palabra, seguida das palabras de extensión. Unha extensión é unha colección de bytes que pode usar para transferir datos adicionais. O estándar non estipula o formato destes datos: pode ser calquera cousa. Por exemplo, pode haber algunhas opcións adicionais para o dispositivo que recibe paquetes RTP. Non obstante, para algunhas aplicacións desenvolvéronse estándares de cabeceira estendidos. Isto faise, por exemplo, para as comunicacións no estándar ED-137 (Estándares de interoperabilidade para compoñentes de cajeros automáticos VoIP).
Agora vexamos os campos de cabeceira con máis detalle. A continuación móstrase unha imaxe canónica coa estrutura da cabeceira RTP, que tampouco puiden resistir e pintei coas mesmas cores.
VER — número de versión do protocolo (versión actual 2);
P - unha marca que se establece nos casos en que o paquete RTP se complementa con bytes baleiros ao final;
X - marcar que a cabeceira está estendida;
CC — contén o número de identificadores CSRC que seguen a cabeceira constante (despois das palabras 1..3), a táboa non se mostra na figura;
M — marcador do inicio dun cadro ou da presenza de voz na canle (se se utiliza un detector de pausa de voz). Se o receptor non contén un detector de pausa de voz, entón este bit estará permanentemente configurado;
PTYPE - especifica o formato da carga útil;
Número de secuencia - número de paquete, usado para restaurar a orde na que se reproducen os paquetes, xa que a situación real é cando os paquetes poden chegar ao receptor na orde incorrecta na que foron enviados. O valor inicial debe ser aleatorio, isto faise para que se o fluxo RTP está cifrado, será difícil piratealo. Este campo tamén permite detectar caídas de paquetes;
Timestamp - selo de tempo. O tempo mídese en mostras de sinal, é dicir. se a ráfaga contén 160 mostras, entón a marca de tempo da seguinte ráfaga será 160 máis. O valor inicial da marca de tempo debe ser aleatorio;
SSRC — identificador de orixe do paquete, debe ser único. É mellor xeralo de forma aleatoria antes de iniciar o fluxo RTP.
Se desenvolves o teu propio transmisor ou receptor RTP, terás que revisar os teus paquetes máis dunha vez para aumentar a produtividade, recoméndoche que aprendas a usar o filtrado de paquetes en TShark, permíteche capturar só aqueles paquetes que son de interese para ti. En condicións nas que decenas de dispositivos RTP funcionan na rede, isto é moi valioso. Na liña de comandos de TShark, os parámetros de filtrado especifícanse coa opción "-f". Usamos esta opción cando queriamos capturar paquetes do porto 8010:
-f "udp port 8010"
Os parámetros de filtrado son esencialmente un conxunto de criterios que debe cumprir un paquete "captado". A condición pode comprobar o enderezo, o porto ou o valor dun byte específico do paquete. As condicións pódense combinar mediante operacións lóxicas "AND", "OU", etc. Unha ferramenta moi poderosa.
Se queres ver a dinámica dos cambios de campo en lotes, terás que duplicar a saída TShark a un ficheiro, como se mostra no último artigo, pasando a saída TShark na entrada Tee. A continuación, abra o ficheiro de rexistro con menos, vim ou outra ferramenta que pode traballar rapidamente con ficheiros de texto enormes e buscar cadeas, podes descubrir todos os matices do comportamento dos campos de paquetes nun fluxo RTP.
Se necesitas escoitar o sinal transmitido polo fluxo RTP, entón tes que usar a versión TShark con interface visual Wireshark. Con manipulacións sinxelas do rato, pode escoitar e ver a forma de onda do sinal. Pero cunha condición: se está codificado en formato u-law ou a-low.
No seguinte Faremos un intercomunicador dúplex contigo. Abastece un par de auriculares e un interlocutor.
Fonte: www.habr.com