[asterisk-users] NAT solutions

[Yuan LIU]

>From: Brad Templeton <brad+aster at templetons.com>
> > I have a really dumb question.  It appears that Yahoo, MSN, AIM, you 
>name
> > them, they don't have a NAT problem, and some use SIP.  I don't think 
>they
> > all stay in voice path, either.  What takes?
>
>When you control both ends of the path, you can eliminate all NAT
>problems.  Skype also deals almost perfectly with NAT (by using
>other nodes as relays if necessary) as does IAX.   SIP was designed

Thanks for this information.  Does this mean two IAX boxes can talk behind 
their respective NAT's (without any server sitting in voice path)?  I'm 
imagining this:

Asterisk1 <--> NAT1 --- { Internet } --- NAT2 <--> Asterisk2

If Asterisk1 can talk to Asterisk2 at trunk level, I'll be happy.

>Some time ago, actually, the SIP and SDP groups devised the ICE
>protocol for highly reliable NAT penetration, but it is still some
>distance from wide adoption, and I don't know when anybody will code
>up Asterisk adoption.

The way Jeff Pulver puts it, ICE has conquered the world :-)  Would love to 
learn more.

>Larger services like you describe often solve NAT by relaying traffic
>through their servers.   They use a "trick", that if they suspect
>an endpoint is behind NAT, they just ignore what they see in the
>SDP, and send all traffic back to the source port/host that the
>traffic comes from.  For RTP, they wait for packets to arrive at
>the (external, routable) RTP port they provided, and send the
>traffic back there instead of the often unroutable address in
>the SDP.

Is this the concept of STUN?  Does this also create latency (by adding an 
additional leg in the route), packet loss, even jitter?

I should have used FWD as an example.  One can't say it uses proprietary 
clients.  Does it stay away from voice path?

Yuan Liu