Summary:	ASTERISK-02736: [PATCH] allow zap gain and echo params to be twiddled on the fly from console
Reporter:	kb1_kanobe2 (kb1_kanobe2)	Labels:
Date Opened:	2004-11-03 23:14:37.000-0600	Date Closed:	2011-06-07 14:11:54
Priority:	Trivial	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) patch-settable-zap-echo.diff ( 1) patch-settable-zap-gains.diff
Description:	This trivial patch adds new CLI commands 'zap set echo...' and 'zap set gain...' which allow the zap echo and gain configuration of each channel to be adjusted in memory without reloading. In addition the gain adjustments are immediately applied to the channel even if it's in use. ****** ADDITIONAL INFORMATION ****** This pair of new commands stemmed from two issues: firstly the effort required to do precise gain calibrations across multiple trunk groups (restart/measure/adjust/repeat ad-nauseam). The second from an echo settings typo on one channel that was not noticed until the server was up and in use - tearing it down for the restart was poorly received by the users. The gain command is easy enough, but I'm a little concerned the echo command might have consequences I've not forseen. Disclaimer on file.
Comments:	By: Mark Spencer (markster) 2004-11-04 08:46:20.000-0600 chan_zap is now reloadable.  This patch should be unnecessary.  Try "reload chan_zap.so" By: mochouinard (mochouinard) 2004-11-07 02:31:40.000-0600 mark, it still look nice, beable to tweak the gain while the channel is open. Alot better than save all the time and reload chan_zap.so By: Mark Spencer (markster) 2004-11-07 11:16:04.000-0600 But then how many such optiosn are people going to want special command line options to set?  I think this sets a very dangerous precendent to merge.  Asterisk is designed to be simple and consistent, and I'm afraid this kind of option opens a whole new can of worms. By: mochouinard (mochouinard) 2004-11-07 12:03:01.000-0600 I agree, but until we have some sort of calibration tool to help fine tuning those analog line, this patch seem helpful. I know i never got my tdm400 to work right, echo or gains are never right. I would love a app that use a digital voip provider (nufone or whatever) and beable to auto find the BEST posible settings. Maybe by doing loopback between a TDM400 FXS and FXO port would be GREAT ... it calibrate echo, and calibrate gain. If this happen, then I guess you dont need to beable to change the settings live, but since it all try and error rightnow, this should help.  Maybe make this option available under debug cli, you need to put zap interface on debug to have access to those settings ? By: Brian West (bkw918) 2004-11-08 09:23:57.000-0600 BZZT WRONG... you can restart/reset/kick/beat your asterisk box when you first set it up to get the settings correct.  This patch IS NOT NEEDED and if we let it in we will invite other such patches that will clutter the cli and the code. Do we really want a say.c part 2?  but with other spots in asterisk. NO NO NO NO NO bkw By: kb1_kanobe2 (kb1_kanobe2) 2004-11-08 09:34:32.000-0600 Alright, I'll venture an opintion here: Asterisk is intended to be a stable, back end system. As such it doesn't need commands like the one proposed in this patch - as bkw918 points out, once it's up it's better not to have commands available that allow you to break the running configuration or generally complicate the codebase. Consider the IOS CLI, it's cluttered with arcane commands. However, there can be situations where such functionality is desirable - such as while learning/experimenting/testbenching. The existing configuration file structure is well optimised for groups of channels and so on - this style of command is directed at twidding with just one channel without having to restructure things. So, given the availability of reloadable zap in head, this is indeed redundant. Would maintainers prefer to see it closed or deleted entirely? By: petersv (petersv) 2004-11-08 15:21:58.000-0600 Bkw: I think the proper solution is to get the code base to the point where it is simpler and safe to grant access to as much of the state as possible. For example, we have an application where calls sent over a pri to one specific destination ould benefit from having a different gain setting. An app to change the gain would help there. I think it is better to grant as much access to as much as possible through the dialplan and for that matter through the manager interface / cli. If more things were exposed as channel variables things would be more regular. By: Mark Spencer (markster) 2004-11-08 15:44:13.000-0600 Definitely not deleted, but closed, perhaps.  It is *extremely* rare that we simply close out a feature contribution without merging it in some form or another, however, and I would like to derive concensus that the feature is, essentially, present in the existing code base and that the addition of this new entry point for activating it is inconsistent with the remainder of the asterisk structure (i.e the only runtime variables that are configured from the command line are debug related like sip debug, sip history, pri debug, etc). In fact, the only exception I can think of right now is the extension handling (add extension, etc) and that has been a *major* pain in the rear end because it means maintaining a lot of code that is essentially duplicating existing code. By: kb1_kanobe2 (kb1_kanobe2) 2004-11-09 02:18:21.000-0600 Thanks for the input everyone.