Thanks Moj! The RTP packet problem makes sense. Still unclear on some of the other points:
I think the biggest problem with SIP is the RTP ports. The initial SIP request goes out (for example) to port 5060, and FROM port 5060 as well. The response needs to get back to the SIP UA on that port (which would limit the nat router to only be able to deal with ONE internal ua at a time, if they were both using the standard port 5060), which could conceivably happen easily enough.
An Internet browser uses port 80. I might have two or more behind a NAT both using port 80. Isn't that the same thing?
But in the SIP "handshake" more ports are chosen, typically in the 10,000 to 20,000 range. The NAT router would then need to be configured to direct that anticipated RTP stream to the proper internal client. That just doesn't happen :)
Hmmm, that makes sense.
For various reasons, I'm not too partial to UPnP, but maybe there needs to be a SIP UA that uses UPnP to configure a NAT router for it, when an RTP stream is begun?
Not following this part...
Now the clincher to all of this is that I'm merely talking about the ip packets transferred and their return addresses. While I'm not qualified or experienced enough to comment on problems that might arise with the contents of the SIP headers themselves, I suspect that's where the REAL trouble lies with SIP NAT traversal. The SIP UA needs to put the proper return address in the SIP headers before the lower layers of the OSI model take over. It can't know its externally-visible ip address unless A) the user manually enters it or B) it can ask some outside server what it's perceived address is.
Isn't this what a STUN server does? Sends an HTTP message to SIP UA so that the SIP UA can strip out the external IP address of the NAT? Thanks again, H _______________________________________________ --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
