Голосовая связь через TCP / IP

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

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

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

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

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

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

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

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

2. заполнить - играть молчание в пропасть.

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

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

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

alt текст http://img688.imageshack.us/img688/3962/capturevnk.png

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

alt-текст 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.

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

• блок interleaver является простым и
  эффективный метод повышения QoS.

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

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

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

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

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

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

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

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

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

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

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

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

Что касается того, почему вы получаете шум, как вы обрабатываете опоздавшие пакеты из-за ретрансляция?

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

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

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

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

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

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

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

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