Verken die Mediastreamer2 VoIP-enjin. Deel 6

Die materiaal van die artikel is geneem uit my zen-kanaal.

Stuur 'n oudiosein via RTP-stroom

In die laaste Artikel Ons het 'n afstandbeheerkring van 'n toongenerator en 'n toondetektor saamgestel wat binne dieselfde program werk. In hierdie artikel sal ons leer hoe om die RTP-protokol te gebruik (RFC 3550 - RTP: 'n Vervoerprotokol vir intydse toepassings) vir die ontvang/versending van 'n oudiosein oor 'n Ethernet-netwerk.

RTP protokol (Intydse Protokol) vertaal beteken intydse protokol, dit word gebruik om oudio, video, data, alles wat oordrag in reële tyd vereis oor te dra. Kom ons neem 'n oudiosein as 'n voorbeeld. Die buigsaamheid van die protokol is sodanig dat dit jou toelaat om 'n oudiosein met 'n voorafbepaalde kwaliteit uit te stuur.

Die transmissie word uitgevoer met behulp van UDP-pakkies, wat beteken dat pakkieverlies redelik aanvaarbaar is tydens transmissie. Elke pakkie bevat 'n spesiale RTP-kopskrif en 'n datablok van die gestuurde sein. Die opskrif bevat 'n ewekansige geselekteerde seinbron-identifiseerder, inligting oor die tipe sein wat versend word, en 'n unieke pakkievolgordenommer sodat die pakkies in die regte volgorde gerangskik kan word tydens dekodering, ongeag die volgorde waarin hulle deur die netwerk. Die kopskrif kan ook bykomende inligting bevat, die sogenaamde uitbreiding, wat toelaat dat die kopskrif aangepas kan word vir gebruik in 'n spesifieke toepassingstaak.

Die datablok bevat die loonvrag van die pakkie. Die interne organisasie van die inhoud hang af van die tipe vrag, dit kan monsters van 'n monosein, 'n stereosein, 'n videobeeldlyn, ens.

Die tipe las word deur 'n sewe-bis-nommer aangedui. Aanbeveling RFC3551 (RTP-profiel vir oudio- en videokonferensies met minimale beheer) stel verskeie tipes vrag vas; die ooreenstemmende tabel verskaf 'n beskrywing van die tipes vrag en die betekenis van die kodes waarmee hulle aangewys word. Sommige kodes is nie streng gekoppel aan enige tipe vrag nie; hulle kan gebruik word om 'n arbitrêre las aan te wys.

Die grootte van 'n datablok word hierbo beperk deur die maksimum pakkiegrootte wat op 'n gegewe netwerk sonder segmentering (MTU-parameter) versend kan word. Oor die algemeen is dit nie meer as 1500 grepe nie. Dus, om die hoeveelheid data wat per sekonde versend word, te verhoog, kan u die pakkiegrootte tot op 'n sekere punt verhoog, en dan sal u die frekwensie van die stuur van pakkies moet verhoog. In 'n mediastreamer is dit 'n konfigureerbare instelling. By verstek is dit 50 Hz, d.w.s. 50 pakkies per sekonde. Ons sal die volgorde van gestuurde RTP-pakkies 'n RTP-stroom noem.

Om data tussen die bron en die ontvanger te begin oordra, is dit genoeg dat die sender die IP-adres van die ontvanger ken en die poortnommer wat dit vir ontvangs gebruik. Dié. sonder enige voorlopige prosedures begin die bron om data oor te dra, en die ontvanger is op sy beurt gereed om dit onmiddellik te ontvang en te verwerk. Volgens die standaard moet die poortnommer wat gebruik word om 'n RTP-stroom te stuur of te ontvang ewe wees.

In situasies waar dit onmoontlik is om vooraf die ontvanger se adres te weet, word bedieners gebruik waar ontvangers hul adres verlaat, en die sender kan dit versoek deur na die een of ander unieke naam van die ontvanger te verwys.

In gevalle waar die kwaliteit van die kommunikasiekanaal of die vermoëns van die ontvanger onbekend is, word 'n terugvoerkanaal georganiseer waardeur die ontvanger die sender kan inlig oor sy vermoëns, die aantal pakkies wat hy gemis het, ens. Hierdie kanaal gebruik die RTCP-protokol. Die formaat van pakkies wat in hierdie kanaal versend word, word in RFC 3605 gedefinieer. Relatief min data word oor hierdie kanaal versend, 200...300 grepe per sekonde, so oor die algemeen is die teenwoordigheid daarvan nie lastig nie. Die poortnommer waarheen RTCP-pakkies gestuur word, moet vreemd wees en een groter as die poortnommer waaruit die RTP-stroom kom. In ons voorbeeld sal ons nie hierdie kanaal gebruik nie, aangesien die vermoëns van die ontvanger en kanaal natuurlik ons, tot dusver beskeie, behoeftes oorskry.

In ons program sal die data-oordragkring, anders as die vorige voorbeeld, in twee dele verdeel word: 'n versendingpad en 'n ontvangpad. Vir elke deel sal ons ons eie klokbron maak, soos in die titelprent getoon.

Eenrigtingkommunikasie tussen hulle sal met behulp van die RTP-protokol uitgevoer word. In hierdie voorbeeld het ons nie 'n eksterne netwerk nodig nie, aangesien beide die sender en die ontvanger op dieselfde rekenaar geleë sal wees - die pakkies sal daarin beweeg.

Om 'n RTP-stroom te vestig, gebruik die mediastreamer twee filters: MS_RTP_SEND en MS_RTP_RECV. Die eerste een stuur die tweede een en ontvang die RTP-stroom. Om hierdie filters te laat werk, moet hulle 'n wyser na 'n RTP-sessie-objek stuur, wat óf 'n stroom datablokke in 'n stroom RTP-pakkies kan omskep, óf die teenoorgestelde kan doen. Aangesien die interne dataformaat van die mediastreamer nie ooreenstem met die dataformaat van die RTP-pakkie nie, voordat die data na MS_RTP_SEND oorgedra word, moet jy 'n enkodeerderfilter gebruik wat 16-bis oudioseinmonsters omskakel in agtbis geënkodeer volgens die u-wet (mu-wet). Aan die ontvangkant voer die dekodeerderfilter die teenoorgestelde funksie uit.

Hieronder is die teks van die program wat die skema in die figuur implementeer (die # simbole voor die insluit-aanwysings is verwyder, moenie vergeet om dit in te sluit nie):

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

Ons stel saam en hardloop. Die program sal werk soos in die vorige voorbeeld, maar die data sal deur 'n RTP-stroom versend word.

In die volgende artikel sal ons hierdie program in twee onafhanklike toepassings verdeel - 'n ontvanger en 'n sender en dit in verskillende terminale begin. Terselfdertyd sal ons leer hoe om RTP-pakkies te ontleed met behulp van die TShark-program.

Bron: will.com