Reaction of Equipment after Change of IP-Number?

Your configuration should look like this: ModemSPA3000Routerpc(s)

and all four devices should use DHCP to get IP and DNS addresses.

I'm using VoIP behind a NAT Modem-Router from Netgear and a Sipura SPA3000 for inbound and outbound telephony from all my phones.

But I get a new IP-number at least once a day from my DSL Provider. After this number change the Sipura failes to reregister correctly.

Does anybody have problems with these IP-number changes? How do you solve this?

Wolfgang

You are using DHCP on the router and using private IP addresses on all the connected devices, aren't you..?

Ivor

Yes. I do use a modem-router from Netgear with port restricted cone NAT.

This is my DHCP source for my private LAN, where the SIPURA is in.

Everything works properly. Even NAT traversal. The only problem is that reregistering(?) and/or NAT stay alive(?) tend to fail after change of the EXTERNAL IP-Number.

Wolfgang

But I have a modem-router with DHCP and behind that there is the SPA3000 and the PCs. I cannot change this configuration.

PCs and Sipura do use DHCP to get local IP and DNS addresses. The modem-router gets its via PPPoE.

Wolfgang

Why not? How do you expect the SPA3000 to do QoS?

Why is that?

Yes, the problem is that the Sipura device doesn't have any way of being actively alerted that the external IP of the router has changed, so it constructs its SIP headers incorrectly.

I suppose it could be configured to check more frequently (with the STUN server or something); I haven't been sufficiently motivated to look into it further yet though.

miguel

If it's DHCP then it should come with a lease time. Does the sipura ignore the lease time?

For example, because the router handles the PPPoE decoding and NATting.

Because that's how things work when your provider uses PPPoE and gives you only one IP address (assigned through PPPoE), which obviously can't be shared among devices: hence the need for NAT functionality, and often the DHCP service to assign the local IP addresses, both of which can be provided by the route.

That said, I have the same configuration as Wolfgang's (SPA-3000 behind the NAT router) and never noticed that problem. On the other hand, I used to have a different type of problem with a Netgear MR814v2

. Now I'm running Linux on a Linksys WRT54G ) and Netgear is only a painful memory :-)

The nice thing of using Linux as router is that one can run tcpdump to capture packets to a file, transfer the file to a bigger machine and inspect them with Ethereal. This would tell you more about why the re-registration fails: which is a quite unusual thing. Wolfgang, are you sure it fails? Or perhaps is it not repeated often enough, so that after the change of IP address the remote SIP registrar still remembers the old address? In that case, you could try to reduce the re-registration interval of the SPA-3000 to, say, a couple of minutes. You can do this putting 60 (the number of seconds) in the "Register Expires:" field of the "Line 1" and "PSTN Line" screens of the Admin interface.

Another way of inspecting the SIP packets would be installing a NON switching 10baseT hub between router and SPA-3000, and use it just like a T-joint to tap into the traffic with a monitoring machine directly running Ethereal. Unfortunately, in these days non-switching hubs are hard to find.

Enzo

[snip]

It doesn't *need* to know. All the Sipura needs to know is the private IP address of the router, usually 192.168.1.1 or something similar. It doesn't know or care about the public IP address, only the router does.

My connection has what I call a semi-static IP address, in that it can stay the same for weeks on end then change for no apparent reason..! My Sipura has never failed to register because of it.

Ivor

Actually it _should_ care, in order to meet the SIP specifications; but some registrar proxies flat-out ignore the SIP headers and use, as IP address and UDP port, the same present as source on the headers of the packet that contained the registration request. This violation of the SIP specs often saves the day, but sometimes the results turn out to be annoying because it prevents third-party registration. Before understanding what was going on, I wasted days trying to register a Sipura SPA-3000 on multiple registrars using a utility, Sipsak

running on a PC on the same LAN. I did that because the SPA-3000, due to a silly firmware limitation, can place calls through several outbound proxies BUT can register only on one of them. Well, it didn't work, despite the fact that I passed all the right parameters to Sipsak and Sipsak prepared the SIP headers accordingly: the registrar always registered the SPA-3000 at the UDP port mapped as source by the NAT router for the packets coming from the Sipsak client, which of course was different from the one I had specified for the SPA-3000 :-(

Moral of this story: if you deal with NATs, whenever possible avoid SIP like the plague, and use IAX2.

Enzo

I think we can take it for granted that if the thing is doing anything at all, it knows its proximal router's address.

But if you sniff SIP traffic you will probably see your external (outside of NAT) IP address communicated in the payload (not just in packet headers). At least I do between my Sipura (inside NAT) and Asterisk server (in the wild).

miguel

Register expires is 3600 seconds in the moment. But reregistering failed several times after IP-change. At least for 10 hours. But I will give it a try an reregister earlier.

In this moment I have this combined modem-router, so I do not want to change hardware.

Thanks for the hints.

Wolfgang

Seams so.

Wolfgang

[snip]

I've got a 16 port 10-base-T hub if anyone wants it..! Redundant since I upgraded all my stuff to 100-base-T.

Ivor

By the way, which NAT-related options have you set under "NAT Support Parameters" in the SIP screen of the Admin interface? I have set everything to "yes" with the exception of "Send Resp To Src Port:" which is a "no"; "STUN Server:" points to "stun.fwdnet.net:3478"; "EXT RTP Port Min:" and "EXT IP:" are both blank, and "NAT Keep Alive Intvl:" is set to "15".

Enzo

I thought you said the sipura was given a fixed IP...

Ok. I'll think about this. But as far as I understood its necessary to set "Send Resp to src port" to yes because my router users "port restricted cone NAT".

But its working ok since two days now. No idea why.

Wolfgang

Internally it uses DHCP but based on the MAC it will always be the same.

But the problem is with the EXTERNAL IP-number which is very different each day.

Wolfgang