Только что проверил статус по этому вопросу. Ребята, вы нашли проблему? У меня тоже эта проблема.

@jeff3820 больше никаких задержек... Я инвертировал то, что ты говоришь: исходные порты и IP ограничены тем, что было предоставлено, а порты назначения — любые. Исходные IP и порты следующие:  
Порт 5060:  
54.172.60.0/30  
54.244.51.0/30  
54.171.127.192/30  
35.156.191.128/30  
54.65.63.192/30  
54.169.127.128/30  
54.252.254.64/30  
177.71.206.192/30  

Порты с 10 000 по 20 000:  
54.172.60.0/23  
34.203.250.0/23  
54.244.51.0/24  
54.171.127.192/26  
52.215.127.0/24  
35.156.191.128/25  
3.122.181.0/24  
54.65.63.192/26  
3.112.80.0/24  
54.169.127.128/26  
3.1.77.0/24  
54.252.254.64/26  
3.104.90.0/24  
177.71.206.192/26  
18.228.249.0/24  
IP назначения — UCK2+, а порты назначения — «любые». То есть любой трафик от указанных комбинаций IP/порта (независимо от порта назначения), направленный на мой WAN IP, перенаправляется на UCK2+. @jeffgreg я не использую voip.ms, всё это для провайдера Unifi Talk (Twilio). Так что про это ничего сказать не могу. Также я не сталкивался с проблемой, которая заставила бы меня разбираться с перенастройкой pfSense на более консервативную очистку неактивных соединений (System -> Advanced -> Firewall & NAT -> Firewall Optimization Options).

Я пользуюсь voip.ms и могу подтвердить, что всё работает без проблем — никаких правил не нужно (если только ты не используешь статическую сигнализацию). Нужно только аккуратно настроить очистку портов, иначе регистрации слетают из-за закрытых портов, и звонки (как входящие, так и исходящие) начинают глючить.

Спасибо за информацию. Не уверен, что у меня была та же проблема, так как в логах не было заблокированных записей, поэтому отладка была затруднена.

Вы сделали это и для сигнальных, и для медиа-портов? Если да, то мне немного непонятно, зачем это нужно. Вы используете статическую сигнализацию? Если да, то у вас должно было быть NAT-правило для порта 6767, и я предполагаю, что вы указали исходный IP как any (позволяя Freeswitch блокировать злоумышленников через IP-списки доступа). Всё остальное, как я думал, было исходящим трафиком, и, если ваш файрвол не блокирует исходящие порты (или диапазоны IP), это должно работать. Очевидно, это не так, и я пытаюсь понять, почему именно.Замечу, что другие провайдеры, например voip.ms, с этой проблемой не сталкиваются. Похоже, это в основном касается Twilio... почему?

@jeff3820 да, как и подозревал, создал IP-алиасы для блоков, перечисленных в посте unifi, и настроил входящие NAT-правила (комбинации исходного IP/порта из поста UI), назначение — адрес Интернета, перенаправлять весь трафик на IP CK2+. Звонки соединяются за секунды, и в логах файрвола больше нет лишних блоков от исходных IP-адресов Twilio (ec2).

@jeff3820 Думаю, в этом и проблема, сейчас пробую это первым делом... Я тоже вижу, что эти UDP-пакеты отбрасываются в логах файрвола. Только что нашел это, тестирую... Actually попробую сначала это только с Северной Америкой...

@cdude5565 Ты используешь Unifi Talk как SIP-провайдера или стороннего SIP-провайдера?

Мне интересно, не связано ли как-то проблема с задержкой с pfSense. У меня тоже была 15-секундная задержка с номером Talk. Дело в том, что у меня также есть сторонний SIP-сервис (voip.ms), и там задержки нет — когда я звоню со своего мобильного, телефон Talk звонит в тот же момент, когда я слышу гудок на мобильном. В поддержке UI мне сказали, что невозможность установить RTP-соединение вызывает 5-секундную задержку — если она пытается три раза, прежде чем переключиться на другой механизм, это и приводит к такой задержке. Увы, поддержка не смогла мне помочь (ну, технически я просто устал от переписки туда-сюда по одному кругу раз в день-два) и бросил попытки решить проблему. Иронично, что сторонний сервис работал лучше, чем провайдер Talk. Кстати — если ты ещё этого не сделал, нужно следовать инструкциям pfSense для SIP. В частности, изменение алгоритма очистки UDP на консервативный было очень важным для моей конфигурации — без этого регистрации периодически сбрасывались, вызывая сбои входящих звонков (а иногда и исходящих).