[Asterisk-Users] Re: Ring requested on channel already in use

[alan]

I posted this 1.2.0-beta1 success story to asterisk-dev, and someone
recommended that asterisk-users might benefit from it as well.

Thanks,

Alan Ferrency
pair Networks, Inc.
alan at pair.com


---------- Forwarded message ----------
Date: Thu, 22 Sep 2005 17:35:08 -0400 (EDT)
Subject: [Asterisk-Dev] Re: Ring requested on channel already in use
To: asterisk-dev at lists.digium.com

> alan wrote:
> > A problem was recently posted on the Asterisk-Users mailing list, and it
> > went unresolved. Now that it's plaguing our production system as well, I
> > need to look into it further.

> Good report, lots of information.  See if you can reproduce it in CVS-HEAD
> (Asterisk, libpri, zaptel)

<snip>

> You need to test this with cvs head (1.2beta) first to see if it's not
> already fixed...


I am happy to say that since we upgraded to 1.2.0-beta1, our problems
with Asterisk instability have not recurred. Our uptime is over a week,
with the last restart a result of the upgrade.

Thanks!

I didn't like to see the answer "upgrade your production system to a
beta version," but the truth is, it was working poorly enough that it
was basically impossible not to at least try it.


Here is a summary of the symptoms we were seeing in 1.0.9, for others
with this issue who may benefit from an upgrade:

We narrowed the problem down to this sequence of events:
- an incoming Zap call on a PRI channel
- was sent to the queue
- and answered by a AgentCallbackLogin queue agent
- who was using a SIP phone
- and the agent attempted to SIP REFER transfer the call
- to another AgentCallbackLogin agent on a SIP phone

That's a lot of channels (zap -> agent -> local -> sip, transferring to
agent -> local -> sip).

When this happened, we saw these symptoms:
- Rarely, the transfer succeeded.
- More often, the ZAP channel was put in limbo and both SIP parties were
  dropped; or the transfer completed but there was one-way audio from
  Zap to SIP only.
- Often, when the transfer failed, Asterisk was left in an inconsistent
  state, and would not function correctly until a restart was performed.
-- asterisk -r consoles could not execute commands successfully
-- "sip show channels" produced bogus output
-- incoming Zap calls (over a PRI) resulted in "Ring requested on
   channel... already in use" errors, and the calling party was dropped
   immediately.


After this experience with 1.2, I'd say that the upgrade should not
cause many problems, as long as you thoroughly research and implement
all required configuration changes. We have not experienced any problems
with 1.2 which weren't also problems in 1.0.8/9, but we have had many
other little issues solved which we were previously trying to ignore.


Thank you very much,

Alan Ferrency
pair Networks, Inc.
alan at pair.com