Голосовая связь по TCP / IP

Question

В настоящее время я разрабатываю приложение, использующее DirectSound для связи в интрасети. У меня было рабочее решение с использованием UDP, но потом мой начальник сказал мне, что по какой-то причине хочет использовать TCP / IP. Я пытался реализовать его почти так же, как UDP, но с очень небольшим успехом. То, что я получаю, это просто шум. 20% из них - записанный звук, а остальное - просто странный шум.

Я думаю, причина в том, что TCP должен прочитать все принятые данные несколько раз, пока не получит окончательный звук, который я могу воспроизвести.

Теперь два вопроса:

• Я на правильном пути? Является ли даже хорошей идеей использовать TCP / IP для такого рода приложений (своего рода голосовая конференция)?
• Я делаю это на C #, но не думаю, что это зависит от языка.

Answer 1

Нет, использование TCP - это ужасная идея. UDP в этом случае будет работать намного лучше, и пропущенные / не синхронизированные пакеты не будут иметь значения!

Если ваш начальник не может понять технические детали, скажите ему или ей, что практически все существующие в настоящее время системы VOIP используют UDP, и на это должна быть причина: Skype, ventrilo, teampeak, World of Warcraft и т. Д.

Answer 2

Чтобы правильно ответить на этот вопрос, я чувствую, что некоторые ключевые концепции VoIP необходимо объяснить.

Во-первых, UDP является наиболее популярным и широко используемым методом для VoIP. Помните, что IP-сеть с коммутацией пакетов идеально подходит для передачи данных не в реальном времени и не предназначена для VoIP в реальном времени.

Для преодоления этой проблемы используется UDP. UDP является ненадежным протоколом без установления соединения. Хотя UDP потеряет пакеты, речевой звук все еще можно понять, мозг будет эффективно компенсировать ошибки. Вот почему вы все еще можете говорить с кем-то по телефону с 3 полосами сигнала.

Длина пакета и длина пакета

Потеря пакета часто происходит из-за перегрузки, поэтому величина потери пакета будет зависеть от того, насколько хорошо оборудована сеть. Потеря пакетов в VoIP с использованием UDP чаще всего происходит при длинах пакета. A длина пакета - это количество пакетов, потерянных подряд при передаче, поэтому длина пакета 3 означает 3 пакета подряд погибли.

Компенсация потери пакета

Там, где происходит потеря пакета, будут применяться простые методы компенсации потери пакета, и качество обслуживания не будет серьезно затронуто, речь все еще может быть понята даже в тех случаях, когда теряется 20-30% пакетов. Методы включают в себя:

1. Повтор последнего успешно полученный пакет.

2. Fill in - Воспроизведение тишины в промежутке.

3. Сплайсинг - эффективно это может быть думал взять удаление разрыв, вызванный длиной взрыва нажав на начало и конец разрыв вместе.

4. Интерполяция - Используйте знания речь до и после интерполировать потерянные пакеты в пределах разрыв, например среднее значение между пакетами, успешно полученными до и после длины пакета.

Хороший метод уменьшения размера серийных пакетов известен как чередование, и, таким образом, увеличение QoS составляет чередование . Функция блочного чередования берет речь и разбивает ее на набор пакетов. Эти пакеты загружаются в буфер в форме матрицы (например, 4 на 4), используется функция поворота или транспонирования буфера, так что пакеты расположены не по порядку. На стороне приемника обратная функция используется для переупорядочения пакетов. Этот метод прост и эффективен, см. Рисунок ниже:

альтернативный текст http://img688.imageshack.us/img688/3962/capturevnk.png

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

альтернативный текст http://img338.imageshack.us/img338/6566/captureec.png

На диаграмме приложение определяет свой собственный дизайн пакета. Заголовок может быть просто номером пакета (используя 1 байт) и полезной нагрузкой аудиоданных (n байтов, размер полезной нагрузки). Определение этого позволяет улучшить методы компенсации пакетов и логический поток для программирования.

TCP - это плохой выбор для VoIP по нескольким причинам. Быстрый Google 'TCP VoIP' показывает, почему первый результат поддерживает это представление .

TCP - это надежный протокол, ориентированный на соединение, это означает, что пакеты, потерянные при передаче, в какой-то момент будут повторно отправлены с другого хоста. Эта повторная передача нецелесообразна для служб реального времени и увеличит дрожание, задержку и, возможно, увеличит потери пакетов (в некоторых случаях).

Ответы на ваши вопросы

То, что я получаю, это просто шум. 20% из них - записанный звук, а остальное - просто странный шум.

TCP не должен вносить шум, он должен вводить дрожание и задержку. Сокеты, как правило, имеют автоматически определенное время ожидания. Вы определяете время ожидания? Если нет, то что происходит, почему вы не получаете правильный пакет во время до воспроизведения?

