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

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

В зависимости от типа базовой сети, если у вас есть Ethernet с надежностью 99,9%, я предполагаю, что TCP подойдет. Однако, если вы делаете это, скажем, 802.11, тогда TCP будет не очень хорошей идеей.

Вы можете спросить своего начальника о конкретной причине использования TCP, а затем реализовать эту конкретную службу, например, базовую надежность или службу исправления ошибок. через UDP. Вы также можете изучить RTP. ( http://en.wikipedia.org/wiki/Real-time_Transport_Protocol )

Существует несколько основных причин, по которым для потоковой передачи данных в реальном времени используется UDP. Самая большая из них - получение запоздалых данных - это так же хорошо, как и отсутствие их вообще, а задержка потока для повторной передачи - определенно не лучшая идея. Для VoIP допустимая задержка составляет около 150 мс. Любой голосовой пакет, который задерживается дольше указанного, становится заметным для пользователей.

Что касается того, почему вы слышите шум,

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

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

TCP не должен вносить какой-либо шум. Джиттер и лаг, да (особенно, если ваши ссылки с потерями); но никакого шума. Что-то не так с вашим программированием.

Кстати, я согласен с тем, что в данном случае UDP гораздо более уместен, чем TCP.

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

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

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

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

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

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

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

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

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

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

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

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

Потеря пакетов и длина пакетов

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

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

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

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

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

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

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

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

alt text http://img688.imageshack.us/img688/3962/capturevnk.png

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

alt text 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.

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

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