Порты IP-телефонии, обход блокировок
- В этой теме 2 ответа, 3 участника, последнее обновление 8 лет, 10 месяцев назад сделано
.
-
Сообщения
-
Столкнулся с проблемой, которая не сразу была понятна. Только после настроек нескольких устройств на двух разных сервисах. Итак, по UDP блокируется порт 5060. При этом, к счастью, TCP проходит там-же нормально. Блокировка не абсолютная, а скорее всего интеллектуальная, выдаётся ошибка 488 (неверные параметры). При этом блокируются только исходящие звонки, входящие проходят без проблем и регистрация на сервисе проходит без проблем.
Проверялась работа с сервисами Т37 и pbxes на хард и софт телефонах. Именно статус зарегистрированного устройства долгое время вводил в заблуждение. После перезагрузки устройства блок на короткое время пропадал, потом появлялся.
Либо это хитрая работа провайдера, либо глюк роутера. Так или иначе в случае с pbxes использовал альтернативный порт из предложенного сервисом списка. А вот на Т37 перевёл часть в TLS+SRTP:5061 а то, что такой режим не поддерживает, поставил в TCP:5060Попробую догадаться о причине.
Дело в том, что UDP протокол работает без установки соединений, т.е. пакеты просто идут каждый “изолированно”.
Если за роутером (за NAT в простейшей реализации) находятся НЕСКОЛЬКО устройств, каждое из которых работает с одним и тем же клиентским (именно клиентский) порт 5060.. то NAT, получая извне пакеты на UDP порт 5060, отправляет его устройству, которое последнее отправляло пакет с этого порта. Самым видимым следствием является потеря регистрации устройств, т.к. пакеты об успешной регистрации роутер отправляет совсем другому устройству..
Решением является:
– использование NAT с поддержкой SIP алгоритмов
– настройка на устройствах разных клиентских портов (или динамически выбираемых). В это случае роутер так же будет использовать разные порты и сервер отправлять ответы на разные порты
– использовать TCP порты, которые работают с установкой соединений (сессий).У меня ошибка 488 выскакивала, когда на клиенте первым приоритетом был настроен кодек alaw, а на аккаунте был принудительно настроен g729. Соответственно при исходящем звонке клиент пытался инициировать звонок с alaw, и его отшивало. А вот входящие по g729 при этом проходили без проблем, т.к. такой кодек тоже был настроен на клиенте.
- Для ответа в этой теме необходимо авторизоваться.