Re: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
I'd suggest turning off echotraining on the FXS altogether, and perhaps even killing the echocanceller on FXS entirely. (you won't be getting significant echo from the FXS, and the FXO should be handling it anyway) -- echocancelwhenbridged might be an interesting thing to play with as well. e.g. (assuming port 1-3 are FXO and port 4-7 are FXS) echocancel=64 echocancelwhenbridged=yes echotraining=800 channel = 1-3 echocancelwhenbridged=no channel = 4-7 Andrew, I am sure you know that in zapata.conf parameter settings are in effect until specifically overridden later on in the file. In the first paragraph you suggest that I turn off both echotraining and echocanceler on FXS channels, so may I correct your example, that is, do you mean something like the following?: echocancel=64 echocancelwhenbridged=yes echotraining=800 channel = 1-3 echocancel=no echocancelwhenbridged=no echotraining=no channel = 4-7 Please correct me if I'm wrong, in your example echocanceler would still run on connections other than TDM (such as FXS-SIP). Did you knowingly mean it? With my additions above, FXS channels would never use echocanceler. Right? Thank you guys for all the help and comments. Rich's last comments were quite enlighthening, as always. I never knew echocanceler could be used on FXS channels. Sorry for my ignorance (but nowhere in docs or wiki could I see this information, I should have thought about it, my bad). I'll try and post the results. There are lots of things like this that aren't documented and probably never will be given the constant upgrades, code additions, etc. It will be interesting to hear your results. :) ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
On Sun, Aug 28, 2005 at 02:52:20PM -0400, Andrew Kohlsmith wrote: On Sunday 28 August 2005 11:59, Steve Underwood wrote: I don't follow why knowing that impedance mismatch is the problem has stopped you making fxotune fix it. :-\ Where you the one who asked me how to make fxotune work well on IRC? Someone asked a while ago, and said they were working on a faster tuning algorithm for fxotune. I've forgotten who. I thought fxotune set up the built-in FIR filter in the DAA and nothing more. I'm really uncertain how a little filter is going to help with impedance matching, as it's still the same frequency ranges that need to get through to be digitized. I have, however, been known to be mistaken on more than one occassion. :-) fxotune currently only does tuning with the AC impedance functions on the Si3050. If there is continued line-related echo problems, there is always the option of adding the onboard digital hybrid tuning to the mix, but it is unable to fix the problem as much as doing the AC impedance tuning. The onboard hybrid is more for that last step of tweaking, only to be used after doing the line adjustment for the AC impedance. -- Matthew Fredrickson ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
Are changes to the zapata.conf file read on the fly or do you have to restart the asterisk process? On 8/29/05, Matt Fredrickson [EMAIL PROTECTED] wrote: On Sun, Aug 28, 2005 at 02:52:20PM -0400, Andrew Kohlsmith wrote: On Sunday 28 August 2005 11:59, Steve Underwood wrote: I don't follow why knowing that impedance mismatch is the problem has stopped you making fxotune fix it. :-\ Where you the one who asked me how to make fxotune work well on IRC? Someone asked a while ago, and said they were working on a faster tuning algorithm for fxotune. I've forgotten who. I thought fxotune set up the built-in FIR filter in the DAA and nothing more. I'm really uncertain how a little filter is going to help with impedance matching, as it's still the same frequency ranges that need to get through to be digitized. I have, however, been known to be mistaken on more than one occassion. :-) fxotune currently only does tuning with the AC impedance functions on the Si3050. If there is continued line-related echo problems, there is always the option of adding the onboard digital hybrid tuning to the mix, but it is unable to fix the problem as much as doing the AC impedance tuning. The onboard hybrid is more for that last step of tweaking, only to be used after doing the line adjustment for the AC impedance. -- Matthew Fredrickson ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
Are changes to the zapata.conf file read on the fly or do you have to restart the asterisk process? I've never seen any .conf changes activated without reload. On CLI, try this: reload chan_zap.so ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
I'm 98% sure the zapata.conf changes require a full stop/start of asterisk. Are changes to the zapata.conf file read on the fly or do you have to restart the asterisk process? On 8/29/05, Matt Fredrickson [EMAIL PROTECTED] wrote: On Sun, Aug 28, 2005 at 02:52:20PM -0400, Andrew Kohlsmith wrote: On Sunday 28 August 2005 11:59, Steve Underwood wrote: I don't follow why knowing that impedance mismatch is the problem has stopped you making fxotune fix it. :-\ Where you the one who asked me how to make fxotune work well on IRC? Someone asked a while ago, and said they were working on a faster tuning algorithm for fxotune. I've forgotten who. I thought fxotune set up the built-in FIR filter in the DAA and nothing more. I'm really uncertain how a little filter is going to help with impedance matching, as it's still the same frequency ranges that need to get through to be digitized. I have, however, been known to be mistaken on more than one occassion. :-) fxotune currently only does tuning with the AC impedance functions on the Si3050. If there is continued line-related echo problems, there is always the option of adding the onboard digital hybrid tuning to the mix, but it is unable to fix the problem as much as doing the AC impedance tuning. The onboard hybrid is more for that last step of tweaking, only to be used after doing the line adjustment for the AC impedance. -- Matthew Fredrickson ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ---End of Original Message- ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
On Mon, Aug 29, 2005 at 03:24:01PM -0500, Ric Moseley wrote: Are changes to the zapata.conf file read on the fly or do you have to restart the asterisk process? It doesn't make any changes to the zapata.conf file. It has it's own config file that you have to set it up to load from before you start asterisk. See the README.fxotune file in zaptel CVS HEAD. -- Matthew Fredrickson ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
Correct -- any changes to just zapata.conf do require a full restart of asterisk (but do not require reloading of zaptel modules) Rich Adamson wrote: I'm 98% sure the zapata.conf changes require a full stop/start of asterisk. Are changes to the zapata.conf file read on the fly or do you have to restart the asterisk process? On 8/29/05, Matt Fredrickson [EMAIL PROTECTED] wrote: On Sun, Aug 28, 2005 at 02:52:20PM -0400, Andrew Kohlsmith wrote: On Sunday 28 August 2005 11:59, Steve Underwood wrote: I don't follow why knowing that impedance mismatch is the problem has stopped you making fxotune fix it. :-\ Where you the one who asked me how to make fxotune work well on IRC? Someone asked a while ago, and said they were working on a faster tuning algorithm for fxotune. I've forgotten who. I thought fxotune set up the built-in FIR filter in the DAA and nothing more. I'm really uncertain how a little filter is going to help with impedance matching, as it's still the same frequency ranges that need to get through to be digitized. I have, however, been known to be mistaken on more than one occassion. :-) fxotune currently only does tuning with the AC impedance functions on the Si3050. If there is continued line-related echo problems, there is always the option of adding the onboard digital hybrid tuning to the mix, but it is unable to fix the problem as much as doing the AC impedance tuning. The onboard hybrid is more for that last step of tweaking, only to be used after doing the line adjustment for the AC impedance. -- Matthew Fredrickson ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ---End of Original Message- ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
In my experience, rxgain and txgain settings is changing without full restart, reload of chan_zap.so seems to be enough. Please let me know if you think this is problematic. I don't know about other zapata.conf parameters. - Original Message - From: Samy Kamkar [EMAIL PROTECTED] To: Asterisk Users Mailing List - Non-Commercial Discussion asterisk-users@lists.digium.com Sent: Tuesday, August 30, 2005 2:11 AM Subject: Re: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared Correct -- any changes to just zapata.conf do require a full restart of asterisk (but do not require reloading of zaptel modules) Rich Adamson wrote: I'm 98% sure the zapata.conf changes require a full stop/start of asterisk. Are changes to the zapata.conf file read on the fly or do you have to restart the asterisk process? On 8/29/05, Matt Fredrickson [EMAIL PROTECTED] wrote: On Sun, Aug 28, 2005 at 02:52:20PM -0400, Andrew Kohlsmith wrote: On Sunday 28 August 2005 11:59, Steve Underwood wrote: I don't follow why knowing that impedance mismatch is the problem has stopped you making fxotune fix it. :-\ Where you the one who asked me how to make fxotune work well on IRC? Someone asked a while ago, and said they were working on a faster tuning algorithm for fxotune. I've forgotten who. I thought fxotune set up the built-in FIR filter in the DAA and nothing more. I'm really uncertain how a little filter is going to help with impedance matching, as it's still the same frequency ranges that need to get through to be digitized. I have, however, been known to be mistaken on more than one occassion. :-) fxotune currently only does tuning with the AC impedance functions on the Si3050. If there is continued line-related echo problems, there is always the option of adding the onboard digital hybrid tuning to the mix, but it is unable to fix the problem as much as doing the AC impedance tuning. The onboard hybrid is more for that last step of tweaking, only to be used after doing the line adjustment for the AC impedance. -- Matthew Fredrickson ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ---End of Original Message- ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
Is it practical to 'assume' that in your case mentioned above that #1 is not going to occur again (since I assume when you say 'line' you are referring to an outside pstn line), and, #2 is in a mode of fine-tuning the training when in fact you'd really like it to start the coarse-training from scratch? Thanks Rich for the comments. Obviously you got my point. And I was hoping that it is possible somehow to do #1 (coarse-training from scratch) after a PSTN line is transfered to another phone or something very important changes about a call. But considering how complicated a situation this might be (there is music on hold to say the least, or perhaps the transferee may reject the call and the call returns to the operator [in which case you wouldn't want #1], etc.) I guess this is not a simple task. Anyway, I'll keep on watching for a solution. The echo canceler preload happens shortly after the analog line is seized. Since a call transfer does not open/close the pstn line again, its not going to preload again. However, it should not have to anyway since there hasn't been any electrical changes there. What type of phones are you using internal when you're transferring a call? The internal phones involved were both analog phones, i.e. Zap channels. This problem happened once in the last 2 days (with KB1), so I'm not too negative. Are the analog phones connected to a TDM card, channel bank, or what? cvs head or stable version? I have 2x TDM cards (4x FXS + 3x FXO), so all analog phones and pstn lines are connected to TDM cards, Rev E/F. Asterisk CVS-HEAD built by [EMAIL PROTECTED] on a i686 running Linux on 2005-08-19 22:03:57 UTC That's on an Athlon 2000+, with CentOS 4.1, 2.6.11 kernel. (I have the monitor recording of that call, and I've listened to it a couple of times. When the caller from pstn is talking to the operator [before transfer] I can't hear echo, but it's a very short converstion, so now I can't be sure %100. But after the transfer I can clearly hear the echo. I should catch another case like this.) Thanks for the splitter answer, btw. ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
Is it practical to 'assume' that in your case mentioned above that #1 is not going to occur again (since I assume when you say 'line' you are referring to an outside pstn line), and, #2 is in a mode of fine-tuning the training when in fact you'd really like it to start the coarse-training from scratch? Thanks Rich for the comments. Obviously you got my point. And I was hoping that it is possible somehow to do #1 (coarse-training from scratch) after a PSTN line is transfered to another phone or something very important changes about a call. But considering how complicated a situation this might be (there is music on hold to say the least, or perhaps the transferee may reject the call and the call returns to the operator [in which case you wouldn't want #1], etc.) I guess this is not a simple task. Anyway, I'll keep on watching for a solution. The echo canceler preload happens shortly after the analog line is seized. Since a call transfer does not open/close the pstn line again, its not going to preload again. However, it should not have to anyway since there hasn't been any electrical changes there. What type of phones are you using internal when you're transferring a call? The internal phones involved were both analog phones, i.e. Zap channels. This problem happened once in the last 2 days (with KB1), so I'm not too negative. Are the analog phones connected to a TDM card, channel bank, or what? cvs head or stable version? I have 2x TDM cards (4x FXS + 3x FXO), so all analog phones and pstn lines are connected to TDM cards, Rev E/F. Asterisk CVS-HEAD built by [EMAIL PROTECTED] on a i686 running Linux on 2005-08-19 22:03:57 UTC That's on an Athlon 2000+, with CentOS 4.1, 2.6.11 kernel. (I have the monitor recording of that call, and I've listened to it a couple of times. When the caller from pstn is talking to the operator [before transfer] I can't hear echo, but it's a very short converstion, so now I can't be sure %100. But after the transfer I can clearly hear the echo. I should catch another case like this.) Thanks for the splitter answer, btw. I don't use the fxs modules on a TDM card, so all I can do is guess that the internal call handling (eg, drivers) for the fxs is suspect. The guess is based on an assumption that *'s echo canceler is involved with fxs modules since there _is_ a hybrid involved, and, another set of canceler parameters are involved with the fxo side of the call. (In effect, two instances of the canceler per fxo-fxs call.) Since you've mentioned the echo after transfer doesn't happen on a regular basis, that would suggest the problem is not a coding issue as that would likely involve echo on every transfer. If its not a coding issue, then its likely the issue is related to interaction of the two echo canceler instances. Might try playing around with the canceler parameters on the fxs channel. Since the analog fxs phone is always very close physically, maybe play with the echotraining (echocancel=32, and other echo parameters) to see what impact those might have. (In theory, using something like echotraining=800 on the fxo port and echotraining=200 on the fxs port might influence the interaction, if that really is the issue.) ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
On Sunday 28 August 2005 10:21, Rich Adamson wrote: Might try playing around with the canceler parameters on the fxs channel. Since the analog fxs phone is always very close physically, maybe play with the echotraining (echocancel=32, and other echo parameters) to see what impact those might have. (In theory, using something like echotraining=800 on the fxo port and echotraining=200 on the fxs port might influence the interaction, if that really is the issue.) I'd suggest turning off echotraining on the FXS altogether, and perhaps even killing the echocanceller on FXS entirely. (you won't be getting significant echo from the FXS, and the FXO should be handling it anyway) -- echocancelwhenbridged might be an interesting thing to play with as well. e.g. (assuming port 1-3 are FXO and port 4-7 are FXS) echocancel=64 echocancelwhenbridged=yes echotraining=800 channel = 1-3 echocancelwhenbridged=no channel = 4-7 type of thing... I'm just throwing out some ideas here and have not tried it myself. -A. ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
Might try playing around with the canceler parameters on the fxs channel. Since the analog fxs phone is always very close physically, maybe play with the echotraining (echocancel=32, and other echo parameters) to see what impact those might have. (In theory, using something like echotraining=800 on the fxo port and echotraining=200 on the fxs port might influence the interaction, if that really is the issue.) I'd suggest turning off echotraining on the FXS altogether, and perhaps even killing the echocanceller on FXS entirely. (you won't be getting significant echo from the FXS, and the FXO should be handling it anyway) -- echocancelwhenbridged might be an interesting thing to play with as well. e.g. (assuming port 1-3 are FXO and port 4-7 are FXS) echocancel=64 echocancelwhenbridged=yes echotraining=800 channel = 1-3 echocancelwhenbridged=no channel = 4-7 type of thing... I'm just throwing out some ideas here and have not tried it myself. That certainly makes more sence then my logic did. :) ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
Then, on a commercial turn up (back when I did these, it was Western Union and/or MCI), the tech at the other end would again dialup the milliwatt, report the value measured over the loop and the pad(s) re-adjusted to match the values for the loss in a document provided. That is the device called that would measure the milliwatt db loss when plugged into an analog port and dialed into a milliwatt line? Take a look at http://www.repaircalibration.com/triplett-triplett-telco-testers.html The model 2 is fine for simply measuring line loss, noise, etc. The model 5 is the same but with a tone generator as well. (Handy for sending a tone from one ATA and measuring the received tone on another ATA.) There are other companies besides Triplett that make equivalent units. The model numbers (eg, 2, 5) has its roots in the old Western Electric specifications, and several manufactureres stuck with those. Google terms: transmission test set, subscriber loop test set (450,000 hits). A simple analog Voltmeter will also work in some cases for measuring telephony audio tones. If you can find one with a scale marked in db, try it. Don't forget to place a 600 ohm resistor across tip ring as the cable pair _must_ be terminated (lot left wide open) to obtain accurate values. (Use an old pots telephone to dial the CO milliwatt, add the 600 ohm resister after you reached to milliwatt, hang up the pots telephone, and measure the loss.) Another approach is to have the telco come out on a low volume trouble ticket and ask the technician what values he read to the milliwatt generator. ;) ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
Matt Fredrickson wrote: On Fri, Aug 26, 2005 at 02:00:54PM -0600, Rich Adamson wrote: Relative to the fxotune app, it would appear the app is specific to the v2.4 kernels (/dev/zap*), which the v2.6 kernels don't use It should with 2.4 and 2.6. 2.6 kernels with properly configured udev rules should create the /dev/zap/* entries dynamically. (but rather the udev equivalent). (When I had * running on a v2.4 kernel, the output from fxotune never deviated from all zero's. So I'm assuming the default chipset values were already tweaked by the chipset manufacturer to US telco lines. If that is true, then running fxotune in the US has very little value.) Sometimes in the US you still deal with line impedance issues. In fact, I was told by an engineer that worked for the company that designs the line interface part that the bulk of echo problems (with line interface parts such as this) are related to AC impedance mismatches (which is one reason why I haven't done the digital hybrid tuning portion of fxotune still). It should work the same regardless of which kernel (2.4 or 2.6) you are using. Everyone has to deal with line impedance issues. The hyrbids in exchanges usually use a compromise impedance, but there are tolerance in the circuits. The lines themselves vary far more, especially if loading coil, and other fudges have been used. To get pretty good hybrid performance you always need to individually tune. What you have to remember about hybrids is they are not there to give great rejection. They are there to give enough rejection to prevent howling. Nothing more. The telephone approvals specs in most places only call for 12dB of suppression through a hybrid. The exchange specs tend to use a slightly higher figure, but only slightly. I don't follow why knowing that impedance mismatch is the problem has stopped you making fxotune fix it. :-\ Where you the one who asked me how to make fxotune work well on IRC? Someone asked a while ago, and said they were working on a faster tuning algorithm for fxotune. I've forgotten who. If it doesn't, and you have udev setup correctly, something is fundamentally wrong in the setup. Regards, Steve ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
On Sunday 28 August 2005 11:59, Steve Underwood wrote: I don't follow why knowing that impedance mismatch is the problem has stopped you making fxotune fix it. :-\ Where you the one who asked me how to make fxotune work well on IRC? Someone asked a while ago, and said they were working on a faster tuning algorithm for fxotune. I've forgotten who. I thought fxotune set up the built-in FIR filter in the DAA and nothing more. I'm really uncertain how a little filter is going to help with impedance matching, as it's still the same frequency ranges that need to get through to be digitized. I have, however, been known to be mistaken on more than one occassion. :-) -A. ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
I'd suggest turning off echotraining on the FXS altogether, and perhaps even killing the echocanceller on FXS entirely. (you won't be getting significant echo from the FXS, and the FXO should be handling it anyway) -- echocancelwhenbridged might be an interesting thing to play with as well. e.g. (assuming port 1-3 are FXO and port 4-7 are FXS) echocancel=64 echocancelwhenbridged=yes echotraining=800 channel = 1-3 echocancelwhenbridged=no channel = 4-7 Andrew, I am sure you know that in zapata.conf parameter settings are in effect until specifically overridden later on in the file. In the first paragraph you suggest that I turn off both echotraining and echocanceler on FXS channels, so may I correct your example, that is, do you mean something like the following?: echocancel=64 echocancelwhenbridged=yes echotraining=800 channel = 1-3 echocancel=no echocancelwhenbridged=no echotraining=no channel = 4-7 Please correct me if I'm wrong, in your example echocanceler would still run on connections other than TDM (such as FXS-SIP). Did you knowingly mean it? With my additions above, FXS channels would never use echocanceler. Right? Thank you guys for all the help and comments. Rich's last comments were quite enlighthening, as always. I never knew echocanceler could be used on FXS channels. Sorry for my ignorance (but nowhere in docs or wiki could I see this information, I should have thought about it, my bad). I'll try and post the results. Soner ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
Since this is a lively topic, I'll ask here... How can I measure the interval between the original and the echo? On Mon, 29 Aug 2005, Soner Tari wrote: I'd suggest turning off echotraining on the FXS altogether, and perhaps even killing the echocanceller on FXS entirely. (you won't be getting significant echo from the FXS, and the FXO should be handling it anyway) -- echocancelwhenbridged might be an interesting thing to play with as well. e.g. (assuming port 1-3 are FXO and port 4-7 are FXS) echocancel=64 echocancelwhenbridged=yes echotraining=800 channel = 1-3 echocancelwhenbridged=no channel = 4-7 Andrew, I am sure you know that in zapata.conf parameter settings are in effect until specifically overridden later on in the file. In the first paragraph you suggest that I turn off both echotraining and echocanceler on FXS channels, so may I correct your example, that is, do you mean something like the following?: echocancel=64 echocancelwhenbridged=yes echotraining=800 channel = 1-3 echocancel=no echocancelwhenbridged=no echotraining=no channel = 4-7 Please correct me if I'm wrong, in your example echocanceler would still run on connections other than TDM (such as FXS-SIP). Did you knowingly mean it? With my additions above, FXS channels would never use echocanceler. Right? Thank you guys for all the help and comments. Rich's last comments were quite enlighthening, as always. I never knew echocanceler could be used on FXS channels. Sorry for my ignorance (but nowhere in docs or wiki could I see this information, I should have thought about it, my bad). I'll try and post the results. Soner ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users Thanks in advance, Steve Edwards [EMAIL PROTECTED] Voice: +1-760-468-3867 PST Newline [EMAIL PROTECTED]Fax: +1-760-731-3000 ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
On Sunday 28 August 2005 19:55, Soner Tari wrote: Andrew sez: echocancel=64 echocancelwhenbridged=yes echotraining=800 channel = 1-3 echocancelwhenbridged=no channel = 4-7 I am sure you know that in zapata.conf parameter settings are in effect until specifically overridden later on in the file. In the first paragraph you suggest that I turn off both echotraining and echocanceler on FXS channels, so may I correct your example, that is, do you mean something like the following?: echocancel=64 echocancelwhenbridged=yes echotraining=800 channel = 1-3 echocancel=no echocancelwhenbridged=no echotraining=no channel = 4-7 Please correct me if I'm wrong, in your example echocanceler would still run on connections other than TDM (such as FXS-SIP). Did you knowingly mean it? With my additions above, FXS channels would never use echocanceler. Right? Correct. That's precisely how I meant to say it. You may still want the echo canceller for Zap--SIP and so on since the FXS port is (potentially) the only hybrid in the circuit. -A. ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
Is it practical to 'assume' that in your case mentioned above that #1 is not going to occur again (since I assume when you say 'line' you are referring to an outside pstn line), and, #2 is in a mode of fine-tuning the training when in fact you'd really like it to start the coarse-training from scratch? Thanks Rich for the comments. Obviously you got my point. And I was hoping that it is possible somehow to do #1 (coarse-training from scratch) after a PSTN line is transfered to another phone or something very important changes about a call. But considering how complicated a situation this might be (there is music on hold to say the least, or perhaps the transferee may reject the call and the call returns to the operator [in which case you wouldn't want #1], etc.) I guess this is not a simple task. Anyway, I'll keep on watching for a solution. The echo canceler preload happens shortly after the analog line is seized. Since a call transfer does not open/close the pstn line again, its not going to preload again. However, it should not have to anyway since there hasn't been any electrical changes there. What type of phones are you using internal when you're transferring a call? Rich ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
Is it practical to 'assume' that in your case mentioned above that #1 is not going to occur again (since I assume when you say 'line' you are referring to an outside pstn line), and, #2 is in a mode of fine-tuning the training when in fact you'd really like it to start the coarse-training from scratch? Thanks Rich for the comments. Obviously you got my point. And I was hoping that it is possible somehow to do #1 (coarse-training from scratch) after a PSTN line is transfered to another phone or something very important changes about a call. But considering how complicated a situation this might be (there is music on hold to say the least, or perhaps the transferee may reject the call and the call returns to the operator [in which case you wouldn't want #1], etc.) I guess this is not a simple task. Anyway, I'll keep on watching for a solution. The echo canceler preload happens shortly after the analog line is seized. Since a call transfer does not open/close the pstn line again, its not going to preload again. However, it should not have to anyway since there hasn't been any electrical changes there. What type of phones are you using internal when you're transferring a call? The internal phones involved were both analog phones, i.e. Zap channels. This problem happened once in the last 2 days (with KB1), so I'm not too negative. Soner ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
Is it practical to 'assume' that in your case mentioned above that #1 is not going to occur again (since I assume when you say 'line' you are referring to an outside pstn line), and, #2 is in a mode of fine-tuning the training when in fact you'd really like it to start the coarse-training from scratch? Thanks Rich for the comments. Obviously you got my point. And I was hoping that it is possible somehow to do #1 (coarse-training from scratch) after a PSTN line is transfered to another phone or something very important changes about a call. But considering how complicated a situation this might be (there is music on hold to say the least, or perhaps the transferee may reject the call and the call returns to the operator [in which case you wouldn't want #1], etc.) I guess this is not a simple task. Anyway, I'll keep on watching for a solution. The echo canceler preload happens shortly after the analog line is seized. Since a call transfer does not open/close the pstn line again, its not going to preload again. However, it should not have to anyway since there hasn't been any electrical changes there. What type of phones are you using internal when you're transferring a call? The internal phones involved were both analog phones, i.e. Zap channels. This problem happened once in the last 2 days (with KB1), so I'm not too negative. Are the analog phones connected to a TDM card, channel bank, or what? cvs head or stable version? ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
I have splitters on 2 of the 3 PSTN lines. As I mentioned in my previous posts, the echo performance of my system is not so bad, but does anybody know if ADSL splitters may cause echo? After all, splitters have some circuitry, and my wild guess is that that may influence the characteristics of those lines. Soner ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
I have splitters on 2 of the 3 PSTN lines. As I mentioned in my previous posts, the echo performance of my system is not so bad, but does anybody know if ADSL splitters may cause echo? After all, splitters have some circuitry, and my wild guess is that that may influence the characteristics of those lines. I've got four pstn lines of which one has adsl on it with a filter. No problem here, and its been that way for several years. All four lines operate the same and sound exactly the same. ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
This is an interesting document about VoIP and Echo. http://www.cisco.com/univercd/cc/td/doc/cisintwk/intsolns/voipsol/ea_isd.htm ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
Hi, I'm not the OP, but I had a similar problem, in my case fxotune ran successfully for just one out of 3x FXO modules, but the coefficients were all 0's. My kernel is 2.6.11 on CentOS 4.1. So I'm curious if 2.6 kernel (instead of 2.4) has any input in this whole echo issue, not just fxotune. Yesterday I switched to KB1 echo canceller, it is by far the best. But today I had a similar experience to Eric Rees's Strange Echo post. After transfering to another internal line, echo starts. My theory is that after transfer some characteristics of the internal connection change, especially the Tx voice (the person talking on our side changes). So if the echo canceller is too committed to the voice of the first person answering the line (the operator), that would be quite expected. I don't know how KB1 or other echo cancellers work, but if I'm right, it would be better if echo canceller readjusted itself after transfer. Sorry if that's plain wrong. Can somebody comment please? I'm really interested in all posts in this thread and others or documents on echo. Btw, thanks Eric Wieling for the Cisco link. Soner - Original Message - From: Derek Whitten [EMAIL PROTECTED] To: Asterisk Users Mailing List - Non-Commercial Discussion asterisk-users@lists.digium.com Sent: Friday, August 26, 2005 2:39 AM Subject: Re: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
RE: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
So bottom line please. Have we decided that it is STILL correct to set RX/TX gain for 14800 with ztmonitor quantitative using a telco 1004hz 0dbm test phone number? If not, what should we set it to with ztmonitor. -Original Message- From: Rich Adamson [mailto:[EMAIL PROTECTED] Sent: Thursday, August 25, 2005 8:20 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared I'll do my comments in line and hope I don't offend. Rich Adamson wrote: First off, thank you *very* much for this unbelievably informative post! I've got it saved away now along with Kris Boutilier's adjusting rxgain/txgain post. On Wednesday 24 August 2005 17:14, Bruce Ferrell wrote: At the point where the phone line get's to your demarc the is supposed to ba a -2 to 3db reference point, sometimes called a -2 or -3 test level point (TLP). So that milliwatt tone at that point should read in the range of -2 to -3 dbm. If I read the above words exactly as written, the above is not true. Maybe there was a different intent that I'm missing, or, maybe words left out? I'm a lousy typist :) I'm reading the words to say if I put a transmission test set on the cable pair just before the pair leaves the central office, the reading should be in the -2 to -3 dbm range. If that is what you meant, then its incorrect. Even the old analog step-by-step switch specs called for no more then .5db loss from the milliwatt generator to the cable pair (CO distribution frame). If you mean placing a transmission test set at the customer's demarc (at the customer's site), the -2 to -3 db is still incorrect for analog pstn circuits. That level _will be_ the 0db generator tone minus the cable loss from the CO to the customer's demarc. That cable loss is 100% predictable if you know the length and gauge of the copper wires between the central office and the customer's site. (That is exactly how the engineering spec is set for the less technical telephone installers to measure after installing a new pstn facility to a customer site.) at the last point leaving the CO, the tone level should be a nominal 0dbm. By the time it get's to the customer demarc, -2 to -3 dbm. The loops are suppposed to be engineered that way. On a brand spanky new loop, yes 100% predictable. Over time, all sorts of oddities (corrosion, half taps, loading coils, and just general funkieness) are introduced in the real world. The -2 to -3 db is not correct for analog circuits. Copper wires have a loss that is directly related to the length of the cable. (I don't have the chart right here, but a 7,000 foot cable pair will have lets say 6db of loss and a 3,000 foot pair will be a 3db loss. You can't engineer something into a copper pair to compensate for that loss.) The only thing that I can think of that you might be talking about is using an old analog carrier system on a copper pair. If that's what you're thinking, then yes -2 to -3 db is very reasonable. ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
I'm not the OP, but I had a similar problem, in my case fxotune ran successfully for just one out of 3x FXO modules, but the coefficients were all 0's. My kernel is 2.6.11 on CentOS 4.1. So I'm curious if 2.6 kernel (instead of 2.4) has any input in this whole echo issue, not just fxotune. Yesterday I switched to KB1 echo canceller, it is by far the best. But today I had a similar experience to Eric Rees's Strange Echo post. After transfering to another internal line, echo starts. My theory is that after transfer some characteristics of the internal connection change, especially the Tx voice (the person talking on our side changes). So if the echo canceller is too committed to the voice of the first person answering the line (the operator), that would be quite expected. I don't know how KB1 or other echo cancellers work, but if I'm right, it would be better if echo canceller readjusted itself after transfer. Sorry if that's plain wrong. Can somebody comment please? I'm really interested in all posts in this thread and others or documents on echo. Btw, thanks Eric Wieling for the Cisco link. That article is an excellent read. Readers should be a little carefull with it however as there can be additional sources not mentioned in the article. Others that have more capability to read code then I might want to comment on the following to help ensure we're all running with the same reasonable understanding. Relative to asterisk's canceler and based on two years of rather heavy experience with asterisk, one can characterize the existing canceler(s) by saying there are two distinct functional pieces: 1. the pstn line pulsing used to preload the canceler, and, 2. the ongoing real-time training. The first function is controlled by 'echotraining=800' (or whatever value including 'yes' might be provided) in zapatal.conf. The second part can actually be heard in most implementations by changing echotraining=no and listen to an actual call. Typically, it takes about ten seconds or so for the training to occur. (The actual time varies depending upon how good/bad the end-to-end circuit happens to be. Is it practical to 'assume' that in your case mentioned above that #1 is not going to occur again (since I assume when you say 'line' you are referring to an outside pstn line), and, #2 is in a mode of fine-tuning the training when in fact you'd really like it to start the coarse-training from scratch? Relative to the fxotune app, it would appear the app is specific to the v2.4 kernels (/dev/zap*), which the v2.6 kernels don't use (but rather the udev equivalent). (When I had * running on a v2.4 kernel, the output from fxotune never deviated from all zero's. So I'm assuming the default chipset values were already tweaked by the chipset manufacturer to US telco lines. If that is true, then running fxotune in the US has very little value.) The KB1 canceler _does_ work just fine in the v2.6 kernels and I'm in favor of moving it to the default for future Head and Stable releases as soon as practical. ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
RE: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
Bottom line... ztmonitor can be used to 'assist' in setting some starting values, but the further your asterisk box is from the central office, the more likely the gain values will have to be adjusted lower then what you want, and may very well appear off-scale with ztmonitor. Given the curent code and issues, using your ears instead of ztmonitor will lead to better results, period. (Before lots of people jump on this and say it does work, please reread the further you are from the CO words again. Yes, ztmonitor can be used with low-loss pstn loops; no, it will not provide anything close to an optimal circuit for higher-loss loops.) So bottom line please. Have we decided that it is STILL correct to set RX/TX gain for 14800 with ztmonitor quantitative using a telco 1004hz 0dbm test phone number? If not, what should we set it to with ztmonitor. -Original Message- From: Rich Adamson [mailto:[EMAIL PROTECTED] Sent: Thursday, August 25, 2005 8:20 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared I'll do my comments in line and hope I don't offend. Rich Adamson wrote: First off, thank you *very* much for this unbelievably informative post! I've got it saved away now along with Kris Boutilier's adjusting rxgain/txgain post. On Wednesday 24 August 2005 17:14, Bruce Ferrell wrote: At the point where the phone line get's to your demarc the is supposed to ba a -2 to 3db reference point, sometimes called a -2 or -3 test level point (TLP). So that milliwatt tone at that point should read in the range of -2 to -3 dbm. If I read the above words exactly as written, the above is not true. Maybe there was a different intent that I'm missing, or, maybe words left out? I'm a lousy typist :) I'm reading the words to say if I put a transmission test set on the cable pair just before the pair leaves the central office, the reading should be in the -2 to -3 dbm range. If that is what you meant, then its incorrect. Even the old analog step-by-step switch specs called for no more then .5db loss from the milliwatt generator to the cable pair (CO distribution frame). If you mean placing a transmission test set at the customer's demarc (at the customer's site), the -2 to -3 db is still incorrect for analog pstn circuits. That level _will be_ the 0db generator tone minus the cable loss from the CO to the customer's demarc. That cable loss is 100% predictable if you know the length and gauge of the copper wires between the central office and the customer's site. (That is exactly how the engineering spec is set for the less technical telephone installers to measure after installing a new pstn facility to a customer site.) at the last point leaving the CO, the tone level should be a nominal 0dbm. By the time it get's to the customer demarc, -2 to -3 dbm. The loops are suppposed to be engineered that way. On a brand spanky new loop, yes 100% predictable. Over time, all sorts of oddities (corrosion, half taps, loading coils, and just general funkieness) are introduced in the real world. The -2 to -3 db is not correct for analog circuits. Copper wires have a loss that is directly related to the length of the cable. (I don't have the chart right here, but a 7,000 foot cable pair will have lets say 6db of loss and a 3,000 foot pair will be a 3db loss. You can't engineer something into a copper pair to compensate for that loss.) The only thing that I can think of that you might be talking about is using an old analog carrier system on a copper pair. If that's what you're thinking, then yes -2 to -3 db is very reasonable. ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ---End of Original Message- ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
RE: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
Assuming I am an average asterisk install an average distance from the CO with average ears with current stable asterisk code (v1.0.9) looking for 'assistance' for optimal values knowing full well that it may not be optimal...I ask again, what should I set ztmonitor quantitative to. -Original Message- From: Rich Adamson [mailto:[EMAIL PROTECTED] Sent: Friday, August 26, 2005 1:38 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: RE: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared Bottom line... ztmonitor can be used to 'assist' in setting some starting values, but the further your asterisk box is from the central office, the more likely the gain values will have to be adjusted lower then what you want, and may very well appear off-scale with ztmonitor. Given the curent code and issues, using your ears instead of ztmonitor will lead to better results, period. (Before lots of people jump on this and say it does work, please reread the further you are from the CO words again. Yes, ztmonitor can be used with low-loss pstn loops; no, it will not provide anything close to an optimal circuit for higher-loss loops.) So bottom line please. Have we decided that it is STILL correct to set RX/TX gain for 14800 with ztmonitor quantitative using a telco 1004hz 0dbm test phone number? If not, what should we set it to with ztmonitor. -Original Message- From: Rich Adamson [mailto:[EMAIL PROTECTED] Sent: Thursday, August 25, 2005 8:20 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared I'll do my comments in line and hope I don't offend. Rich Adamson wrote: First off, thank you *very* much for this unbelievably informative post! I've got it saved away now along with Kris Boutilier's adjusting rxgain/txgain post. On Wednesday 24 August 2005 17:14, Bruce Ferrell wrote: At the point where the phone line get's to your demarc the is supposed to ba a -2 to 3db reference point, sometimes called a -2 or -3 test level point (TLP). So that milliwatt tone at that point should read in the range of -2 to -3 dbm. If I read the above words exactly as written, the above is not true. Maybe there was a different intent that I'm missing, or, maybe words left out? I'm a lousy typist :) I'm reading the words to say if I put a transmission test set on the cable pair just before the pair leaves the central office, the reading should be in the -2 to -3 dbm range. If that is what you meant, then its incorrect. Even the old analog step-by-step switch specs called for no more then .5db loss from the milliwatt generator to the cable pair (CO distribution frame). If you mean placing a transmission test set at the customer's demarc (at the customer's site), the -2 to -3 db is still incorrect for analog pstn circuits. That level _will be_ the 0db generator tone minus the cable loss from the CO to the customer's demarc. That cable loss is 100% predictable if you know the length and gauge of the copper wires between the central office and the customer's site. (That is exactly how the engineering spec is set for the less technical telephone installers to measure after installing a new pstn facility to a customer site.) at the last point leaving the CO, the tone level should be a nominal 0dbm. By the time it get's to the customer demarc, -2 to -3 dbm. The loops are suppposed to be engineered that way. On a brand spanky new loop, yes 100% predictable. Over time, all sorts of oddities (corrosion, half taps, loading coils, and just general funkieness) are introduced in the real world. The -2 to -3 db is not correct for analog circuits. Copper wires have a loss that is directly related to the length of the cable. (I don't have the chart right here, but a 7,000 foot cable pair will have lets say 6db of loss and a 3,000 foot pair will be a 3db loss. You can't engineer something into a copper pair to compensate for that loss.) The only thing that I can think of that you might be talking about is using an old analog carrier system on a copper pair. If that's what you're thinking, then yes -2 to -3 db is very reasonable. ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ---End of Original Message- ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman
Re: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
On Fri, Aug 26, 2005 at 02:00:54PM -0600, Rich Adamson wrote: Relative to the fxotune app, it would appear the app is specific to the v2.4 kernels (/dev/zap*), which the v2.6 kernels don't use It should with 2.4 and 2.6. 2.6 kernels with properly configured udev rules should create the /dev/zap/* entries dynamically. (but rather the udev equivalent). (When I had * running on a v2.4 kernel, the output from fxotune never deviated from all zero's. So I'm assuming the default chipset values were already tweaked by the chipset manufacturer to US telco lines. If that is true, then running fxotune in the US has very little value.) Sometimes in the US you still deal with line impedance issues. In fact, I was told by an engineer that worked for the company that designs the line interface part that the bulk of echo problems (with line interface parts such as this) are related to AC impedance mismatches (which is one reason why I haven't done the digital hybrid tuning portion of fxotune still). It should work the same regardless of which kernel (2.4 or 2.6) you are using. If it doesn't, and you have udev setup correctly, something is fundamentally wrong in the setup. -- Matthew Fredrickson ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
Rich Adamson wrote: clippage here The -2 to -3 db is not correct for analog circuits. Copper wires have a loss that is directly related to the length of the cable. (I don't have the chart right here, but a 7,000 foot cable pair will have lets say 6db of loss and a 3,000 foot pair will be a 3db loss. You can't engineer something into a copper pair to compensate for that loss.) The only thing that I can think of that you might be talking about is using an old analog carrier system on a copper pair. If that's what you're thinking, then yes -2 to -3 db is very reasonable. Analog carrier was(is?) engineered for -16/+7 tx/rx TLP. That was because microwave links liked it that way and it kept spurious emmisions down. What can be engineered into a loop is an odd little device called a pad. Most often today they're found in the channel module in a channel bank coming off of a digital switch. The milliwatt are accessed right at the card and measured. the pad(s) on the card are adjusted for the calculated values. Analog switches were similar in that banks of pad sockets were wired to the ports on the switch and plug-in pad/amp units installed and adjusted. Then, on a commercial turn up (back when I did these, it was Western Union and/or MCI), the tech at the other end would again dialup the milliwatt, report the value measured over the loop and the pad(s) re-adjusted to match the values for the loss in a document provided. We spent a lot of time talking to telco guys who called down to the frames to get a shoe put up in the frame so they could take their own measurements. Watching telco field techs today, they still seems to do it a lot the same way. I gues the exact equipment has changed, but the process still seems similar. If we were dependant on only the length and gauge of wire, as it was 70 years ago, that would be that. As it is, there are all sort of gadgets they stick into pots loops. There used to be a device designated VRMN; called vermin because that what we thought of them. I never saw one physically, I only saw the effects of them. They were two wite, bi-directional gain devices and when they went out of whack they did totally insidious things to pots loops... Vermin! Anyway, this is getting long. ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
On Fri, Aug 26, 2005 at 02:00:54PM -0600, Rich Adamson wrote: Relative to the fxotune app, it would appear the app is specific to the v2.4 kernels (/dev/zap*), which the v2.6 kernels don't use It should with 2.4 and 2.6. 2.6 kernels with properly configured udev rules should create the /dev/zap/* entries dynamically. (but rather the udev equivalent). (When I had * running on a v2.4 kernel, the output from fxotune never deviated from all zero's. So I'm assuming the default chipset values were already tweaked by the chipset manufacturer to US telco lines. If that is true, then running fxotune in the US has very little value.) Sometimes in the US you still deal with line impedance issues. In fact, I was told by an engineer that worked for the company that designs the line interface part that the bulk of echo problems (with line interface parts such as this) are related to AC impedance mismatches (which is one reason why I haven't done the digital hybrid tuning portion of fxotune still). It should work the same regardless of which kernel (2.4 or 2.6) you are using. If it doesn't, and you have udev setup correctly, something is fundamentally wrong in the setup. Matt, To bring closure (and for archive purposes), the changes that you submitted to cvs-head around noon today (8/26/05) did correct the issue with running fxotune on FC3 (v2.6 kernel). Since the values written to the /etc/fxotune.conf file were identical (and the file datestamp matched the individual runs of fxotune), I'll assume the error messages that I seen yesterday were cosmetic and not real. As mentioned in my last private email, all four analog pstn lines attached to my TDM04b have been tested with a professional transmission test set and all four are in excellent condition. Fxotune did not generate any noticable differences to my ear. I'm only mentioning that for those readers that might expect something different to happen and don't notice any changes/improvements on US pstn lines. Rich ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
Bruce Ferrell wrote: Then, on a commercial turn up (back when I did these, it was Western Union and/or MCI), the tech at the other end would again dialup the milliwatt, report the value measured over the loop and the pad(s) re-adjusted to match the values for the loss in a document provided. That is the device called that would measure the milliwatt db loss when plugged into an analog port and dialed into a milliwatt line? ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
On Friday 26 August 2005 18:14, Rich Adamson wrote: As mentioned in my last private email, all four analog pstn lines attached to my TDM04b have been tested with a professional transmission test set and all four are in excellent condition. Fxotune did not generate any noticable differences to my ear. I'm only mentioning that for those readers that might expect something different to happen and don't notice any changes/improvements on US pstn lines. Can you elaborate on the specific issues you're having? It's nice to be able to talk to someone who's got experience in telco and also computing (and CTI too) to get to the heart of some of these issues. Specifically, have you tried the KB1 echo canceller? What about enabling MMX (if you're on intel), enabling/uncommenting the CALC_XLAW #define and compiling zaptel with KFLAGS+=-march=pentium4 (or whatever) and CFLAGS+=-march=pentium4 (or whatever) in your zaptel Makefile just underneath the comments regarding everything being done in zconfig.h. I'm *really* interested in hearing what your findings are. -A. ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
Is it practical to 'assume' that in your case mentioned above that #1 is not going to occur again (since I assume when you say 'line' you are referring to an outside pstn line), and, #2 is in a mode of fine-tuning the training when in fact you'd really like it to start the coarse-training from scratch? Thanks Rich for the comments. Obviously you got my point. And I was hoping that it is possible somehow to do #1 (coarse-training from scratch) after a PSTN line is transfered to another phone or something very important changes about a call. But considering how complicated a situation this might be (there is music on hold to say the least, or perhaps the transferee may reject the call and the call returns to the operator [in which case you wouldn't want #1], etc.) I guess this is not a simple task. Anyway, I'll keep on watching for a solution. Soner ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
Eric Wieling aka ManxPower wrote: Bruce Ferrell wrote: Then, on a commercial turn up (back when I did these, it was Western Union and/or MCI), the tech at the other end would again dialup the milliwatt, report the value measured over the loop and the pad(s) re-adjusted to match the values for the loss in a document provided. That is the device called that would measure the milliwatt db loss when plugged into an analog port and dialed into a milliwatt line? The device was a TMS or tims... Transmission Measurement Set. We basicly used the same gear at either end ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
The -2 to -3 db is not correct for analog circuits. Copper wires have a loss that is directly related to the length of the cable. (I don't have the chart right here, but a 7,000 foot cable pair will have lets say 6db of loss and a 3,000 foot pair will be a 3db loss. You can't engineer something into a copper pair to compensate for that loss.) The only thing that I can think of that you might be talking about is using an old analog carrier system on a copper pair. If that's what you're thinking, then yes -2 to -3 db is very reasonable. Analog carrier was(is?) engineered for -16/+7 tx/rx TLP. That was because microwave links liked it that way and it kept spurious emmisions down. No, -16/+7 is associated with setting up analog Toll and CO-to-CO trunks, not pbx trunks. What can be engineered into a loop is an odd little device called a pad. Most often today they're found in the channel module in a channel bank coming off of a digital switch. The milliwatt are accessed right at the card and measured. the pad(s) on the card are adjusted for the calculated values. Analog switches were similar in that banks of pad sockets were wired to the ports on the switch and plug-in pad/amp units installed and adjusted. Okay, now I understand how this got way off into incorrect gain settings. The OP was talking about pure copper analog wires from the Central Office to the client's pbx. No carrier involved, no pads, no repeaters, no amplifiers, no microwave, no nothing. Purely a pair of copper wires terminated in a TDM04b card from the CO. Given that, the entire discussion of undertanding/measuring the loop loss and setting the rxgain and txgain to about 2 or 3 db below that _is_ the realistic starting point. Then adjust those same gain settings to balance the echo with lack of volume (for the TDM and X100P cards). So, for those not understanding the above: - dial into the central office milliwatt generator and using a transmission test set (lots of them available), measure the cable loss. Can be anywhere from -1 or 2 db up to more then 12 db. - set the rxgain and txgain to about 2db less. (If the loss is measured at -8db, set the gain at +6db.) - make test calls to another local CO telephone number and eval the echo and audio levels. (Stop and Start * after each change as a reload won't cut it. The gain settings should be reduced by 1 or 2 db for each test call.) - Repeat the manual calls and eval until some reasonable balance is achieved. (ztmonitor won't help at all.) - Repeat the last two steps for a LD call to ensure gain settings are reasonable. Again, the above is oriented to copper pstn circuits from the CO to the TDM card. If the combination is other then a TDM or X100P card (eg, SIP gateway with an echo canceler), then there isn't any need for mucking around with the gain settings manually. Just set the gain in whatever external gateway device one is using to about 1 or 2 db less then the cable loss and use it. ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
On Friday 26 August 2005 18:14, Rich Adamson wrote: As mentioned in my last private email, all four analog pstn lines attached to my TDM04b have been tested with a professional transmission test set and all four are in excellent condition. Fxotune did not generate any noticable differences to my ear. I'm only mentioning that for those readers that might expect something different to happen and don't notice any changes/improvements on US pstn lines. Can you elaborate on the specific issues you're having? It's nice to be able to talk to someone who's got experience in telco and also computing (and CTI too) to get to the heart of some of these issues. I'm the one that opened bug 2022 and 2023 some time ago involving low audio on VM when using either the TDM or X100P card. After doing extensive testing, I also found that setting the rx/tx gains were no where near realistic from a telephony perspective (eg, balancing levels and echo), and no where near competing external gateway devices. Specifically, have you tried the KB1 echo canceller? What about enabling MMX (if you're on intel), enabling/uncommenting the CALC_XLAW #define and compiling zaptel with Yes the KB1 as of today, and its good. Tried all of those other items over the last two years, and worked with Mark to implement some of the stuff that's there today (eg, echotraining=800). You'll also find my postings related to the zttest and trying to identify some of the pci (and/or interrupt latency) issues that cause spandsp to fail (95% of the time) with the TDM card. Think Kevin/digium may have some resources poking at the pci stuff. KFLAGS+=-march=pentium4 (or whatever) and CFLAGS+=-march=pentium4 (or whatever) in your zaptel Makefile just underneath the comments regarding everything being done in zconfig.h. I'm *really* interested in hearing what your findings are. Any experience with how those flags might impact spandsp with the TDM? My interest in TDM/echo postings is to help identify why the TDM card (and older X100P card) are so unrealistic in the telephony standards world. Just about everything that one does with those two cards have major exceptions in telephony, and I'm a rather firm believer those exceptions can be corrected. It just so happens that spandsp is an excellent tool to help point out those exceptions. (I don't actually need spandsp any more since converting to a commercial fax service.) I've had a pair of digium x100p's for two years and a TDM04b a week or two before it was annouced. The original TDM has since been replaced with a rev H card, which is now stable, but stil has those other nagging issues that we all seen posted in the last 12 months or so. The TDM is in use on a production server and levels/echo are 'acceptable' but can use some serious improvements. Hoping to help make the TDM an even better card (and not rag on digium). Its heading in that direction and there are some specialists truly focusing on it now. :) As mentioned in several previous postings, the level/echo issues are far more negative for those using asterisk a greater distance from the CO then what other implementations are that are very close to the CO. That's one of the reasons why there is such a hugh difference in what folks see with that card. (Its almost like bits 5 6 are miswired (reversed) on the card's digital audio path to (or in) the TigerJet chip.) I had signed up to teach a basic telephony class (to cover all of this telephony interfacing stuff) at the first Astricon in Atlanta, but cancelled out since there were so many different problems with these cards. (It wouldn't do much good to teach a class on how to do this only to say 'well, it doesn't work that way in asterisk'.) ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
You did not specify anything about your network. If your network has a big latency, echo cancellers can get into trouble. For instance, I have echo problems just using wireless POTS phones on my sipura 2100 sip adapter/router on an otherwise unused 8Mbps ADSL internet connection at home. Lars Dybdahl. On 8/24/05, canuck15 [EMAIL PROTECTED] wrote: My problem is that I cannot eliminate echo no matter what I try. ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
First off, thank you *very* much for this unbelievably informative post! I've got it saved away now along with Kris Boutilier's adjusting rxgain/txgain post. On Wednesday 24 August 2005 17:14, Bruce Ferrell wrote: At the point where the phone line get's to your demarc the is supposed to ba a -2 to 3db reference point, sometimes called a -2 or -3 test level point (TLP). So that milliwatt tone at that point should read in the range of -2 to -3 dbm. If I read the above words exactly as written, the above is not true. Maybe there was a different intent that I'm missing, or, maybe words left out? I'm reading the words to say if I put a transmission test set on the cable pair just before the pair leaves the central office, the reading should be in the -2 to -3 dbm range. If that is what you meant, then its incorrect. Even the old analog step-by-step switch specs called for no more then .5db loss from the milliwatt generator to the cable pair (CO distribution frame). If you mean placing a transmission test set at the customer's demarc (at the customer's site), the -2 to -3 db is still incorrect for analog pstn circuits. That level _will be_ the 0db generator tone minus the cable loss from the CO to the customer's demarc. That cable loss is 100% predictable if you know the length and gauge of the copper wires between the central office and the customer's site. (That is exactly how the engineering spec is set for the less technical telephone installers to measure after installing a new pstn facility to a customer site.) If you are referring to a Remote Line Module (where CO lines are extended into a neighborhood using fiber, T1's, or whatever) and placing a transmission test set on the customer's cable pair as it leaves that remote module, then the -2 to -3 dbm range is correct at the remote module. It is not correct at the customer's demarc as you still have the physical copper loss from the module to the customer's site. That loss is still 100% dependent on the length and gauge of the copper cable to the customer's demarc. If you are referring to a customer site that is 100% digital (eg, T1, fiber) from the CO to the customer site demarc, then your words are correct. But, the customer probably wouldn't be using an analog asterisk interface if they had a clue. FWIW, the majority of the larger telco's now store a variable in the customer's online record that represents the length of copper cable from the customer's physical address to the CO (or remote line module). That length is used by less technical types to predict whether DSL can be supported, and, is translated into an expected loss value that is given to the installer (on their service order). That expected loss value becomes the boggy for the installer to determine whether the completed installation meets company standards. Any deviation of that value is suppose to be reported as trouble and resolved before the service order is completed. Ok so since -3dB is 1/2 power we should be expecting a reading of 7422 in ztmonitor if it's a linear reading of the signal. If the milliwatt is arriving at the demarc at the nominal -2 to -3dbm and getting into the asterisk to be measured at 8dBm (+8dbm0), I'd say something is grossly mal-adjusted. You're seeing 8db of gain! Agreed, regardless of what type of facility exists between the CO and the customer's site. No, he was saying he had to set his rxgain to 8 in order to get a level of 14844 (0dBm) in ztmonitor. Right, and if we knew the gauge of copper used to that customer's site, we could calculate exactly how many feet of copper exists between the customer and the CO (or remote module). An 8db loss is very very common, and even 12 db of loss is acceptable by some telco's to distant customers. FWIW, those individuals that are responsible for planning the location of a new central office or remote line module use programs that calculate the copper loss from several potential sites to each potential customer. Sort of like drawing a circle around a potential module location and asking the question how many customer sites can be reached that are within 12 dbm of that module location? (Substitute some realistic engineering value for the 12db.) Part of that planning process actually involves playing what-if games with things like: 1) if I use 26 gauge cable to every customer from that potential site, what is the total cost of deploying a remote module? 2) if I use 19 gauge copper, what's the total cost? (19 gauge copper has a much lower transmission loss then does 26 gauge, and can reach more customers. However, the cost of 19 gauge copper is much greater then 26 gauge so some sort of economic trade off is obvious.) I fully understand the TLP point referenced in the post, but the words that were used is going to lead other readers to an incorrect conclusion. The echo cancellation problem with the x100p and TDM cards are very much related to the narrow operating
Re: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
On Thursday 25 August 2005 08:00, Rich Adamson wrote: If you mean placing a transmission test set at the customer's demarc (at the customer's site), the -2 to -3 db is still incorrect for analog pstn circuits. That level _will be_ the 0db generator tone minus the cable loss from the CO to the customer's demarc. That cable loss is 100% predictable if you know the length and gauge of the copper wires between the central office and the customer's site. (That is exactly how the engineering spec is set for the less technical telephone installers to measure after installing a new pstn facility to a customer site.) Ok... The echo cancellation problem with the x100p and TDM cards are very much related to the narrow operating range that the existing echo cancellation software can operate within. In the above 8 db loss example (assuming there is an actual 8 db of copper loss between the CO and the customer's site), the _correct_ rxgain and txgain settings would be to provide approximately +6 dbm of gain within asterisk/zaptel. Those gain settings would fall within the stated -2 to -3 db TLP range. However, that 6db of gain (in both directions) will fall outside the operating range of the existing echo canceller, therefore smaller gain values are almost always required in asterisk. It doesn't make any difference whether the transmission level is measured with ztmonitor or a $10k transmission test set. Neither will make it work right. Now I'm confused. In the first quoted paragraph you seem to be saying that I should tune the rxgain in order to achieve a perceived 0dBm by Asterisk. (14844 in ztmonitor.) But then in the paragraph quoted above you're saying that a reading of 7422 (-3dBm if ztmonitor's output is linear-reading) to 14844 is acceptable. I'm reading it as if it takes an rxgain of +8 to get a 0dBm level in ztmonitor, you should tune rxgain to provide 6dBm of gain in order to fall within the -2dB to -3dB range. Am I misreading? I was under the impression that the echo canceller worked with whatever came out of the zaptel driver *after* the rxgain was applied and *before* the txgain was applied. This would mean that your rxgain setting to achieve -2dB to -3dB TPM would certainly fall within what the echo canceller was designed to expect on its input, and that the echo canceller assumes that it's output is at 0dBm, so whatever it sent out would be corrected to 0dBm by the transmit amp stage of the zaptel driver. of reflected energy (latency), etc. The companies that engineer dedicated echo cancellers can throw processing power at the problem or use dedicated chips (DSP's) to do that function. Not likely asterisk's canceller will ever be equivalent to dedicated hardware cancellers. (And, why does the new digium T1 card have it on board?) You just described why; it's an enormously complex problem that takes lots of CPU time. By putting it in hardware before the PCI bus access you eliminate a lot of the variables that doing it on the host CPU introduce. One other point that may not be obvious from previous echo postings. Those asterisk users that are physically located a greater distance from the CO _always_ have greater echo issues. Those that are relatively close don't have as big an issue. That _is_ due to the small operating range of asterisk's echo canceller. And, that is _one_ of the reasons why one implementor's settings don't work at another implementor's location. (Not to mention differences in motherboards, etc, etc.) Agreed. -A. ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
On Thursday 25 August 2005 08:00, Rich Adamson wrote: If you mean placing a transmission test set at the customer's demarc (at the customer's site), the -2 to -3 db is still incorrect for analog pstn circuits. That level _will be_ the 0db generator tone minus the cable loss from the CO to the customer's demarc. That cable loss is 100% predictable if you know the length and gauge of the copper wires between the central office and the customer's site. (That is exactly how the engineering spec is set for the less technical telephone installers to measure after installing a new pstn facility to a customer site.) Ok... The echo cancellation problem with the x100p and TDM cards are very much related to the narrow operating range that the existing echo cancellation software can operate within. In the above 8 db loss example (assuming there is an actual 8 db of copper loss between the CO and the customer's site), the _correct_ rxgain and txgain settings would be to provide approximately +6 dbm of gain within asterisk/zaptel. Those gain settings would fall within the stated -2 to -3 db TLP range. However, that 6db of gain (in both directions) will fall outside the operating range of the existing echo canceller, therefore smaller gain values are almost always required in asterisk. It doesn't make any difference whether the transmission level is measured with ztmonitor or a $10k transmission test set. Neither will make it work right. Now I'm confused. In the first quoted paragraph you seem to be saying that I should tune the rxgain in order to achieve a perceived 0dBm by Asterisk. (14844 in ztmonitor.) But then in the paragraph quoted above you're saying that a reading of 7422 (-3dBm if ztmonitor's output is linear-reading) to 14844 is acceptable. I'm reading it as if it takes an rxgain of +8 to get a 0dBm level in ztmonitor, you should tune rxgain to provide 6dBm of gain in order to fall within the -2dB to -3dB range. Am I misreading? I was under the impression that the echo canceller worked with whatever came out of the zaptel driver *after* the rxgain was applied and *before* the txgain was applied. This would mean that your rxgain setting to achieve -2dB to -3dB TPM would certainly fall within what the echo canceller was designed to expect on its input, and that the echo canceller assumes that it's output is at 0dBm, so whatever it sent out would be corrected to 0dBm by the transmit amp stage of the zaptel driver. of reflected energy (latency), etc. The companies that engineer dedicated echo cancellers can throw processing power at the problem or use dedicated chips (DSP's) to do that function. Not likely asterisk's canceller will ever be equivalent to dedicated hardware cancellers. (And, why does the new digium T1 card have it on board?) You just described why; it's an enormously complex problem that takes lots of CPU time. By putting it in hardware before the PCI bus access you eliminate a lot of the variables that doing it on the host CPU introduce. One other point that may not be obvious from previous echo postings. Those asterisk users that are physically located a greater distance from the CO _always_ have greater echo issues. Those that are relatively close don't have as big an issue. That _is_ due to the small operating range of asterisk's echo canceller. And, that is _one_ of the reasons why one implementor's settings don't work at another implementor's location. (Not to mention differences in motherboards, etc, etc.) Agreed. Let's see if I can clearify all of the above a little. Two different examples #1: audio signal from an internal asterisk source (eg, sip phone) passing to an outbound analog pstn facility. It _is_ normal practice to set both rxgain and txgain to the exact same value in non-asterisk telephony terms, and that value is typically about 2db less then the loss that you're trying to overcome. The closer you try to set those gains to no loss (eg, 8db of gain to compensate for 8db of cable loss), the higher the probability of creating an unwanted audio feedback loop that _could_ create a hawl, echo, or other unwanted sounds. Its common practice to set the gains to 2-3db below that level. Using an audio tone for this example, a 0db tone would be amplified by the 6db gain (txgain) to hit the rj11 jack of the pstn interface. As the signal passes through the cable pair to the CO, the cable loss reduces the audio to -2db at the CO (effectively at the TPL). However, as that audio passes through the TDM card to the rj11 (and pstn copper), some level of energy is always reflected back to the receive side of the TDM card. The larger the outbound signal, generally the larger the inbound energy. (Some of that is the result of an imperfect hybrid on the TDM card, some from mismatched impedance (there is always some at different frequencies), some from the
Re: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
Ok, fxotune is a work in progress so to speak. I fixed something in it about a week ago that may help it adjust to the line better (whereas before I'm not sure that it was at all). Try the latest CVS-HEAD version of fxotune as your first step. (oh, after you use fxotune you should turn off your gain settings in zapata.conf). Matt, When I run fxotune on a FC3 box, I get: ./fxotune -i 4 [EMAIL PROTECTED] zaptel]# ./fxotune -i 4 Tuning module 1Failure! Tuning module 2Failure! Tuning module 3Failure! Tuning module 4Failure! /dev/zap/5 absent: No such file or directory /dev/zap/6 absent: No such file or directory /dev/zap/7 absent: No such file or directory /dev/a-bunch more... Contents of /etc/fxotune.conf 1=4,0,0,0,0,0,0,0,0 2=8,0,0,0,0,0,0,0,0 3=8,0,0,0,0,0,0,0,0 4=8,0,0,0,0,0,0,0,0 That's with a TDM04B rev H card installed that's working, and * stopped. What's need to make this work on FC3 with udev (no /dev/zap)? Rich ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
what kernel are you running ? On Thu, 2005-08-25 at 17:01, Rich Adamson wrote: Ok, fxotune is a work in progress so to speak. I fixed something in it about a week ago that may help it adjust to the line better (whereas before I'm not sure that it was at all). Try the latest CVS-HEAD version of fxotune as your first step. (oh, after you use fxotune you should turn off your gain settings in zapata.conf). Matt, When I run fxotune on a FC3 box, I get: ./fxotune -i 4 [EMAIL PROTECTED] zaptel]# ./fxotune -i 4 Tuning module 1Failure! Tuning module 2Failure! Tuning module 3Failure! Tuning module 4Failure! /dev/zap/5 absent: No such file or directory /dev/zap/6 absent: No such file or directory /dev/zap/7 absent: No such file or directory /dev/a-bunch more... Contents of /etc/fxotune.conf 1=4,0,0,0,0,0,0,0,0 2=8,0,0,0,0,0,0,0,0 3=8,0,0,0,0,0,0,0,0 4=8,0,0,0,0,0,0,0,0 That's with a TDM04B rev H card installed that's working, and * stopped. What's need to make this work on FC3 with udev (no /dev/zap)? Rich ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users -- -BEGIN GEEK CODE BLOCK- Version: 3.1 GCS/GIT d-@ s+:+ a? C+++ BLHIS$ U+++ P+ L+++ !E W+++$ N++ o+ K w-- PS+++ PE@ Y+ PGP++ t 5? X !R tv+ b- DI-- D G e+ h r+++ y --END GEEK CODE BLOCK-- signature.asc Description: This is a digitally signed message part ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
I'll do my comments in line and hope I don't offend. Rich Adamson wrote: First off, thank you *very* much for this unbelievably informative post! I've got it saved away now along with Kris Boutilier's adjusting rxgain/txgain post. On Wednesday 24 August 2005 17:14, Bruce Ferrell wrote: At the point where the phone line get's to your demarc the is supposed to ba a -2 to 3db reference point, sometimes called a -2 or -3 test level point (TLP). So that milliwatt tone at that point should read in the range of -2 to -3 dbm. If I read the above words exactly as written, the above is not true. Maybe there was a different intent that I'm missing, or, maybe words left out? I'm a lousy typist :) I'm reading the words to say if I put a transmission test set on the cable pair just before the pair leaves the central office, the reading should be in the -2 to -3 dbm range. If that is what you meant, then its incorrect. Even the old analog step-by-step switch specs called for no more then .5db loss from the milliwatt generator to the cable pair (CO distribution frame). If you mean placing a transmission test set at the customer's demarc (at the customer's site), the -2 to -3 db is still incorrect for analog pstn circuits. That level _will be_ the 0db generator tone minus the cable loss from the CO to the customer's demarc. That cable loss is 100% predictable if you know the length and gauge of the copper wires between the central office and the customer's site. (That is exactly how the engineering spec is set for the less technical telephone installers to measure after installing a new pstn facility to a customer site.) at the last point leaving the CO, the tone level should be a nominal 0dbm. By the time it get's to the customer demarc, -2 to -3 dbm. The loops are suppposed to be engineered that way. On a brand spanky new loop, yes 100% predictable. Over time, all sorts of oddities (corrosion, half taps, loading coils, and just general funkieness) are introduced in the real world. If you are referring to a Remote Line Module (where CO lines are extended into a neighborhood using fiber, T1's, or whatever) and placing a transmission test set on the customer's cable pair as it leaves that remote module, then the -2 to -3 dbm range is correct at the remote module. It is not correct at the customer's demarc as you still have the physical copper loss from the module to the customer's site. That loss is still 100% dependent on the length and gauge of the copper cable to the customer's demarc. If you are referring to a customer site that is 100% digital (eg, T1, fiber) from the CO to the customer site demarc, then your words are correct. But, the customer probably wouldn't be using an analog asterisk interface if they had a clue. Can't argue that. FWIW, the majority of the larger telco's now store a variable in the customer's online record that represents the length of copper cable from the customer's physical address to the CO (or remote line module). That length is used by less technical types to predict whether DSL can be supported, and, is translated into an expected loss value that is given to the installer (on their service order). That expected loss value becomes the boggy for the installer to determine whether the completed installation meets company standards. Any deviation of that value is suppose to be reported as trouble and resolved before the service order is completed. We were supposed to too back when I did this, but if it meant delaying an order... we tended to just take the pair and note it. Ok so since -3dB is 1/2 power we should be expecting a reading of 7422 in ztmonitor if it's a linear reading of the signal. If the milliwatt is arriving at the demarc at the nominal -2 to -3dbm and getting into the asterisk to be measured at 8dBm (+8dbm0), I'd say something is grossly mal-adjusted. You're seeing 8db of gain! Agreed, regardless of what type of facility exists between the CO and the customer's site. No, he was saying he had to set his rxgain to 8 in order to get a level of 14844 (0dBm) in ztmonitor. Ahhh OK a dimensionless number 8. not a reading of 8dbm. Right, and if we knew the gauge of copper used to that customer's site, we could calculate exactly how many feet of copper exists between the customer and the CO (or remote module). An 8db loss is very very common, and even 12 db of loss is acceptable by some telco's to distant customers. FWIW, those individuals that are responsible for planning the location of a new central office or remote line module use programs that calculate the copper loss from several potential sites to each potential customer. Sort of like drawing a circle around a potential module location and asking the question how many customer sites can be reached that are within 12 dbm of that module location? (Substitute some realistic engineering value for the 12db.) Part of that planning process actually involves
Re: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
and just for REALLY bad form, responding to my own post with a postscript: I had to have a lot of pictures drawn for me when I was learning this 20 years ago :) Bruce Ferrell wrote: I'll do my comments in line and hope I don't offend. Rich Adamson wrote: First off, thank you *very* much for this unbelievably informative post! I've got it saved away now along with Kris Boutilier's adjusting rxgain/txgain post. On Wednesday 24 August 2005 17:14, Bruce Ferrell wrote: At the point where the phone line get's to your demarc the is supposed to ba a -2 to 3db reference point, sometimes called a -2 or -3 test level point (TLP). So that milliwatt tone at that point should read in the range of -2 to -3 dbm. If I read the above words exactly as written, the above is not true. Maybe there was a different intent that I'm missing, or, maybe words left out? I'm a lousy typist :) I'm reading the words to say if I put a transmission test set on the cable pair just before the pair leaves the central office, the reading should be in the -2 to -3 dbm range. If that is what you meant, then its incorrect. Even the old analog step-by-step switch specs called for no more then .5db loss from the milliwatt generator to the cable pair (CO distribution frame). If you mean placing a transmission test set at the customer's demarc (at the customer's site), the -2 to -3 db is still incorrect for analog pstn circuits. That level _will be_ the 0db generator tone minus the cable loss from the CO to the customer's demarc. That cable loss is 100% predictable if you know the length and gauge of the copper wires between the central office and the customer's site. (That is exactly how the engineering spec is set for the less technical telephone installers to measure after installing a new pstn facility to a customer site.) at the last point leaving the CO, the tone level should be a nominal 0dbm. By the time it get's to the customer demarc, -2 to -3 dbm. The loops are suppposed to be engineered that way. On a brand spanky new loop, yes 100% predictable. Over time, all sorts of oddities (corrosion, half taps, loading coils, and just general funkieness) are introduced in the real world. If you are referring to a Remote Line Module (where CO lines are extended into a neighborhood using fiber, T1's, or whatever) and placing a transmission test set on the customer's cable pair as it leaves that remote module, then the -2 to -3 dbm range is correct at the remote module. It is not correct at the customer's demarc as you still have the physical copper loss from the module to the customer's site. That loss is still 100% dependent on the length and gauge of the copper cable to the customer's demarc. If you are referring to a customer site that is 100% digital (eg, T1, fiber) from the CO to the customer site demarc, then your words are correct. But, the customer probably wouldn't be using an analog asterisk interface if they had a clue. Can't argue that. FWIW, the majority of the larger telco's now store a variable in the customer's online record that represents the length of copper cable from the customer's physical address to the CO (or remote line module). That length is used by less technical types to predict whether DSL can be supported, and, is translated into an expected loss value that is given to the installer (on their service order). That expected loss value becomes the boggy for the installer to determine whether the completed installation meets company standards. Any deviation of that value is suppose to be reported as trouble and resolved before the service order is completed. We were supposed to too back when I did this, but if it meant delaying an order... we tended to just take the pair and note it. Ok so since -3dB is 1/2 power we should be expecting a reading of 7422 in ztmonitor if it's a linear reading of the signal. If the milliwatt is arriving at the demarc at the nominal -2 to -3dbm and getting into the asterisk to be measured at 8dBm (+8dbm0), I'd say something is grossly mal-adjusted. You're seeing 8db of gain! Agreed, regardless of what type of facility exists between the CO and the customer's site. No, he was saying he had to set his rxgain to 8 in order to get a level of 14844 (0dBm) in ztmonitor. Ahhh OK a dimensionless number 8. not a reading of 8dbm. Right, and if we knew the gauge of copper used to that customer's site, we could calculate exactly how many feet of copper exists between the customer and the CO (or remote module). An 8db loss is very very common, and even 12 db of loss is acceptable by some telco's to distant customers. FWIW, those individuals that are responsible for planning the location of a new central office or remote line module use programs that calculate the copper loss from several potential sites to each potential customer. Sort of like drawing a circle around a potential module location and asking the
Re: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
I'm running 2.6.9-1.667 (with udev as mentioned in the original post). what kernel are you running ? On Thu, 2005-08-25 at 17:01, Rich Adamson wrote: Ok, fxotune is a work in progress so to speak. I fixed something in it about a week ago that may help it adjust to the line better (whereas before I'm not sure that it was at all). Try the latest CVS-HEAD version of fxotune as your first step. (oh, after you use fxotune you should turn off your gain settings in zapata.conf). Matt, When I run fxotune on a FC3 box, I get: ./fxotune -i 4 [EMAIL PROTECTED] zaptel]# ./fxotune -i 4 Tuning module 1Failure! Tuning module 2Failure! Tuning module 3Failure! Tuning module 4Failure! /dev/zap/5 absent: No such file or directory /dev/zap/6 absent: No such file or directory /dev/zap/7 absent: No such file or directory /dev/a-bunch more... Contents of /etc/fxotune.conf 1=4,0,0,0,0,0,0,0,0 2=8,0,0,0,0,0,0,0,0 3=8,0,0,0,0,0,0,0,0 4=8,0,0,0,0,0,0,0,0 That's with a TDM04B rev H card installed that's working, and * stopped. What's need to make this work on FC3 with udev (no /dev/zap)? Rich ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
I'll do my comments in line and hope I don't offend. Rich Adamson wrote: First off, thank you *very* much for this unbelievably informative post! I've got it saved away now along with Kris Boutilier's adjusting rxgain/txgain post. On Wednesday 24 August 2005 17:14, Bruce Ferrell wrote: At the point where the phone line get's to your demarc the is supposed to ba a -2 to 3db reference point, sometimes called a -2 or -3 test level point (TLP). So that milliwatt tone at that point should read in the range of -2 to -3 dbm. If I read the above words exactly as written, the above is not true. Maybe there was a different intent that I'm missing, or, maybe words left out? I'm a lousy typist :) I'm reading the words to say if I put a transmission test set on the cable pair just before the pair leaves the central office, the reading should be in the -2 to -3 dbm range. If that is what you meant, then its incorrect. Even the old analog step-by-step switch specs called for no more then .5db loss from the milliwatt generator to the cable pair (CO distribution frame). If you mean placing a transmission test set at the customer's demarc (at the customer's site), the -2 to -3 db is still incorrect for analog pstn circuits. That level _will be_ the 0db generator tone minus the cable loss from the CO to the customer's demarc. That cable loss is 100% predictable if you know the length and gauge of the copper wires between the central office and the customer's site. (That is exactly how the engineering spec is set for the less technical telephone installers to measure after installing a new pstn facility to a customer site.) at the last point leaving the CO, the tone level should be a nominal 0dbm. By the time it get's to the customer demarc, -2 to -3 dbm. The loops are suppposed to be engineered that way. On a brand spanky new loop, yes 100% predictable. Over time, all sorts of oddities (corrosion, half taps, loading coils, and just general funkieness) are introduced in the real world. The -2 to -3 db is not correct for analog circuits. Copper wires have a loss that is directly related to the length of the cable. (I don't have the chart right here, but a 7,000 foot cable pair will have lets say 6db of loss and a 3,000 foot pair will be a 3db loss. You can't engineer something into a copper pair to compensate for that loss.) The only thing that I can think of that you might be talking about is using an old analog carrier system on a copper pair. If that's what you're thinking, then yes -2 to -3 db is very reasonable. ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
On Wednesday 24 August 2005 16:37, canuck15 wrote: As others have recommended, I created a test system with the proposed production parts. I bought a couple different SIP phones to try and a Digium TDM01B card. I am using an older PIII 1Ghz system with 815chipset (PCI Rev2.2) with 256MB for my test system. The only thing that will be different on a production system is that I will be using a newer chipset PC with faster processor and 512MB. Probably Intel 7505, 7210, or 7211 chipsets which seem to be the most compatible with Asterisk. So in other words, everything will be changing on your production system. Not a good way to start. My problem is that I cannot eliminate echo no matter what I try. I seriously doubt that a newer chipset faster PC with more memory will eliminate or even reduce my echo problems based on what I have read. I am not about to drop more cash to try and find out. Essentially, my findings are that Asterisk is NOT production capable for my configuration which is via FXO and PSTN. That is probably THE most common configuration so if it is not production capable like that it isn't production capable period as far as I'm concerned. What a disappointment :(. Most of us don't have any trouble. *Buy latest TDM400P with latest FXO module *Ensure copper connection to analog telco lines and telco are not causing problems including running a separate shielded line to the demarc AND having the telco guy come out and test the levels, impedance etc. I'd be damn curious to know what you got out of this -- most telco guys will do a basic metallic check, throw on a butt-set and say yup, I got dialtone. -- hardly a real check but that's neither here nor there. I'm also in Canada (1.5hrs from Toronto, ON) so I'm *really* curious who you got on the line to do a real line test with you. I have resorted to buying my own telco test equipment off ebay and using that, even though our techs here are excellent. *Adjust RX/TX levels as per Asterisk Wiki using the quick Ztmonitor method and by using the detailed Ztmonitor method via a Telco 102milliwatt test phone #. The end result was RX=8.0, TX=-1.0. Since I still have echo problems I have tried all sort of other settings without success. Ok good. Can you detail exactly what you did to reach these numbers? I'm curious. *After ALL of the above, try every possible combination of all of the following on Asterisk v1.0.9: echocancel (off, on, 128, 256, 16, 32, 64), echowhenbridged (on, off), echotraining (off, on, 800), Mark 2 (default, aggressive, CVS head developments, bugs.digium.com patches, adjust threshold level as per wiki etc. etc.) I'd posted something earlier that basically says this: Without measured, controlled tests, you're just pissing up a rope. Wildly changing settings and hoping for the best does nothing but cost you time and energy. *Run fxotune which did not find a need to adjust the FXO levels (1=0,0,0,0,0,0,0,0) fxotune doesn't adjust FXO levels, it adjusts a very simple FIR filter which is part of the DAA in the FXO module. IMO it helps with audio quality but not much with echo. Still have echo. Aggressive mode helps a bit but then the other persons voice get's cut off a lot especially when I talk and the cutting in and out of the canceller is more noticeable and objectionable in general than if Aggressive is turned off. Agressive mode turns the phone line into a half-duplex environment. When your voice energy is detected it mutes the receive audio. I have two SIP phones. An Aastra 9133i and a Grandstream GXP2000. Echo problem is the same on both phones. Do you have echo between the two phones? What about when calling out to a VOIP provider, dialing a DID you own that comes back in and hits the other phone? Any comments and/or suggestions would be greatly appreciated as I am pretty much out of ideas and ready to give up on Asterisk as a suitable traditional small business phone system replacement. I haven't seen your zconfig.h nor your zaptel Makefile, and you didn't tell us anything about your network (network card, switch, etc.). My general advice for zaptel is to do the following: zaptel Makefile: underneath the comments about zconfig.h add KFLAGS+=-march=pentium4 (or pentium3 or pentiumpro, use the exact proc) CFLAGS+=-march=pentium4 (or pentium3 or pentiumpro, use the exact proc) and in zconfig.h - enable XLAW (optimize for small # of zap channels) - enable MMX - MARK2, no agressive mode. Whenever I've done that my echo has largely disappeared. Have you also tried flipping tip and ring going into the TDM card? -A. ___ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
RE: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
Just because you cannot get it to work does not mean that IT does not work. Just using the right motherboard is not enough. Did you check for IRQ problems? You don't mention whether you have checked for this. Look for a thread called "Asterisk-Users Small office setupusing analog lines w Asterisk" in the archive via Google. use site:lists.digium.com Try all the things listed in that thread. Do you have a network that is capable of VoIP? Are you using hubs when you should be using switches? There is a major difference and hubs WILL NOT work reliably with VoIP. Are you using QoS on your switches if you have lots of network traffic? If you are using your own Distro and installing from scratch, try to use Asterisk at Home just to see if you still have the same problem. I am putting my money on an IRQ issue myself. W From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of canuck15Sent: Wednesday, August 24, 2005 1:38 PMTo: asterisk-users@lists.digium.comSubject: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared I came into this with my eyes wide open. I have read ABSOLUTELY EVERYTHING there is to be found on the net about avoiding echo problems BEFORE I even attempted to create a production system. Since lots of people are apparently using this in production environments now I just assumed that echo IS avoidable. As others have recommended, I created a test system with the proposed production parts. I bought a couple different SIP phones to try and a Digium TDM01B card. I am using an older PIII 1Ghz system with 815chipset (PCI Rev2.2) with 256MBfor my test system. The only thing that will be different on a production system is that I will be using a newer chipset PC with faster processor and 512MB. Probably Intel 7505, 7210, or 7211chipsets which seem to be the most compatible with Asterisk. My problem is that I cannot eliminate echo no matter what I try. I seriously doubt that a newer chipset faster PC with more memory will eliminate or even reduce my echo problems based on what I have read.I am not about to drop more cash to try and find out. Essentially, my findingsare that Asterisk is NOT production capable for my configuration which is via FXO and PSTN. That is probably THE most common configuration so if itis not production capable like that itisn't production capable period as far as I'm concerned. What a disappointment :(. Unless I am missing something I am sure that many many people with a similar configuration in a production environment have the same problem. Perhaps they are just living with it?? For me it is just as unacceptable on an Asterisk system as it is on a traditional PBX. Some calls are ok and some are not. No correlation to local, long distance, time of day. There always seems to be some echo. Sometimes it is worse than other times. Again, no correlation to local, long distance, time of day. Tried connecting to ATA adapter and using VoIP provider instead to see if the telco was causing the problem. That did not change anything. Still the same general echo problem The things I have tried includein no particular order and not limited to are: *Buy latest TDM400P withlatest FXO module *Ensurecopper connection to analog telco lines and telco are not causing problems including running a separate shielded line to the demarc AND having the telco guy come out and test the levels, impedance etc. *Adjust RX/TX levels as per Asterisk Wiki using the quick Ztmonitor method and by using the detailed Ztmonitor method via a Telco 102milliwatt test phone #. The end result was RX=8.0, TX=-1.0. Since I still have echo problems I have tried all sort of other settings without success. *After ALL of the above, try every possible combination of all of the following on Asterisk v1.0.9: echocancel (off, on, 128, 256, 16, 32, 64), echowhenbridged (on, off), echotraining (off, on, 800), Mark 2(default, aggressive,CVS head developments, bugs.digium.com patches, adjust threshold level as per wiki etc. etc.) *Make sure echotraining line is before FXO channel assignment in zapata.conf file *Run fxotune which did not find a need to adjust the FXO levels (1=0,0,0,0,0,0,0,0) Based on all the above testing the best settings were pretty much in line with what most people are finding. echocancel=on. echowhenbridged=on, echotraining=800, Mark 2 echo canceller, aggressive cancellation OFF, bugs.digium.com #2820 patch, RX=8.0, TX=-1.0. Still have echo. Aggressive mode helps a bit but then the other persons voice get's cut offa lotespecially when I talkand the cutting in and out of the canceller is more noticeable and objectionableingeneral thanif Aggressive is turned off. Ihave two SIP phones. An Aastra 9133i and a Grandstream GXP2000. Echo problem is the same on both phones. I am located within a metropolitan area in Canada. Any comments and/or suggestions would be greatly appreciated as I am pretty
Re: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
OK comments on echo and levels. I made a living doing this in a central office so take it for what it's worth. Milliwatt is 0dbm0 or 0dbm at a 0 reference point. At the point where the phone line get's to your demarc the is supposed to ba a -2 to 3db reference point, sometimes called a -2 or -3 test level point (TLP). So that milliwatt tone at that point should read in the range of -2 to -3 dbm. Voice BTW, is considered to be a nominal -15dbm0. The digital stream of a T1/E1 is considered to be a 0 reference point. When I worked on telephone switches (NorTel DMS250) the entire switch, because it was all digital was considered to be a 0 TLP. If the milliwatt is arriving at the demarc at the nominal -2 to -3dbm and getting into the asterisk to be measured at 8dBm (+8dbm0), I'd say something is grossly mal-adjusted. You're seeing 8db of gain! Fix that and your echo should go away. P.S. With that much gain, there is no echo cancellor that I know that can cope, hard or soft. canuck15 wrote: I came into this with my eyes wide open. I have read ABSOLUTELY EVERYTHING there is to be found on the net about avoiding echo problems BEFORE I even attempted to create a production system. Since lots of people are apparently using this in production environments now I just assumed that echo IS avoidable. As others have recommended, I created a test system with the proposed production parts. I bought a couple different SIP phones to try and a Digium TDM01B card. I am using an older PIII 1Ghz system with 815chipset (PCI Rev2.2) with 256MB for my test system. The only thing that will be different on a production system is that I will be using a newer chipset PC with faster processor and 512MB. Probably Intel 7505, 7210, or 7211 chipsets which seem to be the most compatible with Asterisk. My problem is that I cannot eliminate echo no matter what I try. I seriously doubt that a newer chipset faster PC with more memory will eliminate or even reduce my echo problems based on what I have read. I am not about to drop more cash to try and find out. Essentially, my findings are that Asterisk is NOT production capable for my configuration which is via FXO and PSTN. That is probably THE most common configuration so if it is not production capable like that it isn't production capable period as far as I'm concerned. What a disappointment :(. Unless I am missing something I am sure that many many people with a similar configuration in a production environment have the same problem. Perhaps they are just living with it?? For me it is just as unacceptable on an Asterisk system as it is on a traditional PBX. Some calls are ok and some are not. No correlation to local, long distance, time of day. There always seems to be some echo. Sometimes it is worse than other times. Again, no correlation to local, long distance, time of day. Tried connecting to ATA adapter and using VoIP provider instead to see if the telco was causing the problem. That did not change anything. Still the same general echo problem The things I have tried include in no particular order and not limited to are: *Buy latest TDM400P with latest FXO module *Ensure copper connection to analog telco lines and telco are not causing problems including running a separate shielded line to the demarc AND having the telco guy come out and test the levels, impedance etc. *Adjust RX/TX levels as per Asterisk Wiki using the quick Ztmonitor method and by using the detailed Ztmonitor method via a Telco 102milliwatt test phone #. The end result was RX=8.0, TX=-1.0. Since I still have echo problems I have tried all sort of other settings without success. *After ALL of the above, try every possible combination of all of the following on Asterisk v1.0.9: echocancel (off, on, 128, 256, 16, 32, 64), echowhenbridged (on, off), echotraining (off, on, 800), Mark 2 (default, aggressive, CVS head developments, bugs.digium.com patches, adjust threshold level as per wiki etc. etc.) *Make sure echotraining line is before FXO channel assignment in zapata.conf file *Run fxotune which did not find a need to adjust the FXO levels (1=0,0,0,0,0,0,0,0) Based on all the above testing the best settings were pretty much in line with what most people are finding. echocancel=on. echowhenbridged=on, echotraining=800, Mark 2 echo canceller, aggressive cancellation OFF, bugs.digium.com #2820 patch, RX=8.0, TX=-1.0. Still have echo. Aggressive mode helps a bit but then the other persons voice get's cut off a lot especially when I talk and the cutting in and out of the canceller is more noticeable and objectionable in general than if Aggressive is turned off. I have two SIP phones. An Aastra 9133i and a Grandstream GXP2000. Echo problem is the same on both phones. I am located within a metropolitan area in Canada. Any comments and/or suggestions would be greatly appreciated as I am pretty
Re: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
Has anyone tried this approach? 1) Install * on a PC(probably don't need much horsepower) 2) Setup a sipura spa-2000 ata so that it is not on the same lan you are troubleshooting. One way to do this is with a crossover cable to the above PC. Restrict both ata ports to ulaw only. 3) Port 1 of ata gets a good analog phone 4) Port 2 simulates a pots line. Run a quality short cable to the fxo you are testing. This way you can also test things like caller ID without paying a telco. I suppose you could also use the ata that comes with vonage and others to test an fxo. As long as you get good call quality it should work. Wiley Siler wrote: Just because you cannot get it to work does not mean that IT does not work. Just using the right motherboard is not enough. Did you check for IRQ problems? You don't mention whether you have checked for this. Look for a thread called Asterisk-Users Small office setupusing analog lines w Asterisk in the archive via Google. use site:lists.digium.com Try all the things listed in that thread. Do you have a network that is capable of VoIP? Are you using hubs when you should be using switches? There is a major difference and hubs WILL NOT work reliably with VoIP. Are you using QoS on your switches if you have lots of network traffic? If you are using your own Distro and installing from scratch, try to use Asterisk at Home just to see if you still have the same problem. I am putting my money on an IRQ issue myself. W *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On Behalf Of *canuck15 *Sent:* Wednesday, August 24, 2005 1:38 PM *To:* asterisk-users@lists.digium.com *Subject:* [Asterisk-Users] Will Echo problems EVER be solved, I'm scared I came into this with my eyes wide open. I have read ABSOLUTELY EVERYTHING there is to be found on the net about avoiding echo problems BEFORE I even attempted to create a production system. Since lots of people are apparently using this in production environments now I just assumed that echo IS avoidable. As others have recommended, I created a test system with the proposed production parts. I bought a couple different SIP phones to try and a Digium TDM01B card. I am using an older PIII 1Ghz system with 815chipset (PCI Rev2.2) with 256MB for my test system. The only thing that will be different on a production system is that I will be using a newer chipset PC with faster processor and 512MB. Probably Intel 7505, 7210, or 7211 chipsets which seem to be the most compatible with Asterisk. My problem is that I cannot eliminate echo no matter what I try. I seriously doubt that a newer chipset faster PC with more memory will eliminate or even reduce my echo problems based on what I have read. I am not about to drop more cash to try and find out. Essentially, my findings are that Asterisk is NOT production capable for my configuration which is via FXO and PSTN. That is probably THE most common configuration so if it is not production capable like that it isn't production capable period as far as I'm concerned. What a disappointment :(. Unless I am missing something I am sure that many many people with a similar configuration in a production environment have the same problem. Perhaps they are just living with it?? For me it is just as unacceptable on an Asterisk system as it is on a traditional PBX. Some calls are ok and some are not. No correlation to local, long distance, time of day. There always seems to be some echo. Sometimes it is worse than other times. Again, no correlation to local, long distance, time of day. Tried connecting to ATA adapter and using VoIP provider instead to see if the telco was causing the problem. That did not change anything. Still the same general echo problem The things I have tried include in no particular order and not limited to are: *Buy latest TDM400P with latest FXO module *Ensure copper connection to analog telco lines and telco are not causing problems including running a separate shielded line to the demarc AND having the telco guy come out and test the levels, impedance etc. *Adjust RX/TX levels as per Asterisk Wiki using the quick Ztmonitor method and by using the detailed Ztmonitor method via a Telco 102milliwatt test phone #. The end result was RX=8.0, TX=-1.0. Since I still have echo problems I have tried all sort of other settings without success. *After ALL of the above, try every possible combination of all of the following on Asterisk v1.0.9: echocancel (off, on, 128, 256, 16, 32, 64), echowhenbridged (on, off), echotraining (off, on, 800), Mark 2 (default, aggressive, CVS head developments, bugs.digium.com patches, adjust threshold level as per wiki etc. etc.) *Make sure echotraining line is before FXO channel assignment in zapata.conf file *Run fxotune which did not find a need to adjust the FXO
Re: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
The Asterisk Software is not the problem. I'm thinking and I could be wrong that your having a total line balance mismatch with the card your using. Check the line impedance and the card's. Most people using Asterisk don't have that much echo. Anyway It would be nice to see a manual Hybrid adjustment on analog cards. Don't give up. canuck15 wrote: I came into this with my eyes wide open. I have read ABSOLUTELY EVERYTHING there is to be found on the net about avoiding echo problems BEFORE I even attempted to create a production system. Since lots of people are apparently using this in production environments now I just assumed that echo IS avoidable. As others have recommended, I created a test system with the proposed production parts. I bought a couple different SIP phones to try and a Digium TDM01B card. I am using an older PIII 1Ghz system with 815chipset (PCI Rev2.2) with 256MBfor my test system. The only thing that will be different on a production system is that I will be using a newer chipset PC with faster processor and 512MB. Probably Intel 7505, 7210, or 7211chipsets which seem to be the most compatible with Asterisk. My problem is that I cannot eliminate echo no matter what I try. I seriously doubt that a newer chipset faster PC with more memory will eliminate or even reduce my echo problems based on what I have read.I am not about to drop more cash to try and find out. Essentially, my findingsare that Asterisk is NOT production capable for my configuration which is via FXO and PSTN. That is probably THE most common configuration so if itis not production capable like that itisn't production capable period as far as I'm concerned. What a disappointment :(. Unless I am missing something I am sure that many many people with a similar configuration in a production environment have the same problem. Perhaps they are just living with it?? For me it is just as unacceptable on an Asterisk system as it is on a traditional PBX. Some calls are ok and some are not. No correlation to local, long distance, time of day. There always seems to be some echo. Sometimes it is worse than other times. Again, no correlation to local, long distance, time of day. Tried connecting to ATA adapter and using VoIP provider instead to see if the telco was causing the problem. That did not change anything. Still the same general echo problem The things I have tried includein no particular order and not limited to are: *Buy latest TDM400P withlatest FXO module *Ensurecopper connection to analog telco lines and telco are not causing problems including running a separate shielded line to the demarc AND having the telco guy come out and test the levels, impedance etc. *Adjust RX/TX levels as per Asterisk Wiki using the quick Ztmonitor method and by using the detailed Ztmonitor method via a Telco 102milliwatt test phone #. The end result was RX=8.0, TX=-1.0. Since I still have echo problems I have tried all sort of other settings without success. *After ALL of the above, try every possible combination of all of the following on Asterisk v1.0.9: echocancel (off, on, 128, 256, 16, 32, 64), echowhenbridged (on, off), echotraining (off, on, 800), Mark 2(default, aggressive,CVS head developments, bugs.digium.com patches, adjust threshold level as per wiki etc. etc.) *Make sure echotraining line is before FXO channel assignment in zapata.conf file *Run fxotune which did not find a need to adjust the FXO levels (1=0,0,0,0,0,0,0,0) Based on all the above testing the best settings were pretty much in line with what most people are finding. echocancel=on. echowhenbridged=on, echotraining=800, Mark 2 echo canceller, aggressive cancellation OFF, bugs.digium.com #2820 patch, RX=8.0, TX=-1.0. Still have echo. Aggressive mode helps a bit but then the other persons voice get's cut offa lotespecially when I talkand the cutting in and out of the canceller is more noticeable and objectionableingeneral thanif Aggressive is turned off. Ihave two SIP phones. An Aastra 9133i and a Grandstream GXP2000. Echo problem is the same on both phones. I am located within a metropolitan area in Canada. Any comments and/or suggestions would be greatly appreciated as I am pretty much out of ideas and ready to give up on Asterisk as a suitable traditional small business phone system replacement. ___ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
Try to use another land line and test the echo problem again. Do you have any DSL service running in that line? Quoting canuck15 [EMAIL PROTECTED]: I came into this with my eyes wide open. I have read ABSOLUTELY EVERYTHING there is to be found on the net about avoiding echo problems BEFORE I even attempted to create a production system. Since lots of people are apparently using this in production environments now I just assumed that echo IS avoidable. As others have recommended, I created a test system with the proposed production parts. I bought a couple different SIP phones to try and a Digium TDM01B card. I am using an older PIII 1Ghz system with 815chipset (PCI Rev2.2) with 256MB for my test system. The only thing that will be different on a production system is that I will be using a newer chipset PC with faster processor and 512MB. Probably Intel 7505, 7210, or 7211 chipsets which seem to be the most compatible with Asterisk. My problem is that I cannot eliminate echo no matter what I try. I seriously doubt that a newer chipset faster PC with more memory will eliminate or even reduce my echo problems based on what I have read. I am not about to drop more cash to try and find out. Essentially, my findings are that Asterisk is NOT production capable for my configuration which is via FXO and PSTN. That is probably THE most common configuration so if it is not production capable like that it isn't production capable period as far as I'm concerned. What a disappointment :(. Unless I am missing something I am sure that many many people with a similar configuration in a production environment have the same problem. Perhaps they are just living with it?? For me it is just as unacceptable on an Asterisk system as it is on a traditional PBX. Some calls are ok and some are not. No correlation to local, long distance, time of day. There always seems to be some echo. Sometimes it is worse than other times. Again, no correlation to local, long distance, time of day. Tried connecting to ATA adapter and using VoIP provider instead to see if the telco was causing the problem. That did not change anything. Still the same general echo problem The things I have tried include in no particular order and not limited to are: *Buy latest TDM400P with latest FXO module *Ensure copper connection to analog telco lines and telco are not causing problems including running a separate shielded line to the demarc AND having the telco guy come out and test the levels, impedance etc. *Adjust RX/TX levels as per Asterisk Wiki using the quick Ztmonitor method and by using the detailed Ztmonitor method via a Telco 102milliwatt test phone #. The end result was RX=8.0, TX=-1.0. Since I still have echo problems I have tried all sort of other settings without success. *After ALL of the above, try every possible combination of all of the following on Asterisk v1.0.9: echocancel (off, on, 128, 256, 16, 32, 64), echowhenbridged (on, off), echotraining (off, on, 800), Mark 2 (default, aggressive, CVS head developments, bugs.digium.com patches, adjust threshold level as per wiki etc. etc.) *Make sure echotraining line is before FXO channel assignment in zapata.conf file *Run fxotune which did not find a need to adjust the FXO levels (1=0,0,0,0,0,0,0,0) Based on all the above testing the best settings were pretty much in line with what most people are finding. echocancel=on. echowhenbridged=on, echotraining=800, Mark 2 echo canceller, aggressive cancellation OFF, bugs.digium.com #2820 patch, RX=8.0, TX=-1.0. Still have echo. Aggressive mode helps a bit but then the other persons voice get's cut off a lot especially when I talk and the cutting in and out of the canceller is more noticeable and objectionable in general than if Aggressive is turned off. I have two SIP phones. An Aastra 9133i and a Grandstream GXP2000. Echo problem is the same on both phones. I am located within a metropolitan area in Canada. Any comments and/or suggestions would be greatly appreciated as I am pretty much out of ideas and ready to give up on Asterisk as a suitable traditional small business phone system replacement. -- Alfredo J. Fabretti IPFLOW :: La inteligencia en sus comunicaciones Argentina: (5411) 4294-8897 USA: (1) 914 301 8268 www.ip-flow.com.ar ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
RE: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
Wiley, The very first thing I checked was for IRQ problems. Iapoligize for forgetting to mention that. The only thing I found in the Google search you suggested is a thread from January 2004 suggesting that businesses should ONLY use a T1 card with a channel bank instead of X100P cards. I understand the "don't use X100P" part but I just assumed the TDM400P with echo cancellation is working fine now. I am using a WRT54G (switch). I am NOT connecting via wireless. I have no traffic to QoS. Just VoIP and a WRT54G switch is quite capable of that as far as I know. No hubs! I pretty much just use AAH now for it's ease of install but I have rolled my own in the past.The echo has persisted through AAH v1.3, 1.4, 1.5. I have recently (yesterday) installed the latest Asterisk and Zaptel CVS headdevelopment tree just to see if it made a difference and it DID NOT! From: Wiley Siler [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 24, 2005 2:00 PMTo: Asterisk Users Mailing List - Non-Commercial DiscussionSubject: RE: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared Just because you cannot get it to work does not mean that IT does not work. Just using the right motherboard is not enough. Did you check for IRQ problems? You don't mention whether you have checked for this. Look for a thread called "Asterisk-Users Small office setupusing analog lines w Asterisk" in the archive via Google. use site:lists.digium.com Try all the things listed in that thread. Do you have a network that is capable of VoIP? Are you using hubs when you should be using switches? There is a major difference and hubs WILL NOT work reliably with VoIP. Are you using QoS on your switches if you have lots of network traffic? If you are using your own Distro and installing from scratch, try to use Asterisk at Home just to see if you still have the same problem. I am putting my money on an IRQ issue myself. W From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of canuck15Sent: Wednesday, August 24, 2005 1:38 PMTo: asterisk-users@lists.digium.comSubject: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared I came into this with my eyes wide open. I have read ABSOLUTELY EVERYTHING there is to be found on the net about avoiding echo problems BEFORE I even attempted to create a production system. Since lots of people are apparently using this in production environments now I just assumed that echo IS avoidable. As others have recommended, I created a test system with the proposed production parts. I bought a couple different SIP phones to try and a Digium TDM01B card. I am using an older PIII 1Ghz system with 815chipset (PCI Rev2.2) with 256MBfor my test system. The only thing that will be different on a production system is that I will be using a newer chipset PC with faster processor and 512MB. Probably Intel 7505, 7210, or 7211chipsets which seem to be the most compatible with Asterisk. My problem is that I cannot eliminate echo no matter what I try. I seriously doubt that a newer chipset faster PC with more memory will eliminate or even reduce my echo problems based on what I have read.I am not about to drop more cash to try and find out. Essentially, my findingsare that Asterisk is NOT production capable for my configuration which is via FXO and PSTN. That is probably THE most common configuration so if itis not production capable like that itisn't production capable period as far as I'm concerned. What a disappointment :(. Unless I am missing something I am sure that many many people with a similar configuration in a production environment have the same problem. Perhaps they are just living with it?? For me it is just as unacceptable on an Asterisk system as it is on a traditional PBX. Some calls are ok and some are not. No correlation to local, long distance, time of day. There always seems to be some echo. Sometimes it is worse than other times. Again, no correlation to local, long distance, time of day. Tried connecting to ATA adapter and using VoIP provider instead to see if the telco was causing the problem. That did not change anything. Still the same general echo problem The things I have tried includein no particular order and not limited to are: *Buy latest TDM400P withlatest FXO module *Ensurecopper connection to analog telco lines and telco are not causing problems including running a separate shielded line to the demarc AND having the telco guy come out and test the levels, impedance etc. *Adjust RX/TX levels as per Asterisk Wiki using the quick Ztmonitor method and by using the detailed Ztmonitor method via a Telco 102milliwatt test phone #. The end result was RX=8.0, TX=-1.0. Since I still have echo problems I have tried all sort of other settings without success. *After ALL of the above, try every possible combination of all of the following on Asterisk v1.0.9: echocance
RE: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
Alfredo, I tried a regular telco PSTN and a VoIP provider (webcall.ca using their Nortel ATA connected to the TDM01B). Both have very similar echo problems using completely different wiring so I am quite convinced it has nothing to do with the PSTN or wiring. By the way, I sound just fine to the person on the other end. They hear absolutely no echo and say I sound crystal clear. I also want to say that I am encouraged at the optimistic responses so far. It tells me that there is hope if so many people feel this can work today with existing hardware. -Original Message- From: Alfredo J. Fabretti [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 24, 2005 3:18 PM To: asterisk-users@lists.digium.com Subject: Re: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared Try to use another land line and test the echo problem again. Do you have any DSL service running in that line? Quoting canuck15 [EMAIL PROTECTED]: I came into this with my eyes wide open. I have read ABSOLUTELY EVERYTHING there is to be found on the net about avoiding echo problems BEFORE I even attempted to create a production system. Since lots of people are apparently using this in production environments now I just assumed that echo IS avoidable. As others have recommended, I created a test system with the proposed production parts. I bought a couple different SIP phones to try and a Digium TDM01B card. I am using an older PIII 1Ghz system with 815chipset (PCI Rev2.2) with 256MB for my test system. The only thing that will be different on a production system is that I will be using a newer chipset PC with faster processor and 512MB. Probably Intel 7505, 7210, or 7211 chipsets which seem to be the most compatible with Asterisk. My problem is that I cannot eliminate echo no matter what I try. I seriously doubt that a newer chipset faster PC with more memory will eliminate or even reduce my echo problems based on what I have read. I am not about to drop more cash to try and find out. Essentially, my findings are that Asterisk is NOT production capable for my configuration which is via FXO and PSTN. That is probably THE most common configuration so if it is not production capable like that it isn't production capable period as far as I'm concerned. What a disappointment :(. Unless I am missing something I am sure that many many people with a similar configuration in a production environment have the same problem. Perhaps they are just living with it?? For me it is just as unacceptable on an Asterisk system as it is on a traditional PBX. Some calls are ok and some are not. No correlation to local, long distance, time of day. There always seems to be some echo. Sometimes it is worse than other times. Again, no correlation to local, long distance, time of day. Tried connecting to ATA adapter and using VoIP provider instead to see if the telco was causing the problem. That did not change anything. Still the same general echo problem The things I have tried include in no particular order and not limited to are: *Buy latest TDM400P with latest FXO module *Ensure copper connection to analog telco lines and telco are not causing problems including running a separate shielded line to the demarc AND having the telco guy come out and test the levels, impedance etc. *Adjust RX/TX levels as per Asterisk Wiki using the quick Ztmonitor method and by using the detailed Ztmonitor method via a Telco 102milliwatt test phone #. The end result was RX=8.0, TX=-1.0. Since I still have echo problems I have tried all sort of other settings without success. *After ALL of the above, try every possible combination of all of the following on Asterisk v1.0.9: echocancel (off, on, 128, 256, 16, 32, 64), echowhenbridged (on, off), echotraining (off, on, 800), Mark 2 (default, aggressive, CVS head developments, bugs.digium.com patches, adjust threshold level as per wiki etc. etc.) *Make sure echotraining line is before FXO channel assignment in zapata.conf file *Run fxotune which did not find a need to adjust the FXO levels (1=0,0,0,0,0,0,0,0) Based on all the above testing the best settings were pretty much in line with what most people are finding. echocancel=on. echowhenbridged=on, echotraining=800, Mark 2 echo canceller, aggressive cancellation OFF, bugs.digium.com #2820 patch, RX=8.0, TX=-1.0. Still have echo. Aggressive mode helps a bit but then the other persons voice get's cut off a lot especially when I talk and the cutting in and out of the canceller is more noticeable and objectionable in general than if Aggressive is turned off. I have two SIP phones. An Aastra 9133i and a Grandstream GXP2000. Echo problem is the same on both phones. I am located within a metropolitan area in Canada. Any comments and/or suggestions would be greatly appreciated as I am pretty much out of ideas and ready to give up
RE: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
I have several production systems with tdm400p. Do you have any IRQ conflict? cat /proc/interrupts Did you try changing the pci slot? Maybe the fxo module is damaged? did you try changing it to another place of the card? I don't know if this can help, anyone? Quoting canuck15 [EMAIL PROTECTED]: Alfredo, I tried a regular telco PSTN and a VoIP provider (webcall.ca using their Nortel ATA connected to the TDM01B). Both have very similar echo problems using completely different wiring so I am quite convinced it has nothing to do with the PSTN or wiring. By the way, I sound just fine to the person on the other end. They hear absolutely no echo and say I sound crystal clear. I also want to say that I am encouraged at the optimistic responses so far. It tells me that there is hope if so many people feel this can work today with existing hardware. -Original Message- From: Alfredo J. Fabretti [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 24, 2005 3:18 PM To: asterisk-users@lists.digium.com Subject: Re: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared Try to use another land line and test the echo problem again. Do you have any DSL service running in that line? ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
First off, thank you *very* much for this unbelievably informative post! I've got it saved away now along with Kris Boutilier's adjusting rxgain/txgain post. On Wednesday 24 August 2005 17:14, Bruce Ferrell wrote: At the point where the phone line get's to your demarc the is supposed to ba a -2 to 3db reference point, sometimes called a -2 or -3 test level point (TLP). So that milliwatt tone at that point should read in the range of -2 to -3 dbm. Ok so since -3dB is 1/2 power we should be expecting a reading of 7422 in ztmonitor if it's a linear reading of the signal. If the milliwatt is arriving at the demarc at the nominal -2 to -3dbm and getting into the asterisk to be measured at 8dBm (+8dbm0), I'd say something is grossly mal-adjusted. You're seeing 8db of gain! No, he was saying he had to set his rxgain to 8 in order to get a level of 14844 (0dBm) in ztmonitor. -A. ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
Ok, fxotune is a work in progress so to speak. I fixed something in it about a week ago that may help it adjust to the line better (whereas before I'm not sure that it was at all). Try the latest CVS-HEAD version of fxotune as your first step. (oh, after you use fxotune you should turn off your gain settings in zapata.conf). Second step is to try the new echo canceller that was added to CVS-HEAD. Look in zconfig.h and try the KB1 echo canceller. I have received many good reports that it has cured practically all echo on all of the systems that I have heard feedback from. If all of this doesn't work, you probably have a serious hardware line issue that you should resolve with your telco. --- Matthew Fredrickson ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
RE: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared
Colin, Your suggestions about identical hardware and BIOS revisions sound like good advice. If I ever get past this it is something I will definitely be careful about. Well I am starting to think that maybe it is my PC. I have a newer, faster AMD system with PCI2.2 so I might give that one a shot. You are using FXS modules with analog phones. I am using SIP phones. It is my understanding that there is a LOT more delay when using SIP phones and of course a lot of other things going on. zttest yields 100% at least half the time and 99.987793% the rest of the time. Someone else suggested enabling MMX and CONFIG CALC XLAW in zconfig.h as well as adding the following to the Zaptel Makefile: KFLAGS+=-march=pentium3 CFLAGS+=-march=pentium3 I did all this, recompiled zaptel and rebooted but it didn't seem to make any difference. -Original Message- From: Colin Anderson [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 24, 2005 8:18 PM To: 'Asterisk Users Mailing List - Non-Commercial Discussion' Subject: RE: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared dude it's gotta be something with your system. Im using same setup at home with a TDM22 with no probs. [EMAIL PROTECTED] 1.5, Compaq Deskpro EN P3 500, cordless phones. You did a ton more than I did, I basically plugged everything in and installed [EMAIL PROTECTED] first try. Hate to say it, but would it be possible to try a different system? Even an old system as long as it is PCI 2.2. The big clue here is that you say that echo is the same regardless of phone or PSTN source. That pretty much narrows it down to the system. What's your score on /usr/src/zaptel/zttest? This is the burn of Asterisk. It's extremely difficult to make random hardware work good with it. Because it is designed for commodity hardware, stability is a moving target. Even bios revs can make a difference. In the deployment I have done for my work I have a master Asterisk server and 30 IAX servers in remote locations. All 30 boxen are exactly the same, down to the BIOS rev, Linux version, network cards, everything. This is the way to do it, to narrow down infinite variables to a controllable few. You need patience or luck but preferably both. You have an advantage, though. From your post it looks like you've done your homework, you aren't a dumbass, and you know how to arrive at a conclusion through process of elimination. You're on the right track. Don't give up now, 'cause you are close. -- From: canuck15 Reply To: Asterisk Users Mailing List - Non-Commercial Discussion Sent: Wednesday, August 24, 2005 5:02 PM To: 'Asterisk Users Mailing List - Non-Commercial Discussion' Subject: RE: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared File: ATT11994.txt Wiley, The very first thing I checked was for IRQ problems. I apoligize for forgetting to mention that. The only thing I found in the Google search you suggested is a thread from January 2004 suggesting that businesses should ONLY use a T1 card with a channel bank instead of X100P cards. I understand the don't use X100P part but I just assumed the TDM400P with echo cancellation is working fine now. I am using a WRT54G (switch). I am NOT connecting via wireless. I have no traffic to QoS. Just VoIP and a WRT54G switch is quite capable of that as far as I know. No hubs! I pretty much just use AAH now for it's ease of install but I have rolled my own in the past. The echo has persisted through AAH v1.3, 1.4, 1.5. I have recently (yesterday) installed the latest Asterisk and Zaptel CVS head development tree just to see if it made a difference and it DID NOT! _ From: Wiley Siler [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 24, 2005 2:00 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: RE: [Asterisk-Users] Will Echo problems EVER be solved, I'm scared Just because you cannot get it to work does not mean that IT does not work. Just using the right motherboard is not enough. Did you check for IRQ problems? You don't mention whether you have checked for this. Look for a thread called Asterisk-Users Small office setupusing analog lines w Asterisk in the archive via Google. use site:lists.digium.com Try all the things listed in that thread. Do you have a network that is capable of VoIP? Are you using hubs when you should be using switches? There is a major difference and hubs WILL NOT work reliably with VoIP. Are you using QoS on your switches if you have lots of network traffic? If you are using your own Distro and installing from scratch, try to use Asterisk at Home just to see if you still have the same problem. I am putting my money on an IRQ issue myself. W _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of canuck15 Sent: Wednesday, August 24, 2005 1:38 PM
