Summary:	ASTERISK-06917: [patch] Selectively disable EC for incoming DID's from PRI
Reporter:	reformed (reformed)	Labels:
Date Opened:	2006-05-08 07:08:40	Date Closed:	2006-05-18 09:23:50
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_zap
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) ec_disable.patch
Description:	We needed a way to selectively disable EC on incoming PRI DID's (our reason was faxes on iaxmodem and faxes on SIP ATA's). It can be useful for anyone wishing to have control of EC at runtime on PRI trunks (for whatever reason). After applying the patch you can disable EC as follows: database put EC/Disable [incoming DID number] 1 to re-enable it: database put EC/Disable [incoming DID number] 0 If the formatting is wrong, please feel free to change it. ****** ADDITIONAL INFORMATION ****** We did not use faxdetect so EC was always on for PRI->iaxmodem and PRI Span1->PRI Span2 fax calls
Comments:	By: BJ Weschke (bweschke) 2006-05-08 07:40:14 I like the idea in the patch, but the community has tended to try to not "hardcode" any new name/value params in the AstDB. Rather, you may want to take a look at enabling/disabling ec by means of the CHANNEL function similar to the way we just introduced zaptel txgain/rxgain adjustment on an individual channel. Come find me in #asterisk-bugs if you need any guidance on this. By: reformed (reformed) 2006-05-08 08:50:09 The server is running * 1.2 in production envoronment so i cannot implement CHANNEL func (its only in trunk) on it to be able to test your suggestion. I dont have space PRI hardware to be able to test it on a separate server. What would be best way to to implement this so that it can be accepted into 1.2 branch? I'm thinking of a channel variable (say DISABLE_ZAP_EC=yes) that chan_zap can check before briging and just call zt_disable_ec for the ZAP legs of the bridge thats about to be created. Would that be acceptable to be included into 1.2 brunch. If dynamic EC change would not make it to 1.2 branch i'd rather leave it as it is as we know it works and it would be pointless spending time implemeting this. If we have a chance of getting it into 1.2 branch i'm open to any suggestion on how to implement it best. I'll rewrite it, test it on production server and submit a patch. By: BJ Weschke (bweschke) 2006-05-08 09:16:13 reformed: we don't accept any new features/functionality into the 1.2 branch. only bugfixes. If you want to put together a patch for /trunk, I'm sure there are a number of folks who would be happy to test it for you. By: Serge Vecher (serge-v) 2006-05-18 09:22:09 mattf has recently committed a different solution to trunk in r27523 http://lists.digium.com/pipermail/svn-commits/2006-May/013637.html Please test the feature: it will be in the next stable (1.4). If for some reason, this needs to be looked at still, please reopen with an appropriate comment. Thank you for contribution!