Я на правильном пути? Является ли даже хорошей идеей использовать TCP / IP для такого рода приложений (своего рода голосовая конференция)?

Не делать НЕ использовать TCP / IP, это не очень хорошая идея. Похоже, ваш менеджер неправильно предположил, что любая потеря пакетов - ужасная вещь.

Резюме

Некоторые общие ключевые концепции были показаны здесь, чтобы попытаться максимально помочь этой конкретной проблеме, однако это не следует считать исчерпывающим. Убедитесь, что система VoIP также использует некоторые основополагающие принципы методов кодирования речи / обработки сигналов.

Запомните следующие ключевые моменты:

• Использовать UDP для VoIP.

• Реализация компенсации потери пакетов
  методы.

• Блочный перемежитель является простым и
  эффективный метод повышения QoS.

Надеюсь, это поможет.

Answer 3

Когда люди говорят о стеке TCP / IP, они часто имеют в виду «весь стек Интернет-протоколов», который включает UDP. Может быть, это делает вашего менеджера счастливым; -)

Answer 4

Я разработал решение IPO для голосовой связи для дуплексной связи с wave-api для дистанционного управления любительским радиотрансивером. Очень хорошо работает с UDP, а также с TCI / IP! Я использую 512-байтовый буфер каждые 64 мс, данные моно волны 8 кГц. В прошлом месяце у меня была работа между США и Европой по протоколу TCP / IP! Теперь мой вопрос: wave-api не работает корректно с Win7, поэтому я считаю, что DirectSound - лучший способ. Как раз в то время, когда у меня была проблема с реализацией под управлением Managed DirectX9, мое приложение VB.Net 2008. Я ищу ссылки на документацию для потокового вывода с DirectSound - ManagedDirectX9 для VB.Net.

Answer 5

Нет причин, по которым вы должны получать шум по TCP, и поэтому это выглядит как ошибка в вашем коде. На самом деле большинство потокового мультимедиа, которое мы получаем (например, YouTube), выполняется через TCP.

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

RTP / RTCP over UDP обычно используется для доставки медиапотока. RTP включает в себя такие вещи, как порядковые номера в заголовке пакета, которые позволяют вставлять запоздалые пакеты в их правильное положение, где это возможно. RTCP имеет функцию отчетности, которая позволяет кодеку адаптироваться к ситуациям, когда потеря пакетов начинает увеличиваться. Поэтому RTP / RTCP предоставляет некоторые, но не все функции TCP.

Для потоковой передачи мультимедиа по протоколу TCP это можно легко решить с помощью большого буфера дрожания. Это добавляет задержку, но для односторонней потоковой передачи это не проблема. Однако задержка является серьезной проблемой при двусторонней потоковой передаче.

Однако одно из основных преимуществ TCP состоит в том, что он проходит через брандмауэры легче, чем UDP. Во время одного сеанса TCP брандмауэр открыт для отправки и получения данных. Это сложнее для UDP, особенно когда ожидается входящий поток данных. Есть способы обойти это, но они могут быть сложными и могут включать понимание протокола управления сеансом (например, SIP или RTSP).

Answer 6

TCP / IP по современным маршрутизаторам и сетям очень быстрый. Он более чем способен обрабатывать передачу голоса по IP. (Я сделал это сам)

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

Answer 7

TCP / IP будет работать; это доставит данные. Это может быть не так эффективно, как UDP, если вы не беспокоитесь о потере пакетов, но вы должны иметь возможность передавать данные очень хорошо.

Answer 8

Насколько медленнее TCP, чем UDP? С TCP вы получаете задержку повторной передачи, если какие-либо пакеты приходят не в порядке или повреждены. Я скажу, что есть способы оптимизировать TCP, чтобы меньше задержек. В Linux и Winsock есть опция TCP_NODELAY для использования. Также компактный кодек поможет, например, G.729, уменьшить размер полезной нагрузки. Поскольку передача основана на принимаемых пакетах (по порядку - TCP), следует сосредоточиться на оптимизации размера пакета, чтобы он был достаточно мал, чтобы уменьшить задержку повторной передачи, но достаточно велик, чтобы поддерживать качественный поток. Хорошая VoIP-программа TCP будет иметь возможность изменять качество кодирования и размер пакета на лету, когда отправитель должен будет сообщить получателю об изменении. Но на самом деле единственным преимуществом использования TCP в режиме реального времени является то, что он менее вероятно блокируется брандмауэрами.

Answer 9

Если вы получаете шум, вы, вероятно, превышаете ту часть вашего буфера, которая успешно заполнена пакетами, и воспроизводите пустой / неинициализированный буфер.

Answer 10

Я почти уверен, что большинство потоковых аудио / видео использует UDP ... вы можете потерять несколько пакетов, но вы никогда не заметите.