cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Please be advised, the GuideMe Wizard is no longer available on the Small Business Support Community. For search capability please use the community search field to find content related to Cisco Small Business documents, videos, and discussions.
920
Views
5
Helpful
12
Replies
Highlighted
Beginner

SPA504G and PBX Asterisk with different registration state.

Hi,
I've faced up a issue on 136 Cisco SPA504G with firmware 7.5.2 and 7.5.4, which I wish  to share with you in order to get help from you.

In one moment, we started to receive claims from our users who were saying " they couldn't dial nor received any phone call".  We verified our  Asterisk PBX and we realized that there were 136 extensions in "unreachable" state. So, we entered into the some  web service of the phone and we could see its registration state was "Registered" and its next registration in was "0s". But the PBX saw them as "unreachable".

We checked the LAN conection between them and the PBX, but didn't find any problem. 

The only way for recover this situation was unplug and plug the power all the phones.

 

Have you experienced a similar issue ?, How can I prevent a new issue?


Regards

Rodrigo

12 REPLIES 12
Engager

Well, I'm maintainer of a lot

Well, I'm maintainer of a lot of Asterisks (v.11.11.0) switches. Some of them have few hundreds SPA504G phones registered all the time. We deployed no 7.5.2 version of firmware, but we user 7.5.4. Currently we are using 7.5.5. During past three years we has not been affected by issue you described or something similar.

Increase verbosity and turn on debug messages on Asterisk console. Catch packets between your Asterisk switch and a device. Start with registered and reachable device, wait until the PBX will claim it unreachable. Console messages as well as trace file may help you (or us) to analyze the issue.

Beginner

Thank for your fast answer. I

Thank for your fast answer. I take your recommendations.

Regards

Beginner

Unfortunatley I am seeing

Unfortunatley I am seeing exactly the same issue with Asterisk 13.6.0 and SPA508G with firmware 7.6.1.


It is only happening on the handset which is configured with two different extensions on separate line keys.


It usually happens when I ring that phone, e.g. from my cell, and hang up.

Here is the problem state (701/701 should be at 192.168.1.82 along with extension 753):

PBX*CLI> sip show peers
Name/username Host Dyn Forcerport Comedia ACL Port Status Description
701/701 (Unspecified) D No No A 0 UNKNOWN
702/702 192.168.1.33 D No No A 5060 OK (8 ms)
703 (Unspecified) D No No A 0 UNKNOWN
704 (Unspecified) D No No A 0 UNKNOWN
705 (Unspecified) D No No A 0 UNKNOWN
706 (Unspecified) D No No A 0 UNKNOWN
707 (Unspecified) D No No A 0 UNKNOWN
708 (Unspecified) D No No A 0 UNKNOWN
709 (Unspecified) D No No A 0 UNKNOWN
710 (Unspecified) D No No A 0 UNKNOWN
711 (Unspecified) D No No A 0 UNKNOWN
712 (Unspecified) D No No A 0 UNKNOWN
713 (Unspecified) D No No A 0 UNKNOWN
714 (Unspecified) D No No A 0 UNKNOWN
751 (Unspecified) D No No A 0 UNKNOWN
752 (Unspecified) D No No A 0 UNKNOWN
753/753 192.168.1.82 D No No A 5060 OK (9 ms)
799 (Unspecified) D No No A 0 UNKNOWN
99702 (Unspecified) D No No A 0 UNKNOWN
gamma 88.215.63.9 Yes Yes 5060 OK (13 ms)
20 sip peers [Monitored: 3 online, 17 offline Unmonitored: 0 online, 0 offline]
[2015-10-31 02:07:41] NOTICE[3336]: chan_sip.c:23908 handle_response_peerpoke: Peer '701' is now Reachable. (11ms / 2000ms)

and when the phone's registration timer expires, and it re-registers, all is OK again:

