voip-telefonie SX541 hinter Router

hi rob,

here's what the stun client returns:
D:\SX541\Stun>client.exe iphone-stun.freenet.de
STUN client version 0.94
Primary: Full Cone Nat, random port, will hairpin
Return value is 0x1

Regarding the NAT I will further investigate this tomorrow.

/JockyW

[Edit]: I was looking a bit more careful at the serial console. This is the last SIP packet after succesful registration of the first account:
SIP/2.0 200 OK
Call-ID: [email protected]
CSeq: 2 REGISTER
From: "JockyW Line1"<sip:[email protected]>;tag=siemens-sx541-1.62-113863885-3a
a68255-560616472
To: "JockyW Line1"<sip:[email protected]>;tag=b11cb9bb270104b49a99a995b8c68544.8fc4
Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK341ef00a6094e703e0f3553a4eb625
67;rport=60180;received=217.228.167.133
Contact: <sip:[email protected]:63466>;q=0.00;expires=945
Contact: <sip:[email protected]:60180>;q=0.00;expires=1800
Server: sipgate ser
Content-Length: 0
Warning: 392 217.10.79.9:5060 "Noisy feedback tells: pid=19044 req_src_ip=217.228.167.133 req_src_port=60180 in_uri=sip:sipgate.de:5060 out_uri=sip:sipgate.de:
5060 via_cnt==1"

