SPA112 drops registration - no dialtone

[danbuchko]

Just picked up the SPA112 on the weekend, and am setting it up with voip.ms.  Several times a day, registration fails, resulting in no dialtone when the phone is picked up.  It does eventually seem to reconnect, but I won't be able to use it if this continues.  I followed all the instructions for setting it up as posted on the voip.ms wiki.  It also looks like I could reduce the "Reg Retry Long Intvl" param in the Voice-SIP settings, but I feel this would just be masking the real issue.

I have also tried using the Cisco Support chat, but after sitting there for hours with no response, I thought I'd try this forum -- it looks like it is monitored by the support engineers.  (I've captured my settings and log files, ready to send them in for analysis.)

Anyone else had this issue and been able to resolve it?

Dan

[nseto]

In the log file, how often is the registration supposed to re-occur?  The service provider sends a setting and we do as well.  The parameter that controls this on the ata, is called 'register expires'. 

Also, is the service provider looking for a keep alive?  We do provide for this, it's the NAT Keep Alive.  You would enable the NAT keep alive for this.

[danbuchko]

I cannot find any indication in the log files (even though I have them set to debug level) as to why the registration fails.  In fact, I don't see anything even indicating it failed.

In the Voice menu, I have set the following params:

NAT Settings:

NAT Mapping Enable: Yes

NAT Keep Alive Enable:  Yes

Proxy and Registration:

Register: Yes

Register Expires:  60

Proxy Fallback Intvl: 60

After my posting yesterday, I've also made the following changes in the SIP section:

SIP Timer Values (sec):

Reg Retry Intvl: 10

Reg Retry Long Intvl: 60

At least now after making these last changes, I haven't found an instance where there is no dialtone on picking up the phone.  I will try to find out from my provider the correct value to set in the "Response Status Code Handling-Retry Reg RSC" parameter (which is currently empty).  It would seem if I can get the right value there then the "Reg Retry Long Intvl" timer should not kick in very often.

Is there any way I can get the reason for the registration failure?  It would seem that if I could get the reason, then it would be possible to determine what the root cause is.

Regards,

Dan

P.S.  I've already upgraded to the latest firmware, version 1.1.0(011).

[nseto]

Based on your registration settings, you should be seeing Reg sent out every 60 secs.  Are you seeing that in the log file?

Make sure the SIP debug is set to All.

Further details at https://supportforums.cisco.com/docs/DOC-9862

[danbuchko]

Ok, I've followed your instructions to successfully capture the debug log.  I reverted the latest settings I'd made last night in order to reproduce the problem, and waited for it to re-occur.  It did, and I have captured a log file.  How can I get the log file to you for analysis?

Regards,

Dan

[nseto]

You can email me the logs with my user name nseto at cisco.com.

[robbikay1]

Hi nseto, I sent you my logs as well. I'd like to suggest for the engineers involved with these units to get a free account with voip.ms and les.net (I don't think they charge unless you buy a DID), and it takes a minute to set up. This way you can look at the registration problem directly, and hopefully at least determine if you can do anything about it.

Rob K.

[danbuchko]

I have opened a support case

SR 620929613

You will find the logs there, I will also e-mail them to you directly.

As per Rob's note below, since the issue is reproducible, opening your own account with one of these providers might be the best way to troubleshoot this issue.

Regards,

Dan

[nomadoVoIP]

Obviousely, the problem is this buggy 1.1 SPA112 firmware which makes the shame on Cisco. PAP2T should have been kept :-(

Also posted here :

https://supportforums.cisco.com/thread/2160107

Nomado VoIP provider
Best Quality Rate of VoIP (datanews.com)

[robbikay1]

This looks like the same problem I have. See...

https://supportforums.cisco.com/thread/2124463

Of course my solution doesn't do anything to address the problem.

I will re-open my case and submit my log as well.

[danbuchko]

I agree -- it sounds the same.

I tried connecting my SPA112 directly to my cable modem (not going through my router), and it still lost the dialtone, so it definitely isn't a router issue.

Regards,

Dan

[robbikay1]

Hi Daniel,

To get the proper logs, put the ip address of your computer running slogsrv into Voice -> System -> Miscellaneous Settings -> Debug Server:

Make sure its level 3.

Don't use the Log module in the Administration section.

I attached my log file as an example. For the purposes of the log I set...

Register Expires: 60

Reg Retry Long Intvl: 30

To attach the log file, switch to advanced editor.

Rob K.

Message was edited by: Robert Kralik (log file removed)

[danbuchko]

Hi Rob,

Thanks for the logging tips.  I had followed the links nseto had provided above, and managed to get some detailed logs with the failures.  (They don't look quite as nice as yours with the date/timestamps, but do have more detailed info on each transaction.)

From what I can see, both your logs and mine indicate registration is failing on authorization.  It fails 3 times, then the long timer kicks in (default of 1200s).  Question I have, why does authorization suddenly start failing?

Another thing I see (that my provider also pointed out) was a number of "489 Bad event" entries in the log, and they'd suggested that often indicates a NAT issue.  But I've got the NAT Mapping & Keep Alive both set to "Yes".  And also, I still lost dialtone when connecting directly to my cable modem (taking my router completely out of the loop).

Anyways, I was able to get through to Cisco support today and open a case, referring them to this thread.  They suggested the issue had to do with the expiry time not matching my voip provider's registration expiry time.  So I'm currently running some tests with it set to 100 to see.  I am skeptical that is the real issue, given the clues in the log files indicating the bad events and authorization failures.  But I'm willing to give it a shot.

Will keep you posted.

Regards,

Dan

[robbikay1]

Thanks for that, I was suspicious my log looked a bit sparse .

Rob K.

[danbuchko]

Well, I think I corrected my "489 Bad event" issue.  I changed the "NAT Keep Alive Msg" from $NOTIFY to $REGISTER.  My provider's server didn't like the $NOTIFY for the NAT keep-alive event.

So maybe that was the problem?  If the keep-alive didn't get through, then perhaps that eventually results in an auth failure?  Would be curious to know if you are also getting those 489 messages in your debug logs.

The other thing I've done is enable and set the "Use auth ID" in the Voice-Line 1-Subscriber Information section.  Although I am betting that is redundant, so I will probably revert that change if this keep alive change works.

I'll let it go overnight, and see how things look in the morning.

Regards,

Dan