Need to reboot SIP device often

[fplLover]

It seems whenever my dynamic Teksavvy DSL Ip address changes I have to reboot my Cisco SPA112 in order to restore my phone service.

Anyone else experience this when their IP address changes?

My guess is that paying extra for a static Ip address would fix the problem but I would rather avoid having to do this if possible...

Other than this problem the service has been fantastic....great features and call quality...

BTW: My SPA112 sits behind my firewall.

Thanks

[Mango]

In order to troubleshoot this issue, we need to know what router you have.

[fplLover]

It is a Dlink DSR-250. Again, I'm quite certain it is happening in a 1 to 1 fashion when Teksavvy gives me a new Ip address.

Thanks

[Mango]

I looked through the manual for your router but was not able to find any documentation about its UDP timeouts. As far as I am aware they are not configurable, though I would be delighted to be corrected if I am wrong. We can try some general troubleshooting:

As always, please make sure your ATA is configured as per the official guide: http://forum.fongo.com/viewtopic.php?f=15&t=16206

From within your router's Advanced >> Firewall Settings >> ALGs, please uncheck SIP if it is not already. Sometimes, SIP ALGs cause an inordinately long UDP timeout.

If you still have the problem, you will need to increase your ATA's Reg Retry Intvl. The purpose of this is to make the ATA wait for a time before attempting to re-register. This allows your router's NAT connection (with your old IP) to time out so that a new one can be created. Start out with a Reg Retry Intvl of 120. If it is already set to that number or greater, add a few minutes to it. Unfortunately, determining the correct interval will be a bit of a guessing game. Next time you experience the problem, wait for the length of the Reg Retry Intvl and see if it automatically resolves by itself. If not, increase the Reg Retry Intvl some more.

[fplLover]

I would agree, it does not look like it is settable in my router....

My ATA was configured using that guide. I just went through the config again and verified all the settings. All looks good.

I confirmed in my firewall that the SIP ALG is unchecked.

In any case, I do not think this has anything to do with my router from what I can tell. To prove this idea I simply did the following while everything was up and running perfectly -->

I simply power cycled my router. This was enough to put the Cisco SPA112 into a state where it will never successfully register again unless it is either rebooted or I login to it and resave its configuration after changing the "Register Expires" setting. This is despite the fact that after power cycling the router the Internet connectivity fully came back afterwards. The Cisco SPA just sits there in a defunct state until either the reboot or config re-save on it is performed. So by the fact that just a reboot on the router can cause this to happen I highly doubt in my case that the timeout of NAT state tables in the router has anything to do with it...ie: given that a reboot on the router would ensure that said state tables are flushed...

I even tried lowering the "Register Expires" and "Proxy Fallback Intvl" settings to 60 secs before doing both the router power cycle test and a less intrusive WAN Ip DHCP renegotiation on the router. In doing so I brought the settings down from the original values of 3600 sec.

I assume when you say Reg Retry Intvl you are referring to the "Register Expires" setting?

This is really weird for sure. Any other thoughts? It is definitely tied 1:1 with a change in WAN IP address.

One other thing I would state --> I am using my SPA112 with STUN configured on and the STUN server I am hitting is stun.counterpath.net

[Mango]

Any other thoughts?

Yes. Try the advice of someone who has been administering VoIP systems professionally for nearly a decade.

[fplLover]

okay sorry...

I now see the Reg Retry Intvl you are talking about...I did not mess with that at all...I will play with that...I was confusing that with the Register Expires setting...

[Mango]

Good stuff. After you increase that, try to power cycle your router again, then wait the length of the Reg Retry Intvl. Hopefully the ATA will auto-recover, after the length of the Reg Retry Intvl. If not, we will continue to troubleshoot.

Also, I would like to recommend again that you configure your ATA as per the official guide: http://forum.fongo.com/viewtopic.php?f=15&t=16206 . I see that you have a Register Expires setting of 60, and you are using a STUN server, which are not part of the official guide. Once you get things working, then you can modify to your liking.

