C ++ в Linux: настройка сокета & amp; пакеты для минимальной задержки потока RTP

У меня есть устройство Linux, которое должно транслироваться из различных аудиоисточников в режиме реального времени по RTP / UDP на несколько клиентов, и я хочу добиться минимальной задержки. Он работает так, как будто извлекает кадры из различных интерфейсов ALSA и перенаправляет их в виде потоков RTP, используя обычные сокеты C.

Я провел некоторое тестирование с использованием Wireshark и уверен, что правильно настраиваю поле DSCP сокета в поле IP_TOS для ускоренной пересылки, что, насколько я понимаю, обеспечивает наибольшее снижение задержки на этом фронте.

Однако меня беспокоит, что я ничего не делаю, чтобы пометить пакеты как VoIP, чтобы обеспечить наилучшее из возможных QoS для каждого узла в сети (используя стандарт 802.11e), и это может привести к неоптимальному результату. задержка. Что вызывает у меня наибольшее подозрение, так это то, что согласно моим журналам Wireshark мои пакеты помечаются как видеопакеты вместо аудио / VoIP:

QoS часть пакета под Wireshark

Итак, вот мои вопросы:

  1. Как DSCP относится к 802.11e? Я думаю, что они делают разные вещи в разных слоях сети, но я не настолько осведомлен и, возможно, не уверен в этом.

  2. Показывает ли приведенное выше изображение что-либо о неоптимальной настройке пакетов и / или сокета UDP, который я использую для отправки потока RTP на фронтах DSCP или 802.11e?

  3. Как я могу пометить пакеты для приоритета VoIP, используя стандартные сокеты на C ++ (если это возможно)?

  4. Есть ли какая-то конкретная конфигурация, на которую я должен обратить внимание в отношении 802.11e на моем маршрутизаторе? Стоит ли искать маршрутизаторы, поддерживающие 802.11e, или это уже предрешено? Я предполагаю, что, возможно, 802.11e не о конкретных пакетах, а о конфигурации маршрутизатора.

Опять же, я немного растерялся и думаю, что мне может понадобиться кто-то, кто ударит меня по голове и расскажет, как все это работает. Все, что я могу найти в Интернете, похоже, связано с CISCO, и я не уверен, насколько это полезно для моих целей, как описано здесь.

2

Решение

  1. Насколько я понимаю, октет QoS (ToS / DS) является вторым октетом заголовка IP. 802.11e специально для беспроводных сетей и находится на более низком уровне, чем IP.
  2. Для ускоренной пересылки в DiffServ я думаю, что октет должен быть 0xb8. Я не уверен, что это за картинка … 2 октета?
  3. Я более знаком с Windows, и ОС накладывает ограничения на тегирование QoS. Для тех, кто находит этот пост, загляните в qwave и QOSCreateHandle, В Linux, я думаю, вы могли бы использовать необработанные сокеты с соответствующими разрешениями.
  4. Есть несколько разных способов, которыми октет IP QoS может быть преобразован маршрутизаторами … выберите тот, который соответствует вашим потребностям; DSCP должен быть обычным. Еще раз обратите внимание, что это отличается от 802.11e.

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

0

Другие решения

Других решений пока нет …

По вопросам рекламы [email protected]