@dhatz:
@fos4X:
No, that did not work. However this seems to be an issue that is very hard fix. Even a pfsense restart sometimes (indeterministic as far as I can tell) will not bring asterisk back to a register-able state.
Even resetting both (pfsense and freepbx/asterisk) sometimes doesn't help. We will next try to stop the asterisk service, reset pfsense and re-enable asterisk.
Does anyone have any idea how we can deliver a debug/trace that would help the developers see what is going on. We would very much like to fix this long-standing issue in pfsense because we are otherwise very happy with its quality and features.
If resetting all your gear doesn't help, I'm not so sure it's a pfsense issue …
In the past, SIP issues with pfsense were mostly due to its use of symmetric NAT and rewriting of both SIP and RTP ports, however most relatively current software (<3 yr old) employing ICE can deal with that, if not then you'd need to use static-port NAT.
But if you need to troubleshoot VoIP issues beyond the basics, checking SIP software and firewalls & NAT gateways, there can be a huge number of combinations of configuration parameters and intricacies of the various software / firmware involved (e.g. NAT type, UDP timeouts, WAN failover, SIP keepalives, ITSP config etc). Each version of asterisk had its own issues.
Getting VoIP right is much more difficult than let's say running a webserver.
Believe me, pfSense does not clear SIP states when WAN IP changes. I have tested a lot of configurations and this issue does not occur with OpenWrt or Tomato routers.