Ну, где то так.
В настоящее время все VoIP шлюзы отцепил из DMZ, поднятой на DFL и до решения проблемы разработчиком в будущих прошивках зацепил их напрямую мимо DFL. На VoIP перекидываю WAN-ы вручную, путем тупых перетыканий кабелей на кроссе

У меня аналогичная проблема с двумя провайдерами и переключением телефонии с основного на резервный провайдер в случае отказа первого. Мучался около полутора лет, но сегодня удалось дописать программку и победить DFL-800.
Суть следующая: программная миниатс стоит за фаерволом DFL-800 (STUN выключен). SIP+RTP порты проброшены статически, НО все хорошо работает на основом провайдере со статическим внешним IP, но как только происходит переключение на резервного провайдера с динамическим внешним IP - сразу ничего не слышно (разумеется при выключенном STUN).
Включение SIP_ALG дает серьезные сбои, видно что миниатс пытается работать, но практически безрезультатно, слышимости нет, трубка не поднимается, не ложится, иногда не регистрируется...
Включить STUN тоже нельзя: полнейший хаос с транслированием портов, если бы NAT хоть на время запоминал комбинацию (IP источника и порт) + (транислируемый порт), думаю STUN бы помог на миниатс.

Решение было сделано примитивное:
1. статический проброс портов SIP+RTP на DFL-800 сохраняется
2. я написал и установил на томже сервере свой примитивный STUN сервер
3. на миниатс был включен STUN и прописан именно мой STUN, вместо реального

Мой STUN сервер получает запрос на resolving внешенего ай-пи от миниатс, сам определяет у реального STUN сервера внешний IP и возвращает миниатс ответ с внешним IP, но с исходным портом (тем самым минатс динамически определяет свой внешний IP но порты при этом остаются постоянные). Таким образом переключение с одно провайдера на второй осуществляется успешно при статическом пробросе портов.
Решение еще тестирую на выносливость, но если будет интересно - могу дать самописный STUN сервер.

Ну как проблема решилась c SIP ? У меня такая же беда, при переходе на резервного провайдера , DFL надо ребудеть.

Проблему удалось решить как было указано в предыдущем моем посте (с помощью "подставного" STUN сервера), но решение некрасивое, по этому в резултате от него отказался. Суть проблемы в том, что на DFL-800 симметричный NAT и это никакими настройками не побороть. SIP ALG на DFL работают некорректно, по этому их также неполучается применять. В резултате из-за симметричного NAT в DFL и кривости SIP ALG использование функции автоматического переключение на резервного провайдера становится бессмысленным, работу со STUN сервер на VoIP АТС можно отключить, только один провайдер и только статические порты. По этому железяку DFL для защиты Вашей VoIP АТС можно смело выкидывать в мусорник, поставить любой роутер за 30$ (а не за 600$) и не пытаться победить криворукость разработчиков firmware для DFL.

вот тут не знаю как у вас там , у меня прекрасно 210й отрабатывает такую схему , но у меня отличается тем что,
в качестве резервного интернета работает IPSEC туннель , а на другом конце туннеля , поднимается PPTP соединение с провайдером , прекрасно работает такая схема - уже 4й день так живу

_________________
Своим вопросом Вы загоняете меня в ГУГЛ.....
DFL-210 -архив образов
Меня можно найти в боте Телеграмма @MyKingdombot когда РКН перестанет заниматься ерундой :-)
Готовыe платить - пишите
Прикуплю неисправные девайсы ради корпусов ....-> в личку

Это из-за тунеля, так как в тунеле у Вас порты не ретранслируются, на то он и тунель.

ну дальше же он натится в интернет

_________________
Своим вопросом Вы загоняете меня в ГУГЛ.....
DFL-210 -архив образов
Меня можно найти в боте Телеграмма @MyKingdombot когда РКН перестанет заниматься ерундой :-)
Готовыe платить - пишите
Прикуплю неисправные девайсы ради корпусов ....-> в личку

Здесь можно скачать STUN клиент:
http://sourceforge.net/projects/stun/fi ... &download=

Потом в командной строке запускаете:
client.exe stunserver.org

И посмотрите какой тип NAT у Вас используется (можете сюда скопировать).