From: Brad Templeton <[EMAIL PROTECTED]>
> 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
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
