Hi Simon, thank you for your long and explaining email. I was afraid that i'll face someday a problem like that. A nat problem. I read some things about the specification and about how f**** up it is, but never cared.
However, my router is a linux box with shorewall. I "natted" all traffic (ports 5060 and 16384-16482) to my adapter, but that wont do the trick. Looking at the logs i think i see the problem: Sep 24 18:29:39 192.168.15.9 SIP/2.0 200 OK^M Record-Route: <sip:217.10.68.147;lr=on;ftag=65bbf9ec3a01a2cco0>^M Via: SIP/2.0/UDP 192.168.15.9:5060;branch=z9hG4bK-201f4727;rport=5060^M From: Richter <sip:[email protected]>;tag=65bbf9ec3a01a2cco0^M To: <sip:217.10.68.147>;tag=efae1b206a1df22b5fbc395b5a747d13.8532^M Call-ID: [email protected]^m CSeq: 79 NOTIFY^M Content-Length: 0^M ^M There at the and i see the internal ip and not the external one. But, my adapter has both abilities, the one to use the stun server and the one to enter an external ip (i dont have a fixed one, but our dynamic ip only changes all few weeks). I tried both options, but neither worked. Here is the log with stun server enabled: Sep 24 18:31:51 192.168.15.9 [0]On Hook Sep 24 18:31:53 192.168.15.9 [0]Off Hook Sep 24 18:31:58 192.168.15.9 [5060]STUN trying 0 Sep 24 18:31:58 192.168.15.9 [16444]STUN trying 0 Sep 24 18:31:58 192.168.15.9 [16445]STUN trying 0 Sep 24 18:31:58 192.168.15.9 [16446]STUN trying 0 Sep 24 18:31:58 192.168.15.9 [16447]STUN trying 0 Sep 24 18:31:58 192.168.15.9 [0:0]CC:STUN OK:c0a80f09->4d14ed71, 5060->5060 16444->16444 Sep 24 18:31:58 192.168.15.9 Calling:[email protected]:0 Sep 24 18:31:58 192.168.15.9 [0:0]AUD ALLOC CALL (port=16444) Sep 24 18:31:58 192.168.15.9 [0:0]RTP Rx Up Sep 24 18:31:58 192.168.15.9 [0:5060]->217.10.68.147:5060 Sep 24 18:31:58 192.168.15.9 [0:5060]->217.10.68.147:5060 Sep 24 18:31:58 192.168.15.9 INVITE sip:[email protected] SIP/2.0^M Via: SIP/2.0/UDP 77.20.237.113:5060;branch=z9hG4bK-5fa7a07e;rport^M From: Richter <sip:[email protected]>;tag=a1e57602f246d1deo0^M To: <sip:[email protected]>^M Call-ID: [email protected]^m CSeq: 101 INVITE^M Max-Forwards: 70^M Contact: Richter <sip:[email protected]:5060>^M Expires: 240^M User-Agent: Linksys/PAP2T-5.1.1(LS)^M Content-Length: 442^M Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER^M Supported: x-sipura, replaces^M Content-Type: application/sdp^M ^M v=0^M o=- 93561 93561 IN IP4 77.20.237.113^M s=-^M c=IN IP4 77.20.237.113^M t=0 0^M m=audio 16444 RTP/AVP 8 0 2 4 18 96 97 98 100 101^M a=rtpmap:8 PCMA/8000^M a=rtpmap:0 PCMU/8000^M a=rtpmap:2 G726-32/8000^M a=rtpmap:4 G723/8000^M a=rtpmap:18 G729a/8000^M a=rtpmap:96 G726-40/8000^M a=rtpmap:97 G726-24/8000^M a=rtpmap:98 G726-16/8000^M a=rtpmap:100 NSE/8000^M a=fmtp:100 192-193^M a=rtpmap:101 telephone-event/8000^M a=fmtp:101 0-15^M a=ptime:20^M a=sendrecv^M Sep 24 18:31:58 192.168.15.9 Sep 24 18:31:58 192.168.15.9 Sep 24 18:31:59 192.168.15.9 [0:5060]->217.10.68.147:5060 Sep 24 18:31:59 192.168.15.9 [0:5060]->217.10.68.147:5060 Sep 24 18:31:59 192.168.15.9 INVITE sip:[email protected] SIP/2.0^M Via: SIP/2.0/UDP 77.20.237.113:5060;branch=z9hG4bK-5fa7a07e;rport^M From: Richter <sip:[email protected]>;tag=a1e57602f246d1deo0^M To: <sip:[email protected]>^M Call-ID: [email protected]^m CSeq: 101 INVITE^M Max-Forwards: 70^M Contact: Richter <sip:[email protected]:5060>^M Expires: 240^M User-Agent: Linksys/PAP2T-5.1.1(LS)^M Content-Length: 442^M Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER^M Supported: x-sipura, replaces^M Content-Type: application/sdp^M ^M v=0^M o=- 93561 93561 IN IP4 77.20.237.113^M s=-^M c=IN IP4 77.20.237.113^M t=0 0^M m=audio 16444 RTP/AVP 8 0 2 4 18 96 97 98 100 101^M a=rtpmap:8 PCMA/8000^M a=rtpmap:0 PCMU/8000^M a=rtpmap:2 G726-32/8000^M a=rtpmap:4 G723/8000^M a=rtpmap:18 G729a/8000^M a=rtpmap:96 G726-40/8000^M a=rtpmap:97 G726-24/8000^M a=rtpmap:98 G726-16/8000^M a=rtpmap:100 NSE/8000^M a=fmtp:100 192-193^M a=rtpmap:101 telephone-event/8000^M a=fmtp:101 0-15^M a=ptime:20^M a=sendrecv^M Sep 24 18:31:59 192.168.15.9 Sep 24 18:31:59 192.168.15.9 Sep 24 18:31:59 192.168.15.9 [0:5060]->217.10.68.147:5060 Sep 24 18:31:59 192.168.15.9 [0:5060]->217.10.68.147:5060 Sep 24 18:31:59 192.168.15.9 NOTIFY sip:217.10.68.147 SIP/2.0^M Via: SIP/2.0/UDP 77.20.237.113:5060;branch=z9hG4bK-6d7849d0;rport^M From: Richter <sip:[email protected]>;tag=65bbf9ec3a01a2cco0^M To: <sip:217.10.68.147>^M Call-ID: [email protected]^m CSeq: 93 NOTIFY^M Max-Forwards: 70^M Event: keep-alive^M User-Agent: Linksys/PAP2T-5.1.1(LS)^M Content-Length: 0^M ^M Sep 24 18:49:29 192.168.15.9 Sep 24 18:49:29 192.168.15.9 Sep 24 18:49:29 192.168.15.9 [0:5060]<<217.10.68.147:5060 Sep 24 18:49:29 192.168.15.9 [0:5060]<<217.10.68.147:5060 Sep 24 18:49:29 192.168.15.9 SIP/2.0 200 OK^M Record-Route: <sip:217.10.68.147;lr=on;ftag=36bb74bb43384db3o0>^M Via: SIP/2.0/UDP 192.168.15.9:5060;branch=z9hG4bK-c62ea4f2;rport=5060^M From: Richter <sip:[email protected]>;tag=36bb74bb43384db3o0^M To: <sip:217.10.68.147>;tag=efae1b206a1df22b5fbc395b5a747d13.d026^M Call-ID: [email protected]^m CSeq: 3 NOTIFY^M Content-Length: 0^M ^M Sep 24 18:49:29 192.168.15.9 [messages repeating] Sep 24 18:32:30 192.168.15.9 Sep 24 18:32:30 192.168.15.9 Sep 24 18:32:30 192.168.15.9 [0:0]AUD Rel Call Sep 24 18:32:30 192.168.15.9 CC:Failed w/ Calling Sep 24 18:32:30 192.168.15.9 Sess Terminated And here is the one with the external ip enabled: Sep 24 18:51:29 192.168.15.9 [0]On Hook Sep 24 18:51:30 192.168.15.9 [0]Off Hook Sep 24 18:51:30 192.168.15.9 [0]CID interrupted Sep 24 18:51:35 192.168.15.9 Calling:[email protected]:0 Sep 24 18:51:35 192.168.15.9 [0:0]AUD ALLOC CALL (port=16410) Sep 24 18:51:35 192.168.15.9 [0:0]RTP Rx Up Sep 24 18:51:35 192.168.15.9 [0:5060]->217.10.68.147:5060 Sep 24 18:51:35 192.168.15.9 [0:5060]->217.10.68.147:5060 Sep 24 18:51:35 192.168.15.9 INVITE sip:[email protected] SIP/2.0^M Via: SIP/2.0/UDP 77.20.237.113:5060;branch=z9hG4bK-e55ce0da;rport^M From: Richter <sip:[email protected]>;tag=b82078c374d3f749o0^M To: <sip:[email protected]>^M Call-ID: [email protected]^m CSeq: 101 INVITE^M Max-Forwards: 70^M Contact: Richter <sip:[email protected]:5060>^M Expires: 240^M User-Agent: Linksys/PAP2T-5.1.1(LS)^M Content-Length: 440^M Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER^M Supported: x-sipura, replaces^M Content-Type: application/sdp^M ^M v=0^M o=- 7857 7857 IN IP4 77.20.237.113^M s=-^M c=IN IP4 77.20.237.113^M t=0 0^M m=audio 16410 RTP/AVP 8 0 2 4 18 96 97 98 100 101^M a=rtpmap:8 PCMA/8000^M a=rtpmap:0 PCMU/8000^M a=rtpmap:2 G726-32/8000^M a=rtpmap:4 G723/8000^M a=rtpmap:18 G729a/8000^M a=rtpmap:96 G726-40/8000^M a=rtpmap:97 G726-24/8000^M a=rtpmap:98 G726-16/8000^M a=rtpmap:100 NSE/8000^M a=fmtp:100 192-193^M a=rtpmap:101 telephone-event/8000^M a=fmtp:101 0-15^M a=ptime:20^M a=sendrecv^M Sep 24 18:51:35 192.168.15.9 Sep 24 18:51:35 192.168.15.9 Sep 24 18:51:36 192.168.15.9 [0:5060]->217.10.68.147:5060 Sep 24 18:51:36 192.168.15.9 [0:5060]->217.10.68.147:5060 Sep 24 18:51:36 192.168.15.9 INVITE sip:[email protected] SIP/2.0^M Via: SIP/2.0/UDP 77.20.237.113:5060;branch=z9hG4bK-e55ce0da;rport^M From: Richter <sip:[email protected]>;tag=b82078c374d3f749o0^M To: <sip:[email protected]>^M Call-ID: [email protected]^m CSeq: 101 INVITE^M Max-Forwards: 70^M Contact: Richter <sip:[email protected]:5060>^M Expires: 240^M User-Agent: Linksys/PAP2T-5.1.1(LS)^M Content-Length: 440^M Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER^M Supported: x-sipura, replaces^M Content-Type: application/sdp^M ^M v=0^M o=- 7857 7857 IN IP4 77.20.237.113^M s=-^M c=IN IP4 77.20.237.113^M t=0 0^M m=audio 16410 RTP/AVP 8 0 2 4 18 96 97 98 100 101^M a=rtpmap:8 PCMA/8000^M a=rtpmap:0 PCMU/8000^M a=rtpmap:2 G726-32/8000^M a=rtpmap:4 G723/8000^M a=rtpmap:18 G729a/8000^M a=rtpmap:96 G726-40/8000^M a=rtpmap:97 G726-24/8000^M a=rtpmap:98 G726-16/8000^M a=rtpmap:100 NSE/8000^M a=fmtp:100 192-193^M a=rtpmap:101 telephone-event/8000^M a=fmtp:101 0-15^M a=ptime:20^M a=sendrecv^M Sep 24 18:51:36 192.168.15.9 Sep 24 18:51:36 192.168.15.9 Sep 24 18:51:37 192.168.15.9 [0:5060]->217.10.68.147:5060 Sep 24 18:51:37 192.168.15.9 [0:5060]->217.10.68.147:5060 Sep 24 18:51:37 192.168.15.9 INVITE sip:[email protected] SIP/2.0^M Via: SIP/2.0/UDP 77.20.237.113:5060;branch=z9hG4bK-e55ce0da;rport^M From: Richter <sip:[email protected]>;tag=b82078c374d3f749o0^M To: <sip:[email protected]>^M Call-ID: [email protected]^m CSeq: 101 INVITE^M Max-Forwards: 70^M Contact: Richter <sip:[email protected]:5060>^M Expires: 240^M User-Agent: Linksys/PAP2T-5.1.1(LS)^M Content-Length: 440^M Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER^M Supported: x-sipura, replaces^M Content-Type: application/sdp^M ^M v=0^M o=- 7857 7857 IN IP4 77.20.237.113^M s=-^M c=IN IP4 77.20.237.113^M t=0 0^M m=audio 16410 RTP/AVP 8 0 2 4 18 96 97 98 100 101^M a=rtpmap:8 PCMA/8000^M a=rtpmap:0 PCMU/8000^M a=rtpmap:2 G726-32/8000^M a=rtpmap:4 G723/8000^M a=rtpmap:18 G729a/8000^M a=rtpmap:96 G726-40/8000^M a=rtpmap:97 G726-24/8000^M a=rtpmap:98 G726-16/8000^M a=rtpmap:100 NSE/8000^M a=fmtp:100 192-193^M a=rtpmap:101 telephone-event/8000^M a=fmtp:101 0-15^M a=ptime:20^M a=sendrecv^M Sep 24 18:51:37 192.168.15.9 Sep 24 18:51:37 192.168.15.9 Sep 24 18:51:38 192.168.15.9 [0:5060]->217.10.68.147:5060 Sep 24 18:51:38 192.168.15.9 [0:5060]->217.10.68.147:5060 Sep 24 18:51:38 192.168.15.9 NOTIFY sip:217.10.68.147 SIP/2.0^M Via: SIP/2.0/UDP 77.20.237.113:5060;branch=z9hG4bK-52ed5778;rport^M From: Richter <sip:[email protected]>;tag=ac368516db778115o0^M To: <sip:217.10.68.147>^M Call-ID: [email protected]^m CSeq: 8 NOTIFY^M Max-Forwards: 70^M Event: keep-alive^M User-Agent: Linksys/PAP2T-5.1.1(LS)^M Content-Length: 0^M ^M [messages repeating] Sep 24 18:52:07 192.168.15.9 Sep 24 18:52:07 192.168.15.9 Sep 24 18:52:07 192.168.15.9 [0:0]AUD Rel Call Sep 24 18:52:07 192.168.15.9 CC:Failed w/ Calling Sep 24 18:52:07 192.168.15.9 Sess Terminated In both you can see the following line: <sip:217.10.68.147>^M Call-ID: [email protected] I supsect that this is the faulty one. But maybe i am wrong? However, all that doesnt work. I didnt find my provider (sipgate.de) to have a nat proxy. But i read something about sip server or something like that? Any other ideas what is going on here? Thanks Sven On Thu, Sep 24, 2009 at 2:25 PM, Simon Hobson <[email protected]> wrote: > 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 > ------------------------------------------------------------------------------ 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
