Does anyone know what parked calls and calls on hold being dropped at exact=
ly 50 seconds is a telltale sign of?

In a cluster with 7 sites there is one site which is experience this proble=
m.  All the other sites work fine.  No service parameters are even close to=
50 seconds (or 5000 milliseconds).  Both internal and external calls are a=
ffected.  =A0SQL replication appears to be fine.  Rebooting CallManagers do=
es not change behavior.  Never seen anything like this in 5 years.  Any ins=
ight would be appreciated.

Jon Pritchard


This message and any attachments are intended only for the use of the addre=
ssee and may contain information that is privileged and confidential. If th=
e reader of the message is not the intended recipient or an authorized repr=
esentative of the intended recipient, you are hereby notified that any diss=
emination of this communication is strictly prohibited. If you have receive=
d this communication in error, please notify us immediately by e-mail and d=
elete the message and any attachments from your system.

[ Post a follow-up to this message ]

Yes...but if you don't pick up the call in 10 seconds (50 seconds total) it 
gets dropped. 
 
Jon

________________________________

From: Jason Aarons (US) [mailto:jason.aarons@us.didata.com]
Sent: Wed 6/28/2006 6:06 PM
To: Pritchard, Jon
Subject: RE: [cisco-voip] Parked and Hold Calls Dropped at 50 Seconds



If you lower your Park Reversion timeout to 40 seconds do you get calls back
?

-----Original Message-----
From: cisco-voip-bounces@puck.nether.net [mailto:cisco-voip-bounces@puck
.nether.net] On Behalf Of Pritchard, Jon
Sent: Wednesday, June 28, 2006 6:55 PM
To: cisco-voip@puck.nether.net
Subject: [cisco-voip] Parked and Hold Calls Dropped at 50 Seconds

Does anyone know what parked calls and calls on hold being dropped at exactl
y 50 seconds is a telltale sign of?

In a cluster with 7 sites there is one site which is experience this problem
.  All the other sites work fine.  No service parameters are even close to 5
0 seconds (or 5000 milliseconds).  Both internal and external calls are affe
cted.   SQL replication appears to be fine.  Rebooting CallManagers does not
 change behavior.  Never seen anything like this in 5 years.  Any insight wo
uld be appreciated.

Jon Pritchard


This message and any attachments are intended only for the use of the addres
see and may contain information that is privileged and confidential. If the 
reader of the message is not the intended recipient or an authorized represe
ntative of the intended recipient, you are hereby notified that any dissemin
ation of this communication is strictly prohibited. If you have received thi
s communication in error, please notify us immediately by e-mail and delete 
the message and any attachments from your system.

 ________________________________________
_______
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

-----------------------------------------
Disclaimer:

This e-mail communication and any attachments may contain
confidential and privileged information and is for use by the
designated addressee(s) named above only.  If you are not the
intended addressee, you are hereby notified that you have received
this communication in error and that any use or reproduction of
this email or its contents is strictly prohibited and may be
unlawful.  If you have received this communication in error, please
notify us immediately by replying to this message and deleting it
from your computer. Thank you.




This message and any attachments are intended only for the use of the addres
see and may contain information that is privileged and confidential. If the 
reader of the message is not the intended recipient or an authorized represe
ntative of the intended recipient, you are hereby notified that any dissemin
ation of this communication is strictly prohibited. If you have received thi
s communication in error, please notify us immediately by e-mail and delete 
the message and any attachments from your system.

Attachment:
This has been downloaded 0 time(s).

[ Post a follow-up to this message ]

Does this happen with IP Phone to IP Phone calls or with calls through =

a GW or both?

If you are experiencing the problem with an MGCP GW try the command "no =

mgcp timer receive-rtcp".  If this doesn't help please describe more =

about the call flow and the devices involved when the failures happen.

Kevin
On Jun 28, 2006, at 6:55 PM, Pritchard, Jon wrote:

> Does anyone know what parked calls and calls on hold being dropped at =

> exactly 50 seconds is a telltale sign of?
>
> In a cluster with 7 sites there is one site which is experience this =

> problem.  All the other sites work fine.  No service parameters are =

> even close to 50 seconds (or 5000 milliseconds).  Both internal and =

