[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