Archwilio peiriant VoIP Mediastreamer2. Rhan 6

Mae deunydd yr erthygl yn cael ei gymryd o fy sianel zen.

Trosglwyddo signal sain trwy ffrwd CTRh

Yn yr olaf Erthygl Rydym wedi cydosod cylched rheoli o bell o generadur tôn a synhwyrydd tôn sy'n gweithredu o fewn yr un rhaglen. Yn yr erthygl hon byddwn yn dysgu sut i ddefnyddio'r protocol CTRh (RFC 3550 - CTRh: Protocol Trafnidiaeth ar gyfer Cymwysiadau Amser Real) ar gyfer derbyn/trosglwyddo signal sain dros rwydwaith Ethernet.

Protocol RTP (Protocol Amser Real) Mae cyfieithu yn golygu protocol amser real, fe'i defnyddir i drosglwyddo sain, fideo, data, popeth y mae angen ei drosglwyddo mewn amser real. Gadewch i ni gymryd signal sain fel enghraifft. Mae hyblygrwydd y protocol yn golygu ei fod yn caniatáu ichi drosglwyddo signal sain o ansawdd a bennwyd ymlaen llaw.

Gwneir y trosglwyddiad gan ddefnyddio pecynnau CDU, sy'n golygu bod colli pecynnau yn eithaf derbyniol wrth drosglwyddo. Mae pob pecyn yn cynnwys pennawd RTP arbennig a bloc data o'r signal a drosglwyddir. Mae'r pennawd yn cynnwys dynodwr ffynhonnell signal a ddewiswyd ar hap, gwybodaeth am y math o signal sy'n cael ei drosglwyddo, a rhif dilyniant pecyn unigryw fel y gellir trefnu'r pecynnau yn y drefn gywir wrth ddatgodio, waeth ym mha drefn y cawsant eu danfon gan y rhwydwaith. Gall y pennawd hefyd gynnwys gwybodaeth ychwanegol, yr estyniad fel y'i gelwir, sy'n caniatáu i'r pennawd gael ei addasu i'w ddefnyddio mewn tasg cais penodol.

Mae'r bloc data yn cynnwys llwyth tâl y pecyn. Mae trefniadaeth fewnol y cynnwys yn dibynnu ar y math o lwyth, gall fod yn samplau o signal mono, signal stereo, llinell delwedd fideo, ac ati.

Mae'r math o lwyth yn cael ei nodi gan rif saith-did. Argymhelliad RFC3551 (Proffil CTRh ar gyfer Cynadleddau Sain a Fideo gyda Rheolaeth Leiaf) yn sefydlu sawl math o lwyth; mae'r tabl cyfatebol yn rhoi disgrifiad o'r mathau o lwyth ac ystyr y codau y maent wedi'u dynodi ganddynt. Nid yw rhai codau wedi'u cysylltu'n llym ag unrhyw fath o lwyth; gellir eu defnyddio i ddynodi llwyth mympwyol.

Mae maint bloc data wedi'i gyfyngu uchod gan yr uchafswm maint pecyn y gellir ei drosglwyddo ar rwydwaith penodol heb segmentiad (paramedr MTU). Yn gyffredinol, nid yw hyn yn fwy na 1500 beit. Felly, er mwyn cynyddu faint o ddata a drosglwyddir yr eiliad, gallwch gynyddu maint y pecyn hyd at bwynt penodol, ac yna bydd angen i chi gynyddu amlder anfon pecynnau. Mewn ffrwdiwr cyfryngau, mae hwn yn osodiad ffurfweddadwy. Yn ddiofyn mae'n 50 Hz, h.y. 50 pecyn yr eiliad. Byddwn yn galw dilyniant y pecynnau CTRh a drosglwyddir yn ffrwd CTRh.

I ddechrau trosglwyddo data rhwng y ffynhonnell a'r derbynnydd, mae'n ddigon bod y trosglwyddydd yn gwybod cyfeiriad IP y derbynnydd a'r rhif porthladd y mae'n ei ddefnyddio i'w dderbyn. Y rhai. heb unrhyw weithdrefnau rhagarweiniol, mae'r ffynhonnell yn dechrau trosglwyddo data, ac mae'r derbynnydd, yn ei dro, yn barod i'w dderbyn a'i brosesu ar unwaith. Yn ôl y safon, rhaid i'r rhif porthladd a ddefnyddir i drosglwyddo neu dderbyn ffrwd CTRh fod yn wastad.

