Re: russell: branch 1.4 r104332 - /branches/1.4/channels/chan_zap.c

Hi

On Wed, Feb 27, 2008 at 12:54:29AM -0000, SVN commits to the
Digium repositories wrote:
> Author: russell
> Date: Tue Feb 26 18:54:29 2008
> New Revision: 104332
> 
> URL: http://svn.digium.com/view/asterisk?view=rev&rev=
104332
> Log:
> Zaptel 1.4 now exposes FXO battery state as an alarm. 
However, Asterisk 1.4
> does not know what to do with these alarms.  Only
Asterisk 1.6 cares about it.
> So, if we get an unknown alarm in chan_zap, don't
generate confusing log messages
> about it.

Useful hack, indeed. But,

> 
> Modified:
>     branches/1.4/channels/chan_zap.c
> 
> Modified: branches/1.4/channels/chan_zap.c
> URL: http://svn.digium.com/view/asterisk/branches/1.4/ch
annels/chan_zap.c?view=diff&rev=104332&r1=104331&
;r2=104332
>
============================================================
==================
> --- branches/1.4/channels/chan_zap.c (original)
> +++ branches/1.4/channels/chan_zap.c Tue Feb 26
18:54:29 2008
>  -461,6 +461,7 
>  	unsigned int ignoredtmf:1;
>  	unsigned int immediate:1;			/*!< Answer before
getting digits? */
>  	unsigned int inalarm:1;
> +	unsigned int unknown_alarm:1;
>  	unsigned int mate:1;				/*!< flag to say its in
MATE mode */
>  	unsigned int outgoing:1;
>  	unsigned int overlapdial:1;
>  -3832,11 +3833,22 
>  #endif
>  			p->inalarm = 1;
>  			res = get_alarms(p);
> -			ast_log(LOG_WARNING, "Detected alarm on
channel %d: %sn", p->channel, alarm2str(res));
> -			manager_event(EVENT_FLAG_SYSTEM,
"Alarm",
> -								"Alarm: %srn"
> -								"Channel: %drn",
> -								alarm2str(res), p->channel);
> +			do {

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.

> +					p->unknown_alarm = 1;
> +					break;
> +				}
> +					
> +				ast_log(LOG_WARNING, "Detected alarm on
channel %d: %sn", p->channel, alarm_str);
> +				manager_event(EVENT_FLAG_SYSTEM,
"Alarm",
> +					"Alarm: %srn"
> +					"Channel: %drn",
> +					alarm_str, p->channel);
> +			} while (0);
>  #ifdef HAVE_LIBPRI
>  			if (!p->pri || !p->pri->pri ||
pri_get_timer(p->pri->pri, PRI_TIMER_T309) < 0) {
>  				/* fall through intentionally */
>  -4167,9 +4179,13 
>  			if (p->bearer)
>  				p->bearer->inalarm = 0;
>  #endif				
> -			ast_log(LOG_NOTICE, "Alarm cleared on channel
%dn", p->channel);
> -			manager_event(EVENT_FLAG_SYSTEM,
"AlarmClear",
> -								"Channel: %drn", p->channel);
> +			if (!p->unknown_alarm) {
> +				ast_log(LOG_NOTICE, "Alarm cleared on channel
%dn", p->channel);
> +				manager_event(EVENT_FLAG_SYSTEM,
"AlarmClear",
> +					"Channel: %drn", p->channel);
> +			} else {
> +				p->unknown_alarm = 0;
> +			}
>  			break;
>  		case ZT_EVENT_WINKFLASH:
>  			if (p->inalarm) break;
>  -6675,18 +6691,33 
>  		break;
>  	case ZT_EVENT_NOALARM:
>  		i->inalarm = 0;
> -		ast_log(LOG_NOTICE, "Alarm cleared on channel
%dn", i->channel);
> -		manager_event(EVENT_FLAG_SYSTEM,
"AlarmClear",
> -			"Channel: %drn", i->channel);
> +		if (!i->unknown_alarm) {
> +			ast_log(LOG_NOTICE, "Alarm cleared on channel
%dn", i->channel);
> +			manager_event(EVENT_FLAG_SYSTEM,
"AlarmClear",
> +				"Channel: %drn", i->channel);
> +		} else {
> +			i->unknown_alarm = 0;
> +		}

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

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?

>  		break;
>  	case ZT_EVENT_ALARM:
>  		i->inalarm = 1;
>  		res = get_alarms(i);
> -		ast_log(LOG_WARNING, "Detected alarm on channel
%d: %sn", i->channel, alarm2str(res));
> -		manager_event(EVENT_FLAG_SYSTEM, "Alarm",
> -			"Alarm: %srn"
> -			"Channel: %drn",
> -			alarm2str(res), i->channel);
> +		do {
> +			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")) {
> +				i->unknown_alarm = 1;
> +				break;
> +			}
> +
> +			ast_log(LOG_WARNING, "Detected alarm on
channel %d: %sn", i->channel, alarm_str);
> +			manager_event(EVENT_FLAG_SYSTEM,
"Alarm",
> +				"Alarm: %srn"
> +				"Channel: %drn",
> +				alarm_str, i->channel);
> +		} while (0);
>  		/* fall thru intentionally */
>  	case ZT_EVENT_ONHOOK:
>  		if (i->radio)

-- 
               Tzafrir Cohen
icq#16849755              jabber:tzafrir.cohenxorcom.com
+972-50-7952406           mailto:tzafrir.cohenxorcom.com
http://www.xorcom.com 
iax:guestlocal.xorcom.com/tzafrir

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.c
om--

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: russell: branch 1.4 r104332 - /branches/1.4/channels/chan_zap.c

Thread: Re: russell: branch 1.4 r104332 - /branches/1.4/channels/chan_zap.c