Explorando o motor VoIP Mediastreamer2. Parte 6

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

Transmissão de sinal de áudio através de um fluxo RTP

Explorando o motor VoIP Mediastreamer2. Parte 6

Na parte anterior artigo reunimos um esquema de controle remoto a partir de um gerador e detector de sinais tonais, que funcionam dentro de um único programa. Neste artigo, vamos aprender a utilizar o protocolo RTP (RFC 3550 — RTP: Um Protocolo de Transporte para Aplicações em Tempo Real) para recepção/transmissão de sinal de áudio através de uma rede Ethernet.

O protocolo RTP (Protocolo em Tempo Real) é traduzido como um protocolo de tempo real, utilizado para a transmissão de áudio, vídeo e dados que requerem envio em tempo real. Tomemos como exemplo um sinal de áudio. A flexibilidade do protocolo permite transmitir sinais de áudio com qualidade pré-definida.

A transmissão é realizada através de pacotes UDP, o que significa que a perda de pacotes durante a transmissão é aceitável. Cada pacote contém um cabeçalho RTP especial e um bloco de dados do sinal transmitido. O cabeçalho inclui um identificador de fonte de sinal escolhido aleatoriamente, informações sobre o tipo de sinal transmitido, um número de sequência exclusivo para que os pacotes possam ser organizados corretamente durante a decodificação, independentemente da ordem em que foram entregues pela rede. O cabeçalho também pode conter informações adicionais, chamadas de extensão, que permitem adaptar o cabeçalho a uma tarefa específica.

O bloco de dados contém a carga útil do pacote. A organização interna do conteúdo depende do tipo de carga, que pode incluir amostras de um sinal mono, sinal estéreo, linha de vídeo, etc.

O tipo de carga é indicado por um número de sete bits. A recomendação RFC3551 (Perfil RTP para Conferências de Áudio e Vídeo com Controle Mínimo) estabelece vários tipos de carga na tabela correspondente, dando descrições dos tipos de carga e os valores dos códigos que os representam. Alguns códigos não têm uma ligação rígida a qualquer tipo de carga e podem ser usados para indicar cargas arbitrárias.

O tamanho do bloco de dados é limitado pelo tamanho máximo do pacote que pode ser transmitido nesta rede sem segmentação (parâmetro MTU). Em geral, isso não ultrapassa 1500 bytes. Assim, para aumentar a quantidade de dados transmitidos por segundo, é possível aumentar o tamanho do pacote até um certo ponto, e depois será necessário aumentar a frequência de envio de pacotes. Para o mediastreamer, esse é um parâmetro configurável. Por padrão, ele é definido como 50 Hz, ou seja, 50 pacotes por segundo. A sequência de pacotes RTP transmitidos será chamada de fluxo RTP.

Para iniciar a transmissão de dados entre a fonte e o receptor, é suficiente que o transmissor conheça o endereço IP do receptor e o número da porta que este usa para receber. Ou seja, sem qualquer procedimento preliminar, a fonte começa a transmitir dados, enquanto o receptor está pronto para recebê-los e processá-los imediatamente. De acordo com o padrão, o número da porta utilizada para transmitir ou receber o fluxo RTP deve ser par.

Em situações onde não é possível saber previamente o endereço do receptor, são utilizados servidores nos quais os receptores deixam seu endereço, permitindo que o transmissor o solicite referindo-se a um nome único do receptor.

Nos casos em que a qualidade do canal de comunicação ou as capacidades do receptor são desconhecidas, é criado um canal de feedback, pelo qual o receptor pode informar ao transmissor sobre suas capacidades, a quantidade de pacotes que ele não recebeu, etc. Nesse canal, é utilizado o protocolo RTCP. O formato dos pacotes transmitidos nesse canal é definido no RFC 3605. Por meio desse canal, são enviados relativamente poucos dados, de 200 a 300 bytes por segundo, portanto, em geral, sua presença não é onerosa. O número da porta para a qual os pacotes RTCP são enviados deve ser ímpar e um a mais do que o número da porta de onde vem o fluxo RTP. No nosso exemplo, não usaremos esse canal, pois as capacidades do receptor e do canal excedem, por enquanto, nossas modestas necessidades.

No nosso programa, o esquema de transmissão de dados, ao contrário do esquema do exemplo anterior, será dividido em duas partes: o caminho de transmissão e o caminho de recepção. Para cada parte, faremos nossa própria fonte de relógio, como mostrado na imagem de cabeçalho.

A comunicação unidirecional entre eles será feita através do protocolo RTP. Neste exemplo, não precisaremos de uma rede externa, pois tanto o transmissor quanto o receptor estarão no mesmo computador - os pacotes trafegarão internamente.