> external calls are affected.  =A0SQL replication appears to be fine.  =

> Rebooting CallManagers does not change behavior.  Never seen anything =

> like this in 5 years.  Any insight would be appreciated.
>
> Jon Pritchard
>
>
> This message and any attachments are intended only for the use of the =

> addressee and may contain information that is privileged and =

> confidential. If the reader of the message is not the intended =

> recipient or an authorized representative of the intended recipient, =

> you are hereby notified that any dissemination of this communication =

> is strictly prohibited. If you have received this communication in =

> error, please notify us immediately by e-mail and delete the message =

> and any attachments from your system.
>
>  ________________________________________
_______
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>

[ Post a follow-up to this message ]

GW inbound and outbound.  We've now tried routing calls from another gateway
 over the WAN and those calls work fine.  We are looking for discrepencies i
n the mgcp config.
 
Jon

________________________________

From: Kevin Thorngren [mailto:kthorngr@cisco.com]
Sent: Wed 6/28/2006 6:28 PM
To: Pritchard, Jon
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] Parked and Hold Calls Dropped at 50 Seconds



Does this happen with IP Phone to IP Phone calls or with calls through
a GW or both?

If you are experiencing the problem with an MGCP GW try the command "no
mgcp timer receive-rtcp".  If this doesn't help please describe more
about the call flow and the devices involved when the failures happen.

Kevin
On Jun 28, 2006, at 6:55 PM, Pritchard, Jon wrote:

> Does anyone know what parked calls and calls on hold being dropped at
> exactly 50 seconds is a telltale sign of?
>
> In a cluster with 7 sites there is one site which is experience this
> problem.  All the other sites work fine.  No service parameters are
> even close to 50 seconds (or 5000 milliseconds).  Both internal and
> external calls are affected.   SQL replication appears to be fine. 
> Rebooting CallManagers does not change behavior.  Never seen anything
> like this in 5 years.  Any insight would be appreciated.
>
> Jon Pritchard
>
>
> This message and any attachments are intended only for the use of the
> addressee and may contain information that is privileged and
> confidential. If the reader of the message is not the intended
> recipient or an authorized representative of the intended recipient,
> you are hereby notified that any dissemination of this communication
> is strictly prohibited. If you have received this communication in
> error, please notify us immediately by e-mail and delete the message
> and any attachments from your system.
>
>  ________________________________________
_______
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>




This message and any attachments are intended only for the use of the addres
see and may contain information that is privileged and confidential. If the 
reader of the message is not the intended recipient or an authorized represe
ntative of the intended recipient, you are hereby notified that any dissemin
ation of this communication is strictly prohibited. If you have received thi
s communication in error, please notify us immediately by e-mail and delete 
the message and any attachments from your system.

Attachment:
This has been downloaded 0 time(s).

[ Post a follow-up to this message ]

Lack of 'no mgcp timer receive-rtcp' was the problem.  A combination of
the IP connectivity (i.e. call on hold) and, in this case, using
multicast moh_live locally on the gateway so there was no unicast stream
arriving from an external source for the specific B channel.

 

Jon

 

________________________________

From: Pritchard, Jon 
Sent: Wednesday, June 28, 2006 5:12 PM
To: Kevin Thorngren
Cc: cisco-voip@puck.nether.net
Subject: RE: [cisco-voip] Parked and Hold Calls Dropped at 50 Seconds

 

GW inbound and outbound.  We've now tried routing calls from another
gateway over the WAN and those calls work fine.  We are looking for
discrepencies in the mgcp config.

 

Jon

 

________________________________

From: Kevin Thorngren [mailto:kthorngr@cisco.com]
Sent: Wed 6/28/2006 6:28 PM
To: Pritchard, Jon
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] Parked and Hold Calls Dropped at 50 Seconds

Does this happen with IP Phone to IP Phone calls or with calls through
a GW or both?

If you are experiencing the problem with an MGCP GW try the command "no
mgcp timer receive-rtcp".  If this doesn't help please describe more
about the call flow and the devices involved when the failures happen.

Kevin
On Jun 28, 2006, at 6:55 PM, Pritchard, Jon wrote:

