Брандмауэр блокирует данные, передаваемые через сокет Python

У меня есть приложение, написанное на Python 3, которое взаимодействует с внешним прокси-сервером SIP через его общедоступный IP-адрес. В основном приложение, которое я написал, отправляет SIP-приглашение на SIP-прокси через сокет UDP. К сожалению, когда я запускаю свое приложение, данные не передаются через брандмауэр. Брандмауэр настроен на разрешение всех входящих и исходящих соединений. Я очень уверен, что приложение Python работает правильно, потому что, когда скрипт создается для связи с прокси-сервером SIP, работающим локально, все работает как положено. Только когда скрипт должен пройти через брандмауэр, происходят странные вещи. Я использовал инструмент под названием SIP p для имитации функциональности моего скрипта (отправка приглашения SIP), и, к моему удивлению, приглашение, отправленное с помощью указанного инструмента, успешно достигает внешнего прокси-сервера SIP. Я сделал сравнение захвата пакетов между пакетами, сгенерированными моим сценарием и инструментом SIP p, все значения заголовка и поля одинаковы. Поэтому я начинаю верить, что FW не позволяет пакеты, отправленные через мой скрипт, из-за другой кодировки. Я попытался найти кодировку, используемую инструментом, но не смог найти ее в документации. В настоящее время я использую 'utf-8' в качестве моей кодировки в моем сценарии. Что может быть причиной такого странного поведения? Правильны ли выводы о проблемах брандмауэра из-за разной кодировки? Пожалуйста, порекомендуйте.

Обновление: я локализовал проблему. Проблема заключается в том, что когда я отправляю данные на порт 5060. Когда я отправляю данные на любой другой порт, прокси-сервер SIP может их получить. Я проверил свой компьютер, никакое другое приложение не использует порт 5060. Инструмент SIP p также использовал порт 5060.

Я на 100% убежден, что это та вещь, которая блокирует пакеты моего скрипта. Я не уверен, как SIP ALG может обнаружить пакеты моего скрипта и заблокировать их. Это из-за конкретной кодировки?