Robert Hajime Lanning wrote: > > > SIP doesn't really work over NAT. The recommendation in the Asterisk > community is you have the Asterisk server on a public IP, then the > clients (soft or hard) can be behind NATs. And all media (RTP) is run > through the Asterisk server (canreinvite=no), not directly to the peer.
I have very little experience with SIP, but my understanding is that it is very similar to xmpp, which I have more experience with, as a matter of fact, I suspect the p2p protocols negotiated by SIP and XMPP are the same, typically guided more by what the clients can accept. Anyway, NAT is a problem for any p2p that is not tcp based, and voice and video tend to be udp... But, there are work-arounds, such as STUN which work quite well. One thing that I have found interesting: I have major problems running my own STUN server, never quite got it running. Turns out that OpenFire (an xmpp server) implements its own STUN server. I tried to use it but had the same issues.. Eventually I read the small warning above the enable box (yeah, who rtfm, really ‽), and it says that the stun server can only work with two ip addresses on the public internet. I only used one, so I turned that off, and pointed to a public stun server (who fund those? all of them seems to be aliases to an amazon EC2 node!), and my problems were solved. I haven't had time to read the STUN RFC yet, but I have a feeling a lot of people run into this problem, most stun servers do not document the fact that they need more than one ip on the public internet. > So, in this case SIP is more of a client/server model, than peer2peer. Yes, using a server as a proxy is bad, making your packets potentially traveling many thousands of extra kilometers. STUN should solved that issue. Not that with xmpp + stun (should be the same with sip), I've done the following without any problem: me ---> nat --> internet xmpp server (in another city) --> internet stun server residing on EC2 -->internet google talk --> internet other --> nat --> internet the initial call, using xmmp, goes: me --> nat --> xmpp server --> gtalk --> nat --> other Then they (the clients) negotiate, and decide to use the stun server briefly to established that they are NATed and find out their actually public ip + "punching a whole" the respective firewalls, then: me --> nat --> nat -- other I have even tried this: shutdown the xmpp server after the communication was established, IM stopped working (it's server based) but the voice call wasn't affected at all, since once it is established, it is truly p2p. I didn't shutdown the xmpp server for the sake of it, I am not that bored, but was trying to change some settings that necessitated to shut it down to take effect. Anyway, NAT shouldn't be a problem with IPv6, right? -- Yves. http://www.SollerS.ca/ _______________________________________________ Discuss mailing list Discuss@lopsa.org http://lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
