Exploring the VoIP engine Mediastreamer2. Part 6

The article material is taken from my Zen channel.

Transmission of audio signals via RTP stream

Previously article We have assembled a remote control scheme from a generator and a detector of tone signals, which work within one program. In this article, we will learn to use the RTP protocol (RFC 3550 — RTP: A Transport Protocol for Real-Time Applications) for receiving/transmitting audio signals over an Ethernet network.

The RTP protocol (Real Time Protocol) refers to a real-time protocol that is used for transmitting audio, video, data, and anything that requires real-time delivery. As an example, let's take an audio signal. The flexibility of the protocol allows transmitting audio signals with a predefined quality.

Transmission is carried out using UDP packets, which means that loss of packets is acceptable during transmission. Each packet includes a special RTP header and a block of transmitted signal data. The header contains a randomly selected source identifier, information about the type of transmitted signal, and a unique sequence number for packets so that they can be arranged in the correct order during decoding, regardless of the order delivered by the network. The header may also contain additional information, called extensions, which adapt the header for use in a specific application task.

The data block contains the payload of the packet. The internal organization of the content depends on the type of payload; this may include samples of mono audio signals, stereo signals, or a line of video images, etc.

The type of payload is indicated by a seven-bit number. RFC3551 recommendation (RTP Profile for Audio and Video Conferences with Minimal Control) specifies several types of payload in the corresponding table, providing descriptions of types of payloads and the values of the codes that represent them. Some codes do not have a strict association with any payload type—they can be used to represent arbitrary payloads.

The size of a data block is limited by the maximum transmission unit (MTU) that can be transmitted over this network without segmentation. In general, this is no more than 1500 bytes. Thus, to increase the amount of data transmitted per second, the packet size can be increased up to a certain point, after which it will be necessary to increase the transmission frequency of the packets. For media streamers, this is a configurable parameter. By default, it is set to 50 Hz, meaning 50 packets per second. The sequence of transmitted RTP packets will be referred to as the RTP stream.

To start transmitting data between the source and the receiver, the transmitter only needs to know the receiver's IP address and the port number that it uses for receiving. This means that without any preliminary procedures, the source begins to transmit data, and the receiver is ready to immediately accept and process it. According to the standard, the port number used for sending or receiving the RTP stream must be even.

In situations where the receiver's address cannot be known in advance, servers are used where receivers leave their address, and the transmitter can request it by referring to a unique identifier for the receiver.

In cases where the quality of the communication channel or the capabilities of the receiver are unknown, a feedback channel is established, allowing the receiver to inform the transmitter about its capabilities, the number of packets it has missed, etc. The RTCP protocol is used in this channel. The packet format sent through this channel is defined in RFC 3605. Relatively few data (200–300 bytes per second) are sent through this channel, so its presence is not burdensome. The port number for sending RTCP packets must be odd and one more than the port number from which the RTP stream comes. In our example, we will not use this channel, as the capabilities of the receiver and channel are already known to exceed our modest needs.

In our program, the data transmission scheme, unlike the scheme from the previous example, will be divided into two parts: the transmitting path and the receiving path. For each part, we will create our own clock source, as shown in the title image.

The one-way communication between them will occur using the RTP protocol. In this example, an external network is not required, as both the transmitter and receiver will be located on the same computer — the packets will be transmitted internally.

To establish an RTP stream in the media streamer, two filters are used: MS_RTP_SEND and MS_RTP_RECV. The first handles the transmission, while the second receives the RTP stream. For these filters to operate, they need to be provided with a pointer to the RTP session object, which can transform a stream of data blocks into a stream of RTP packets and vice versa. Since the internal data format of the media streamer does not match the RTP packet data format, a converter filter (encoder) must be used before sending data to MS_RTP_SEND, which converts 16-bit sound signal samples into eight-bit samples encoded according to the u-law (mu-law). On the receiving side, the decoder filter performs the reverse function.

Below is the program code that implements the scheme shown in the figure (remove the # symbols before the include directives, and don't forget to add them back):

/* Файл 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 compile and run it. The program will function as in the previous example, but the data will be transmitted via the RTP stream.

In the next article, we will split this program into two separate applications — the receiver and the transmitter, and will run them in different terminals. Meanwhile, we will learn to analyze RTP packets using the TShark program.

Source: habr.com