On the SBC side of things, NAT does not come in play, but…
The UCM formulates messages based on its awareness of how and where it resides in relation to the devices that it needs to communicate with. In the same section that Lucas indicated about putting in the public IP and checking the SDP box in SIP, NAT, you must also input in the local LAN segment further down below on the same page. Additionally, if the SBC is not on the same LAN segment, it too needs to be set in the same settings with its IP or LAN segment.
The above tells the UCM if it see messages from these segments that it needs to formulate the message such that it will tell the devices to use the local UCM IP when replying; otherwise is will assume the devices are external.
What Lucas provided is telling the UCM which address to implicitly use when needing to message external devices.
In the SIP trunk settings for the Callcentric trunk, un-check NAT if checked and then test. After doing the other suggestions.
As stated, what was then is not what it is now so how it may not have needed port forwarding might still be true today if all the settings and functionality were the same. While port forwarding was not on, it is likely that a keep-alive was in action which forced the port open.If not, then no inbound Callcentric call could have passed thru the firewall as the port should have been closed. When you have control of the router, it is best to port forward as it also establishes a direct route that is not reliant upon PAT tables. Further, most versions of dd/wrt do have SIP ALG and these may also cause issue by re-writing things assuming that one needs help in configuring things. Only a few manufacturers have implemented a SIP ALG implementation well, most others break things rather than help.