Jump to content

This is the support site for Andrews & Arnold Ltd, a UK Internet provider. Information on these pages is generally for our customers but may be useful to others, enjoy!

VoIP NAT: Difference between revisions

Content deleted Content added
Reedy (talk | contribs)
m NAT is evil: clean up, typos fixed: mutliple → multiple, etc) → etc.)
Adsb (talk | contribs)
m Remove duplicated text
Line 3: Line 3:
'''We'd always suggest using public IP addresses for VoIP devices.'''
'''We'd always suggest using public IP addresses for VoIP devices.'''


*The technicolor broadband routers we used to supply with Home::1 provide a full SIP/NAT ALG which means they work such that neither the phone nor our call server know NAT is in use. This appears to be a well implemented ALG and just works.
*The Technicolor broadband routers we used to supply with Home::1 provide a full SIP/NAT ALG which means they work such that neither the phone nor our call server know NAT is in use. This appears to be a well implemented ALG and just works.
*Using a FireBrick FB2700 providing NAT has no ALG and does simple dynamic port forwarding of outgoing UDP connections with a default timeout of over 2 minutes. This also just works as the call server recognises the NAT and sends one minute keep-alive packets to hold the NAT session open, as well as sending symmetric RTP response packets.
*Using a FireBrick FB2700 providing NAT has no ALG and does simple dynamic port forwarding of outgoing UDP connections with a default timeout of over 2 minutes. This also just works as the call server recognises the NAT and sends one minute keep-alive packets to hold the NAT session open, as well as sending symmetric RTP response packets.
*Other cases where testing has been done have usually required one or other approach, and in some cases required "NAT assist" to be disabled on phones or routers to allow the correct operation.
*Other cases where testing has been done have usually required one or other approach, and in some cases required "NAT assist" to be disabled on phones or routers to allow the correct operation.
Line 18: Line 18:


NAT is not officially supported, but generally can be made to work.
NAT is not officially supported, but generally can be made to work.

*The technicolor broadband routers we supply with Home::1 provide a full SIP/NAT ALG which means they work such that neither the phone nor our call server know NAT is in use. This appears to be a well implemented ALG and just works.
*Using a FireBrick FB2700 providing NAT has no ALG and does simple dynamic port forwarding of outgoing UDP connections with a default timeout of over 2 minutes. This also just works as the call server recognises the NAT and sends one minute keep-alive packets to hold the NAT session open, as well as sending symmetric RTP response packets.
*Other cases where testing has been done have usually required one or other approach, and in some cases required "NAT assist" to be disabled on phones or routers to allow the correct operation.
*SIP and NAT requires the call server, NAT device and phone to all play nicely and can still mean problems. There are a few specific cases we have tested and found reliable, but we cannot guarantee it will work in all cases or without some specific configuration settings.


==Why is NAT a problem with SIP?==
==Why is NAT a problem with SIP?==