Вязмин В.И. Обзор существующих протоколов для программной реализации голосового мессенджера / В.И. Вязмин, А.В. Чернышова // Информатика, управляющие системы, математическое и компьютерное моделирование в рамках V форума Инновационные перспективы Донбасса (ПИИВС–2019) / Донец. национал. техн. ун-т; — Донецк, 2019. — C. 55-59 [Ссылка на сборник].

УДК 004.4

Обзор существующих протоколов для программной реализации голосового мессенджера

Вязмин В.И., Чернышова А.В.

Донецкий национальный технический университет

кафедра программной инженерии

E-mail: testerreality@gmail.com, chernyshova.alla@rambler.ru

Введение

Голосовые мессенджеры [1] приобрели свою популярность совсем недавно. Развитие данной отрасли берет своё начало в момент, когда средняя скорость интернета по всему миру стала достаточно комфортной для использования данных приложений даже на смартфонах. Мессенджер – это программа, мобильное приложение или веб-сервис для мгновенного обмена сообщениями, в данном случае, голосовыми. Данная отрасль начала развиваться достаточно бурно и эффективно, что привело к созданию по меньшей мере сотен, а то и тысячи мессенджеров.

Месенджеры – это новый способ коммуницирования между людьми, вне зависимости от географических особенностей, посредством обмена мгновенными сообщениями. В условиях развития интернета как публичного пространства с возможностью доступа к различной персональной информации у пользователей возникает потребность в осознанном потреблении и приватном взаимодействии. Потому и растет актуальность среди приложений, предоставляемых подобные возможности.

Основные подходы разработки голосовых мессенджеров

Каждый мессенджер включает в себя как клиентскую, так и серверную часть. Основной задачей мессенджеров является обеспечение связи (видео, голосовой и т.д.) между пользователями. Взаимодействие между клиентом и сервером, как правило, включает в себя обмен различными сигнальными данным (состояние присутствия, начало звонка и т.д.). Наиболее известным протоколом для этих целей служит XMPP [2]. Важной особенностью при передачи данных (в данном случае аудиоданных) является скорость. Основными протоколами для передачи данных являются TCP [3] и UDP [4]. TCP хоть и является надежным протоколом, однако он не походит для скоростной передачи потока медиа, а UDP протокол отлично с этим справляется, однако, данный протокол не гарантирует целостность доставленных данных, с чем ему на помощь для решения данной задачи приходит протокол RTP [5]. RTP является основным транспортным протоколом в сетях IP-телефонии [6].

Каждые несколько миллисекунд сервер запрашивает у пользователя его состояние активности (в сети ли он), при хорошем варианте развития событий, при окончании сессии пользователь должен послать сигнал серверу о том, что он вышел из сети, в ином же случае сервер запросит несколько раз состояние, и если его связь была внезапно прервана, и пользователь об этом не сообщил, соответственно ответа на сигнал об активности не будет, что свидетельствует о том, что пользователь сейчас не в сети (завершил сессию).

Если пользователю необходимо начать сеанс связи с одним из контактов, он посылает запрос об этом на сервер, как правило, за эту часть отвечает SIP-протокол [7]. В соответствии с архитектурой клиент сервер все сообщения подразделяются на запросы и ответы. Запросы передаются от клиента к серверу, ответы – от сервера к клиенту. Для установления соединения вызывающий пользователь формирует SIP-запрос, в котором сообщает серверу адрес вызываемого пользователя, характеристики каналов. В обратном направлении от вызываемого абонента к вызывающему передается ответ на запрос, также с определенными параметрами. Сообщения по протоколу SIP представляют набор текстовых строк. Однако, для этих целей часто используют и дугой протокол – Jingle [8].

