Summary:	DAHLIN-00151: [patch] RX RBS signalling not reset on alarm
Reporter:	Tzafrir Cohen (tzafrir)	Labels:
Date Opened:	2009-10-12 12:40:33	Date Closed:	2010-01-10 09:33:02.000-0600
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	dahdi (the module)
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) reset_span_to_onhook.diff
Description:	A had an incoming call in a CAS channel was running when an alarm was set. The alarm triggered disconnecting the call. However once the alarm is cleared, the channel can no longer be used for outgoing call until a call comes in. The hardware driver reported an alarm. But the fact that the state of the call has changed is not exactly a concern of the hardware driver. In case of CAS the state is maintained by DAHDI. And indeed the call has failed because nobody bothered updating the RX rbsbits of the channel. The attached patch aims at doing so. ****** ADDITIONAL INFORMATION ****** Reproducing the issue: Connect a cable in loop between two ports of a DAHDI T1 adapter. /etc/dahdi/genconf_parameters:: pri_connection_type     CAS tdm_framing             d4 em_signalling em /etc/dahdi/system.conf:: span=1,1,0,d4,b8zs span=2,0,0,d4,b8zs e&m=1-48 echocanceller=1-48 loadzone        = us defaultzone     = us /etc/dahdi/chan_dahdi.conf:: [channels] context=dahdi-test switchtype = national signalling = em channel => 1-48 /etc/asterisk/extensions.conf:: [general] [globals] [dahdi-test] exten => _X.,1,NoOp(got ${EXTEN} from ${CALLERID(all)}) exten => _X.,n,Answer exten => _X.,n,Wait(500) exten => _X.,n,Hangup Now run: asterisk -rx  "channel request DAHDI/2/123456 application Echo" # s/channel request/originate/ if you're on Asterisk 1.4 Disconnect loopback cable. Reconnect. Run again. Expected: call should be re-initiated. Actual: call fails: [Oct 12 17:36:13] NOTICE[9550]: channel.c:3046 __ast_request_and_dial: Unable to request channel DAHDI/2/123456 (This is on some Asterisk 1.4) Tested with both a Xorcom "PRI" module, and a Digium TE205P . In both cases with loopback calls between two ports. In both cases, with DAHDI trunk.
Comments:	By: Tzafrir Cohen (tzafrir) 2009-10-18 04:07:07 While this fix looks too simple, it works for all the cases I've tried. So now I challenge you all to find a scenario where this fix breaks something :-) By: Tzafrir Cohen (tzafrir) 2010-01-10 09:33:02.000-0600 It turned out that this issue is basically an issue that should be resolved on the driver level.