Ongoing ECHO

[j.magee]

After reviewing the Cisco documents on Echo and changing Phone Loads . We contacted the carrier and requested to have the lines checked . On a typical T1/PRI circuit in North America the input signal should be -15db . The carrier came back to us with the following levels : recieve from customer -19.5 dbdsx...transmit -19.2dbdsx . Could these levels be the root to our ongoing issues with ECHO . Thanks for all replys !!

[jraarons]

This was a good posting. I'm glad you pointed it out, however I researched this on CCO to learn more. It appears that depending on the hardware the expected db varies in IOS. So you should match the PSTN to the hardware.

2600/MFT

http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120t/120t7/t1_mf_t6.htm

For a 2600/MFT If you do not set the cable length, the system defaults to a setting of cablelength long gain26 0db

[mflanigan]

Actually, at least on 12.1.5YD3 and 12.1.5YH1 in 2600/VG200, the default is long gain36 0db, despite what the documentation says. We are having some echo problems - has anyone had experience with setting the cablelength to address echo instead of/in addition to voice port gain/attenuation? I have just noticed this looking at sh controller output.

Thanks

[vimoreno]

Echo can be a hard to tackle one.

Cable length, output attenuation and input gain all affect the same component of the echo: ERL level (Echo Return Loss). So playing with the cable length or the output/input levels should have similar effects on your ERL levels, however using the gain and attenuation on the ports is more granular.

Once you are satisfied with your ERL, you need to also take into consideration the delay of the echo being received. If this is two long (>32 ms) the echo cancellers will not consider the returning signal as echo and will therefore not cancel it. Not a lot we can do on the gateway side in this scenario. Delay would have to be reduced in the network itself.

Regards