My wan IP is 217.228.167.133
See that req_src_port=60180 ?
It must be the point where trouble starts, because some time later when I try to call the siemens I see a UDP packet sent by sipgate to siemens port 60180 and the siemens answering a ICMP packet "port unreachable", followed by sipgate sending a SIP/SD INVITE to siemens port 60180, siemens answering the same ICMP, the same game once more and then the call ends in nirvana (no ring tone and the serial log doesn't log any of the sip packets which ethereal logged nicely). Seems that the SX541 blocks traffic to ports which it's very own sip engine generated in the first place!
 
Hi Jockyw,

- "full cone NAT"? - a very good starting point
- in the console log you posted yesterday, there was a 5060 (instead of a very high port - here 60180) in the req_src_port. Is this because it was edited or was it really 5060 (at the same position in the "rport" and "req_src_port" statement). I suppose, it should have been the 63150 of your firewall log?
- Does the icmp 3/3 (port inreachable) come directly from the SX541 and not from your D-Link-Box? If it came from the D-Link-Box, this would indicate a NAT timeout problem, otherwise it really would mean a big question mark. Did you etherealize that? What would be a little bit strange about the blocking situation (or just already closed port?), is, that, if placed in the WAN with official IPs, there is no port blocking. The port indicated after the "rport" and the "req_src_port" are, is I read it, in the case of a NATed environment the Source Ports after NAT. So there could be a difference between the Ports the SX541 opened and the Ports after NAT.

Bis gleich,

Rob
 
rob schrieb:
- in the console log you posted yesterday, there was a 5060 (instead of a very high port - here 60180) in the req_src_port. Is this because it was edited or was it really 5060 (at the same position in the "rport" and "req_src_port" statement). I suppose, it should have been the 63150 of your firewall log?
I didn't edit those port values. Sometimes it is 5060 and sometimes they are values >60000. Yesterday before going to bed I rebooted the SX541 as many times until I got port 5060:
Contact: <sip:[email protected]:5060>;q=0.00;expires=1800
Then I went to bed and this morning I called the SX541. My phone said "connection not possible". I rebooted the SX541 and got something like:
Contact: <sip:[email protected]:61973>;q=0.00;expires=1800
Then I called the SX541 and it worked. But after some time it fails again. So I'm unsure which device, D-Link or SX541, closes the NAT ports. So I have to answer the question you also just asked me:
- Does the icmp 3/3 (port inreachable) come directly from the SX541 and not from your D-Link-Box? If it came from the D-Link-Box, this would indicate a NAT timeout problem...
To answer this question I have to do further ethereal traces. I suppose I have to observe the mac source address?

cya later ...
/JockyW

[Edit]: yes according ethereal these packets really come directly from the SX541 (both the IP and the mac src address belong to the SX541). I will pick up my SX541 from home and connect it in my office in ca. 1 hr
 
Yeah, MAC addr would be the best and most precise way to determine that.
Where is the Hub positionned? Can you see all the traffic (even that generated by the WAN-device of the D-Link-Modem/Router?

Quite a strange behavior - sometimes a 5060, sometimes a 6xxxx source port. I made the same experiences ...

cya later (hope not too much later ;-)),

Rob
 
Those damn meetings are good for nothing :(

Ok, finally found some time to test the SX541 here in the office in front of the firewall and with a public IP. What shall I say, it works great! I should mention that the phone is different. At home I use a Loewe DECT mobile+basestation.

So this prolly means that my D-Link is causing the trouble at home. I was thinking of 2 more solutions for a working SX541 behind my D-Link at home:
1. Switch on UPNP on both the D-Link and the SX541. On the D-Link: disable DMZ, remove all PAT and firewall rules referring to the SX541. On the SX541: disable NAT, Firewall, DHCP, WLAN (actually these settings were already set on the SX541). My hope is then that UPNP will take care of the port handling
2. Install a SIP Proxy in my LAN (e.g. http://siproxd.sourceforge.net/). I could easily run that on my Asus WL-HDD :)

Of course I'm still very interested in a good explanation of my current issues. I hate it if there is something which can't be explained ...

/JockyW
 
Hi Jockyw,

- public IP with still the same constellation? - RFC 1483 on the WAN side, same IP on the "LAN" side ... like you already posted it before?
- to 1.: the SX541 as a UPnP-client of the D-Link? Don't know whether this really works - it's worth trying ...
- I would like to find out (if your time permits), where the 6xxxx-requests came from - from the Siemens or the D-Link (although the SX541 works as a "standalone" machine directly in the Internet - I also love explanations. Think if we've solved that we got a very good understanding of how SIP exactly works.

Thanks for your investigations,

Herbert
 
rob schrieb:
- public IP with still the same constellation? - RFC 1483 on the WAN side, same IP on the "LAN" side ... like you already posted it before?
yes, wan=lan IP, and of course I needed to change def.gateway and dns server IP as well

- to 1.: the SX541 as a UPnP-client of the D-Link? Don't know whether this really works - it's worth trying ...
I'll try this evening at ca. 21:00

- I would like to find out (if your time permits), where the 6xxxx-requests came from - from the Siemens or the D-Link (although the SX541 works as a "standalone" machine directly in the Internet - I also love explanations. Think if we've solved that we got a very good understanding of how SIP exactly works.
my time doesn't permit me, it's me who permits time :)
Take a look at the faq section here, it helped me understanding sip a bit better: http://siproxd.sourceforge.net

cya later, JockyW
 
Hi,

didn't watch for a while, I am shure, the 60xxx Ports are the NATed from your D-Link, strange is only, that you tell that the destination unreachable ist from the Siemens.

Klaus
 
Well I did the test with UPNP enabled on both D-Link & SX541. It works fine for exactly 30 minutes (1800 seconds), then the Sipgate registration expires and incoming & outgoing VoIP calls are no longer possible.
In a desparate last attempt I added a firewall rule on the D-Link to allow all traffic from sipgate.de on wan/lan and all ports. But this didn't help either. Despite the firewall rule (and a reboot) the D-Link still logs things like: "Apr/01/2005 00:14:05 Drop UDP packet from WAN 217.10.79.9:5060 217.228.167.79:5060 Rule: Default deny"
So the rule (it's the first rule, so highest priority) doesn't work.

So unfortunately in my LAN there is no way to operate the SX541 behind the D-Link 614. The D-Link NAT spoils it :(

goodnight, JockyW

PS: actually I'm running the Trendware 3.11 firmware on the D-link. So if anyone running original D-Link or other firmwares on the D-Link 614 please test and post your experiences here
 
Hey Jockw,

was there really an identifiable difference between the state "UPnP enabled" and "UPnP not enabled". I cannot imagine the SX541 acting as a UPnP-Client for the stuff we're trying to do (where would be the statement for that?). Don't you think the 1800s are the same for UPnP and non-UPnP-configuration?

Rob
 
Hello,
don't you think that there is no UPnP clienent functionalyty in the SX? The SX is a Router by design, why should they implement client functionality. I think there is only the part in it needed for a Router.

Klaus
 
I'm also pretty sure that there is no UPnP client functionality in the SX541. But can anyone explain me why the SX541 works 30 minutes behind the D-Link without portforwarding and no 'allow' firewall rules :?:

Furthermore, I wonder why the D-Link still drops UDP packets coming from sipgate.de despite that I now added a firewall rule allowing this :?:

/JockyW
 
Maybe, the SX has no functionality to keep the firewall open. Normally there is no need for the concept of the Siemens SX to keep the firewall open, because the concept is that the VOIP functionality sits on the border. So no NATing is needed for the normal functionality. In other VOIP hardware you will find timer settings where you can adjust how often to reregister - no such thing in the SX :-(

Klaus
 
hi Klaus,
karpe schrieb:
... In other VOIP hardware you will find timer settings where you can adjust how often to reregister - no such thing in the SX :-(
Exactly, this is something Siemens should add. If Siemens doesn't add it I have to do it myself I'm afraid. For example by running some code on the pc, dbox or asus wl-hdd.

/JockyW

[edit] Yes, I think reregistering can simply be achieved by a small script which accesses http://sx541/voip_port.stm and "presses" the OK button. Any developer out there who can program that?
 
Hi Jockyw,

- does it work exactly 30 minutes (which is exactly the expiration time in the REGISTER-package) or does it work just some minutes like you wrote in the first testing? I would be quite astonished about that - this would mean that the D-Link keeps the NAT mapping for even 30 minutes (if no keepalives are sent)
- I think it could work without port forwarding rules: if you just open a socket (e.g. registration) and keep that alive and if you are able to handle by that socket not only the registration but also RTP, it could work at least for calling. For getting called there is a statement in SDP (a=direction:active) which tells the calling person that you (the called person) are the one to initiate the traffic (just to open a socket to have it opened backwards for RTP). This is a kind of weired theory, I admit, but I even saw that etherealized in my setup with a softphone behind the SX541which got called without any port forwarding. Just a theory - cannot prove it exactly, but I saw the traces.

For the dropped packages: do not understand that neither. Maybe a kind of weired configuration like: traffic allowed only when initiated before? O.K. - just another theory ;-), but better to have one than none? ;-) ;-) ;-). No to be honest, do not understand that. It might be that the D-Link interprets the icmp 3/3 and does not accept traffic where there is no endpoint socket (because this no longer exists on the SX541)? - theory Nr. 3

Rob
 
hi rob,
rob schrieb:
- does it work exactly 30 minutes (which is exactly the expiration time in the REGISTER-package) or does it work just some minutes like you wrote in the first testing? I would be quite astonished about that - this would mean that the D-Link keeps the NAT mapping for even 30 minutes (if no keepalives are sent)
Yes, exactly 30 minutes which was also the expiry time in the REGISTER packet. I rebooted the sx541, observed the SIP trace in the serial console and started incoming/outgoing calls. Exactly after 30 minutes calls were no longer possible in both directions.

- I think it could work without port forwarding rules: if you just open a socket (e.g. registration) and keep that alive and if you are able to handle by that socket not only the registration but also RTP, it could work at least for calling. For getting called there is a statement in SDP (a=direction:active) which tells the calling person that you (the called person) are the one to initiate the traffic (just to open a socket to have it opened backwards for RTP). This is a kind of weired theory, I admit, but I even saw that etherealized in my setup with a softphone behind the SX541which got called without any port forwarding. Just a theory - cannot prove it exactly, but I saw the traces.
ok, weird but plausible

Regarding the D-Link614+, I found here that there is a Pheenet 3.4.1 firmware which perhaps has a less buggy firewall. Perhaps I will give it a try, otherwise I will go for a solution using a script based periodic sip reregistration.

/JockyW
 
I think my solution will be "Siproxd" developed by Thomas Ries. I can run it on my Asus WL-HDD or even on a Dbox2 :)

Why am I hopeful? Read this.

Full documentation od Siproxd can be found in this pdf

Well, I'm off compiling the latest snapshot...

/JockyW
 
I compiled Siproxd for my Asus NAS (Asus WL-HDD) and finally can start to enjoy the SX541 behind my D-Link614+ router. VoIP works perfect for more than 24 hours now 8)

I can recommend the latest 1.63 firmware, because it has excellent voice quality.

/JockyW
 
Help is what I need!

Hi!

I am in a big fix. I just moved to Islamabad, Pakistan. Very naively, I bought the SX541 and brought it here with me (I am a novice when it comes to networking issues). The standard here is AnnexA G.dmt for DSL. Therefore, it seems that I can't use my SX541 directly and need a modem and router in between. I have procured a DSL205EU locally for the purpose.

I can surf the internet, however, the SX541 does not show that it has connected to the internet and I can't use VOIP. Jocky, you seem to have solved the problem, can you let me know the exact steps and configuration I need? I would appreciate any help I can get, as I otherwise would have to buy a new expensive unit.

I am using sipgate as my VOIP provider.

Thanks,
Adnan
 

Statistik des Forums

Themen
246,197
Beiträge
2,247,885
Mitglieder
373,755
Neuestes Mitglied
grdex
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.