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

[Justin Steinberg]

What version of CallManager?
Do you have a bug id?
Is it fixed in newer versions?

AC admin guide specifically states not to enable any forwarding on member DN's.

Justin

On 6/29/06, Robert Singleton <rsingleton at novateck.com> wrote:
> 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
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>