Назад | Перейти на главную страницу

Обходной путь для блокировки порта SIP (5060) интернет-провайдером

Я узнал, что мой интернет-провайдер блокирует исходящий порт SIP (5060) дома. У меня есть удаленный сервер Linux, который я могу использовать для прослушивания порта, отличного от 5060, и перенаправления трафика. Не уверен, какие правила iptables нужно применить, чтобы все заработало.

Есть ли необходимость делать проброс для RTP портов (10000-20000)?

Ваша помощь очень ценится.

Спасибо.

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

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

Многие операторы VOIP прослушивают другие порты, кроме 5060. (Типичные диапазоны для прослушивания - например, 5060-5080). У меня периодически возникали проблемы, когда я был с Comcast с блокировкой 5060; Мне нужно периодически менять свой VOIP ATA на 5060, 5062 и т. Д.

Я так и не понял, почему порт будет заблокирован, хотя предполагаю, что это была какая-то фильтрация спама или предотвращение злоупотреблений. Это не казалось попыткой полностью заблокировать SIP, поскольку это было легко обойти; Если ваш интернет-провайдер честно пытается помешать вам использовать VOIP, обходной путь может быть не таким тривиальным.

Но я бы «попробовал, прежде чем подглядывать» и просто подхожу к 5061 или чему-то еще в диапазоне прослушивания, прежде чем вы начнете пересылку через удаленный сервер.

Можете ли вы запустить прокси-сервер SIP на своем удаленном компьютере, например, на 15060? Затем вы можете настроить локальный пользовательский агент SIP для использования этой машины. Сигнальный трафик от вашего SIP UA идет на 15060, а входящие вызовы будут проходить через ваш прокси.

У вас не будет дополнительной необходимости пересылать RTP с указанной выше настройкой, но вам все равно может потребоваться обойти свой NAT, если он у вас есть.

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