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@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@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@pair.com
Tim Connolly
2006-Feb-11 03:10 UTC
[Asterisk-Users] Re: Ring requested on channel already in use - fix
I'm replying to this mainly to add my comments to the archive and then all the webcrawlers... I found a deprecated command "curl" which I though had simply been converted from an app to a function, was actually completely non-working. Anytime my call hit a "exten => s,1,set(CURL=curl()), the channel would get hung up. Almost immediately, the call would retry on the same channel and get the message "Ring requested on channel...". I'm not sure if it was because it was being called pre-answer or if some portion of the curl function still exists, but either way, it totally disabled our inbound calls as each and every call used that curl function to replace the callerIDname variable. The fix was simply to remove all mentions of curl. Hope this helps someone else... -----Original Message----- From: asterisk-users-bounces@lists.digium.com [mailto:asterisk-users-bounces@lists.digium.com] On Behalf Of alan Sent: Monday, September 26, 2005 1:28 PM To: asterisk-users@lists.digium.com Subject: [Asterisk-Users] Re: Ring requested on channel already in use 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@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@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@pair.com _______________________________________________ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users