Para estabelecer o fluxo RTP no media streamer, dois filtros são utilizados: MS_RTP_SEND e MS_RTP_RECV. O primeiro realiza a transmissão, e o segundo recebe o fluxo RTP. Para que esses filtros funcionem, é necessário passar um ponteiro para o objeto da sessão RTP, que pode tanto converter o fluxo de blocos de dados em pacotes RTP quanto realizar a operação inversa. Como o formato interno dos dados do media streamer não coincide com o formato dos pacotes RTP, antes de enviar os dados para o MS_RTP_SEND, deve-se usar um filtro conversor (encoder), que transforma as amostras de áudio de 16 bits em amostras de 8 bits, codificadas pelo u-law. No lado do receptor, a função inversa é executada pelo filtro decoder.

Abaixo está o texto do programa que implementa o esquema mostrado na figura (os símbolos # antes das diretivas include foram removidos, não se esqueça de adicioná-los):

/* Файл mstest6.c Имитатор пульта управления и приемника. */

#include <mediastreamer2/msfilter.h>
#include <mediastreamer2/msticker.h>
#include <mediastreamer2/dtmfgen.h>
#include <mediastreamer2/mssndcard.h>
#include <mediastreamer2/msvolume.h>
#include <mediastreamer2/mstonedetector.h>
#include <mediastreamer2/msrtp.h>
#include <ortp/rtpsession.h>
#include <ortp/payloadtype.h>

/* Подключаем заголовочный файл с функциями управления событиями
* медиастримера.*/
include <mediastreamer2/mseventqueue.h>

#define PCMU 0

/* Функция обратного вызова, она будет вызвана фильтром, как только он
обнаружит совпадение характеристик входного сигнала с заданными. */
static void tone_detected_cb(void *data, MSFilter *f, unsigned int event_id,
MSToneDetectorEvent *ev)
{
printf("Принята команда: %sn", ev->tone_name);
}

/*----------------------------------------------------------------------------*/
/* Функция регистрации типов полезных нагрузок. */
void register_payloads(void)
{
/*Регистрируем типы нагрузок в таблице профилей. Позднее, по индексу
взятому из заголовка RTP-пакета из этой таблицы будут извлекаться
параметры нагрузки, необходимые для декодирования данных пакета. */
rtp_profile_set_payload (&av_profile, PCMU, &payload_type_pcm8000);
}

/*----------------------------------------------------------------------------*/
/* Эта функция создана из функции create_duplex_rtpsession() в audiostream.c
медиастримера2. */
static RtpSession *
create_rtpsession (int loc_rtp_port, int loc_rtcp_port,
bool_t ipv6, RtpSessionMode mode)
{
RtpSession *rtpr;
rtpr = rtp_session_new ((int) mode);
rtp_session_set_scheduling_mode (rtpr, 0);
rtp_session_set_blocking_mode (rtpr, 0);
rtp_session_enable_adaptive_jitter_compensation (rtpr, TRUE);
rtp_session_set_symmetric_rtp (rtpr, TRUE);
rtp_session_set_local_addr (rtpr, ipv6 ? "::" : "0.0.0.0", loc_rtp_port,
loc_rtcp_port);
rtp_session_signal_connect (rtpr, "timestamp_jump",
(RtpCallback) rtp_session_resync, 0);
rtp_session_signal_connect (rtpr, "ssrc_changed",
(RtpCallback) rtp_session_resync, 0);
rtp_session_set_ssrc_changed_threshold (rtpr, 0);
rtp_session_set_send_payload_type(rtpr, PCMU);

/* По умолчанию выключаем RTCP-сессию, так как наш пульт не будет использовать её. */
rtp_session_enable_rtcp (rtpr, FALSE);
return rtpr;
}

/*----------------------------------------------------------------------------*/
int main()
{
ms_init();

/* Создаем экземпляры фильтров. */
MSFilter *voidsource = ms_filter_new(MS_VOID_SOURCE_ID);
MSFilter *dtmfgen = ms_filter_new(MS_DTMF_GEN_ID);
MSFilter *volume = ms_filter_new(MS_VOLUME_ID);
MSSndCard *card_playback =
ms_snd_card_manager_get_default_card(ms_snd_card_manager_get());
MSFilter *snd_card_write = ms_snd_card_create_writer(card_playback);
MSFilter *detector = ms_filter_new(MS_TONE_DETECTOR_ID);

/* Очищаем массив находящийся внутри детектора тонов, он описывает
* особые приметы разыскиваемых сигналов.*/
ms_filter_call_method(detector, MS_TONE_DETECTOR_CLEAR_SCANS, 0);

/* Подключаем к фильтру функцию обратного вызова. */
ms_filter_set_notify_callback(detector,
(MSFilterNotifyFunc)tone_detected_cb, NULL);

/* Создаем массив, каждый элемент которого описывает характеристику
* одного из тонов, который требуется обнаруживать: Текстовое имя
* данного элемента, частота в герцах, длительность в миллисекундах,
* минимальный уровень относительно 0,775В. */
MSToneDetectorDef scan[6]=
{
{"V+",440, 100, 0.1}, /* Команда "Увеличить громкость". */
{"V-",540, 100, 0.1}, /* Команда "Уменьшить громкость". */
{"C+",640, 100, 0.1}, /* Команда "Увеличить номер канала". */
{"C-",740, 100, 0.1}, /* Команда "Уменьшить номер канала". */
{"ON",840, 100, 0.1}, /* Команда "Включить телевизор". */
{"OFF", 940, 100, 0.1}/* Команда "Выключить телевизор". */
};

/* Передаем "приметы" сигналов детектор тонов. */
int i;
for (i = 0; i < 6; i++)
{
ms_filter_call_method(detector, MS_TONE_DETECTOR_ADD_SCAN,
&scan[i]);
}

/* Создаем фильтры кодера и декодера */
MSFilter *encoder = ms_filter_create_encoder("PCMU");
MSFilter *decoder=ms_filter_create_decoder("PCMU");
/* Регистрируем типы нагрузки. */
register_payloads();

/* Создаем RTP-сессию передатчика. */
RtpSession *tx_rtp_session = create_rtpsession (8010, 8011, FALSE, RTP_SESSION_SENDONLY);
rtp_session_set_remote_addr_and_port(tx_rtp_session,"127.0.0.1", 7010, 7011);
rtp_session_set_send_payload_type(tx_rtp_session, PCMU);
MSFilter *rtpsend = ms_filter_new(MS_RTP_SEND_ID);
ms_filter_call_method(rtpsend, MS_RTP_SEND_SET_SESSION, tx_rtp_session);

/* Создаем RTP-сессию приемника. */
MSFilter *rtprecv = ms_filter_new(MS_RTP_RECV_ID);
RtpSession *rx_rtp_session = create_rtpsession (7010, 7011, FALSE, RTP_SESSION_RECVONLY);
ms_filter_call_method(rtprecv, MS_RTP_RECV_SET_SESSION, rx_rtp_session);

/* Создаем источники тактов - тикеры. */
MSTicker *ticker_tx = ms_ticker_new();
MSTicker *ticker_rx = ms_ticker_new();

/* Соединяем фильтры передатчика. */
ms_filter_link(voidsource, 0, dtmfgen, 0);
ms_filter_link(dtmfgen, 0, volume, 0);
ms_filter_link(volume, 0, encoder, 0);
ms_filter_link(encoder, 0, rtpsend, 0);

/* Соединяем фильтры приёмника. */
ms_filter_link(rtprecv, 0, decoder, 0);
ms_filter_link(decoder, 0, detector, 0);
ms_filter_link(detector, 0, snd_card_write, 0);

/* Подключаем источник тактов. */
ms_ticker_attach(ticker_tx, voidsource);
ms_ticker_attach(ticker_rx, rtprecv);

/* Настраиваем структуру, управляющую выходным сигналом генератора. */
MSDtmfGenCustomTone dtmf_cfg;
dtmf_cfg.tone_name[0] = 0;
dtmf_cfg.duration = 1000;
dtmf_cfg.frequencies[0] = 440;
/* Будем генерировать один тон, частоту второго тона установим в 0. */
dtmf_cfg.frequencies[1] = 0;
dtmf_cfg.amplitude = 1.0;
dtmf_cfg.interval = 0.;
dtmf_cfg.repeat_count = 0.;

/* Организуем цикл сканирования нажатых клавиш. Ввод нуля завершает
* цикл и работу программы. */
char key='9';
printf("Нажмите клавишу команды, затем ввод.n"
"Для завершения программы введите 0.n");
while(key != '0')
{
key = getchar();
if ((key >= 49) && (key <= 54))
{
printf("Отправлена команда: %cn", key);

/* Устанавливаем частоту генератора в соответствии с
 * кодом нажатой клавиши. */
dtmf_cfg.frequencies[0] = 440 + 100*(key-49);

/* Включаем звуковой генератор c обновленной частотой. */
ms_filter_call_method(dtmfgen, MS_DTMF_GEN_PLAY_CUSTOM,
(void*)&dtmf_cfg);
}

/* Укладываем тред в спячку на 20мс, чтобы другие треды
 * приложения получили время на работу. */
ms_usleep(20000);
}
}

Compilamos e executamos. O programa funcionará como no exemplo anterior, mas os dados serão transmitidos através do fluxo RTP.

No próximo artigo, vamos dividir este programa em duas aplicações independentes - o receptor e o transmissor - e executá-los em terminais diferentes. Paralelamente, aprenderemos a analisar pacotes RTP com o programa TShark.

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