Перейти к публикации

Tcp работает, а Udp - нет


Рекомендованные сообщения

Здравствуйте.

 

Имеются роутеры Zyxel Keenetic VIVA и D-link DI-620.

 

При работе через Zyxel связь работает только по протоколу TCP. Через UDP - я не слышу собеседника, а он меня слышит. Через D-Link - проблемы нет. Решил проблему забиванием болта на это дело и использование TCP, но тем не менее, для общего развития, очень хочу докопаться до истины. И нагадить в образовавшееся углубление.

 

Подскажите пожалуйста, какие настройки за это отвечают? Про SIP в роутере, по-моему, вообще не слова...

Ссылка на комментарий

За это в роутере отвечает исключительно NAT и его настройки.

 

Ваш роутер не точно пробрасывает сессию разговора по UDP.

 

Почитайте на форуме рекомендации по настройке натов, они идентичны. (выключить сип хелперы и sip alg, выключить проброс портов, можно попробовтаь включить stun на клиенте и dmz на роутере, ну и конечно обновить прошивку попробовать).

Ссылка на комментарий

В том и различие, что протокол TCP получше через "кривые" NAT проходит и держит регистрацию - меньше пропущенных входящих будет.

Если у вас траффик ничем не лимитирован - оставьте TCP, так как он чуть больше, чем UDP байтов пересылает. Но это мизерная разница.

 

Интересно узнать мнение Игоря.

Ссылка на комментарий

TCP всегда дает заметно большие задержки чем UDP так как ему нужно поддерживать сессию.

Но он лучше пробивается через кривые NAT-ы.

 

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

 

Так что если починили и все без проблем работает на UDP, то конечно лучше чтобы оставался он.

 

P.S.: между операторами стыки всегда на UDP

Ссылка на комментарий

Нарыл вот такую инфу в инете. Стало любопытно. Хвалят TCP

 

Протокол SIP с установкой соединения с помощью транспортного протокола UDP.

 

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

 

Протокол SIP с установкой соединения с помощью транспортного протокола TCP.

 

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

 

С переходом на транспортный протокол TCP появилась уверенность в том, что вызов от абонента «A» к абоненту «B» можно будет осуществить, так-как сервер точно знает доступен ли вызываемый абонент «B».

 

Протокол SIP с установкой соединения с помощью транспортного протокола TCP и шифрованием.

 

Этот вид наиболее современный и перспективный. Ко всем преимуществам транспорта TCP прибавляется возможность зашифровать соединение, а значит, гарантировать, что о содержании разговора двух собеседников, и даже о самом факте разговора, никто не узнает. Для того, чтобы такой шифрованный разговор мог состояться, оба абонента должны иметь SIP телефоны с поддержкой шифрования. Они обозначаются по разному SIPS & SRTP, или SIP over TLS. Хотя они означают не совсем одно и то-же, но чаще всего клиентское оборудование поддерживает оба метода. .. приветствует переход клиентского оборудования на безопасные технологии.

Ссылка на комментарий

Мне интересно, они сами пробовали так долго работать с задержками больше нескольких миллисекунд? :)

Может просто не знают теорию или у них оборудование/программы которые по другому не умеют нормально работать (случаи разные бывают).

 

Тот факт, что при прочих равных TCP дает хуже качество звука чем UDP мы видели не только в теории но и на практике.

Например одни из клиентов объединяли офисы через шифрованные TCP туннели. При отличных каналах (5-10 мегабит оптика) и задержках не более 40-50мс иногда выпадали куски голоса или падало его качество. Решилось одним - переводом всего на UDP.

 

 

Я уже выше написал в каких случаях подойдет TCP - если лень/невозможно настроить кривой NAT.

Ну а если упадет качество голоса, в первую очередь порекомендуем все-же настроить свой маршрутизатор и перейти на UDP.

Ссылка на комментарий

Нарыл вот такую инфу в инете. Стало любопытно. Хвалят TCP

Неграмотно хвалят:

Протокол SIP с установкой соединения с помощью транспортного протокола TCP и шифрованием.

 

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

И факт разговора, и - подчас - его содержание не защищается режимом "TCP с шифрованием".

 

Факт разговора скрыть невозможно по определению.

А шифрование что-либо начинает защищать только при использовании ZRTP, которому всё равно, UDP или TCP использован для соединения.

Ссылка на комментарий
  • 1 год спустя...

Мне интересно, они сами пробовали так долго работать с задержками больше нескольких миллисекунд? Изображение

Может просто не знают теорию или у них оборудование/программы которые по другому не умеют нормально работать (случаи разные бывают).

 

Тот факт, что при прочих равных TCP дает хуже качество звука чем UDP мы видели не только в теории но и на практике.

Например одни из клиентов объединяли офисы через шифрованные TCP туннели. При отличных каналах (5-10 мегабит оптика) и задержках не более 40-50мс иногда выпадали куски голоса или падало его качество. Решилось одним - переводом всего на UDP.

 

 

Я уже выше написал в каких случаях подойдет TCP - если лень/невозможно настроить кривой NAT.

Ну а если упадет качество голоса, в первую очередь порекомендуем все-же настроить свой маршрутизатор и перейти на UDP.

Это ж сколько километров оптики надо положить или арендовать, чтобы задержка была 40-50 мс, примерно 4-5 тыс. км?

И все ради 5 мбит?

Думается мне, что речь об арендованном канале связи, который вроде как везде идет "по оптике".

Мы лет 7 назад подключали такого корп клиента, который сбежал от другого провайдера к нам. Говорит, подключение по оптике у нас, но работает что-то плохо. Мои монтажники пришли его подключать, а пока подключали, случайно заметили, что оптика заканчивается на соседнем доме, и на конце оптики стоит голимый файфай. Вот и вся история об оптике и 5 мегабитах.

Ссылка на комментарий

 

Это ж сколько километров оптики надо положить или арендовать, чтобы задержка была 40-50 мс, примерно 4-5 тыс. км?

 

Земля большая, и телефонный номер может понадобиться не только в соседнем доме но и в другой стране. И кстати 40мс это обычно 2-3тыс км (если по прямой).

Ссылка на комментарий

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас
×
×
  • Создать...