> > Yes, I've read that. Ztmonitor is simply a very _basic_ tool that provides > > you with a little bit of feedback to adjust the rxgain and txgain > > settings to something relatively close to what the human ear considers > > reasonable audio levels. > > > > The tool cannot detect or determine what settings are reasonable for > > echo. Therefore, the end result is you need to listen to a conversation > > Isn't getting your transmit and receive levels to 0dBm considered THE #1 STEP > in combating echo? The echo cancellers all assume that the audio will be at > a given level and thus it's crucial to make sure this adjustment is fine.
Sort of. Essentially the problem goes something like this... Audio transmitted from the CO incurres an unknown loss due to the length of the copper pstn lines between the CO and *. The longer the copper pairs, the greater the loss. If you're 15k feet from the CO, the loss is roughly 7db (the exact loss is dependent upon the gauge of the copper wires). So to get close to what another sip phone would sound like, one would need to crank rxgain=7.0. If you want the remote pstn party to hear properly, then txgain=7.0 is required as well. Setting both to that level causes echo as the levels are way outside what the * canceller can handle. Using that same example, "if" one could follow transmission engineering practices in use since the dark ages, the correct way to handle the loss would be to adjust the transmit level "at the CO" to be roughly 7db higher then normal so as deliver an audio signal to * that is roughly 0db (after the cable loss). And, then adjust * to transmit audio 7db greater then normal towards to CO. (In actual transmission engineering practice, the gains would typically be specified about 1 or 2db less then the cable loss.) However, I don't know of any telco that wouild do that even if they could, and I don't know of any current CO switch that has that capability on an ordinary pstn line-interface basis. If one think's about setting rxgain and txgain to values like 7db, think also about the noise, hum, and other imperfections that will also be amplified by the same 7db. Amplifying that crap also has a serious negative impact on how well the existing * canceller functions. So, essentially one can truly say "the further * is from the CO, the greater the audio problems will be". In the olden days of US analog pbx trunking, the above example would be handled by the telco by using 4-wire analog circuits, and typically those circuits were engineered with the capability to adjust "transmit" levels at "both" ends of the circuit. Not so today with ordinary pstn lines. In this 4-wire approach, the echo canceller has much less work to do as the reflected energy that it has to deal with is much much less regardless of where it originates from. It would be very consistent with historic transmission engineering practices to essentially say "use a TDM card if * is located within 3db of the CO, or use a digital (eg, pri/bri) line if beyond 3db". But, digium does not suggest/specify parameters like that and as a result we get lots of * implementors trying to use the TDM card in situations that are almost impossible to address. (Plus, as we've all seen over the last couple of years, the majority of * implementors don't have a clue what their pstn line loss happens to be or even how to measure it. Even those that represent themselves as professional pbx vendors don't typically own a transmission test set or know how to use a CO milliwatt generator.) > Perhaps I have just been lucky but after adjusting the levels such that > they're at 0dBm my echo problems are largely gone. Don't know if that's luck or just implementing asterisk with pstn lines that don't have relatively high cable losses. The US telco's have deployed a ton of digital remote line units (or cabinets) in our neighborhoods that effectively moves the CO line interface closer to our businesses and homes (less pstn loss). In those cases, we might think we're some hugh distance from the CO, but the remote line cabinets place the interface much closer to us then one might think. The average telco employee that rolls around in a truck and visits customer locations doesn't have a clue why those cabinets are out there. > If I crank up the gain to compensate for a 7dB loss would the far end not get > audio at correct levels? The 15kft isn't a moving target so that loss should > be constant. Now if the hybrid on the TDM card is causing such jacked-up > audio to be crossed over to the rx side you would *still* only see it as a > sidetone since it's occurring right on the card and your only delays would be > the digitization and PCI transfer delays. Your analogy with sidetone is correct, except with the TDM card there is an internal delay associated with transmitting data from asterisk (as an application) across the pci bus, queued on the TDM card, hybrid, receiving queue, pci bus, back into asterisk, and into * echo canceller. That delay is not at all constant (very high jitter) and when the "missed frames" are added into the picture, expecting the existing * echo canceller to work in some reasonable way is not going to happen. Spandsp with the TDM or x100p card not working correctly is a perfect example of why the software-based echo canceller can't handle reasonable pstn audio in some pstn cases. We all get around that with pure audio by reducing rxgain and txgain settings. (That's addressing the sympton and not the root cause.) > I agree with the second part of this, but as I said I've had very good luck > with MEC2, MMX "optimizations" and adjusting CFLAGS and KFLAGS for your true > processor for the zaptel driver. Once ztmonitor's saying you're tx and rx > levels are at 0dBm everything just seems to work. No echotraining even. > Just an echocancel setting (usually 64, but 128 and 32 have been used too). As mentioned above, those optimizations are 100% dependent on the exact pstn implementation that you've had to deal with, and don't necessarily apply to the next location. Dependencies actually include the use of a solid mobo, how clean the pstn lines are (eg, noise, hum), proper impedence matching, distance from the pstn line interface (eg, CO), and many other things that you've learned from practical experience. If you deployed a system in rural Des Moines, I'd bet that experience becomes somewhat different. ;) I'm not at all disagreeing with anything that you're stated, we just have to be careful suggesting something that works in one case may not work in the next case. (If I recall correctly, the OP for this thread is in France and I'm not even sure where he stands with config'ing the TDM card for proper impedence matching, etc.) Rich _______________________________________________ Asterisk-Users mailing list [email protected] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
