Estudando o motor VoIP Mediastreamer2. Parte 8

O conteúdo deste artigo foi retirado do meu canal Zen.

Estudando o motor VoIP Mediastreamer2. Parte 8

Estrutura do pacote RTP

Na parte anterior artigo usamos TShark capturamos pacotes RTP que estavam sendo trocados entre nosso receptor e transmissor. Agora, nesta seção, pintaremos os elementos do pacote em cores diferentes e falaremos sobre suas funções.

Vamos olhar o mesmo pacote, mas agora com campos coloridos e com descrições explicativas:
Estudando o motor VoIP Mediastreamer2. Parte 8

Na parte inferior da listagem, os bytes que compõem o pacote RTP estão coloridos, e ele, por sua vez, é a carga útil do pacote UDP (seu cabeçalho está demarcado com uma linha preta). Os bytes do cabeçalho RTP são indicados por fundos coloridos, enquanto o bloco de dados, que contém a carga útil do pacote RTP, é destacado em verde. Os dados estão apresentados no formato hexadecimal. Em nosso caso, é um sinal de áudio comprimido pelo u-law (mú-law), ou seja, uma amostra tem tamanho de 1 byte. Como usamos a taxa de amostragem definida por padrão (8000 Hz), com uma frequência de pacotes de 50 Hz, cada pacote RTP deve conter 160 bytes de carga útil. Isso é o que veremos ao contar os bytes na área verde, devendo haver 10 linhas.

De acordo com o padrão, a quantidade de dados na carga útil deve ser múltipla de quatro, ou em outras palavras, deve conter um número inteiro de palavras de quatro bytes. Se acontecer que sua carga útil não corresponda a esta regra, então, no final da carga útil, deve-se adicionar bytes com valores zero e definir o bit Padding (Preenchimento). Este bit está localizado no primeiro byte do cabeçalho RTP, e é colorido em turquesa. Observe que todos os bytes da carga útil têm o valor 0xFF — essa é a aparência do silêncio no formato u-law.

O cabeçalho do pacote RTP consiste em 12 bytes obrigatórios, mas em dois casos pode ser mais longo:

  • Quando o pacote transporta um sinal de áudio obtido da mistura de sinais de várias fontes (fluxos RTP), uma tabela com a lista de identificadores de fontes, cujas cargas úteis foram utilizadas para criar a carga útil deste pacote, é colocada após os primeiros 12 bytes do cabeçalho. Nesse caso, nos quatro bits inferiores do primeiro byte do cabeçalho (campo Número de identificadores de fonte contribuinte) indica o número de fontes. O tamanho do campo é de 4 bits, portanto a tabela pode conter até 15 identificadores de fontes. Cada um ocupa 4 bytes. Esta tabela é utilizada na organização de conferências de comunicação.

  • Quando o cabeçalho possui uma extensão. Nesse caso, o primeiro byte do cabeçalho define um bit X. No cabeçalho estendido, após a tabela de participantes (se houver), está o cabeçalho da extensão, que tem o tamanho de uma palavra, seguido pelas palavras de extensão. A extensão é um conjunto de bytes que você pode usar para transmitir dados adicionais. O padrão não especifica o formato desses dados - pode ser qualquer um. Por exemplo, podem ser algumas configurações adicionais para o dispositivo que recebe os pacotes RTP. Para algumas aplicações, contudo, padrões de cabeçalho estendido foram desenvolvidos. Isso foi feito, por exemplo, para meios de comunicação no padrão ED-137 (Padrões de Interoperabilidade para Componentes VoIP ATM).

Agora vamos examinar os campos do cabeçalho mais detalhadamente. Abaixo está uma imagem canônica da estrutura do cabeçalho RTP, que também colori com as mesmas cores.

Estudando o motor VoIP Mediastreamer2. Parte 8
VER — número da versão do protocolo (a versão atual é 2);

P — flag que é definida em casos onde o pacote RTP é complementado com bytes vazios no final;

X — flag indicando que o cabeçalho é estendido;

Quando se fala em aumentar a eficiência energética, a virtualização possui várias vantagens inegáveis. Em primeiro lugar, a consolidação de serviços existentes em um menor número de servidores físicos permite economizar nos custos de manutenção do hardware, o que se traduz em uma redução nos gastos com refrigeração, eletricidade e espaço ocupado. Em segundo lugar, a virtualização permite otimizar o uso dos recursos de hardware e redistribuir de forma flexível — contém o número de identificadores CSRC que seguem o cabeçalho fixo (após as palavras 1..3), no gráfico a tabela não é mostrada;

M — marcador de início de quadro ou de presença de fala no canal (se um detector de pausas na fala estiver em uso). Se o receptor não contiver um detector de pausas na fala, este bit deve ser continuamente definido;

PTYPE — indica o formato da carga útil;

Número de sequência — número do pacote, utilizado para restaurar a ordem de reprodução dos pacotes, já que na realidade os pacotes podem chegar ao receptor em uma ordem diferente de que foram enviados. O valor inicial deve ser aleatório, isso é feito para dificultar a quebra do fluxo RTP se a criptografia for aplicada. Este campo também permite a detecção de pacotes perdidos;

Timestamp — carimbo de tempo. O tempo é medido em amostras de sinal, ou seja, se um pacote contém 160 amostras, o carimbo de tempo do próximo pacote será maior em 160. O valor inicial do carimbo de tempo deve ser aleatório;

SSRC — identificador de fonte do pacote, deve ser único. É melhor gerar aleatoriamente antes de iniciar o fluxo RTP.

Se você estiver desenvolvendo seu próprio transmissor ou receptor de pacotes RTP, precisará examinar seus pacotes várias vezes. Para aumentar a produtividade, recomendo dominar o uso de filtragem de pacotes no TShark, que permite capturar apenas os pacotes de interesse. Em situações onde dezenas de dispositivos RTP estão operando na rede, isso é muito valioso. Na linha de comando do TShark, os parâmetros de filtragem são definidos pela opção "-f". Usamos essa opção quando queríamos capturar pacotes da porta 8010:
-f "udp port 8010"
Os parâmetros de filtragem são, na essência, um conjunto de critérios que o pacote 'capturado' deve atender. A condição pode verificar o endereço, a porta ou o valor de um determinado byte no pacote. As condições podem ser combinadas com operações lógicas como 'E', 'OU', etc. É uma ferramenta muito poderosa.

Se você deseja observar a dinâmica da mudança dos campos nos pacotes, precisará duplicar a saída TShark para um arquivo, como foi mostrado no artigo anterior, através da transmissão da saída TShark para a entrada tee. Em seguida, abrindo o arquivo de log com less, vim ou outra ferramenta que consiga lidar rapidamente com grandes arquivos de texto e realizar busca de linhas, você poderá descobrir todos os detalhes do comportamento dos campos no fluxo RTP.

Se precisar escutar o sinal transmitido pelo fluxo RTP, você deve utilizar a versão TShark com interface visual Wireshark. Através de manipulções simples com o mouse, é possível escutar e visualizar o oscilograma do sinal. Mas com uma condição — se ele estiver codificado no formato u-law ou a-law.

Na próxima artigo vamos criar um dispositivo de conversação duplex. Prepare um par de fones de ouvido e um interlocutor.

Fonte: habr.com

Compre hospedagem confiável para sites com proteção contra DDoS, servidores VPS VDS 🔥 Compre hospedagem confiável para sites com proteção contra DDoS, servidores VPS VDS | ProHoster