Jingle – универсальный сигнальный протокол для XMPP. Данный протокол не отвечает за передачу данных, а только за организацию соединения. Два клиента, используя Jingle, оговаривают адреса, порты, тип передаваемых данных, кодеки, тип канала, используемые транспорты и другую информацию, необходимую для установки соединения, по которому уже будет происходить непосредственная передача данных. Сигнальный XMPP протокол Jingle работает поверх только XMPP (без использования SIP) из-за того, что создавать и поддерживать клиенты, реализующие два больших протокола вместо одного достаточно сложно. После согласования по протоколу Jingle начинается RTP/RTCP связь между клиентами, уже без непосредственного участия сервера. На рисунке 1 приведен пример согласования сеанса Jingle.

Стоит заметить, что для правильной работы необходим еще один протокол – SDP [9].

SDP (Session Description Protocol) – протокол согласования типа передаваемых данных (для звука и видео – это кодеки и их форматы, для факсов – скорость передачи и коррекция ошибок) и адреса их назначения (IP и порт). Параметры SDP передаются в теле SIP-пакетов, в данном случае, в теле Jingle-пакетов.

Протокол RTP

RTP (Real-time Transport Protocol) – протокол реального времени, был создан для передачи мультимедийной (ауди, видео), закодированной и упакованной в пакеты, информации по IP сетям в строгих временных рамках. Передача сегментов RTP происходит поверх протокола UDP , соответственно на разных уровнях модели OSI [10]. Использование протокола UDP, не гарантирующего доставку, связано со строгими временными рамками передачи мультимедийной информации в реальном времени, а также неспособностью протокола TCP работать в режиме реального времени. Поэтому, не смотря на потерю части данных своевременность доставки более важна в данном случае. Как было сказано ранее, данный протокол отвечает за передачу данных между клиентами.

В типичной среде реального времени отправитель генерирует пакеты с постоянной скоростью. Они отправляются через одинаковые интервалы времени, проходят через сеть и принимаются получателем, воспроизводящим данные в реальном времени при их получении. Однако ввиду изменения времени задержки при передаче пакетов по сети, они могут прибывать через нерегулярные интервалы времени. Для компенсации этого эффекта поступающие пакеты буферизуются, придерживаются на некоторое время и затем предоставляются с постоянной скоростью программному обеспечению, генерирующему вывод. Поэтому для функционирования протокола реального времени необходимо, чтобы каждый пакет содержал временную метку – тогда получатель сможет воспроизвести поступающие данные с той же скоростью, что и отправитель.

Реализацию функций RTP контролирует транспортный протокол управления передачей в режиме реального времени RTCP [11] – Real-time Transport Control Protocol. Он также отслеживает качество обслуживания и снабжает соответствующей информацией участников конференции. RTCP использует тот же самый базовый транспортный протокол, что и RTP (обычно UDP), но другой номер порта. RTP работает поверх UDP и может поддерживать передачу данных в реальном времени между несколькими участниками RTP-сеанса.

При организации аудио-конференции каждый участник должен иметь адрес и два порта, один для звуковых данных, другой для управляющих RTCP-пакетов. Эти параметры должны быть известны всем участникам конференции. При необходимости соблюдения конфиденциальности информация и пакеты управления могут быть зашифрованы. При аудио конференциях каждый из участников пересылает небольшие закодированные звуковые фрагменты длительностью порядка 20 мсек. Каждый из таких фрагментов помещается в поле данных RTP-пакета, который в свою очередь вкладывается в UDP-дейтаграмму [12].

Польку участники конференции могут как появляться, так и исчезать по своему усмотрению, полезно знать не только, кто из них присутствует в сети в данный момент, но и как до них доходят передаваемые данные. Для этой цели периодически каждый из участников транслирует через порт RTCP мультикастинг-сообщение, содержащее имя участника и диагностические данные. Узел-участник конференции шлет пакет BUY (RTCP), если он покидает сессию. На рисунке 2 представлена структурная схема протокола RTP.

В таблице 2 представлено объяснение структурной схемы протокола RTP.

Таблица 2 – Объяснение структурной схемы протокола RTP

Параметр EHL (Extension Header Length) означает количество 32-битных слов в блоке данных расширения заголовка, а L – это последний байт в пакете, определяющий длину области заполнения в байтах (используется для выравнивания в последнем пакете).

