Looking into the docs for Asterisk 1.6.0 for a solution to a NAT issue, you can find that asterisk reinvite has improved significantly in the later versions.
Previously, you had to turn it off for peers stuck behind NAT, this is resolved in newer versions of Asterisk which attempt to determine if a peer is behind NAT, or if the peer is connectable.
The method is simple, for the peers affected or unsure, set the canreinvite option to ‘nonat’ – this will cause the audio to be connected directly to the peer if possible, otherwise, it will packet2packet bridge the audio.
It is important to have the right mix of codecs on the server and specified in the ATA settings also – without it, you’ll just have a mess to sort out.
NAT is a big problem for VoIP – nearly every gateway / router will implement NAT differently from what I have been told.Â The BEST configuration is to have the ports forwarded. This isn’t hard for many people – it’s just a matter of finding what your router calls it, and then forward the ports. Once the ports are forwarded, there should be only codec mismatches to worry about – and of course, if your codecs are specified right – well, there is no problem – the audio should be connected directly, rather than bridged.
Asterisk 1.4 and 1.6 have had many advancements to SIP and RTP implementation. T.38 support is at a strong point now – not completely tested by me, however with T.38 support, it greatly reduces the errors you may experience trying to transmit fax over ulaw / alaw.
Check out the UPGRADE.txtÂ for Asterisk 1.6 – theÂ list is massive and impressive.