Всем привет! Как и обещал, продолжаю публиковать цикл статей про VoIP.
Первую часть можно прочитать тут.
В этой статье, мы продолжим знакомиться с технологией VoIP, а именно, рассмотрим транспортные протоколы, протоколы описывающие передачу данных и способы кодирования речи.
Структура будет выглядеть таким образом:
Транспортный уровень - 4-й уровень модели OSI, предназначен для доставки данных. Важно понять, что уровень является именно механизмом передачи данных. Блоки данных он разделяет на фрагменты, размеры которых зависят от протокола: короткие объединяет в один, а длинные разбивает. Протоколы этого уровня предназначены для взаимодействия типа точка-точка.
Пример: TCP, UDP, SCTP, RTP.
Существует немало классов протоколов транспортного уровня, от протоколов, предоставляющих только основные транспортные функции, например, функции передачи данных без подтверждения приема, и, заканчивая протоколами, которые гарантируют доставку в пункт назначения нескольких пакетов данных в заданной последовательности, мультиплексируют несколько потоков данных, обеспечивают механизм управления потоками данных и гарантируют достоверность принятых данных.
Ниже, моя любимая схема уровней OSI:
В нашем случае, доставка данных, в частности голоса, ложится на плечи RTP – протоколу, о нем немного позже.
UDP: использование UDP в VoIP.
UDP (User Datagram Protocol) — один из ключевых элементов TCP/IP, набора сетевых протоколов для Интернета. С UDP компьютерные приложения могут посылать сообщения (датаграммы) другим хостам по IP-сети без необходимости предварительного сообщения для установки специальных каналов передачи или путей данных.
UDP не предоставляет никаких гарантий доставки сообщения для вышестоящего протокола и не сохраняет состояния отправленных сообщений. По этой причине UDP иногда называют ненадёжный протокол датаграмм (Unreliable Datagram Protocol).
UDP обеспечивает многоканальную передачу (с помощью номеров портов) и проверку целостности (с помощью контрольных сумм) заголовка и существенных данных.
Контрольная сумма в примере ниже - 0x77e2
Фактически функции UDP сводятся к операциям мультиплексирования и демультиплексирования, а также несложной проверке наличия ошибок в данных. Таким образом, при использовании UDP приложение почти напрямую взаимодействует с протоколом сетевого уровня IP.
UDP получает сообщения от прикладного уровня, добавляет к ним поля номеров портов отправителя и получателя для демультиплексирования приемной стороной, а также два других специальных поля и передает полученный сегмент сетевому уровню. Сетевой уровень заключает сегмент в дейтаграмму и «по возможности» передает ее хосту назначения. Если последний успешно получает сегмент, протокол UDP с помощью поля номера порта получателя направляет данные сегмента нужному процессу.
В связи с чувствительным ко времени характером голосового трафика, для передачи голоса логично было выбрать протокол UDP/IP. Однако передача «пакет за пакетом», характерная для протокола UDP, обеспечивает недостаточно подробную информацию, чем необходимо. Для передачи в реальном масштабе времени, а также для передачи трафика, чувствительного к задержке, Инженерная Группа по Решению Задач Интернета, (Internet Engineering Task Force – IETF) выбрала протокол RTP. Данные VoIP передаются поверх протокола RTP, который в свою очередь, передается поверх протокола UDP. Следовательно, пакет VoIP передается с заголовком пакета RTP/UDP/IP.
RTP: использование RTP в VoIP.
Протокол RTP (Real-Time Transport Protocol) используется при передаче трафика реального времени.
В приложениях реального времени отправитель генерирует поток данных с постоянной скоростью, а получатель должен предоставлять эти данные приложению с той же самой скоростью. Такие приложения включают, аудио- и видеоконференции, потоковое видео, удаленную диагностику в медицине, IP - телефонию, распределенное интерактивное моделирование, игры, мониторинг в реальном времени и т.д.
Несмотря на то, что RTP принято считать протоколом транспортного уровня, как правило, он работает поверх UDP. С помощью RTP реализуется распознавание типа трафика, работа с метками времени, контроль передачи и нумерация последовательности пакетов.
Наличие RTP в дампе звонка:
Основное назначение RTP состоит в том, что он присваивает каждому исходящему пакету временные метки, обрабатывающиеся на приемной стороне. Это позволяет принимать данные в надлежащем порядке, снижает влияние неравномерности времени прохождения пакетов по сети, восстанавливает синхронизацию между аудио и видео данными.
Вот как они выглядят в дампе:
Пакеты, содержащие передаваемый голос, передаются с использованием RTP/RTCP для протокола SIP, который используется для VOIP вызовов. Протокол RTP может передавать медиа-данные, идентифицируемые параметрами, которые зарегистрированы организацией: "Internet assigned numbers authority" - IANA. Они так же используются для полей в протоколе SDP, который используется в SIP и MGCP сообщениях.
SDP - протокол описания сеанса. (Session Description Protocol)
Перед тем как состоится голосовой или видео вызов, двум IP устройствам, использующим протокол SIP, необходимо согласовать параметры вызова, такие как транспортные адреса, аудио/видео кодеки, порты и другие данные.
SDP- это не аудио/видео поток или медиа данные. Протокол предназначен для широкого использования в различных приложениях и протоколах связи, может использовать любые транспортные протоколы, например SIP или HTTP.
Протокол SDP можно разделить на три части.
o= (owner/creator and session identification) – информация о создателе сессии и её ID
s= (session name) – название сессии
i= (session information)* – информация о сессии
u= (URI of description)* – URL адрес описания
e= (email address – contact detail)* – контактный email
p= (phone number – contact detail)* – контактный телефон
c= (connection information)* – информация о подключении, не обязательна, если включена в media description
b= (session bandwidth information)* – информация о полосе пропускания
z= (time zone adjustments)* – корректировка часового пояса
k= (encryption key)* – ключ шифрования
a= (zero or more session attribute lines)* – дополнительные поля
r= (repeat times)* – число повторений
i= (media title)* – медиа заголовок
c= (connection information)* – информация о подключении, не обязательна, если включена в session description
b= (bandwidth information)* – информация о пропускной способности
k= (encryption key)* – ключ шифрования
a= (zero or more media attribute lines)* – дополнительные поля
Поля отмеченные * – необязательные
Ниже, пример SDP параметров из сообщения INVITE:
В приведенном выше примере сообщения SDP содержится следующая информация. Пользователь, имеющий буквенный идентификатор nxtnyc09, запрашивает SDP сессию с идентификатором 19018325 и 0 версией. Параметр IN указывает на сетевой протокол создателя сессии, в данном примере “IN” — интернет, IP4 — тип IP-адреса создателя сессии, в данном примере IPv4. Адрес инициатора сессии 127.0.0.1. Имя устройства, инициирующего сессию – sip call. Медиа-трафик будет ожидаться на устройстве с IP-адресом 127.0.0.2, на порту 28528.
Время начала и окончания сессии жестко не ограничены (t=0 0).
Данное устройство поддерживает набор параметров RTP потока мультимедиа-данных и методы его кодирования (профилей RTP), описанных при помощи типов:
Так, под типом данных 8 данное устройство подразумевает голосовой кодек PCMA и частотой дискретизации 8000Гц.( ITU-T G.711 PCM A-Law звук 64 Кбит/с)
Тип данных 0 – PCMU голосовой кодек с частотой дискретизации 8000Гц (ITU-T G.711 PCM µ-Law звук 64 Кбит/с)
Тип данных 18 - Голосовой кодек G729 с частотой дискретизации 8000Гц (ITU-T G.729 и G.729a звук 8 Кбит/с). Это может означать, что устройство поддерживает голосовой кодек G.729, вместе с более простой вариацией того же кодека, описанного в приложении Annex A (или кодек G.729a), так как тип данных 18 однозначно закреплён за этими кодеками.
Динамический тип данных 101 в данном случае — это возможность приёма тональных сигналов DTMF (telephone event) по стандарту, описанному в RFC 2833. Согласно строке a=ftmp для типа 101, устройство может работать с событиями DTMF от 0 до 15. Все SIP-устройства должны поддерживать DTMF-события от 0 до 15, которые являются цифрами 0-9 (номера), 10 — это символ "звёздочка" (*), 11 — "решётка" (#) и 12-15 являются символами A-D.
Приведённый порядок перечисления кодеков также указывает на приоритеты выбора того или иного кодека с точки зрения данного устройства.
В примере ниже, SDP в структуре SIP протокола:
Алгоритмы кодирования/декодирования речевой информации.
Эффективность использования пропускной способности IP-сети существенным образом зависит от выбора оптимального алгоритма кодирования/декодирования речевой информации – кодека.
Под телефонными (VoIP) кодеками понимаются различные математические модели используемые для цифрового кодирования и компрессирования (сжатия) аудио информации. Многие из современных кодеков используют особенности восприятия человеческим мозгом неполной информации: алгоритмы голосового сжатия пользуются этими особенностями, вследствие чего не полностью услышанная информация полностью интерпретируется головным мозгом. Основным смыслом таких кодеков является сохранение баланса между эффективностью передачи данных и их качеством. Изначально, термин кодек происходил от сочетания слов КОДирование/ДЕКодирование, то есть устройств, которые преобразовывали аналог в цифровую форму. В современном мире телекоммуникаций, слово кодек скорее берет начало от сочетания КОмпрессия/ДЕКомпрессия.
Для передачи голоса по IP-сети человеческий голос оцифровывается при помощи импульсно-кодовой модуляции, сжимается (кодируется) и разбивается на пакеты. На принимающей стороне происходит обратная процедура — данные извлекаются из пакетов, декодируются и преобразуются обратно в аналоговый сигнал.
Кодирование вносит дополнительную задержку порядка 15—45 мс, возникающую по следующим причинам:
Задержку кодека необходимо учитывать при расчёте сквозных задержек. Кроме того, сложные алгоритмы кодирования/декодирования требуют более серьёзных затрат вычислительных ресурсов системы.
Проведённый в различных исследовательских группах анализ качества передачи речевых данных через Интернет показывает, что основным источником возникновения искажений, снижения качества и разборчивости синтезированной речи является прерывание потока речевых данных, вызванное:
Все существующие типы речевых кодеков по принципу действия можно разделить на три группы:
Так же, кодирование сигнала должно обеспечивать эхоподавление. Сжатие голосового трафика позволяет экономить трафик, это очень важно, если вы имеете большое количество телефонных разговоров (подключений) одновременно. Еще одним из способов уменьшения трафика, является метод подавления пауз, т.е. когда в телефонном разговоре наступает пауза, пакеты не передаются в сеть.
Ниже представлена таблица с описанием основных аудио кодеков, которые применяются в IP телефонии.
В современных реалиях, в основном используется 711 и 729 кодек, остальное, скорее тонкости при работе с различными клиентами и поставщиками, т.е. необходимо иметь возможность предоставить различные варианты комфортного подключения и в дальнейшем продуктивного сотрудничества.
Вывод:
Первую часть можно прочитать тут.
В этой статье, мы продолжим знакомиться с технологией VoIP, а именно, рассмотрим транспортные протоколы, протоколы описывающие передачу данных и способы кодирования речи.
Структура будет выглядеть таким образом:
- Транспортный уровень OSI. Транспортные протоколы.
- UDP: использование UDP в VoIP.
- RTP: использование RTP в VoIP.
- SDP - протокол описания сеанса.
- Алгоритмы кодирования/декодирования речевой информации.
Транспортный уровень - 4-й уровень модели OSI, предназначен для доставки данных. Важно понять, что уровень является именно механизмом передачи данных. Блоки данных он разделяет на фрагменты, размеры которых зависят от протокола: короткие объединяет в один, а длинные разбивает. Протоколы этого уровня предназначены для взаимодействия типа точка-точка.
Пример: TCP, UDP, SCTP, RTP.
Существует немало классов протоколов транспортного уровня, от протоколов, предоставляющих только основные транспортные функции, например, функции передачи данных без подтверждения приема, и, заканчивая протоколами, которые гарантируют доставку в пункт назначения нескольких пакетов данных в заданной последовательности, мультиплексируют несколько потоков данных, обеспечивают механизм управления потоками данных и гарантируют достоверность принятых данных.
Ниже, моя любимая схема уровней OSI:
В нашем случае, доставка данных, в частности голоса, ложится на плечи RTP – протоколу, о нем немного позже.
UDP: использование UDP в VoIP.
UDP (User Datagram Protocol) — один из ключевых элементов TCP/IP, набора сетевых протоколов для Интернета. С UDP компьютерные приложения могут посылать сообщения (датаграммы) другим хостам по IP-сети без необходимости предварительного сообщения для установки специальных каналов передачи или путей данных.
UDP не предоставляет никаких гарантий доставки сообщения для вышестоящего протокола и не сохраняет состояния отправленных сообщений. По этой причине UDP иногда называют ненадёжный протокол датаграмм (Unreliable Datagram Protocol).
UDP обеспечивает многоканальную передачу (с помощью номеров портов) и проверку целостности (с помощью контрольных сумм) заголовка и существенных данных.
Контрольная сумма в примере ниже - 0x77e2
Фактически функции UDP сводятся к операциям мультиплексирования и демультиплексирования, а также несложной проверке наличия ошибок в данных. Таким образом, при использовании UDP приложение почти напрямую взаимодействует с протоколом сетевого уровня IP.
UDP получает сообщения от прикладного уровня, добавляет к ним поля номеров портов отправителя и получателя для демультиплексирования приемной стороной, а также два других специальных поля и передает полученный сегмент сетевому уровню. Сетевой уровень заключает сегмент в дейтаграмму и «по возможности» передает ее хосту назначения. Если последний успешно получает сегмент, протокол UDP с помощью поля номера порта получателя направляет данные сегмента нужному процессу.
В связи с чувствительным ко времени характером голосового трафика, для передачи голоса логично было выбрать протокол UDP/IP. Однако передача «пакет за пакетом», характерная для протокола UDP, обеспечивает недостаточно подробную информацию, чем необходимо. Для передачи в реальном масштабе времени, а также для передачи трафика, чувствительного к задержке, Инженерная Группа по Решению Задач Интернета, (Internet Engineering Task Force – IETF) выбрала протокол RTP. Данные VoIP передаются поверх протокола RTP, который в свою очередь, передается поверх протокола UDP. Следовательно, пакет VoIP передается с заголовком пакета RTP/UDP/IP.
RTP: использование RTP в VoIP.
Протокол RTP (Real-Time Transport Protocol) используется при передаче трафика реального времени.
В приложениях реального времени отправитель генерирует поток данных с постоянной скоростью, а получатель должен предоставлять эти данные приложению с той же самой скоростью. Такие приложения включают, аудио- и видеоконференции, потоковое видео, удаленную диагностику в медицине, IP - телефонию, распределенное интерактивное моделирование, игры, мониторинг в реальном времени и т.д.
Несмотря на то, что RTP принято считать протоколом транспортного уровня, как правило, он работает поверх UDP. С помощью RTP реализуется распознавание типа трафика, работа с метками времени, контроль передачи и нумерация последовательности пакетов.
Наличие RTP в дампе звонка:
Основное назначение RTP состоит в том, что он присваивает каждому исходящему пакету временные метки, обрабатывающиеся на приемной стороне. Это позволяет принимать данные в надлежащем порядке, снижает влияние неравномерности времени прохождения пакетов по сети, восстанавливает синхронизацию между аудио и видео данными.
Вот как они выглядят в дампе:
Пакеты, содержащие передаваемый голос, передаются с использованием RTP/RTCP для протокола SIP, который используется для VOIP вызовов. Протокол RTP может передавать медиа-данные, идентифицируемые параметрами, которые зарегистрированы организацией: "Internet assigned numbers authority" - IANA. Они так же используются для полей в протоколе SDP, который используется в SIP и MGCP сообщениях.
SDP - протокол описания сеанса. (Session Description Protocol)
Перед тем как состоится голосовой или видео вызов, двум IP устройствам, использующим протокол SIP, необходимо согласовать параметры вызова, такие как транспортные адреса, аудио/видео кодеки, порты и другие данные.
SDP- это не аудио/видео поток или медиа данные. Протокол предназначен для широкого использования в различных приложениях и протоколах связи, может использовать любые транспортные протоколы, например SIP или HTTP.
Протокол SDP можно разделить на три части.
- Session description (Описание сессии)
- Time description (Описание времени) - описывает временные параметры сессии.
- Media description (Описание медиа параметров), описывает медиа данные, которые будут использоваться в будущем соединении.
- Session Description- Описание сессии
o= (owner/creator and session identification) – информация о создателе сессии и её ID
s= (session name) – название сессии
i= (session information)* – информация о сессии
u= (URI of description)* – URL адрес описания
e= (email address – contact detail)* – контактный email
p= (phone number – contact detail)* – контактный телефон
c= (connection information)* – информация о подключении, не обязательна, если включена в media description
b= (session bandwidth information)* – информация о полосе пропускания
z= (time zone adjustments)* – корректировка часового пояса
k= (encryption key)* – ключ шифрования
a= (zero or more session attribute lines)* – дополнительные поля
- Time description- Описание времени
r= (repeat times)* – число повторений
- Media description- Описание медиа параметров
i= (media title)* – медиа заголовок
c= (connection information)* – информация о подключении, не обязательна, если включена в session description
b= (bandwidth information)* – информация о пропускной способности
k= (encryption key)* – ключ шифрования
a= (zero or more media attribute lines)* – дополнительные поля
Поля отмеченные * – необязательные
Ниже, пример SDP параметров из сообщения INVITE:
В приведенном выше примере сообщения SDP содержится следующая информация. Пользователь, имеющий буквенный идентификатор nxtnyc09, запрашивает SDP сессию с идентификатором 19018325 и 0 версией. Параметр IN указывает на сетевой протокол создателя сессии, в данном примере “IN” — интернет, IP4 — тип IP-адреса создателя сессии, в данном примере IPv4. Адрес инициатора сессии 127.0.0.1. Имя устройства, инициирующего сессию – sip call. Медиа-трафик будет ожидаться на устройстве с IP-адресом 127.0.0.2, на порту 28528.
Время начала и окончания сессии жестко не ограничены (t=0 0).
Данное устройство поддерживает набор параметров RTP потока мультимедиа-данных и методы его кодирования (профилей RTP), описанных при помощи типов:
- Payload type – 8, 0, 18, 101
Так, под типом данных 8 данное устройство подразумевает голосовой кодек PCMA и частотой дискретизации 8000Гц.( ITU-T G.711 PCM A-Law звук 64 Кбит/с)
Тип данных 0 – PCMU голосовой кодек с частотой дискретизации 8000Гц (ITU-T G.711 PCM µ-Law звук 64 Кбит/с)
Тип данных 18 - Голосовой кодек G729 с частотой дискретизации 8000Гц (ITU-T G.729 и G.729a звук 8 Кбит/с). Это может означать, что устройство поддерживает голосовой кодек G.729, вместе с более простой вариацией того же кодека, описанного в приложении Annex A (или кодек G.729a), так как тип данных 18 однозначно закреплён за этими кодеками.
Динамический тип данных 101 в данном случае — это возможность приёма тональных сигналов DTMF (telephone event) по стандарту, описанному в RFC 2833. Согласно строке a=ftmp для типа 101, устройство может работать с событиями DTMF от 0 до 15. Все SIP-устройства должны поддерживать DTMF-события от 0 до 15, которые являются цифрами 0-9 (номера), 10 — это символ "звёздочка" (*), 11 — "решётка" (#) и 12-15 являются символами A-D.
Приведённый порядок перечисления кодеков также указывает на приоритеты выбора того или иного кодека с точки зрения данного устройства.
В примере ниже, SDP в структуре SIP протокола:
Алгоритмы кодирования/декодирования речевой информации.
Эффективность использования пропускной способности IP-сети существенным образом зависит от выбора оптимального алгоритма кодирования/декодирования речевой информации – кодека.
Под телефонными (VoIP) кодеками понимаются различные математические модели используемые для цифрового кодирования и компрессирования (сжатия) аудио информации. Многие из современных кодеков используют особенности восприятия человеческим мозгом неполной информации: алгоритмы голосового сжатия пользуются этими особенностями, вследствие чего не полностью услышанная информация полностью интерпретируется головным мозгом. Основным смыслом таких кодеков является сохранение баланса между эффективностью передачи данных и их качеством. Изначально, термин кодек происходил от сочетания слов КОДирование/ДЕКодирование, то есть устройств, которые преобразовывали аналог в цифровую форму. В современном мире телекоммуникаций, слово кодек скорее берет начало от сочетания КОмпрессия/ДЕКомпрессия.
Для передачи голоса по IP-сети человеческий голос оцифровывается при помощи импульсно-кодовой модуляции, сжимается (кодируется) и разбивается на пакеты. На принимающей стороне происходит обратная процедура — данные извлекаются из пакетов, декодируются и преобразуются обратно в аналоговый сигнал.
Кодирование вносит дополнительную задержку порядка 15—45 мс, возникающую по следующим причинам:
- Использование буфера для накопления сигнала и учёта статистики последующих отсчётов (алгоритмическая задержка);
- Математические преобразования, выполняемые над речевым сигналом, требуют процессорного времени (вычислительная задержка).
Задержку кодека необходимо учитывать при расчёте сквозных задержек. Кроме того, сложные алгоритмы кодирования/декодирования требуют более серьёзных затрат вычислительных ресурсов системы.
Проведённый в различных исследовательских группах анализ качества передачи речевых данных через Интернет показывает, что основным источником возникновения искажений, снижения качества и разборчивости синтезированной речи является прерывание потока речевых данных, вызванное:
- Потерями пакетов при передаче по сети связи;
- Превышением допустимого времени доставки пакета с речевыми данными.
Все существующие типы речевых кодеков по принципу действия можно разделить на три группы:
- Кодеки с импульсно-кодовой модуляцией (ИКМ) и адаптивной дифференциальной импульсно-кодовой модуляцией (АДИКМ), появившиеся в конце 50-х годов и использующиеся сегодня в системах традиционной телефонии. В большинстве случаев они представляют собой сочетание АЦП/ЦАП.
- Кодеки с вокодерным преобразованием речевого сигнала возникли в системах мобильной связи для снижения требований к пропускной способности радио тракта. Эта группа кодеков использует гармонический синтез сигнала на основании информации о его вокальных составляющих - фонемах. В большинстве случаев, такие кодеки реализованы как аналоговые устройства.
- Комбинированные (гибридные) кодеки сочетают в себе технологию вокодерного преобразования/синтеза речи (преобразование речевого сигнала в цифровой поток со скоростью от 1,2 до 4,8 Кбит/с), но оперируют уже с цифровым сигналом посредством специализированных цифровых сигнальных процессоров (Digital Signal Processor, DSP). Кодеки этого типа содержат в себе ИКМ или АДИКМ кодек и реализованный цифровым способом вокодер.
Так же, кодирование сигнала должно обеспечивать эхоподавление. Сжатие голосового трафика позволяет экономить трафик, это очень важно, если вы имеете большое количество телефонных разговоров (подключений) одновременно. Еще одним из способов уменьшения трафика, является метод подавления пауз, т.е. когда в телефонном разговоре наступает пауза, пакеты не передаются в сеть.
Ниже представлена таблица с описанием основных аудио кодеков, которые применяются в IP телефонии.
- Битрейт (bit rate) – показывает, сколько бит прошло через коммуникационный канал в единицу времени. Обычно указывается в Кбит/с
- Частота дискретизации – частота взятия отсчетов непрерывного во времени сигнала при его дискретизации (в частности, аналого-цифровым преобразователем). Измеряется в герцах.
- Размер кадра – время между отправкой пакетов с информацией
В современных реалиях, в основном используется 711 и 729 кодек, остальное, скорее тонкости при работе с различными клиентами и поставщиками, т.е. необходимо иметь возможность предоставить различные варианты комфортного подключения и в дальнейшем продуктивного сотрудничества.
Вывод:
- Мы узнали, что транспортный уровень - это 4-й уровень модели OSI, предназначен для доставки данных.
- UDP протокол не удовлетворяет всем требованиям передачи медиа данных в реальном времени, поэтому существует RDP протокол, со своими временными метками работающий поверх протокола UDP, что в конечном итоге всех устраивает.
- Открыли для себя существование – SDP — который является сетевым протоколом прикладного уровня, предназначенным для описания сессии передачи потоковых данных, включая телефонию.
- Рассмотрели алгоритмы кодирования/декодирования речевой информации, ведь для того чтобы мы могли услышать друг друга при звонках в сети VoIP, программы, которые именуются кодеками, должны закодировать наш голос, упаковать его, затем передать используя все эти протоколы, и только потом распаковать и декодировать речь. При этом нужно постараться, чтобы голос сохранил тембр и вообще был узнаваемым, а задержки не мешали вести нормальный диалог в реальном времени.
Последнее редактирование:
