[asterisk-bugs] [Asterisk 0012509]: [patch] MFC/R2 support for chan_zap
noreply at bugs.digium.com
noreply at bugs.digium.com
Wed Jun 4 12:58:08 CDT 2008
A NOTE has been added to this issue.
======================================================================
http://bugs.digium.com/view.php?id=12509
======================================================================
Reported By: moy
Assigned To:
======================================================================
Project: Asterisk
Issue ID: 12509
Category: Channels/chan_zap/NewFeature
Reproducibility: always
Severity: feature
Priority: normal
Status: new
Asterisk Version: SVN
SVN Branch (only for SVN checkouts, not tarball releases): trunk
SVN Revision (number only!): 114097
Disclaimer on File?: N/A
Request Review:
======================================================================
Date Submitted: 04-24-2008 01:31 CDT
Last Modified: 06-04-2008 12:58 CDT
======================================================================
Summary: [patch] MFC/R2 support for chan_zap
Description:
Here we go. This is my first try to give R2 support to chan_zap. I'm sure I
am missing locks and/or features here and there but I have tested it
internally with success with a considerable amount of concurrent channels
(64). That's the best I can do with the hardware I currently have (more
coming!).
======================================================================
----------------------------------------------------------------------
asbestoshead - 06-04-08 12:58
----------------------------------------------------------------------
Hi, I think there might be an issue with alarm clearing. If an alarm
happens on a channel during a call, the channel gets put into an alarm
state (p->inalarm!=0) and will never be used for outbound calls again.
Incoming calls on that channel still work, but chan_zap will never place an
outbound call on the channel.
It seems like sometimes (during calls?) the usual chan_zap
zt_handle_event() gets zap alarms, and other times (between calls?) the
openr2 code gets the alarm and handles it by passing it up to
zt_r2_on_zap_alarm().
If a channel is in a call and an alarm happens, zt_handle_event() gets the
alarm and sets p->inalarm.
Jun 2 11:00:29 gyeast asterisk[13449]: WARNING[14616]: chan_zap.c:4983 in
zt_handle_event: Detected alarm on channel 12: Yellow Alarm
Jun 2 11:00:29 gyeast asterisk[13449]: DEBUG[14616]: chan_zap.c:3707 in
zt_hangup: disconnecting MFC/R2 call on chan 12
When the alarm clears, zt_r2_on_zap_alarm() gets the notification but
doesn't clear p->inalarm.
Jun 2 11:00:34 gyeast asterisk[13449]: DEBUG[14616]: chan_zap.c:1478 in
zt_r2_write_log: Chan 12 - ZT_EVENT_ALARM | ZT_EVENT_NOALARM
Jun 2 11:00:34 gyeast asterisk[13449]: WARNING[14616]: chan_zap.c:1293 in
zt_r2_on_zap_alarm: Zap alarm on chan 12.
We seem to have a couple of alarms a day where all channels go into alarm
(yikes!). After a couple of days of that, there are no outbound channels
anymore :) I guess the fix might be to have zt_r2_on_zap_alarm() set /
clear p->inalarm.
Issue History
Date Modified Username Field Change
======================================================================
06-04-08 12:58 asbestoshead Note Added: 0087820
======================================================================
More information about the asterisk-bugs
mailing list