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

[Tzafrir Cohen]

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/channels/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: %s\n", p->channel, alarm2str(res));
> -			manager_event(EVENT_FLAG_SYSTEM, "Alarm",
> -								"Alarm: %s\r\n"
> -								"Channel: %d\r\n",
> -								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: %s\n", p->channel, alarm_str);
> +				manager_event(EVENT_FLAG_SYSTEM, "Alarm",
> +					"Alarm: %s\r\n"
> +					"Channel: %d\r\n",
> +					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 %d\n", p->channel);
> -			manager_event(EVENT_FLAG_SYSTEM, "AlarmClear",
> -								"Channel: %d\r\n", p->channel);
> +			if (!p->unknown_alarm) {
> +				ast_log(LOG_NOTICE, "Alarm cleared on channel %d\n", p->channel);
> +				manager_event(EVENT_FLAG_SYSTEM, "AlarmClear",
> +					"Channel: %d\r\n", 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 %d\n", i->channel);
> -		manager_event(EVENT_FLAG_SYSTEM, "AlarmClear",
> -			"Channel: %d\r\n", i->channel);
> +		if (!i->unknown_alarm) {
> +			ast_log(LOG_NOTICE, "Alarm cleared on channel %d\n", i->channel);
> +			manager_event(EVENT_FLAG_SYSTEM, "AlarmClear",
> +				"Channel: %d\r\n", 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: %s\n", i->channel, alarm2str(res));
> -		manager_event(EVENT_FLAG_SYSTEM, "Alarm",
> -			"Alarm: %s\r\n"
> -			"Channel: %d\r\n",
> -			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: %s\n", i->channel, alarm_str);
> +			manager_event(EVENT_FLAG_SYSTEM, "Alarm",
> +				"Alarm: %s\r\n"
> +				"Channel: %d\r\n",
> +				alarm_str, i->channel);
> +		} while (0);
>  		/* fall thru intentionally */
>  	case ZT_EVENT_ONHOOK:
>  		if (i->radio)

-- 
               Tzafrir Cohen
icq#16849755              jabber:tzafrir.cohen at xorcom.com
+972-50-7952406           mailto:tzafrir.cohen at xorcom.com
http://www.xorcom.com  iax:guest at local.xorcom.com/tzafrir