> Does anyone know what parked calls and calls on hold being dropped at
> exactly 50 seconds is a telltale sign of?
>
> In a cluster with 7 sites there is one site which is experience this
> problem.  All the other sites work fine.  No service parameters are
> even close to 50 seconds (or 5000 milliseconds).  Both internal and
> external calls are affected.   SQL replication appears to be fine. 
> Rebooting CallManagers does not change behavior.  Never seen anything
> like this in 5 years.  Any insight would be appreciated.
>
> Jon Pritchard
>
>
> This message and any attachments are intended only for the use of the
> addressee and may contain information that is privileged and
> confidential. If the reader of the message is not the intended
> recipient or an authorized representative of the intended recipient,
> you are hereby notified that any dissemination of this communication
> is strictly prohibited. If you have received this communication in
> error, please notify us immediately by e-mail and delete the message
> and any attachments from your system.
>
>  ________________________________________
_______
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>



This message and any attachments are intended only for the use of the addres
see and may contain information that is privileged and confidential. If the 
reader of the message is not the intended recipient or an authorized represe
ntative of the intended recipient, you are hereby notified that any dissemin
ation of this communication is strictly prohibited. If you have received thi
s communication in error, please notify us immediately by e-mail and delete 
the message and any attachments from your system.

Attachment:
This has been downloaded 0 time(s).

[ Post a follow-up to this message ]

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 s
econds 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

[ Post a follow-up to this message ]

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@novateck.com> wrote:
> On Wed, 2006-06-28 at 17:55 -0500, Pritchard, Jon wrote: 
>
> <snip>
> 
>
> 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@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>

[ Post a follow-up to this message ]

On Thu, 2006-06-29 at 10:14 -0400, Justin Steinberg wrote:

> What version of CallManager?

At the time (July 2004), we were running 4.0(1)sr2a

> Do you have a bug id?

There were two TAC cases associated with this problem, each about a year
apart. The first engineer gave this bug report: CSCdz37627

The second gave us this one, which is what fixed the problem: CSCea74550

> Is it fixed in newer versions?

We are currently running 4.0(2a)sr2, but the Attendant Consoles are
still configured with call forwarding on the member lines, so I don't
know for sure if it has changed since then.
[vbcol=seagreen]
> AC admin guide specifically states not to enable any forwarding on member DN's.[/v
bcol]

The first response we got from TAC, once we were able to duplicate the
issue, was that it was actually working as designed. Here is an excerpt
from the case notes:

--------------
"When the park timer expires, the parked call attempts to return to the
attendant. But in this case, the attendant is busy with another call.
So, the attempt to return the call to attendant fails with Busy error
which is as per design intent.

Today you and I duplicated this several times and if we parked the call to a
n
IP Phone we were able to retrive it, but if we call into AC, she parks the
calls and the second person calls the same receptionist, it failed every tim
e.

You can always submit a feature request through your sales partner so that c
all
can go to a differetn AC member if the person initiated the park is busy."
--------------

The case was closed with the following resolution:
--------------
this is  only happening if the receptionist gets an ohter call in between an
d
park call has no place to go back after expired time.

working as design.  suggested cust to submit a feature request
--------------

We apparently accepted this behavior for about a year. It is possible,
however, that during this time, we may have reconfigured the telephones,
accidentally applying the workaround.

In May of 2005, we had an unrelated problem that resulted in dumping the
CallManagers and reinstalling from scratch with an unusable backup. This
resulted in the "whitepaper" configuration of the Attendant Consoles (not
to mention a LOOONG weekend of clicking and typing in our entire database
of about 500 phones at that time) and the subsequent recurrence of the
original complaint. We opened a new TAC case.

This engineer found the 2nd bug report quickly and referred us to it.
The verbiage of the workaround in the bug report does say that the user
is "forced" to use call forwarding (or call waiting), but that is the
closest it comes to mentioning anything counter to the manual.

Robert

[ Post a follow-up to this message ]

--------------
working as design.  suggested cust to submit a feature request
--------------

Very familiar answer , it is easy do nothing then do something.

The question is , if design is bad ?

Actually I think that there is no design - it works how this was
programmed and no body think how it must work.

 ________________________________________
_______
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

[ Post a follow-up to this message ]