[cisco-voip] 69XX Unrecoverable Phantom Hold Issue

[Brian Meade]

Make sure all the phones with the shared line are all registered to the
same CUCM node.  The shared line inter-node communication doesn't scale
great.  10 phones is a lot for a shared line.  Can you possibly move away
from the shared lines to a broadcast hunt group instead?


On Tue, Jun 3, 2014 at 11:21 AM, Gabriel Jackson <gdjackso at oakland.edu>
wrote:

> Both groups experiencing this issue have a line that is shared on roughly
> 10 phones. In both cases the "Maximum Number of Calls" and "Busy Trigger"
> is set to allow for a large number of calls to be taken and managed from a
> single device.
>
> In my research I did not run across any warnings on this type of setup,
> although I realize that Hunt Groups or similar are, more often than not,
> used as an alternative.
>
>
> On Tue, Jun 3, 2014 at 11:11 AM, Brian Meade <bmeade90 at vt.edu> wrote:
>
>> I've seen this on the 7861s.  How many phones have the shared line?
>>
>> I would get console logs from all phones with the shared line and
>> CallManager traces for the time period you see the next phantom call.  That
>> way the call can be tracked in CallManager to where it came from and why it
>> didn't clear.
>>
>> Brian
>>
>>
>> On Tue, Jun 3, 2014 at 10:44 AM, Gabriel Jackson <gdjackso at oakland.edu>
>> wrote:
>>
>>> We are currently experiencing an issue on some Cisco 6945 phones which
>>> results in devices showing a shared line as on-hold, yet no call is
>>> actually present. We can't reproduce this issue on demand, but we have
>>> noticed the following is true when it occurs:
>>>
>>> 1. The shared line often has high call volume and is shared by as many
>>> as 10 devices.
>>> 2. The phantom hold will often only affect a single device, resulting in
>>> the phone being out of sync with its peers.
>>> 3. No amount of line-button/soft-button/hard-button presses seems to
>>> clear the line of the phantom. Rebooting the phone will remove the phantom,
>>> though.
>>> 4. Calls can be made from the afflicted line
>>> 5. To date, this has occurred on SIP6945.9-4-1-3
>>> and SCCP6945.9-3-3-2-SR1 firmwares.
>>>
>>> We have found similar bug reports on the Cisco website, but they either
>>> apply to other phone series and/or were corrected by the 9.3.X code train.
>>>
>>> Has anyone else run into anything similar? Thanks!
>>>
>>> --
>>> Gabriel Jackson
>>> Network and Telecom Systems Engineer
>>> University Technology Services
>>> (248) 370-4560
>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>>
>>
>
>
> --
> Gabriel Jackson
> Network and Telecom Systems Engineer
> University Technology Services
> (248) 370-4560
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20140603/352ada5a/attachment.html>