CME - Shared lines show active calls when person is not on call

Unanswered Question
Jun 1st, 2007

Hi,

I have strange issue where some shared lines will start showing there is an active call on them (icon next to line number on phone, or red light on 7914 sidecar). The lines that have this problem are in a pickup group also.

The phone is able to place/receive calls fine, so this appears to be a display/cosmetic issue at this time.

The only thing I have found to clear this so far, for awhile, is to teboot the router.

It is a 2811 with 12.4(4)XC2 IOS

Firmwares:

load 7910 P00403020214

load 7935 P00503010100

load 7960-7940 P00307020200

load 7914 S00104000100

load ATA ATA030100SCCP040211A.zup

load 7905 CP7905010200SCCP031023A.sbin

load 7902 CP7902010200SCCP031023A.sbin

load 7920 cmterm_7920.3.3-01-07.bin

load 7912 CP7912060000SCCP050124A.sbin

Sample DN config of one of the lines.

ephone-dn 64 dual-line

number 6235

pickup-group 1

label DF 6235

call-forward busy 8000

call-forward noan 8000 timeout 20

I have also tried to reset the phone, remove the pickup group and add it back, etc and only a router reboot appears to clear this for awhile.

Any ideas?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.5 (2 ratings)
Loading.
Paolo Bevilacqua Fri, 06/01/2007 - 08:31

Hello,

can you upgrade to either 12.4(4)XC6 or even better, 12.4(11)XJ3? There are many bug fixes that have been incorporated after the version you are running.

Hope this helps, please rate post if it does!

Erick Bergquist Fri, 06/01/2007 - 08:41

I looked over the release notes and can't find a specific bug match that is fixed for this issue in new release if it is a bug. I'm willing to update the IOS but need to be confident the issue will be fixed.

Paolo Bevilacqua Fri, 06/01/2007 - 08:51

Hello,

what happens with cisco is that many bugs have implications that difficult to relate from the release-notes that are usually quite minimal.

E.g. look at the release notes for XJ3, more than 50 bugs fixed in CCME and note, most of them were present in all releases.

Plus, if you look for support, the TAC will invariably have you upgrade as first step.

This is why I recommend always to start with latest released image before doing anything else.

rob.huffman Fri, 06/01/2007 - 08:51

Hi Erick,

I'm sure Paolo is onto something here (good work) It sure looks like this bug;

CSCsh44232 Bug Details

Headline CME shared line stuck in busy due to UpdateCallState not being sent.

Duplicate of CSCse29317 - First Fixed-in Version 12.4(9.11), 12.4(4)XC03, 12.4(9.12)T, 12.4(9)T03

Symptom:

On CME 4.0, a shared line may get stuck in the 'in-use' state after a user goes OnHook. All phones with this line appearance (other than the phone that went OnHook) will show this line as in-use.

Conditions:

Conditions and triggers are unknown at this time. The line gets stuck due to UpdateCallState never being sent by the ephone after going OnHook. This has been observed on 7960 phones registered to both CME 3.3 and 4.0.

Workaround:

Do a hard reset on the phone after the line is in a stuck state, to free the DN back up for normal use.

Further Problem Description:

When the phone goes OnHook, we never see an UpdateCallState sent for the

call, so other phone think the line is still in use. Every phone but

the one that goes OnHook will get stuck.Symptom:

On CME 4.0, a shared line may get stuck in the 'in-use' state after a user goes OnHook. All phones with this line appearance (other than the phone that went OnHook) will show this line as in-use.

Conditions:

Conditions and triggers are unknown at this time. The line gets stuck due to UpdateCallState never being sent by the ephone after going OnHook. This has been observed on 7960 phones registered to both CME 3.3 and 4.0.

Workaround:

Do a hard reset on the phone after the line is in a stuck state, to free the DN back up for normal use.

Further Problem Description:

When the phone goes OnHook, we never see an UpdateCallState sent for the

call, so other phone think the line is still in use. Every phone but

the one that goes OnHook will get stuck.

Hope this helps!

Rob

Paolo Bevilacqua Fri, 06/01/2007 - 08:56

Thanks Rob, you may have hit the applicable bug.

My approach is to always upgrade first because as I mentioned before, certain bugs are difficult to find documented, _if_ they are documented at all. Without doubt, the one you mentioned, is exceptionally well documented.

That approach worked quite well for the past 14 years :)

rob.huffman Fri, 06/01/2007 - 11:42

Hi Paolo,

I know that you are correct here (as usual, great knowledge!) but I think that your take on upgrading differs from some of us. For me upgrading is always a "last resort" type of thing. There are certain issues that I can live with and I need some proof that the upgrade will fix most of these issues without adding a whole set of new ones. Plus, for you, with your long background of working with probably hundreds if not thousands of these upgrades it is like "old hat". For many of us each upgrade brings a certain level of uncertainty as to what type of "pandoras box" we will open next.

Plus, looking for Bugs is like being a detective, its always fun to catch the bad guy:)

I hope this makes some sense!

Take care,

Rob

Paolo Bevilacqua Fri, 06/01/2007 - 12:46

Hi Rob,

I'm very familiar with your cautious approach to upgrades. I've been confronting customers thinking like you for years during my tenure at Cisco!

I think one due clarification is about which kind of upgrades we are talking about. If it is about going from 12.3 to 12.4, or from non-T to T for example, I mostly agree, it should not be done without a clear justification beforehand. But, when is about bumping up a maintenance release, it's not worth spending much time hesitating about it.

Admittedly, I've also seen maintenance releases breaking things horribly in few cases, and many customers that have been burnt in the past are now firmly in the camp of "don't change code before a bug is identified" because of that.

Ultimately, it's all part of a very major issue about software quality and balance to innovation in these times of fast developed software. The only thing we can do, is to be clear and insistent in telling cisco (or whatever other vendor) when things are broken, and expect a timely response. Exactly as you said about the pleasure of being a bug hunter.

Actions

This Discussion