Esploriamo il motore VoIP Mediastreamer2. Parte 6

Il materiale dell'articolo è tratto dal mio canale Zen.

Trasmissione del segnale audio attraverso un flusso RTP

Nel passato articolo abbiamo assemblato uno schema di controllo remoto da un generatore e un rilevatore di segnali tonali, che operano all'interno di un unico programma. In questo articolo, impareremo a utilizzare il protocollo RTP (RFC 3550 — RTP: Un protocollo di trasporto per applicazioni in tempo reale) per ricevere/inviare segnali audio su una rete Ethernet.

Il protocollo RTP (Real Time Protocol) si traduce in protocollo in tempo reale, ed è utilizzato per trasmettere audio, video, dati, tutto ciò che richiede una trasmissione in tempo reale. Prendiamo come esempio il segnale audio. La flessibilità del protocollo è tale da consentire la trasmissione del segnale audio con una qualità prestabilita.

Il trasferimento avviene tramite pacchetti UDP, il che significa che durante la trasmissione è possibile la perdita di pacchetti. Ogni pacchetto include un'intestazione RTP speciale e un blocco di dati del segnale trasmesso. Nell'intestazione è contenuto un identificatore di origine del segnale scelto in modo casuale, informazioni sul tipo di segnale trasmesso e un numero di sequenza unico del pacchetto, in modo che i pacchetti possano essere riordinati correttamente durante la decodifica, indipendentemente dall'ordine in cui la rete li ha consegnati. L'intestazione può anche contenere informazioni aggiuntive, chiamate estensioni, che consentono di adattare l'intestazione per l'uso in un'applicazione specifica.

Il blocco dati contiene il payload del pacchetto. L'organizzazione interna del contenuto dipende dal tipo di payload; può trattarsi di campioni di segnale monofonico, segnale stereo, riga di un'immagine video, ecc.

Il tipo di payload è indicato da un numero a sette bit. La raccomandazione RFC3551 (Profilo RTP per conferenze audio e video con controllo minimo) imposta diversi tipi di carico nella tabella corrispondente, sono forniti la descrizione dei tipi di carico e i valori dei codici con cui sono identificati. Alcuni codici non hanno un legame rigoroso con alcun tipo di carico e possono essere utilizzati per designare un carico arbitrario.

La dimensione del blocco dati è limitata superiormente dalla dimensione massima del pacchetto che può essere trasmesso in questa rete senza segmentazione (parametro MTU). In generale, questo non supera i 1500 byte. Pertanto, per aumentare la quantità di dati trasmessi al secondo, è possibile aumentare la dimensione del pacchetto fino a un certo punto, dopodiché sarà necessario aumentare la frequenza di invio dei pacchetti. Nel media streamer, questo è un parametro configurabile. Di default è impostato a 50 Hz, ovvero 50 pacchetti al secondo. La sequenza di pacchetti RTP trasmessi sarà chiamata flusso RTP.

Per iniziare la trasmissione dei dati tra sorgente e destinatario, è sufficiente che il trasmettitore conosca l'indirizzo IP del destinatario e il numero di porta che quest'ultimo utilizza per ricevere. Cioè, senza alcuna procedura preliminare, la sorgente inizia a trasmettere dati, mentre il destinatario è pronto a riceverli e elaborarli immediatamente. Secondo lo standard, il numero di porta utilizzato per la trasmissione o ricezione del flusso RTP deve essere pari.

In situazioni in cui non è possibile conoscere in anticipo l'indirizzo del destinatario, si utilizzano server sui quali i destinatari lasciano il proprio indirizzo, e il trasmettitore può richiederlo facendo riferimento a un nome unico del destinatario.

Nei casi in cui la qualità del canale di comunicazione o le capacità del ricevitore non sono note, viene organizzato un canale di feedback, attraverso il quale il ricevitore può informare il trasmettitore sulle proprie possibilità, sul numero di pacchetti mancanti, ecc. In questo canale viene utilizzato il protocollo RTCP. Il formato dei pacchetti trasmessi in questo canale è definito nella RFC 3605. Attraverso questo canale vengono trasmessi relativamente pochi dati, 200-300 byte al secondo, quindi, in generale, la sua presenza non è gravosa. Il numero della porta a cui vengono inviati i pacchetti RTCP deve essere dispari e superiore di uno al numero della porta da cui arriva il flusso RTP. Nel nostro esempio non utilizzeremo questo canale, poiché le capacità del ricevitore e del canale superano già le nostre, per ora modeste, esigenze.

Nel nostro programma, lo schema di trasmissione dei dati, a differenza dello schema del precedente esempio, sarà diviso in due parti: il tratto di trasmissione e il tratto di ricezione. Per ciascuna parte creeremo il nostro sorgente di clock, come mostrato nell'immagine di intestazione.

La comunicazione unidirezionale tra di loro avverrà tramite il protocollo RTP. In questo esempio non avremo bisogno di una rete esterna, poiché sia l'emittente che il ricevitore si trovano sullo stesso computer: i pacchetti si muoveranno all'interno di esso.

Per stabilire un flusso RTP nel media streamer, vengono utilizzati due filtri: MS_RTP_SEND e MS_RTP_RECV. Il primo gestisce l'invio, mentre il secondo riceve il flusso RTP. Affinché questi filtri possano funzionare, è necessario fornire un puntatore all'oggetto della sessione RTP, che può eseguire sia la conversione del flusso di blocchi di dati in flusso di pacchetti RTP, sia l'operazione inversa. Poiché il formato interno dei dati del media streamer non coincide con il formato dei pacchetti RTP, prima di passare i dati a MS_RTP_SEND bisogna utilizzare un filtro convertitore (encoder) che trasforma i campioni audio a 16 bit in campioni a 8 bit, codificati secondo la legge u (legge mu). Sul lato ricevente, la funzione inversa è svolta dal filtro decoder.

Di seguito è riportato il testo del programma che implementa lo schema mostrato nell'immagine (i simboli # davanti alle direttive include sono stati rimossi, non dimenticate di inserirli).

/* Файл 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);
}
}

Compiliamo e avviamo. Il programma funzionerà come nell'esempio precedente, ma i dati saranno trasmessi tramite un flusso RTP.

Nell'articolo successivo divideremo questo programma in due applicazioni indipendenti: ricevitore e trasmettitore, e li eseguirò in terminali diversi. Allo stesso tempo, impareremo ad analizzare i pacchetti RTP utilizzando il programma TShark.

Fonte: habr.com