Ring requested on channel

If this message appears "Ring requested on channel 0/1 already in use on span 1. Hanging up owner.", your only choice (update page if this is untrue) the only solution is to restart Asterisk.

On occassion. I get this message, and it really messes things up. So I wrote a very simple PHP script that will watch /var/log/asterisk/messages for the "Ring Requested on channel" message, and upon seeing it, kill and restart the asterisk server.

Yes, you will lose all active calls, maybe even CDR. For me, it's a small price to pay for having an asterisk system that simply does not answer calls.

here is the PHP script. save it in /var/log/asterisk
 #!/usr/bin/php -q
<?
        ob_implicit_flush(true);
        $in = fopen('php://stdin','r');
        $out = fopen('php://stdout','w');
        while (!feof($in)) {
                $line = fgets($in,4096);
                if (strpos($line,'Ring requested on channel')) {
                        system("killall -9 safe_asterisk");
                        system("killall -9 asterisk");
                        system("killall -9 mpg123");
                        system("/etc/rc.d/init.d/asterisk start");
                }
        }
        fclose($in);
?>


You run it by doing the following:

cd /var/log/asterisk
nohup tail --lines 0 -f messages |./watchring.php &

What this will do is kill safe_asterisk, asterisk, mpg123, then restart them (assuminig redhat /etc/rc.d/init.d).

If anyone else has a more elegent solution to handle the "Ring requested on..." problem, please update this page.



I've seen this too, it happened on me once after I was trying some absolutely crazy dialplan stuff that got caught in a loop or something, show channels showed the channel was in use, I was using CVS Head dated 30th June 2005. Although not a fix to the original bug, surely a better way to handle this in the code would be to kill the owner of the (stale) channel, not the incoming ring, as the provider should know better that a channel was in use or not. Although, If I vaguely remember, the channel seemed to be labelled as reserved, I'm not sure what that means or why it was. Is there a bug id allocated to this on digums bug tracker? I've looked at the code in chan_zap on CVS head, but i'm not entirely sure how to achieve this, but I believe it would be a small change if it has not been done already — Darkskiez



I am also suffering from this problem on a production system. Running Asterisk 1.2.9.1, here are the relevant log lines:

Feb  1 14:09:55 VERBOSE[20400] logger.c:     -- Channel 0/1, span 1 got hangup request
Feb  1 14:10:25 VERBOSE[20400] logger.c:     -- Channel 0/1, span 1 got hangup
Feb  1 14:12:41 WARNING[20400] chan_zap.c: Ring requested on channel 0/1 already in use on span 1.  Hanging up owner.
Feb  1 14:12:42 WARNING[20400] chan_zap.c: Ring requested on channel 0/1 already in use on span 1.  Hanging up owner.
Feb  1 14:12:43 WARNING[20400] chan_zap.c: Ring requested on channel 0/2 already in use on span 1.  Hanging up owner.
Feb  1 14:13:07 WARNING[20400] chan_zap.c: Ring requested on channel 0/1 already in use on span 1.  Hanging up owner.
Feb  1 14:13:08 WARNING[20400] chan_zap.c: Ring requested on channel 0/1 already in use on span 1.  Hanging up owner.
Feb  1 14:13:09 WARNING[20400] chan_zap.c: Ring requested on channel 0/2 already in use on span 1.  Hanging up owner.
Feb  1 14:21:48 WARNING[20400] chan_zap.c: Ring requested on channel 0/1 already in use on span 1.  Hanging up owner.
Feb  1 14:21:49 WARNING[20400] chan_zap.c: Ring requested on channel 0/1 already in use on span 1.  Hanging up owner.
Feb  1 14:21:50 WARNING[20400] chan_zap.c: Ring requested on channel 0/2 already in use on span 1.  Hanging up owner.
Feb  1 14:23:06 WARNING[20400] chan_zap.c: Ring requested on channel 0/1 already in use on span 1.  Hanging up owner.


A restart of asterisk is required to get things back to a working state. It usually takes several weeks of uptime before this problem develops. I have had it happen on three separate occasions now. 'soft hangup Zap/1-1' has no effect. I have found the following threads on this issue with no resolution:
http://bugs.digium.com/view.php?id=5724
http://lists.digium.com/pipermail/asterisk-dev/2005-September/015158.html
http://lists.digium.com/pipermail/asterisk-users/2006-January/134166.html
If this message appears "Ring requested on channel 0/1 already in use on span 1. Hanging up owner.", your only choice (update page if this is untrue) the only solution is to restart Asterisk.

