С SIP, когда использовать TCP не UDP?

Ответ 1

Многие люди обычно связывают UDP с voip и, вероятно, оставляют его на этом, но в простых выражениях есть две части для передачи voip-соединения и передачи голосовых данных.

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

• Перерегистрируйте каждые несколько минут
• Сервер обновления/пинга

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

Я не мог не отметить также очевидные вещи, которые я просмотрел. Например. количество устройств, подключающихся к серверу. По мере роста числа уравнение наклоняется в пользу UDP. Но тогда вы также должны рассмотреть SIP User Agents, расширяющийся для охвата нескольких кодеков, мультимедиа, видео и совместного использования экрана. Пакеты INVITE могут начать расти большими и потенциально запускаться по размеру одиночной датаграммы UDP, тем самым наклоняя уравнение снова в пользу TCP.

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

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

Кредит: замечательная дискуссия на onSip: https://www.onsip.com/blog/sip-via-udp-vs-tcp

Ответ 2

SIP через TCP имеет значительное преимущество перед UDP для мобильных устройств. Причина связана с использованием NAT и тем, что записи NAT-таблицы в беспроводном маршрутизаторе или маршрутизаторе сотовых провайдеров, как правило, значительно ускоряются для UDP и TCP. Так как сохранение одной и той же записи в таблице NAT необходимо для надежного приема вызовов, SIP должен периодически отправлять keep-alives для поддержания записи в таблице NAT. Необходимая частота keep-alives намного выше для UDP (может быть, каждые 30 секунд) по сравнению с TCP (может быть, каждые 15 минут), что приводит к значительному увеличению использования аккумулятора мобильного устройства. Часто, когда вы видите, что кто-то жалуется на то, как их использование батареи сильно пострадало при использовании клиента VOIP, это потому, что клиент использует UDP.

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

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

Ответ 3

Если сообщение велико (в пределах 200 байтов от размера MTU), раздел 18.1.1 RFC 3261 предусматривает использование TCP (точнее, он предусматривает использование "транспортного протокола, управляемого перегрузками", такого как TCP "). Я нанёс это на практике при отправке начального INVITE с большим количеством заголовков и сложным URI запроса.

Ответ 4

Вы не можете надежно собрать аудиопоток из протокола TCP. В аудио гораздо лучше потерять пакет, а затем передать пакет повторно из-за падения пакета. Звук не работает, если есть чрезмерный джиттер в синхронизации пакетов. Аудио - это протокол реального времени и требует, чтобы протокол, такой как UDP, работал правильно. Потеря пакетов не прерывает звук, это только снижает качество. Совершенная доставка TCP не помогает аудио в любом случае, не может быть качества, если вы получаете 100% пакетов, но они не в режиме реального времени. В аудио это время (латентность, дрожание), которые определяют качество больше, чем целостность данных.

Этот sip работает BEST, когда сигнал и управление превышают TCP, но речевые данные превышают UDP.

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

Ответ 5

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