BLF on SPA 500 series phones and SPA9000 IP-PBX

Unanswered Question
Jan 21st, 2010

Hi,

I recently installed the following:

- SPA9000 running 6.1.5

- SPA400 running 1.1.2.2

- 4xSPA508G, running 7.4.3, upgraded from 7.1.3

- 2xSPA500S on 2 of the above phones

The setup is really basic, as those devices are connected to an isolated LAN, without any server (DHCP, NTP,...), no IP voice provider currently.

All outside calls are going through the SPA400 gateway, connected to 4 PSTN lines.

I never used the configuration wizard for all that, as the official releases doesn't seem to support the SPA500 series phones.

As in most small businesses, each individual would like to know if an extension is busy prior transferring a call.

Fo that purpose, I configured the BLF extended functions on the IP phone line keys, and it was running fine with release 7.1.3, originally shipped with the phones.

Green: available

Red: busy

Red fast blinking: ringing

Amber: monitored line not found

Each key is configured using: fnc=blf+cp+sd;sub=stationname@$PROXY;ext=extension@$PROXY

Using the same syntax and release, no BLF status was reported on SPA500S, strange!

I upgraded to correct other bugs,... to 7.4.3

Since the upgrade to 7.4.3, ALL BLF LEDs are turned off a few seconds after each boot on the 2 phones without SPA500S.

On the 2 other phones, with SPA500S, the phone line keys LEDs are not stable, but the SPA500S started to report the correct status.

I then configured one parameter on the 2 phones without any SPA500S attached, changing the attendant console type from Broadsoft to SPA9000, even if no console present. The phone line keys status changed from OFF to unstable, oscillating between green and amber and reversely after a short period of time. As on the two phones with SPA500S.

The SPA500 series admin guide states:

"A monitored extension must be private; not shared. Additionally, an extension can only be monitored by one other extension."

Here, each extension monitors the others. It was however working with 7.1.3, which contradicts this statement, indicating a correct configuration on the SPA9000 side (CTI), and no performance limitation from any hardware.

Can you provide me with the exact capabilities of the devices?

Is this a bug in 7.4.3, will it be fixed?

Is the documentation not correctly written/updated from SPA900 to SPA500?

Was it miraculously working in 7.1.3, for an unknown reason, and this nice feature has definitely disappeared?

Am I wrong with my configuration?

Please advice,

Regards,

Frédéric

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
fhelding Tue, 01/26/2010 - 10:15

Some more info:

Downgrading to 7.3.7 provides similar results, as 7.4.3.

In fact, the system takes too much times to report the extension status.

Example:

A user answers a call,

another phone monitoring the line will report it as busy after a few seconds, not immediately, by showing a red LED.

This red color will not remain stable during the call,

When he call ends, the monitoring phone puts the LED on green, which becomes unstable after a few seconds,...

Is there someone available at Cisco to answer this post?

Regards,

Frédéric

chasegranzow Thu, 03/04/2010 - 17:33

I am experiencing this exact same issue with phones running 7.4.3, on a SPA9000 system running 6.1.5.

We have two "receptionist" phones (SPA509G), each with an attached SPA500S console.  With 7.1.3, both receptionists were able to simultaneously monitor the same group of extensions (8xSPA504G).  However, after upgrading phones to 7.4.3, the BLF LEDs on both SPA500S consoles are unstable.  As described by the original poster, the indicators oscillate between green and amber (sporadically, every few minutes).

If I disconnect either one of the SPA500S consoles, then the other one seems to begin working without issue.  I too am confused by the statement in the admin guide that "an extension can only be monitored by one other extension," because our current setup worked flawlessly before upgrading to the newest firmware version.

Is there a solution to this problem?



fhelding Fri, 03/05/2010 - 00:17

Hi,

I'm happy to learn I'm not alone with this problem.

Did you used the BETA wizard to configure your system?

I'll check if situation improves by disconnecting the SPA500S.

If yes, the problem might be in the configuration of this unit?

Regards,

Frederic

chasegranzow Fri, 03/05/2010 - 00:30

Yes, I tried resetting everything in the system and set it all up again from scratch, using the 2.1.1.2 wizard.  No luck.

If only one SPA500S is in use on our network, the problems seem to dissipate.

fhelding Fri, 03/05/2010 - 08:04

As you mentionned the problem dissipates with only one SPA500S on the network, I decided to physically disconnect one SPA500S, no change.

Then I've been into the phone advanced config to disable the autoattendant console (both units), no change.

Then disconnecting and disabling the second unit, no change.

I'm now running without SPA500S, but still have unstable LEDs.

Note that even with no SPA500S on the network and disabling it on all phones, changing the autoattendant server type impacts the behavior of the phone' own LEDs. As far as I remember, it was NOT the case with 7.1.3.

Is there any way to downgrade to 7.1.3?

Actions

This Discussion

Related Content