У меня есть приложение, написанное на Python 3, которое взаимодействует с внешним прокси-сервером SIP через свой общедоступный IP-адрес. В основном приложение, которое я написал, отправляет приглашение SIP на прокси-сервер SIP через сокет UDP. К сожалению, когда я запускаю свое приложение, данные не отправляются через брандмауэр. Брандмауэр настроен на разрешение всех входящих и исходящих подключений. Я очень уверен, что приложение Python работает правильно, потому что, когда сценарий создается для взаимодействия с прокси-сервером SIP, работающим локально, все работает так, как ожидалось. Странные вещи случаются только тогда, когда скрипту приходится проходить через брандмауэр. Я использовал инструмент под названием SIPp, чтобы смоделировать функциональность моего скрипта (отправить приглашение SIP), и, к моему удивлению, приглашение, отправленное через указанный инструмент, успешно достигает внешнего прокси-сервера SIP. Я провел сравнение захвата пакетов между пакетами, сгенерированными моим скриптом и инструментом SIPp, все значения заголовков и полей идентичны. Поэтому я начинаю верить, что FW не разрешает пакеты, отправленные через мой скрипт, из-за другой кодировки. Я попытался найти кодировку, используемую инструментом, но не смог найти ее в документации. В настоящее время я использую «utf-8» в качестве кодировки в моем скрипте. В чем может быть причина такого странного поведения? Верны ли выводы о проблемах с брандмауэром из-за другой кодировки? Пожалуйста, порекомендуйте.
Обновление: я локализовал проблему. Проблема в том, что я отправляю данные на порт 5060. Когда я отправляю данные на любой другой порт, прокси-сервер SIP может их получить. Я проверил свой компьютер, ни одно другое приложение не использует порт 5060. Инструмент SIPp также использовал порт 5060.
Я на 100% убежден, что это sip-alg, который блокирует пакеты моего скрипта. Я не уверен, как SIP ALG может обнаруживать пакеты моего скрипта и блокировать их. Это из-за конкретной кодировки?