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

[robbikay1]

My providers instruction suggests NAT mapping and keep-alive remain off, so that probably explains why I'm not seeing the 489 messages. The only responses I'm seeing from my provider are "100 Trying", "401 Unauthorized", and eventually "200 OK".

I get three or four 401's before the spa122 fails and goes into reg retry long invl.

I am also doubtful the issue has to do with the local reg expiry not matching the providers'. Following the reg retry long intvl (un-registered state, ie. no expiry to factor in), I'm still seeing a couple 401's occurring.

The logs aren't giving me any clue, I'll send them to Cisco tomorrow to take a look.

Rob K.

[robbikay1]

Hi Daniel,

I got a voip.ms account to play around with and was getting the same loss of registration out-of-the-box. But since I changed $NOTIFY to $REGISTER in NAT Keep Alive Msg like you suggest, it's been re-registering more successfully than before. I had to edit this to add that I was a bit too optimistic and it's once again in reg retry long intvl.

Rob K.

Message was edited by: Robert Kralik

[danbuchko]

Hi Rob,

Changing the message from $NOTIFY to $REGISTER seems to have improved things, but not totally solved the issue.  My wife picked up the phone yesterday (after I'd made the change), and again there was no dialtone so I am assuming it lost the registration again.

I'm going to try to collect some more logs today.

I'm getting to the point where I am thinking this may not be worth it in the end.  In addition to this issue, my wife has said the calls she has been able to make successfully were of poor quality (although I'd specified the G711u codec, and the premium service), so she's basically hung up and redialed on our old line, which isn't saving us anything 

Regards,

Dan

[robbikay1]

I initialy set the spa122 up with my provider's general access proxy and calls had a bit of a bubbles under water quality plus slight delay despite using g7.11u, and there were no packet loss or errors noted. However, since my provider granted permission to use their exclusive local access proxy, the quality is brilliant with no perceptible delay, and I'd say it's equivalent to Shaw Digital phone.

The details I was able to gather is the general access proxy is on the east coast and serves lots of connections, while the local access proxy is in my city and I'm sure serves much fewer connections.

Rob K.

[danbuchko]

Hi Rob,

I switched to point to the chicago.voip.ms server (from the toronto2.voip.ms server) this morning, reverted back to $NOTIFY (as that's what voip.ms support told me it should be), and so far haven't lost the registration.  According to voip.ms, the chicago server has the latest software on it.  I'll give it some more time, though, before I am convinced...

Regards,

Dan

[nseto]

Did the switch over work?  When the keepalive is sent to the proxy, does it respond with 200 ok instead of the 489 bad event?

Normally the unit will send Register and the proxy will send 200 Ok. In this particular case, the proxy wants auth as well, so it sends 401 Unauth and so the unit replies with the Register with the Auth added.

The reg expires is set to 60 secs, so there should be a reg request from the unit every minute to the proxy.  You can turn on the timestamp option with the slogsrv by adding the -t to it.  For various options available, type in slogsrv -h for the help.

If the register is sent out but there's nothing coming back from the proxy, that's when the keepalive may be help (as the port may be closed on the router after some time, this keepalive keeps the port open).

[danbuchko]

Still getting 489 Bad Event messages.  Tried enabling Auth ID, but it made no difference.

In spite of that, so far so good on my side, no registration failures since switching to Chicago.  Will continue to monitor.

Regards,

Dan

[danbuchko]

"In this particular case, the proxy wants auth as well, so it sends 401  Unauth and so the unit replies with the Register with the Auth added."

Is there a way to make the device send the correct event to the proxy (i.e. register with auth) the first time, to eliminate the 489's?

Quick update, have had a few auth failures this morning, but all recovered within 10 seconds and re-registered successfully.

Regards,

Dan

[nseto]

AuthID, isn't the same as the proxy requesting auth during a registration. 

If the proxy needed AuthID in the first place and you didn't have it, the unit would never have been able to register.  You would have gotten something like a 403 registration error.

A 401 Unauth (proxy does this which is optional) is always sent in response to a regular registration. 

Unit would send a Registration, proxy either sends 200 OK or 401 Unauth.  If it sends back 401 Unauth, then the unit sends another Registration with the Auth in the Registration.

You might as well turn off the Notify keepalives if the proxy is only sending 489 in response to that.

[robbikay1]

toronto.voip.ms is running Asterisk 1.4.21.1

chicago.voip.ms is running Asterisk 1.4.32

The most interesting item that comes up in the changelog http://downloads.asterisk.org/pub/telephony/asterisk/old-releases/ChangeLog-1.4.32 is:

2009-07-10 16:23 +0000 [r205804]  David Vossel 

     * channels/chan_sip.c: SIP registration auth loop caused by stale
       nonce If an endpoint sends two registration requests in a very
       short period of time with the same nonce, both receive 401
       responses from Asterisk, each with a different nonce (the second
       401 containing the current nonce and the first one being stale).
       If the endpoint responds to the first 401, it does not match the
       current nonce so Asterisk sends a third 401 with a newly
       generated nonce (which updates the current nonce)... Now if the
       endpoint responds to the second 401, it does not match the
       current nonce either and Asterisk sends a fourth 401 with a newly
       generated nonce... This loop goes on and on. There appears to be
       a simple fix for this. If the nonce from the request does not
       match our nonce, but is a good response to a previous nonce,
       instead of sending a 401 with a newly generated nonce, use the
       current one instead. This breaks the loop as the nonce is not
       updated until a response is received. Additional logic has been
       added to make sure no nonce can be responded to twice though.
       (closes issue #15102) Reported by: Jamuel Patches:
       patch-bug_0015102 uploaded by Jamuel (license 809) nonce_sip.diff
       uploaded by dvossel (license 671) Tested by: Jamuel Review:
       https://reviewboard.asterisk.org/r/289/

If this is the issue with the spa1xx devices, as it seems to be, then any provider running pre-1.4.26 version of Asterisk will be affected.

[robbikay1]

I started logging my connection to the chicago.voip.ms server that you mentioned at 1:44 this after noon. It's interesting that the only times that it failed and went into reg retry long intvl occurred at 2:43, 3:43, and 4:43. I'll keep the log running to see if this pattern continues.

Rob K.

New edit: Actually the chicago.voip.ms server has not failed. I just realized the instances of failure are ocurring on line 1, my les.net connection, which is set to expire every hour. Voip.ms chicago server on line 2 is holding strong.

Message was edited by: Robert Kralik

[robbikay1]

I set up a test to confirm that indeed the spa1xx devices are interacting with the pre-1.4.26 Asterisk registration deadlock condition I mentioned above [r205804]. I reproduced this failure on my LAN with the spa122 and Asterisk 1.4.25.1 running on Linux with netem delay introduced on the network interface. The failure starts to occur somewhere between 40-45ms of delay (40-45ms ping time as seen from the spa122) and greater. As expected, once I applied the 1.4.26 patch to Asterisk, the failure no longer occured.

Rob K.

[robbikay1]

As noted in https://supportforums.cisco.com/message/3616349

The T1 timer is 10x shorter than what's entered in the interface. This appears to be the reason why the spa1xx are sending the second registration request so quickly and thus interacting with the deadlock condition mentioned above.

Rob K.

[Chad Monroe]

If you can't upgrade your Asterisk server (e.g. hosted VoIP), Cisco now has a beta load of firmware available which solves this problem.

[ginne12855]

Anybody who has this beta load of firmware available? I need it desperately.

Guenther