Shared Line state (red light) when/when not active?

dmooreami · ‎02-18-2011

Does anyone have something documented as to when a "shared line" will not be "red", yet the line could be inuse?

My end users are driving me crazy over no "Red line" indicating the line is inuse. I don't have enough lines on the phones to give out BLF's for each extension.

Running UCM 7.x, majority of the phones are 7965G's.

Thanks

Tommer Catlin · ‎02-21-2011

Im a little confused by what you are asking. So the end user wants to see every line that is inuse or? If its a shared line, you cant control t

he BLF when its in use. This is by default. The line is in use somewhere on the CUCM server by someone.

dmooreami · ‎02-21-2011

tcatlinins wrote:

Im a little confused by what you are asking. So the end user wants to see every line that is inuse or? If its a shared line, you cant control t

he BLF when its in use. This is by default. The line is in use somewhere on the CUCM server by someone.

Most times the shared line state is "red" when the line is being used. What I am looking for is what causes a shared line "in use" to not show RED or to go from RED to Green. Seems that 90% of the time, shared line state of RED is working as the old Siemens/NEC phones did. It is the other 10% that is driving me crazy when it doesn't show "RED" when line is active or Inuse on the host phone.

Attorney has 1234 as primary ext on his phone. Sec. has 4567 and 1234 on her phone. She can answer and 1234's calls and see the line is begin used by the RED/Active light associated to that line on her phone. Sometimes Sec claims that 1234 is being used, but there is no RED light beside the line on her phone.

Hope that helps.

Tommer Catlin · ‎02-21-2011

Do you know what version CUCM you are using? Im wondering if there is a bug somewhere in the BLFs. You can also do a dial plan report to verify 1234 is not configured on another phone somewhere.

It is also possible there is a firmware issue on the phone (possibly upgrade, but verify first)

Typical things would be to restart the phones, restart the cluster if it has not been rebooted in a long time, move phones that share BLF into the same device pool and or CSS/PT, or even the same CUCM. If there are any kind of database replication issues going on, BLF status may not be getting updated. Remember, the SCCP on the phone will report back to the CUCM it is registered if its on/off hook status.

Also make sure the Sec understands that if the attorney is on a different line on his/her phone, and its NOT 1234, 1234 is going to show green. Its only when that particular line is in use. If they are looking for more control over the PHONE DEVICE itself, which does not matter which line it is, maybe CUPS or Connect or even the M word (Microsoft) could be used for on/off status.

dmooreami · ‎02-21-2011

I the BLF's are fine. If I put a BLF/Speed Dial, it works flawlessly.

CUCM version is : 7.1.3.32900-4.

I am 99.9% certain its a training issue of how "shared lines" work. Just trying to find the sequence of events that cause them to "lose" the RED/Line Active on the shared line.

Thanks

Tommer Catlin · ‎02-21-2011

Agreed on the training aspect of it. For Lawyers and Sec or admin assistants, its difficult sometimes. You almost have to build out two phones with shared lines in a training room and show them how it works one on one. If the phones are not physically in front of them (both of them) its tough.

Tommer Catlin · ‎02-21-2011

Couple other notes on BLF:

CSCtb92764 Bug Details Bug #3 of 11 | < Previous | Next >

New subscriptions are rejected after Presence subscriptions decreases

Symptom: There are two symptoms.

#1: Based on a percentage of the value specified in the Presence Subscription Throttling Threshold service parameter, when the number of Presence subscriptions decreases to below the percentage specified in this parameter, CUCM does not resume accepting new call list BLF subscriptions.

Note-1: Also, it appears that CUCM counts speed dial subscriptions (active subscriptions) as part of condition of Presence Subscription Resume Threshold. Per designed, speed dial subscriptions should not be counted in resume threshold.

#2: This is related to above symptom with Presence Subscription Resume Threshold. The following alarm is not reported in RTMT.

AlarmDefinition Name="EndThrottlingCallListBLFSubscriptions"

Note-2: However, it appears that another alarm below is reported in RTMT as expected when Presence Subscription Throttling Threshold happens.

AlarmDefinition Name="BeginThrottlingCallListBLFSubscriptions"

Conditions: This is related to the following service parameters.

Presence Subscription Throttling Threshold

Presence Subscription Resume Threshold

Workaround: None

Fixed in 8.0x

Here is another one:

CSCsy59400 Bug Details Bug #2 of 11 | < Previous | Next >

Insert Phones doesn't allow DN to be BLF DN

Symptom:

Insert Phones doesn't allow DN to be BLF DN

Conditions:

Follow the steps mentioned in Defect Description

Workaround:

Don't give the BLF DN same as DN. First Insert Phones with DN and then add BLF DN using another insert job with override option.