We onderzoeken de VoIP-engine Mediastreamer2. Deel 6

Het materiaal van dit artikel is afkomstig van mijn zen-kanaal.

Overdracht van geluidssignalen via een RTP-stroom

In het verleden artikel We hebben een schema samengesteld voor afstandsbediening van een generator en detector van toon-signalen, die binnen één programma werken. In dit artikel leren we hoe we het RTP-protocol (RFC 3550 — RTP: Een transportprotocol voor realtime applicaties) gebruiken voor het ontvangen/verzenden van geluidssignalen via een Ethernet-netwerk.

Het RTP-protocol (Real Time Protocol) wordt in het Nederlands vertaald als real-time protocol en wordt gebruikt voor het verzenden van audio, video, data, alles wat een realtime overdracht vereist. Neem als voorbeeld een geluidssignaal. De flexibiliteit van het protocol maakt het mogelijk om het geluidssignaal met een vooraf bepaald kwaliteitsniveau te verzenden.

De overdracht gebeurt met behulp van UDP-pakketten, wat betekent dat bij de overdracht pakketverlies kan optreden. In elk pakket wordt een speciale RTP-header en een blok gegevens van het verzonden signaal opgenomen. In de header bevindt zich een willekeurig gekozen identificatienummer van de signaalbron, informatie over het type verzonden signaal, een unieke volgnummer van het pakket, zodat pakketten bij decodering in de juiste volgorde kunnen worden gerangschikt, ongeacht de volgorde waarin ze door het netwerk zijn afgeleverd. De header kan ook aanvullende informatie bevatten, een zogenaamde extensie, die het mogelijk maakt de header aan te passen voor gebruik in een specifieke applicatie.

Het gegevensblok bevat de nuttige lading van het pakket. De interne organisatie van de inhoud is afhankelijk van het type lading, dit kan mono-geluid, stereo-geluid, een video-beeldlijn, enz. zijn.

Het type lading wordt aangeduid met een zevenbitsgetal. Aanbeveling RFC3551 (RTP-profiel voor audio- en videovergaderingen met minimale controle) stelt verschillende types lading vast, in de desbetreffende tabel worden de beschrijvingen van de types lading en de waarden van de codes waarmee ze worden aangeduid weergegeven. Sommige codes hebben geen strikte binding aan een bepaald type lading; ze kunnen worden gebruikt om willekeurige lading aan te duiden.

De grootte van een datablok is beperkt door de maximale pakketgrootte die in dit netwerk kan worden verzonden zonder segmentatie (de MTU-parameter). In het algemeen is dit niet meer dan 1500 bytes. Om de hoeveelheid verzonden gegevens per seconde te verhogen, kan de pakketgrootte tot op zekere hoogte worden vergroot, waarna de frequentie van het verzenden van pakketten moet worden verhoogd. Voor de mediaspeler is dit een instelbare parameter. Standaard staat deze op 50 Hz, dat wil zeggen 50 pakketten per seconde. De reeks verzonden RTP-pakketten noemen we een RTP-stroom.

Om gegevensoverdracht tussen een bron en een ontvanger te starten, hoeft de zender alleen het IP-adres van de ontvanger en het poortnummer dat deze gebruikt voor ontvangst te kennen. Dat betekent dat de bron gewoon begint met het verzenden van gegevens, terwijl de ontvanger klaar is om deze onmiddellijk te ontvangen en te verwerken, zonder voorafgaande procedures. Volgens de standaard moet het poortnummer dat wordt gebruikt voor de verzending of ontvangst van de RTP-stroom even zijn.

In situaties waarin het adres van de ontvanger niet van tevoren bekend is, worden servers gebruikt waar ontvangers hun adres achterlaten en de zender dit kan opvragen door te verwijzen naar een uniek naam van de ontvanger.

In gevallen waar de kwaliteit van de communicatielijn of de mogelijkheden van de ontvanger onbekend zijn, wordt een feedbackkanaal opgezet, zodat de ontvanger de zender kan informeren over zijn mogelijkheden, het aantal pakketten dat hij mist, enzovoort. In dit kanaal wordt het RTCP-protocol gebruikt. Het formaat van de in dit kanaal verzonden pakketten is gedefinieerd in RFC 3605. Er worden relatief weinig gegevens verzonden via dit kanaal, 200-300 bytes per seconde, dus over het algemeen is het bestaan ervan niet bezwarend. Het poortnummer waar RTCP-pakketten naartoe worden verzonden, moet oneven zijn en één hoger dan het poortnummer van waaruit de RTP-stroom komt. In ons voorbeeld zullen we dit kanaal niet gebruiken, aangezien de mogelijkheden van de ontvanger en de lijn onze bescheiden behoeften ver overtreffen.

In ons programma zal het gegevensoverdrachtschema, in tegenstelling tot het schema van het vorige voorbeeld, in twee delen worden verdeeld: een verzendpad en een ontvangpad. Voor elk deel zullen we onze eigen klokbron maken, zoals weergegeven in de titelafbeelding.

De unidirectionele communicatie tussen hen zal plaatsvinden via het RTP-protocol. In dit voorbeeld hebben we geen extern netwerk nodig, aangezien zowel de zender als de ontvanger zich op dezelfde computer bevinden - de pakketten zullen intern binnen deze computer circuleren.

Voor het opzetten van de RTP-stroom in de mediastreamer worden twee filters gebruikt: MS_RTP_SEND en MS_RTP_RECV. De eerste verzendt, terwijl de tweede ontvangt de RTP-stroom. Om deze filters te laten werken, moeten ze een verwijzing naar het RTP-sessieobject ontvangen, dat zowel het transformeren van datablokken naar RTP-pakketten als de omgekeerde actie kan uitvoeren. Aangezien het interne gegevensformaat van de mediastreamer niet overeenkomt met het gegevensformaat van een RTP-pakket, moet voor het verzenden van gegevens via MS_RTP_SEND een converterfilter (encoder) worden gebruikt, dat 16-bits geluidssamples omzet in achtbits, gecodeerd volgens de u-wet (mu-wet). Aan de ontvangende kant voert het decoder-filter de omgekeerde functie uit.

Hieronder staat de tekst van het programma dat de in de afbeelding weergegeven schema implementeert (de symbolen # voor de include-directieven zijn verwijderd; vergeet niet deze toe te voegen):

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

We compileren en starten. Het programma zal werken zoals in het vorige voorbeeld, maar de gegevens zullen nu via de RTP-stroom worden verzonden.

In het volgende artikel zullen we dit programma splitsen in twee onafhankelijke applicaties - een ontvanger en een zender, en ze in verschillende terminals uitvoeren. Tegelijkertijd leren we RTP-pakketten analyseren met het programma TShark.

Bron: habr.com