[cisco-voip] Parked and Hold Calls Dropped at 50 Seconds

[Robert Singleton]

On Wed, 2006-06-28 at 17:55 -0500, Pritchard, Jon wrote:
> Does anyone know what parked calls and calls on hold being dropped at exactly 50 seconds is a telltale sign of?

<snip>

> No service parameters are even close to 50 seconds (or 5000 milliseconds).

The timer parameter clue may invalidate what I'm about to say, but....

In our setup, we had a problem with seemingly random calls being dropped
from Call Park, but only at one location. After working for a long time
to duplicate the issue, it was discovered that the caller was dropped at
the expiration of the Call Park Reversion Timer. In the affected branch,
incoming calls were directed to an attendant console hunt group. The
lines that were members of this hunt group were on a 7960. The mode of
failure was tricky to catch, but here's what was happening: Let's say a
call came in and the huntgroup directed it to the first member of the
huntgroup, DN 2007001. The call was placed on Park. Before the Call Park
Reversion Timer expires, another call has come in and is on 2007001.
When the Call Park Reversion Timer expires, the parked call drops rather
than ringing back. The same thing happens with any line; if the specific
line the call was parked from is busy when the timer expires, the call
is dropped. Note that this only happened to calls parked by the
Attendant Console at this location. Calls parked by individuals
functioned correctly.

After troubleshooting with TAC, it was revealed as a known issue. The
workaround is simple enough; simulate a circular huntgroup with
forwarding on each of the affected lines; 2007001 fwd bu/na to 2007002,
2007002 fwd bu/na to 2007003, et al and finally 2007006 fwd bu/na
2007001. Apparently, Call Park Reversion subsumes hunt groups, but not
the forwarding, so when the line that parked the call is not available,
forwarding will send it to the next line, and so on until it finds a
free line or comes full circle. Even when all the lines are busy, at
least the caller gets reorder and drops the call themselves rather than
being unceremoniously disconnected.

I mentioned that this was only happening in one location. That location
happened to be rolled out with Attendant Console in place. In that
branch, the 7960 was programmed with the Attendant Console Hunt Group
members from the start. In the other locations with Attendant Consoles,
Attendant Console was added after calls were already being handled with
a pseudo-huntgroup done by forwarding each line to the next. The
forwarding was not implicitly removed from teh lines when the Attendant
Console was installed, so the workaround was already in place,
preventing us from ever having the problem in the other locations.

Interestingly enough, it was also discovered that at the problem
location, if the attendant pressed the Park button on the phone itself,
the call would not drop. It would only drop if parked from the Attendant
Console application and only when the other conditions were met.

Robert