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.
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.
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.
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).
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".