PBX*CLI> sip show peers
Name/username Host Dyn Forcerport Comedia ACL Port Status Description
701/701 192.168.1.82 D No No A 5060 OK (10 ms)
702/702 192.168.1.33 D No No A 5060 OK (6 ms)
703 (Unspecified) D No No A 0 UNKNOWN
704 (Unspecified) D No No A 0 UNKNOWN
705 (Unspecified) D No No A 0 UNKNOWN
706 (Unspecified) D No No A 0 UNKNOWN
707 (Unspecified) D No No A 0 UNKNOWN
708 (Unspecified) D No No A 0 UNKNOWN
709 (Unspecified) D No No A 0 UNKNOWN
710 (Unspecified) D No No A 0 UNKNOWN
711 (Unspecified) D No No A 0 UNKNOWN
712 (Unspecified) D No No A 0 UNKNOWN
713 (Unspecified) D No No A 0 UNKNOWN
714 (Unspecified) D No No A 0 UNKNOWN
751 (Unspecified) D No No A 0 UNKNOWN
752 (Unspecified) D No No A 0 UNKNOWN
753/753 192.168.1.82 D No No A 5060 OK (11 ms)
799 (Unspecified) D No No A 0 UNKNOWN
99702 (Unspecified) D No No A 0 UNKNOWN
gamma 88.215.63.9 Yes Yes 5060 OK (13 ms)

I have tried putting the other extension to listen (phone side) on udp 5061, but it doesn't help. Nat keepalives (so that it sends $NOTIFY) doesn't help.

I think maybe the phone doesn't respond to the qualify request or something, when a call is just terminated? It's getting confused some how.

Sip debugging does show the NOTIFY (nat keepalive) and OPTIONS (qualify msgs) going both ways. but sometimes (it's unpredicatable), 701 always shows as registered on the handset, but unreachable on Asterisk, right until the phone re-registers.

I have just dropped the registration timeout on the phone to 60 seconds and it hasn't done it again yet, but I set it to 5 mins before and I thought it was all sorted then, but an hour or two later and I see the same problem.


There's no NAT here, it's just on a regular lan. I did read on some old Netgear smart switches doing weird things like this, so I will have to check the switch model when I'm in the office.

Engager

Same issue, same advice:

Same issue, same advice:

Increase verbosity and turn on debug messages on Asterisk console. Catch packets between your Asterisk switch and a device. Start with registered and reachable device, wait until the PBX will claim it unreachable. Console messages as well as trace file may help you (or us) to analyze the issue.

Beginner

I am trying, but I don't see

I am trying, but I don't see anything useful, and the problem is hard to replicate.

I think I am going to try turning off qualify=yes, as there's some talk of this causing problems sometimes.


Perhaps the phone ignore ones of the qualifies (options) when it has already received the same for its other registered extension.

Engager

Unless you provide a data we

Unless you provide a data we can analyze, there's little we can do for you.

Beginner

i get that, and thanks. I'll

i get that, and thanks. I'll see how it goes. I have removed othe devices today but I can't repeat it. I tried for more than an hour.

Beginner

For the record, this appears

For the record, this appears to have been a bug in Asterisk 13.6.0.

I installed another system yesterday, that I had prepared the same Asterisk build on, back around November, and I am seeing similar issues, but this time with a Gigaset N300IP DECT handset.

This time I turned up this bug:

https://issues.asterisk.org/jira/browse/ASTERISK-25476

which sounds exactly like my issue.

Engager

For the record, I has been

For the record, I has been affected by the issue you described when I upgraded our infrastructure from Asterisk 11.11 to Asterisk 11.20. Now I'm moving to 11.21 as it's claimed to be patched.

The issue seems not to be related to particular phone, thus Cisco seems not to be guilty here.

Beginner

Yes it was an Asterisk bug.

Yes it was an Asterisk bug. Really tough when you spend weeks googling and looking into a "phantom issue" that nobody else ever sees, and then months later you realise you were just the only person who seemed to be actually using that code for those few weeks, or the only person reporting on problems anyway.

I spend 9/10 time googling, and 1/10 posting when I utterly give in. I always assume other people will have been there first. A lesson learned for running latest builds of Asterisk anyway, and maybe posting a bit sooner..

Engager

Well, when I has become

Well, when I has become affected, I didn't remembered this thread. So I did own full analysis. It has been not so hard to identify the Asterisk is the cause. Phone has asked registration for N seconds, Asterisk confirmed registration for N seconds. So far so good. But then, after M < N second, Asterisk has claimed the phone unregistered for no apparent reason.

Captured SIP dialog has provided the evidence there's nothing wrong with it, thus the internal Asterisk bug has been the only explanation.

I has been saved from phantom issues offered by Google because of it. But before I started searching the Asterisk bug database I found this thread again, thus your reference to ASTERISK-25476. Thank you for it (despite this part of our conversation is rather off-topic in this community).

Beginner

Yes but when I was doing my

Yes but when I was doing my analysis there was no suitable known bug listed.