Mewn sefyllfaoedd lle mae'n amhosibl gwybod cyfeiriad y derbynnydd ymlaen llaw, defnyddir gweinyddion lle mae derbynwyr yn gadael eu cyfeiriad, a gall y trosglwyddydd ofyn amdano trwy gyfeirio at enw unigryw'r derbynnydd.

Mewn achosion lle nad yw ansawdd y sianel gyfathrebu neu alluoedd y derbynnydd yn hysbys, trefnir sianel adborth lle gall y derbynnydd hysbysu'r trosglwyddydd am ei alluoedd, nifer y pecynnau a fethodd, ac ati. Mae'r sianel hon yn defnyddio'r protocol RTCP. Diffinnir fformat y pecynnau a drosglwyddir yn y sianel hon yn RFC 3605. Cymharol ychydig o ddata a drosglwyddir dros y sianel hon, 200..300 bytes yr eiliad, felly yn gyffredinol, nid yw ei bresenoldeb yn feichus. Rhaid i rif y porthladd yr anfonir pecynnau RTCP iddo fod yn odrif ac un yn fwy na rhif y porthladd y daw'r ffrwd CTRh ohono. Yn ein hesiampl ni, ni fyddwn yn defnyddio'r sianel hon, gan fod galluoedd y derbynnydd a'r sianel yn amlwg yn fwy na'n hanghenion, hyd yn hyn cymedrol.

Yn ein rhaglen, bydd y gylched trosglwyddo data, yn wahanol i'r enghraifft flaenorol, yn cael ei rannu'n ddwy ran: llwybr trawsyrru a llwybr derbyn. Ar gyfer pob rhan byddwn yn gwneud ein ffynhonnell cloc ein hunain, fel y dangosir yn y llun teitl.

Bydd cyfathrebu un ffordd rhyngddynt yn cael ei wneud gan ddefnyddio protocol y Cynllun Trafnidiaeth Rhanbarthol. Yn yr enghraifft hon, nid oes angen rhwydwaith allanol arnom, gan y bydd y trosglwyddydd a'r derbynnydd wedi'u lleoli ar yr un cyfrifiadur - bydd y pecynnau'n teithio y tu mewn iddo.

I sefydlu ffrwd RTP, mae'r ffrwdiwr cyfryngau yn defnyddio dwy hidlydd: MS_RTP_SEND ac MS_RTP_RECV. Mae'r un cyntaf yn trosglwyddo'r ail un ac yn derbyn y ffrwd CTRh. Er mwyn i'r hidlwyr hyn weithio, mae angen iddynt drosglwyddo pwyntydd i wrthrych sesiwn CTRh, a all naill ai drosi llif o flociau data yn ffrwd o becynnau CTRh neu wneud y gwrthwyneb. Gan nad yw fformat data mewnol y ffrwdiwr cyfryngau yn cyd-fynd â fformat data'r pecyn CTRh, cyn trosglwyddo'r data i MS_RTP_SEND, mae angen i chi ddefnyddio hidlydd amgodiwr sy'n trosi samplau signal sain 16-did yn wyth-did wedi'u hamgodio yn ôl y u-gyfraith (mu-law). Ar yr ochr dderbyn, mae'r hidlydd datgodiwr yn cyflawni'r swyddogaeth gyferbyn.

Isod mae testun y rhaglen sy'n gweithredu'r cynllun a ddangosir yn y ffigur (mae'r # symbolau cyn i'r cyfarwyddebau cynnwys gael eu dileu, peidiwch ag anghofio eu cynnwys):

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

Rydym yn llunio ac yn rhedeg. Bydd y rhaglen yn gweithio fel yn yr enghraifft flaenorol, ond bydd y data'n cael ei drosglwyddo trwy ffrwd CTRh.

Yn yr erthygl nesaf byddwn yn rhannu'r rhaglen hon yn ddau gais annibynnol - derbynnydd a throsglwyddydd a'u lansio mewn gwahanol derfynellau. Ar yr un pryd, byddwn yn dysgu sut i ddadansoddi pecynnau CTRh gan ddefnyddio rhaglen TShark.

Ffynhonnell: hab.com