On occassion. I get this message, and it really messes things up. So I wrote a very simple PHP script that will watch /var/log/asterisk/messages for the "Ring Requested on channel" message, and upon seeing it, kill and restart the asterisk server.

Yes, you will lose all active calls, maybe even CDR. For me, it's a small price to pay for having an asterisk system that simply does not answer calls.

here is the PHP script. save it in /var/log/asterisk
 #!/usr/bin/php -q
<?
        ob_implicit_flush(true);
        $in = fopen('php://stdin','r');
        $out = fopen('php://stdout','w');
        while (!feof($in)) {
                $line = fgets($in,4096);
                if (strpos($line,'Ring requested on channel')) {
                        system("killall -9 safe_asterisk");
                        system("killall -9 asterisk");
                        system("killall -9 mpg123");
                        system("/etc/rc.d/init.d/asterisk start");
                }
        }
        fclose($in);
?>


You run it by doing the following:

cd /var/log/asterisk
nohup tail --lines 0 -f messages |./watchring.php &

What this will do is kill safe_asterisk, asterisk, mpg123, then restart them (assuminig redhat /etc/rc.d/init.d).

If anyone else has a more elegent solution to handle the "Ring requested on..." problem, please update this page.



I've seen this too, it happened on me once after I was trying some absolutely crazy dialplan stuff that got caught in a loop or something, show channels showed the channel was in use, I was using CVS Head dated 30th June 2005. Although not a fix to the original bug, surely a better way to handle this in the code would be to kill the owner of the (stale) channel, not the incoming ring, as the provider should know better that a channel was in use or not. Although, If I vaguely remember, the channel seemed to be labelled as reserved, I'm not sure what that means or why it was. Is there a bug id allocated to this on digums bug tracker? I've looked at the code in chan_zap on CVS head, but i'm not entirely sure how to achieve this, but I believe it would be a small change if it has not been done already — Darkskiez



I am also suffering from this problem on a production system. Running Asterisk 1.2.9.1, here are the relevant log lines:

Feb  1 14:09:55 VERBOSE[20400] logger.c:     -- Channel 0/1, span 1 got hangup request
Feb  1 14:10:25 VERBOSE[20400] logger.c:     -- Channel 0/1, span 1 got hangup
Feb  1 14:12:41 WARNING[20400] chan_zap.c: Ring requested on channel 0/1 already in use on span 1.  Hanging up owner.
Feb  1 14:12:42 WARNING[20400] chan_zap.c: Ring requested on channel 0/1 already in use on span 1.  Hanging up owner.
Feb  1 14:12:43 WARNING[20400] chan_zap.c: Ring requested on channel 0/2 already in use on span 1.  Hanging up owner.
Feb  1 14:13:07 WARNING[20400] chan_zap.c: Ring requested on channel 0/1 already in use on span 1.  Hanging up owner.
Feb  1 14:13:08 WARNING[20400] chan_zap.c: Ring requested on channel 0/1 already in use on span 1.  Hanging up owner.
Feb  1 14:13:09 WARNING[20400] chan_zap.c: Ring requested on channel 0/2 already in use on span 1.  Hanging up owner.
Feb  1 14:21:48 WARNING[20400] chan_zap.c: Ring requested on channel 0/1 already in use on span 1.  Hanging up owner.
Feb  1 14:21:49 WARNING[20400] chan_zap.c: Ring requested on channel 0/1 already in use on span 1.  Hanging up owner.
Feb  1 14:21:50 WARNING[20400] chan_zap.c: Ring requested on channel 0/2 already in use on span 1.  Hanging up owner.
Feb  1 14:23:06 WARNING[20400] chan_zap.c: Ring requested on channel 0/1 already in use on span 1.  Hanging up owner.


A restart of asterisk is required to get things back to a working state. It usually takes several weeks of uptime before this problem develops. I have had it happen on three separate occasions now. 'soft hangup Zap/1-1' has no effect. I have found the following threads on this issue with no resolution:
http://bugs.digium.com/view.php?id=5724
http://lists.digium.com/pipermail/asterisk-dev/2005-September/015158.html
http://lists.digium.com/pipermail/asterisk-users/2006-January/134166.html
Created by: lesnet, Last modification: Wed 13 of Jun, 2012 (05:36 UTC) by admin
Please update this page with new information, just login and click on the "Edit" or "Discussion" tab. Get a free login here: Register Thanks! - Find us on Google+