Структура приложения голосового чата (клиент / сервер)?

Question

Мне нужно мнение эксперта, пожалуйста, и извините, если мой вопрос сам по себе является запутанным вопросом.

Я читал о структуре приложений VOIP (клиент / сервер).И в основном UDP рекомендуется для голосовых потоков.Я также проверил некоторые приложения для голосового чата, такие как paltalk и inspeak, и на их сайтах упоминается, что они используют голосовой поток udp, который кажется неправильным по следующим причинам.

Я исследовал трафик / порты, используемые paltalk и inspeak.У них есть открытые порты UDP и TCP, и с помощью анализатора пакетов я вижу, что UDP-соединения не так много, но в основном это TCP-связь.

Также, насколько я знаю, сервер UDP-протокола не можетотправлять данные клиенту за NAT (DSL Router).И «UDP Braodcast» не является опцией для приложений голосового чата, основанных на «интернете».Вот почему в своей документации YAHOO ЗАМЕТИЛИ, что Yahoo Messenger переключается на TCP, если обмен данными по протоколу UDP невозможен.

Так что мой вопрос ...

1. Понимаю ли ячто-то не так в моих заявлениях выше?

2. Если UDP не возможен, тогда эти приложения чата используют TCP Stream для голосовой связи?

3. Так как я испыталчто голосовые потоки TCP создают задержку, нет прерывания голоса, но задержка в голосе, так какая должна быть лучшая структура для общения сервера / клиента голосового чата?

До сих пор я думаю, что еслиКлиент отправляет данные в виде пакетов udp на сервер, а сервер распределяет пакеты клиентам по потокам TCP, это правильное решение?Я имею в виду, это то, что делают коммерческие приложения для голосового чата?

Спасибо, ваш ответ поможет мне и многим другим программистам.

JF

Answer 1

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

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

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

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

Протокол Skype предпочитает UDP, где это возможно, и возвращается к TCP.

в ситуациях SIP проблема NAT решается путем использования пакета поддержки активности nat (любые данные запроса / ответа) для поддержания канала в открытом состоянии и использования и использования факта, что большинство NAT будет принимать ответы от одного и того же источника. порт, с которого было открыто соединение ... это не является надежной защитой, и для него часто требуется прокси-сервер, обеспечивающий соединение между двумя узлами nat'd, но он используется во многих развертываниях.

STUN, TURN и ICE - дополнительные методы, которые помогают в сценариях NAT, особенно в ситуациях p2p (без сервера).

информация о проблемах NAT и носителях:

http://www.voip -info.org / вики / вид / NAT + и + VOIP

http://en.wikipedia.org/wiki/UDP_hole_punching

http://www.h -online.com / безопасности / особенность / How-Skype-Co-получить круглые брандмауэры-747197.html

если вы внедряете какой-либо голосовой сервис, такая система, как FreeSwitch, предоставляет большинство инструментов, необходимых для доставки мультимедиа распределенным клиентам:

http://www.freeswitch.org/

Answer 2

Я вижу, что вопрос просрочен на 3 года, но я не вижу ответа, поэтому я сделаю снимок

1 - ваши утверждения верны

2 - правильно,TCP или UDP могут быть использованы для аудиопотока.

3 - Объединение tcp и udp для аудиопотока бесполезно.Если UDP работает для передачи на сервер, он будет работать для приема, именно так работают все межсетевые экраны NAT, то есть они отправляют дейтаграмму, полученную от внутреннего хоста, на удаленный хост после того, как они изменяют заголовок ip, чтобы заставить пакет казаться исходящим от них,когда они получают ответ, они пересылают его обратно на внутренний хост.Разница между межсетевыми экранами NAT заключается в том, как долго туннель NAT будет оставаться активным, но это не имеет значения для звуковой части вызова, поскольку во время вызова в обоих направлениях присутствует постоянный поток звука.Это будет иметь большее значение для сигнальной части вызова, которая использует протокол SIP.Поэтому я бы порекомендовал использовать TCP для SIP, так как по умолчанию время сеанса TCP составляет 900 с, что делает сообщения поддержки активности менее частыми.

Теперь некоторые приложения, о которых вы упомянули, не используют SIP для инициации сеанса и, следовательно, имеютФирменные способы сигнализации.

Другие приложения используют то, что называется «дырокол», для обеспечения прямой связи (или одноранговой связи) между клиентами (например, Skype).Преимущество этого состоит в том, что сервер не остается в середине голосового потока, и это может эффективно уменьшить задержку, делая TCP потенциальным выбором для аудиопотока.

Ребята, стоящие за разработкой Asterisk,Известные АТС с открытым исходным кодом осознали проблемы в SIP, которые требуют наличия большого количества открытых портов, и разработали собственный протокол, называемый IAX, для передачи сигналов и мультимедиа через один порт.Я бы посоветовал вам рассмотреть возможность реализации IAX для вашего клиента / сервера, потому что он гарантирует, что если клиент сможет подключиться (через сигнализацию), он сможет совершать звонки.