Протокол Jingle

Jingle – это дополнение к протоколу XMPP, позволяющее передавать между двумя клиентами аудио- и видеоданные. Согласование джингла может привести к установлению нескольких сеансов RTP (например, один для аудио и один для видео). Приложению следует учитывать, что все сеансы RTP, которые устанавливаются посредством одного и того же согласования Jingle, должны быть синхронизированы для потоковой передачи, воспроизведения, записи и т. д. На рисунке 3 приведен пример протокола Jingle.

Выводы

В наше время голосовые мессенджеры приобретают широкую популярность. В связи с этим, становится актуальным вопрос программной реализации подобных мессенджеров. Ознакомившись с протоколами, которые позволяют передавать аудиоданные в реальном времени, можно сделать вывод, что разработка данного мессенджера достаточно трудоемкая работа, которая требует точности. Разнообразие технологий и языков для реализации достаточно обширно, что дает большую свободу в действиях, но основным звеном для создания небольшого десктопного голосового мессенджера все же является связь протоколов XMPP, Jingle и RTP.

Литература

1. Обзор мессенджеров. Лучшие и популярные интернет мессенджеры // VoIPOFfice [Электронный ресурс] – Электрон. дан. – 2018. – Режим доступа: http://www.voipoffice.ru/tags/messendzhery. – Загл. с экрана.
2. XMPP (Extensible Messaging and Presence Protocol) // Национальная библиотека им. Н. Э. Баумана [Электронный ресурс] – Электрон. дан. – 2017. – Режим доступа: https://ru.bmstu.wiki/XMPP_(Extensible_Messaging_and_Presence_Protocol). – Загл. с экрана.
3. TCP // Линчакин [Электронный ресурс] – Электрон. дан. – 2019. – Режим доступа: https://linchakin.com/словарь/t/tcp. – Загл. с экрана.
4. Транспортные протоколы – UDP // Vanderboot [Электронный ресурс] – Электрон. дан. – 2019. – Режим доступа http://www.vanderboot.ru/tcp-ip/tcp-udp.php. – Загл. с экрана.
5. Протокол реального времени RTP // citforum [Электронный ресурс] – Электрон. дан. – 2004. – Режим доступа: http://citforum.ru/nets/semenov/4/44/rtp_4492.shtml. – Загл. с экрана.
6. IP-Телефония: от медных проводов до цифровой обработки криптопримитива / Promwad // habr [Электронный ресурс] – Электрон. дан. – 2013. – Режим доступа: https://habr.com/ru/company/promwad/blog/188336/. – Загл. с экрана.
7. SIP-сообщения // ICX [Электронный ресурс] – Электрон. дан. – 2015. – Режим доступа: http://www.ixc.ua/109. – Загл. с экрана.
8. Jingle // jabberworld [Электронный ресурс] – Электрон. дан. – 2013. – Режим доступа: http://jabberworld.info/Jingle. – Загл. с экрана.
9. Основы протокола SDP // voipnotes [Электронный ресурс] – Электрон. дан. – 2019. – Режим доступа https://voipnotes.ru/basic-knowledge-of-sdp/. – Загл. с экрана.
10. Сетевая модель OSI // Википедия [Электронный ресурс] – Электрон. дан. – 2019. – Режим доступа: https://ru.wikipedia.org/wiki/Сетевая_модель_OSI. – Загл. с экрана.
11. RTCP // Национальная библиотека им. Н. Э. Баумана [Электронный ресурс] – Электрон. дан. – 2017. – Режим доступа: https://ru.bmstu.wiki/RTCP_(Real-time_Transport_Control_Protocol). – Загл. с экрана.
12. Протокол UDP и UDP-дейтаграммы // Компьютерные сети [Электронный ресурс] – Электрон. дан. – 2019. – Режим доступа: http://iptcp.net/protokol-udp-i-udp-deitagrammy.html. – Загл. с экрана.