Структура приложения Голосового чата (Клиент/сервер)?
Мне нужно Мнение эксперта, и извините если моим вопросом самим является запутанный вопрос.
Я читал вокруг о структуре приложений VoIP (Клиент/сервер). И главным образом UDP рекомендуется для речевых потоков. Я также проверил некоторые приложения голосового чата как paltalk и inspeak, и их сайты упоминают, что они используют udp речевой поток, которые не кажутся корректными для ниже причин.
Я исследовал трафик/порты, используемый paltalk и inspeak. У них есть порты UDP и TCP, открытые и использующие анализатор пакетов, я вижу, что нет большой коммуникации UDP, но главным образом это - коммуникационное продолжение TCP.
Также насколько я знаю В Протоколе UDP, сервер не может отправить данные клиенту позади NAT (Маршрутизатор DSL). И "UDP Braodcast" не является опцией для основанных на "Интернете" приложений голосового чата. ВОТ ПОЧЕМУ YAHOO УПОМЯНУЛ в их документации, что переключатель yahoo messenger к tcp, если udp коммуникация не возможна.
Таким образом, мой вопрос....
Я понимаю что-то не так в моем выше операторов?
Если UDP не возможен затем, те приложения чата используют Поток TCP для речи?
Так как я испытал ту речь TCP, потоки создают задержку, Никакое речевое повреждение, но Задержку речи, поэтому какова должна быть лучшая структура для коммуникации сервера/клиента голосового чата?
До сих пор я думаю, что, если Клиент отправляет данные, поскольку udp пакеты к серверу и серверу распределяют пакеты клиентам по потокам TCP, действительно ли это - надлежащее решение? Я имею в виду, это, что делают коммерческие приложения голосового чата?
Спасибо Ваш ответ поможет мне и большому количеству других программистов.
JF
1 ответ
UDP имеет меньше над головой (с точки зрения общего размера пакета), поэтому вы можете сжать больше аудио в пропускную способность канала.
UDP также является ненадежной - отправленные пакеты, не могут быть получены или могут быть получены из строя, который на самом деле в порядке для голосовых приложений, поскольку вы можете терпеть некоторую потерю качества сигнала и продолжать идти. Небольшое количество потерянных пакетов может быть допущено (в отличие от загрузки файла, где каждый байт имеет значение).
Можете ли вы использовать TCP? Конечно, почему бы не ... это немного больше над головой, но это может неважно.
SIP - это стандарт голосового / медиа, который поддерживает UDP и TCP. Большинство развертываний используют UDP из-за нижнего накладных расходов.
Протокол Skype предпочитает UDP, где это возможно, и падает обратно в TCP.
В SIP-ситуациях проблема NAT решается с использованием пакета NAT Alive Alive (любой запрос / данные ответа) для хранения канала вверх и открытой, и, используя тот факт, что большинство NAT примет ответы на тот же источник Порт. Соединение было открыто из ... Это не надежно, и часто требует прокси-сервера, посвященного подключению между 2 пирами NAT, но он используется во многих развертываниях.
Стулка, поворота и лед представляют собой дополнительные методы, которые помогают с сценариями NAT, особенно в ситуациях P2P (без серверов).
Информация о проблемах и СМИ на NAT:
http://www.voip-info.org/wiki/view/natfoefog/wikiip
http://en.wikipedia.org/wiki/udp_hale_punching
http://www.h-online.com/security/features/how-skype-co-get-rund-firewalls-747197.html
Если вы реализуете голосовую службу своего рода, Система, такая как FreeSwitch, предоставляет большинство инструментов, необходимых для доставки носителей для распределенных клиентов: