This does a good job of keeping the bad guys from knocking at the door, and basically just works in most cases.
Here's the gotcha...
In a few cases, customers with Cisco SIP phones and customers with Trixbox (Asterisk clone) SIP devices on the inside network report inability to place calls, inability to receive calls, or other strange issues. One Trixbox user couldn't make outbound calls unless he had received an inbound call within the previous two minutes.
Sniffing and debugging reveals that these corner cases are due to the endpoint doing some relatively unusual spoofing of the source of the UDP SIP packets sent from the device.
Some Cisco phones source the UDP from 127.0.0.1 which makes no sense. The internal SIP payload IP is correct.
The Trixbox sources its IP from the outside WAN IP of the TA900. Very strange, as it's on the inside behind NAT.
We had to add host entries to the SIP ACL for 127.0.0.1 and the outside IP of the device in order to make these endpoints behave. Totally not an Adtran issue but buggy implementation on the part of the endpoint manufacturers. It's probably some form of badly-implemented NAT traversal mechanism.
I hope others find this helpful. We've been aggressive in locking down SIP access as the bad guys are pretty aggressively scanning most of the public Internet looking for vulnerable hosts. I strongly suggest that you lock down your devices.