[asterisk-dev] [svn-commits] russell: branch 1.4 r104332 - /branches/1.4/channels/chan_zap.c

[Russell Bryant]

Tzafrir Cohen wrote:
> We already have the alarm as a value (res).
> 
>> +				const char *alarm_str = alarm2str(res);
>> +
>> +				/* hack alert!  Zaptel 1.4 now exposes FXO battery as an alarm, but asterisk 1.4
>> +				 * doesn't know what to do with it.  Don't confuse users with log messages. */
>> +				if (!strcasecmp(alarm_str, "No Alarm") || !strcasecmp(alarm_str, "Unknown Alarm")) {
> 
> Yet we convert it to a string, and compare the generated string.
> 
> We can compare the int directly.

True, but we had to convert it to a string anyway, and I was just lazy and tired
when I wrote it.  :)  Besides, the frequency of alarms should be pretty rare, so
I wasn't really concerned about the performance side ...

> Do you assume that if an alarm is set in a certain way it will be
> cleared in the same way?

I don't think so ...

> I can't think of a realistic scenario that breaks this. One that I hope
> that will become realistic is the following:
> 
> 1. Normal operation
> 2. Disconnection line from FXO port -> RED alarm on that port.
> 3. Disconnecting device altogether -> NOTOPEN alarm on the whole span.
> 4. Reconnecting the line to that FXO port.
> 5. Reconnecting the device, NOTOPEN alarm clean. (this is the "hope" part :-)
> 
> Is the port still in RED alarm?

It shouldn't be.  But, the added code could potentially prevent the NOTOPEN (or
whatever other known) alarm from getting reported via the log and manager
interface.  I can improve that easily and will do so now.

-- 
Russell Bryant
Senior Software Engineer
Open Source Team Lead
Digium, Inc.