[fplLover]

Oh no, I only changed Register Expires to 60 in recent hours surrounding trying to fix this problem. I originally had it set to the 3600 in the official guide.

As for the STUN. Yeah, that I had to have in place because without it I could not seem to get things working properly.

I will try what you are saying shortly. I sort of already tried it like that with doing a WAN IP renegotiate but I hear ya. I will try that next.

Thanks

[fplLover]

So right now the Reg Retry Intvl is at 360. Register Expires is at 3600.

If everything is up and working perfectly and I do a power cycle of my router it does seem to recover...Probably has something to do with the SPA112 going through a new DHCP negotiation with the router? Not sure, but in any case that seems fine.

If, however, I instead log into my router and force my WAN Ip address change (i.e: the more accurate case of where I'm having issues) the problem remains. The SPA112 seems like it will just sit there in a defunct state until I either power cycle it or login to it and force a config update/save by changing certain settings (Register Expires etc)

That's where things are at...

Cheers

[Mango]

That's unfortunate. I was hoping that the SPA would realize via keep-alive that the server was unreachable but it seems that is not the case. Perhaps waiting 3600+360 seconds would get you re-registered, though that would probably not be desirable.

It's likely that you could lower Register Expires to 1800 and not get banned - as OBi ATAs register at half of their X_RegistrationPeriod and we do not hear complaints from those users. Unfortunately, this would still mean about half an hour of downtime after an IP change.

If anyone wants to suggest another solution that does not involve the OP replacing his router, by all means.

[fplLover]

Well, in the past when I have had it happen my setup had been sitting in a "failed state" following an IP change for much more than and hour...more like hours....An ip change would often happen over night and then I would notice it in the morning and need to reboot the SPA112.

I know you are the guy with years of experience with this stuff but I really don't see how the router has anything to do with it at this point. As evidence, consider that I can just re-save configuration on the SPA112 any time and have it re-register without a problem. If there was some sort of a problem with the router then I would not be able to remedy the situation by doing so don't you think? It all seems very SPA112-centric in my possibly naive opinion.

If anyone has any other ideas I'm up for it. Are there any other SIP timeout values that could be in play here?

[Mango]

Well, in the past when I have had it happen my setup had been sitting in a "failed state" following an IP change for much more than and hour...more like hours...

Was this before or after you increased the Reg Retry Intvl? If the Reg Retry Intvl was low, like the default of 30 seconds, the behaviour you describe is expected.

[fplLover]

You are correct on that. Previous to talking with you that Reg Retry Intvl was 30 seconds for sure during these "failed states".

Just for my benefit could you possibly summarize all of the relevant timeout values and intervals, what they are for, and how they relate to one another?

[fplLover]

Like why is there not some setting to say keep retrying every 30 seconds to get a viable connection...and keep trying until it does? Again, based my experience where I can re-save the config and have it re-establish at will it should work if there is a sure fire way to get the SPA112 to for sure retry regularly. It seems to me that it is not trying regularly...Like if it fails to negotiate keep trying, not go hands off for some insane amount of time..

Why is it that I cannot have the Reg Retry Intvl at 30 and have this instruct it to try re-negotiating every 30 sec when it is in a failed state? What would be the setting or combination of setting to get it to perform such behaviour? Again, perhaps this is just me not understanding the ins and outs of these settings and their relationships to one another...

[Mango]

Just for my benefit could you possibly summarize all of the relevant timeout values and intervals

Absolutely.

udp_session_timeout: the amount of time your router will keep a connection active, if no SIP traffic is sent or received.
NAT Keep Alive Intvl: the frequency with which the ATA will send a small packet of data to FPL to keep the connection active.
Register Expires: the frequency with which the ATA will register with FPL.
Reg Retry Intvl: the amount of time the ATA will wait, after a failed registration, before trying to register again.

My theory is that your router does not clear its connections when it obtains a new IP address. NAT Keep Alive keeps the old/invalid connection active until the device fails its next registration, which can take as much as 3600 seconds. Then it waits for Reg Retry Intvl seconds, the connection clears, and the next registration is successful.

Like why is there not some setting to say keep retrying every 30 seconds to get a viable connection...and keep trying until it does?

30 seconds would not work, as this is less than your udp_session_timeout. Your tests indicate that 360 seconds would work - but a Register Expires this low would get you banned from FPL as they require a long Register Expires setting.

It seems to me that it is not trying regularly

I believe you are correct. Your tests indicate that it will not attempt to recover until the registration expires. It would be nice if the ATA noticed the server was unreachable via keep-alive.

Why is it that I cannot have the Reg Retry Intvl at 30 and have this instruct it to try re-negotiating every 30 sec when it is in a failed state?

30 seconds is less than your udp_session_timeout, so in this configuration it would never recover. The ATA would keep the old/invalid connection active. Also, keep in mind that it does not seem to start retrying until the registration expires, which, if you use FPL, can take as much as 3600 seconds.

Does anyone know what the SPA112 would do in this situation if configured with a proxy that has DNS SRV records, or multiple A records?

One other thought: you may want to try to upgrade your router's firmware, in case a later version does not have this bug.

I've made minor edits to this post for accuracy.

[Mango]

Next time you plan to leave your house for an hour or more, change your IP before you go, and let us know if your ATA is back online by the time you get home. That will confirm that my theory is correct, or not.

[fplLover]

I'll try it over night

Thanks

[fplLover]

I found out what the udp_session_timeout is for my router currently. If I telnet into it and use the CLI I can view it and change it.

It is currently set to 120 seconds. With that said shouldn't that work just nicely with a Reg Retry Intvl of 360?

[Mango]

shouldn't that work just nicely with a Reg Retry Intvl of 360?

Yes - but given the behaviour you describe, it seems that you need to wait for the registration to expire (up to 3600 seconds, for FPL customers) before the Reg Retry Intvl comes into play.

[fplLover]

This is all becoming very strange if I'm being honest. Clearly it is not the router. So are you telling me that any freephoneline customer that has a dynamic ip is going to have to deal with this kind of situation every time their ip changes simply because freephoneline has some policy that says this value must be set to an hour?

It seems a bit strange. Can some sort of exception be made for customer like myself who are experiencing these types of problems?

I will still do the test overnight...

Thanks

[Mango]

So are you telling me that any freephoneline customer that has a dynamic ip is going to have to deal with this kind of situation every time their ip changes simply because freephoneline has some policy that says this value must be set to an hour?

Yes. But, if their router works properly, they will be able to make outgoing calls in the time between when their IP changes and their ATA re-registers, and they will not need to powercycle things to restore service.

[fplLover]

Are my problems linked to the fact that I am using STUN? If I did not use STUN by memory I only had voice in one direction or something like that.

Given that clearly my udp session timeout seems okay, what specifically about my router do you think is different than the other guys' router that allows them to "make outgoing calls in the time between when their ip changes and their ATA re-registers"

Again, I'll let you know what my overnight test yields

Cheers

[fplLover]

So based on what we have talked about, and given our discovery that my udp session timeout is 120 sec, things in theory should go like this, no? -->

Everything is working and honky dory

I force a wan ip change

The SPA112 should go into a failed state for its registration and then 360 seconds later from there it should try to register. Given that the udp session should timeout in the router after 120 seconds or so into this 360 second time window in theory the SPA112 should succeed to register at the 360 sec mark, right?

For whatever the reason so far it would seem that this will not happening like this, and hopefully at a minimum an hour in it will succeed due to the Register Expires setting at 3600. Again, I'll let you know how it goes but why would it not succeed to register at the 360 sec mark?

Bah

[Mango]

I don't think your problems are related to STUN. We don't recommend it because if your STUN server goes down, your phone service won't work, or won't work well. As an alternate, you can configure your device as per my post below the official guide: http://forum.fongo.com/viewtopic.php?f=15&t=16206 . However, I suggest you troubleshoot one problem at a time. You can worry about your STUN server later.