The Trouble with NAT and VOIP

This may shed some light for those who are trying to estabilish VOIP behind a NAT router. - RM

from

formatting link

The Trouble with NAT and VOIP "In addition, the way in which conventional VoIP protocols are designed is also posing a problem to VoIP traffic passing through NAT. Conventional VoIP protocols only deal with the signalling of a telephone connection. The audio traffic is handled by another protocol and to make matters worse, the port on which the audio traffic is sent is random. The NAT router may be able to handle the signalling traffic, but it has no way of knowing that the audio traffic is related to the signalling and should hence be passed to the same device the signalling traffic is passed to. As a result, the audio traffic is simply discarded.

"At first, for both the calling and the called party everything will appear just fine. The called party will see the calling party's Caller ID and the telephone will ring while the calling party will hear a ringing feedback tone at the other end. When the called party picks up the telephone, both the ringing and the associated ringing feedback tone at the other end will stop as one would expect. However, the calling party will not hear the called party (one way audio) and the called party may not hear the calling party either (no audio).

"The issue of NAT Traversal is a major problem for the widespread deployment of VOIP. Yet, the issue is non-trivial and there are no simple solutions."

Reply to
Rick Merrill
Loading thread data ...

There is a simple solution! Edgewater Networks has a "box" that enables you to put your phones on private / NAT addresses. You don't have to punch holes in your firewall !

formatting link
Dilbert!

Jim Hatfield wrote:

Reply to
Dilbert2004

UDP hole-punching seems to work pretty well.

See:

formatting link

Reply to
Jim Hatfield

'Simple Traversal of UDP Through NATs' (STUN) is pretty basic to configure. See

formatting link
example.

Arnold.

Reply to
Arnold Ligtvoet

It's just a little bit expensive. Per user, it seems to be cheaper to replace the end user's ATA with one on a public IP.

There are no universal, cheap solutions. Even stuff like STUN and pin holing doesn't work for all.

peter

Reply to
Peter Gradwell

not true. the signalling protocol carries the info about which ports the specific connections will use - otherwise how is the call going to get connected correctly to the end point?

for example, cisco PIX has a fixup protocol that does this for you for H323 and SIP:

formatting link

this is actually an issue for a firewall software supplier who cannot be bothered to write code to handle this particular protocol rather than a problem with the protocol.

the long term fix is simple - if your firewall cant handle the voice protocol you need - take it back, and / or complain to the supplier.

a year or 2 of that and the software will get fixed.

Reply to
stephen

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.