01-21-2010 09:10 AM - last edited on 03-25-2019 10:45 PM by ciscomoderator
I recently installed the following:
- SPA9000 running 6.1.5
- SPA400 running 22.214.171.124
- 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.
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?
01-26-2010 10:15 AM
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.
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?
01-27-2010 03:16 AM
I suggest you use the latest BETA wizard, available here https://www.myciscocommunity.com/docs/DOC-8126 It provides basic support for SPA500 phones (basic support means that you can only configure up to 4 lines per phone).
Regards and please let me know your results
03-04-2010 05:33 PM
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?
03-05-2010 12:17 AM
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?
03-05-2010 12:30 AM
Yes, I tried resetting everything in the system and set it all up again from scratch, using the 126.96.36.199 wizard. No luck.
If only one SPA500S is in use on our network, the problems seem to dissipate.
03-05-2010 08:04 AM
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?
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: