Sven Richter wrote: >I can register with my account, but that is almost all i can do :( >I also can call the phone at the voip adapter, but, thats it. > >If i take up the call i dont hear anything and if i try to call from >the phone at the adapter i never hear it ringing. >That is sad, really sad. > >What seems suspicious to me is that the overview of the adapter shows >me receiving a lot of sip messages and bytes, but the counter for rtp >packages and bytes always remains zero. Again seems like a NAT >problem? > >Is there a way to allow all traffic to that one adapter with >shorewall, so to say to a fixed ip? >Without interupting anything?
<rant>Welcome to the world of NAT - a completely and utterly broken network by design. I want to throttle anyone who tries to tell me that it not broken or is a good idea - it's bodge that breaks lots of stuff and has significantly contributed to the delays in getting IPv6 going mainstream (because clueless f***wits think NAT is a fix for lack of address space in IPv4). It breaks both rules of IP addressing - IP address must be globally unique, and IP addresses must be globally routable.</rant> Here are the steps you need to take to get SIP working. 1) Make sure any SIP helper (or Application Level Gateway (ALG)) is disabled in your router. These try to help, but as often as not simply break things even more. 2) Check the label on the front of your NAT gateway/router. If it says Zyxel, bin it and save yourself some headaches. Zyxel take NAT to new levels of broken that I'd previously considered unreachable. Now comes the fun bit ! If your VoIP provider has a NAT proxy then use it. These simply take your SIP traffic, ignore the IP address and port info in them, substitute the actual address/port seen in the packet header, and logs into the SIP server on your behalf. For RTP traffic, again they look at the actual address/port seen in the packet headers you send out, and send their end of the conversation to that instead of what your SIP device says. Trust me, for a single device this is by far the simplest and most reliable way to do it. If this isn't available then continue : 3) Check what RTP ports your device uses - it should have a range defined in the config somewhere. Configure your router to allow inbound traffic to these udp ports and forward it to your device. Also do the same with SIP (port 5060 on udp, or possibly on tcp as well). If you have a fixed address, then look at the SIP device and find a setting where you can tell it what it's outside address is. Put your fixed public address in there and your device will use that in all it's messages instead of it's actual (internal) network address. Failing that, configure your device to use STUN (Simple Traversal of UDP through NAT). This feature will talk to an external STUN server to probe the network (with help from the external server) and discover what sort of NAT is in use and what your public IP is. Why all this hassle ? Embedded in the SIP messages are IP address/port pairs. When you set up a call, one ends says "I have a call for you, you should send the RTP stream to address:port". The other end replies "OK, I'm going to use address:port for my end". Each end then sends the RTP data packets to the address:port specified - and if that happens to be a non-routable 192.168.x.y address instead of a real address then that half of the conversation 'just disappears'. Part of the reason it's done this way is that the SIP 'exchange' device doesn't have to route the packets - it's perfectly possible to have the two end devices send the RTP packets directly to each other while the SIP exchange does nothing but pass control messages (ie setup and end the call). NAT just completely f***s this up, and it is NOT possible to configure an ALG that can handle all possible permutations of f**k up. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
