netgear ta612v behind netgear DG834G wireless adsl router problems

Has anyone here had any experience setting up a TA612v device behind a (Netgear) firewall and connecting to the Sipgate service? I have been struggling for months to keep the telephone connection live. Sometimes it will stay on for a week or two, other times much less. Once the connection is lost it is almost impossible to get it going again. Rebooting the TA612 VOIP adapter is never enough, and when I do manage to get it working I cannot find any logical reason for it doing so (and there is no sequence of actions yet discovered which will guarantee the connection is restored). I contacted sipgate support on numerous occassions but we never got to the bottom of the problem. Their first suggestion was:

please forward the ports 5004, 5060 and 5083 (all UDP). If you have activated STUN in your TA612V, please deactivate it.

I set up the above services on the ADSL router to allow UDP/TCP forwarding to the LAN port on the TA612 device as suggested, but to no avail.

From looking around the various forums I think the TA612V device is "locked" so I cannot access all the configuration settings to see if STUN us activated, and this option is not available on the available menus. Any suggestions? ... Chris

seems to be still working after three days... logs showing the following message only:

Mon, 2009-08-17 07:58:08 - UDP Packet - Source:10.1.1.91,5083 Destination:217.10.79.23,5060 - [SIPsignal rule match]

where 10.1.1.91 is the IP address of the TA612V internet port (LAN port is on 10.1.1.90, and the destination address is on sipgates servers.

will keep you posted.

Hmmmm.... now the connection has failed - was working up until yesterday.

Line 1 Status
Hook State: ON
Registration State: Failed
Message Waiting: NO

-------------
from the netgear firewall logs (see below) all I can see different today is that the adsl router was rebooted around 18.29 hrs and I think after that the VOIP went down (but I am only guessing this is it as I used the phone earlier that afternoon, and now around 23.40 when I check is is not working. How annoying! I will try rebooting the VOIP device and see if it reconnects. Will keep posting. Anyone know what this is about? (taken from the log below)

Wed, 2009-08-26 18:30:30 - UDP Packet - Source:87.248.104.124,3479 Destination:87.112.1.9,4073 - [DOS]

---------------------------------
firewall logs

Wed, 2009-08-26 18:18:36 - UDP Packet - Source:10.1.1.91,5083 Destination:217.10.79.23,5060 - [SIPsignal rule match]
Wed, 2009-08-26 18:28:36 - UDP Packet - Source:10.1.1.91,5083 Destination:217.10.79.23,5060 - [SIPsignal rule match]
Wed, 2009-08-26 18:28:57 - Administrator login successful - IP:10.1.1.200
Wed, 2009-08-26 18:29:09 - LCP down.
Wed, 2009-08-26 18:29:12 - Initialize LCP.
Wed, 2009-08-26 18:29:35 - UDP Packet - Source:10.1.1.91,5083 Destination:217.10.79.23,5060 - [SIPsignal rule match]
Wed, 2009-08-26 18:29:36 - LCP is allowed to come up.
Wed, 2009-08-26 18:29:37 - UDP Packet - Source:10.1.1.91,5083 Destination:217.10.79.23,5060 - [SIPsignal rule match]
Wed, 2009-08-26 18:29:39 - CHAP authentication success
Wed, 2009-08-26 18:30:30 - UDP Packet - Source:10.1.1.200,4072 Destination:87.248.104.124,3478 - [SIPstunpt rule match]
Wed, 2009-08-26 18:30:30 - UDP Packet - Source:10.1.1.200,4073 Destination:87.248.104.124,3478 - [SIPstunpt rule match]
Wed, 2009-08-26 18:30:30 - UDP Packet - Source:87.248.104.124,3479 Destination:87.112.1.9,4073 - [DOS]
Wed, 2009-08-26 18:30:30 - UDP Packet - Source:87.248.104.123,3478 Destination:87.112.1.9,4073 - [DOS]
Wed, 2009-08-26 18:30:30 - UDP Packet - Source:87.248.104.124,3479 Destination:87.112.1.9,4073 - [DOS]
Wed, 2009-08-26 18:30:30 - UDP Packet - Source:87.248.104.123,3478 Destination:87.112.1.9,4073 - [DOS]
Wed, 2009-08-26 18:30:30 - UDP Packet - Source:87.248.104.124,3479 Destination:87.112.1.9,4073 - [DOS]
Wed, 2009-08-26 18:30:35 - UDP Packet - Source:10.1.1.91,5083 Destination:217.10.79.23,5060 - [SIPsignal rule match]
Wed, 2009-08-26 18:30:54 - UDP Packet - Source:10.1.1.200,4093 Destination:87.248.104.124,3478 - [SIPstunpt rule match]
Wed, 2009-08-26 18:30:54 - UDP Packet - Source:10.1.1.200,4094 Destination:87.248.104.124,3478 - [SIPstunpt rule match]
Wed, 2009-08-26 18:31:35 - UDP Packet - Source:10.1.1.91,5083 Destination:217.10.79.23,5060 - [SIPsignal rule match]
Wed, 2009-08-26 18:38:10 - UDP Packet - Source:10.1.1.91,5083 Destination:217.10.79.23,5060 - [SIPsignal rule match]
Wed, 2009-08-26 18:48:10 - UDP Packet - Source:10.1.1.91,5083 Destination:217.10.79.23,5060 - [SIPsignal rule match]
Wed, 2009-08-26 18:58:10 - UDP Packet - Source:10.1.1.91,5083 Destination:217.10.79.23,5060 - [SIPsignal rule match]
Wed, 2009-08-26 19:08:10 - UDP Packet - Source:10.1.1.91,5083 Destination:217.10.79.23,5060 - [SIPsignal rule match]
Wed, 2009-08-26 19:18:10 - UDP Packet - Source:10.1.1.91,5083 Destination:217.10.79.23,5060 - [SIPsignal rule match]
Wed, 2009-08-26 19:28:10 - UDP Packet - Source:10.1.1.91,5083 Destination:217.10.79.23,5060 - [SIPsignal rule match]
Wed, 2009-08-26 19:38:10 - UDP Packet - Source:10.1.1.91,5083 Destination:217.10.79.23,5060 - [SIPsignal rule match]
Wed, 2009-08-26 19:48:10 - UDP Packet - Source:10.1.1.91,5083 Destination:217.10.79.23,5060 - [SIPsignal rule match]
Wed, 2009-08-26 19:58:10 - UDP Packet - Source:10.1.1.91,5083 Destination:217.10.79.23,5060 - [SIPsignal rule match]
Wed, 2009-08-26 20:08:10 - UDP Packet - Source:10.1.1.91,5083 Destination:217.10.79.23,5060 - [SIPsignal rule match]
Wed, 2009-08-26 20:18:10 - UDP Packet - Source:10.1.1.91,5083 Destination:217.10.79.23,5060 - [SIPsignal rule match]
Wed, 2009-08-26 20:28:10 - UDP Packet - Source:10.1.1.91,5083 Destination:217.10.79.23,5060 - [SIPsignal rule match]
Wed, 2009-08-26 20:38:10 - UDP Packet - Source:10.1.1.91,5083 Destination:217.10.79.23,5060 - [SIPsignal rule match]
Wed, 2009-08-26 20:48:10 - UDP Packet - Source:10.1.1.91,5083 Destination:217.10.79.23,5060 - [SIPsignal rule match]
Wed, 2009-08-26 20:58:10 - UDP Packet - Source:10.1.1.91,5083 Destination:217.10.79.23,5060 - [SIPsignal rule match]
Wed, 2009-08-26 21:08:10 - UDP Packet - Source:10.1.1.91,5083 Destination:217.10.79.23,5060 - [SIPsignal rule match]
Wed, 2009-08-26 21:18:10 - UDP Packet - Source:10.1.1.91,5083 Destination:217.10.79.23,5060 - [SIPsignal rule match]
Wed, 2009-08-26 21:28:09 - UDP Packet - Source:10.1.1.91,5083 Destination:217.10.79.23,5060 - [SIPsignal rule match]
Wed, 2009-08-26 21:38:09 - UDP Packet - Source:10.1.1.91,5083 Destination:217.10.79.23,5060 - [SIPsignal rule match]
Wed, 2009-08-26 21:48:09 - UDP Packet - Source:10.1.1.91,5083 Destination:217.10.79.23,5060 - [SIPsignal rule match]
Wed, 2009-08-26 21:58:09 - UDP Packet - Source:10.1.1.91,5083 Destination:217.10.79.23,5060 - [SIPsignal rule match]
Wed, 2009-08-26 22:08:09 - UDP Packet - Source:10.1.1.91,5083 Destination:217.10.79.23,5060 - [SIPsignal rule match]
Wed, 2009-08-26 22:18:09 - UDP Packet - Source:10.1.1.91,5083 Destination:217.10.79.23,5060 - [SIPsignal rule match]
Wed, 2009-08-26 22:28:09 - UDP Packet - Source:10.1.1.91,5083 Destination:217.10.79.23,5060 - [SIPsignal rule match]
Wed, 2009-08-26 22:38:09 - UDP Packet - Source:10.1.1.91,5083 Destination:217.10.79.23,5060 - [SIPsignal rule match]
Wed, 2009-08-26 22:48:09 - UDP Packet - Source:10.1.1.91,5083 Destination:217.10.79.23,5060 - [SIPsignal rule match]
Wed, 2009-08-26 22:58:09 - UDP Packet - Source:10.1.1.91,5083 Destination:217.10.79.23,5060 - [SIPsignal rule match]
Wed, 2009-08-26 23:08:09 - UDP Packet - Source:10.1.1.91,5083 Destination:217.10.79.23,5060 - [SIPsignal rule match]
Wed, 2009-08-26 23:18:09 - UDP Packet - Source:10.1.1.91,5083 Destination:217.10.79.23,5060 - [SIPsignal rule match]
Wed, 2009-08-26 23:28:09 - UDP Packet - Source:10.1.1.91,5083 Destination:217.10.79.23,5060 - [SIPsignal rule match]
Wed, 2009-08-26 23:38:09 - UDP Packet - Source:10.1.1.91,5083 Destination:217.10.79.23,5060 - [SIPsignal rule match]
Wed, 2009-08-26 23:40:23 - Administrator login successful - IP:10.1.1.200
Wed, 2009-08-26 23:40:34 - UDP Packet - Source:10.1.1.91,5083 Destination:217.10.79.23,5060 - [SIPsignal rule match]

Update: despite two reboots of the TA612 voip device there is no phone connection. Hmmmmmm! Wonder what next?

i have still not figured out how to get the connection back. i did try putting the TA612 into a demilitarised zone but this did not work either. still no-one here with any suggestions?

just to keep you all posted (if anyone is following this thread) - I have now made contact with the Sipgate service team. First thing is for me to check the port forwarding settings again. I was thinking about the log file yesterday and it is interseting that I only log UDP packets on port 5083 - to destination port 5060 at the sipgate end (217.10.79.23). I will ask them about this. Why forward the other ports when they have never shown any activity (as far as my ADSL router is concerned).

for no apparent reason the voip service has started working again today. sipgate support have been unable to provide any solution to the problem. I was asked to reboot the ta612 device last week so they could check their logs. after rebooting they did not record any packets from my router. i have asked them to check their logs today and for a copy of this for me to look at. logs this side give no clues to the problem. i am thinking of adding a syslog server as the TA612v has a facility to send detailed logs out to this. i just need to find a syslog server program now. if anyone here has any suggestions which program to use I would be most grateful.

I think I am getting to the bottom of this problem. My netgear router does not have a fixed IP address assigned to it by the ISP. The TA612 adapter has been registering with your servers for the last week or so correctly. However, when I reinitialise the netgear firewall, the TA612 no longer registers with the sipgate VOIP servers. I can only assume that the new IP address assigned to me by my ISP has something to do with this. Here is the syslog record of the event I recorded yesterday. As you can see, after the LCP is initialised, the TA612 no longer registers on the server (time LCP initialised 2009-09-21 01:51:15). Is this something anyone is aware of and does anyone have a work around for this? This will happen from time to time after, for instance, after a power failure.

2009-09-21 01:46:39 Local0.Warning 10.1.1.98 UDP Packet - Source:10.1.1.91,5083 Destination:217.10.79.23,5060 - [SIPsignal rule match]
2009-09-21 01:48:19 Kernel.Info 10.1.1.90 2009 Sep 21 00:39:40 (TA612V-da-f6-1e) 10.1.1.91 send REGISTER sip:1993151@sipgate.co.uk:5060 => sip:1993151@sipgate.co.uk:5060
2009-09-21 01:48:21 Kernel.Warning 10.1.1.90 2009 Sep 21 00:39:44 (TA612V-da-f6-1e) 10.1.1.91 SIP 401/407 received, SSMU_RVREG Authantication Needed
2009-09-21 01:48:21 Kernel.Notice 10.1.1.90 2009 Sep 21 00:39:45 (TA612V-da-f6-1e) 10.1.1.91 REGISTER with authentication send
2009-09-21 01:48:23 Kernel.Notice 10.1.1.90 2009 Sep 21 00:39:45 (TA612V-da-f6-1e) 10.1.1.91 SIP 200 OK received
2009-09-21 01:50:17 Local7.Notice 10.1.1.90 2009 Sep 21 00:41:40 (TA612V-da-f6-1e) 10.1.1.91 Administrator login successful - IP:10.1.1.200
2009-09-21 01:50:38 Auth.Info 10.1.1.98 Administrator login successful - IP:10.1.1.200
2009-09-21 01:50:39 Local0.Warning 10.1.1.98 UDP Packet - Source:10.1.1.91,5083 Destination:217.10.79.23,5060 - [SIPsignal rule match]
2009-09-21 01:50:46 Local7.Notice 10.1.1.90 2009 Sep 21 00:42:10 (TA612V-da-f6-1e) 10.1.1.91 Administrator logout - IP:10.1.1.200
2009-09-21 01:51:15 Syslog.Info 10.1.1.98 LCP down.
2009-09-21 01:51:18 Syslog.Info 10.1.1.98 Initialize LCP.
2009-09-21 01:51:39 Local0.Warning 10.1.1.98 UDP Packet - Source:10.1.1.91,5083 Destination:217.10.79.23,5060 - [SIPsignal rule match]
2009-09-21 01:51:39 Syslog.Info 10.1.1.98 LCP is allowed to come up.
2009-09-21 01:51:41 Local0.Warning 10.1.1.98 UDP Packet - Source:10.1.1.91,5083 Destination:217.10.79.23,5060 - [SIPsignal rule match]
2009-09-21 01:51:43 Syslog.Info 10.1.1.98 CHAP authentication success
2009-09-21 01:51:50 Local0.Warning 10.1.1.98 UDP Packet - Source:10.1.1.91,5083 Destination:217.10.79.23,5060 - [SIPsignal rule match]
2009-09-21 01:56:39 Local0.Warning 10.1.1.98 UDP Packet - Source:10.1.1.91,5083 Destination:217.10.79.23,5060 - [SIPsignal rule match]
2009-09-21 01:57:19 Kernel.Info 10.1.1.90 2009 Sep 21 00:48:40 (TA612V-da-f6-1e) 10.1.1.91 send REGISTER sip:1993151@sipgate.co.uk:5060 => sip:1993151@sipgate.co.uk:5060
2009-09-21 01:57:42 Kernel.Warning 10.1.1.90 2009 Sep 21 00:48:44 (TA612V-da-f6-1e) 10.1.1.91 SSMU_RVREG Registration Failed
2009-09-21 01:57:49 Kernel.Info 10.1.1.90 2009 Sep 21 00:49:10 (TA612V-da-f6-1e) 10.1.1.91 send REGISTER sip:1993151@sipgate.co.uk:5060 => sip:1993151@sipgate.co.uk:5060
2009-09-21 01:58:12 Kernel.Warning 10.1.1.90 2009 Sep 21 00:49:14 (TA612V-da-f6-1e) 10.1.1.91 SSMU_RVREG Registration Failed

the problem with the erratic connection of the TA612adapter through the firewall has been finally resolved. I do not have a fixed IP address, so when the netgear DG834 router reboots after, for instance, a power failure, or changing a setting in its configuration, it is assigned a new IP address. The IP address of the router is recorded by the sipgate servers along with the MAC address of the TA612 telephone adapter. When the firewall reboots, for some reason the sipgate server wont re-register the new IP address, and rejects all UDP packets form the TA612v forever after. To resolve this, sipgate suggest that I put the firewall and TA612v on a timeswitch so every night they are both turned off for around 10 minutes, enough time for the sipgate servers to re-register the TA621 mac address along with a new IP address of the firewall. So far this works - i have tested it by turning both devices off and then turning them on again an hour later. I have yet to find out what the minimum length of time is needed to make the re-connection. I hope this is helpful for anyone who has been having the same problems. I wonder if sipgate can change their service to take account of this difficulty. I suspect most home users are on variable IP addresses. I will update this thread if needed, but for now I consider this workaround adequate if not ideal.

It seems that only the TA612 VOIP adapter needs to be reset... so power it off for a lenght of time that is sufficent for the sipgate servers to reset themselves. Odd though, as both the VOIP adapter and the router are on a PSU backup battery to prevent them resetting when the power goes down. I don't really understand why the VOIP adapter loses its connection in this case, but turning the power off for at least 10 minutes (I have not yet worked out what the shortest time is needed) seems to work for now.

I don't really understand why the VOIP adapter loses its connection in some cases, but turning the power off for several minutes.