Shared Line going to voicemail after adding shared line to Jabber devices

[rory.schmitz]

Hello,

We introduced MRA along with Jabber in May of 2020.  All has been working great until I started configuring Jabber devices with a particular shared line using extension 7100.  An incoming call rings for a half of a ring, then goes to voicemail.  The shared line is now on 44 devices and is mixed between hardware devices, IP Communicator, and Jabber.  Jabber is replacing the old IP Communicator soft phone.

The max call/busy trigger threshholds for the various devices are as follows.

Physical phones - Max Calls:  24   Busy Trigger: 20

IP Communicator - Max Calls:  24   Busy Trigger: 20

Jabber - Max Calls:  6   Busy Trigger: 6

The "No answer Ring Duration (seconds)": is set to 24 seconds for the directory number.

With this shared line, there are never more than 2 calls incoming at the same time so we're confident it's not hitting the 6 call limit on the Jabber devices.  What could cause this to go to voicemail after a few seconds?

[sudaggar]

please check busy trigger on each device having shared lines. I have seen the scenarios where busy trigger is set to 1 for a device having shared lines causing calls directly going to VM.

You can check busy trigger values using below sql command ("label" is your shared extension):
run sql select fkdevice,DeviceNumPlanMap.BusyTrigger from DeviceNumPlanMap where (DeviceNumPlanMap.BusyTrigger = 1 AND label = 7100)

Regards

[rory.schmitz]

Thank you for the response.  Where would I run that command?

Yesterday, I manually went into each of the 44 devices in CUCM and increased a few of them from 2 up to 6 (Jabber max).  The physical phones are set to 20 or more.  No luck that way, but the command seems far more efficient.

[rory.schmitz]

I think I was in the correct CLI for the CUCM servers, but was getting an incorrect syntax error.

[TONY SMITH]

Alternatively you can run a BAT job to set all the Busy Triggers to the correct value.

[rory.schmitz]

I did unchecked these settings on the shared line and we thought it was then fixed.  The two that are checked in red made sense because jabber isn't always running for each person so they would show as unregistered.  Staff have indicated that now it's hit or miss.  Other than suggesting that other staff are declining the call, how can I trace what is happening?

[Roger Kallberg]

Just a speculation, but could it be that someone that have this shared line in Jabber is in presenting state or have set the present state to busy? If I’m not wrong this will turn on DND, Do Not Disturb, and the default action for this world be to divert the call to voicemail if it’s setup. This would be seen in the CM SDL traces for a call where this happened.

[rory.schmitz · Accepted solution]

Thanks Roger.  I thought of that too and looked into where we could set the DND for the secondary (shared) line.  What we ended up finding was a combination of things taking place.  One major thing was that we had the Call Forward and Call Pickup Settings wrong, specifically Unregistered Internal and Unregistered External options were checked. When Jabber wasn't being used and their laptop was offline, the system showed that their Jabber phone device as "Unregistered", which it was and made sense.  Unchecking those options and saving fixed the first issue (Screenshot attached). 

The second issue was on an incoming call, Jabber shows the incoming call notifications and gives you the options to Answer or Decline.  Staff weren't doing either, but they were clicking the X on that notification to close it out and get it off of their screen.  This also sends it to Voicemail (iDivert) just as Declining the call.  Personally, I think it's a poor design, but at least we've identified the issues and now have trained staff appropriately.  

[Roger Kallberg]

Glad to hear that you managed to figure it out and thanks for sharing the solution.