[asterisk-bugs] [Asterisk 0012160]: [patch] channel alarm set when a channel is opened

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=12160 
====================================================================== 
Reported By:                tzafrir
Assigned To:                kpfleming
====================================================================== 
Project:                    Asterisk
Issue ID:                   12160
Category:                   Channels/chan_zap
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     assigned
Asterisk Version:           SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 106393 
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             03-06-2008 10:11 CST
Last Modified:              07-23-2008 10:42 CDT
====================================================================== 
Summary:                    [patch] channel alarm set when a channel is opened
Description: 
If a channel alarm is already set when a channel is opened by Asterisk,
whose responsibility is it to check for the alarms?

1. The channe l driver should detect that and re-send alarms on zt_open

2. Zaptel should  send an alarm event at channel open time. The
applicaiton opening the channel should then be able to read those events
and will have the proper information.

3. The application should read channel alarms at channel initialization
time. No need for Zaptel to send extra events.

As senseless as (1) is, it has been used in practice by the xpp d FXO
module driver. I figure you all agree with me it is not the way to go.


The behaviour with regards to span alarm seems in Asterisk seems to be
(3).

Attached are patches implementing both (2) and (3)
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0012841 Unable to get the hook status for 100XP...
====================================================================== 

---------------------------------------------------------------------- 
 kpfleming - 07-23-08 10:42  
---------------------------------------------------------------------- 
The information isn't already available from previous ioctls, unless the
channel is part of a PRI. The code that was there already called
DAHDI_SPANSTAT, directly, I've just replaced that with a call to
get_alarms() instead to reduce code duplication.

Your comment is valid though; if the channel is already in 'channel alarm'
state during mkintf(), calling get_alarms() won't catch it, so
tmp->unknown_alarm won't be set by handle_alarms(). I'm going to commit a
patch to *always* set tmp->unknown_alarm when the channel is not in a span
alarm; this will have the desired result of suppressing the 'alarm cleared'
message if we don't receive a new (span) alarm before the clearing of the
channel alarm occurs. We can't set tmp->inalarm here without adding full
support for channel alarms, which is overkill. If the channel is created
while in this state, chan_dahdi won't be able to avoid placing calls on the
channel like it would if the alarm occurred later, but I don't see a way to
solve that without adding channel alarm support. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
07-23-08 10:42  kpfleming      Note Added: 0090606                          
======================================================================