Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations TouchToneTommy on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

SCN Echo problem

Status
Not open for further replies.

liquidshokk

Technical User
Jan 31, 2007
940
GB

Hi All

We have a customer that has 5 sites using SCN. All sites are IP406 except one with IP403 (Annoyingly, as cannot upgrade to latest version) The central site has a 406 with a VCM30 card in it.

All boxes are on 3.2 (61)

Only two of the remote sites were setup for external calls to go out through the central site (currently planning the same for the rest) however one of them is experiencing bad echo on outgoing calls. We have swapped the VCM Card at the affected site then returned and swapped out the 406.

I am startting to believe it is the VCM card at the central site that is the issue, however I do not know enough about the causes of echo to say for sure. Could someone advise?

Also eventually with all remote sites going out through the central site, is this going to cause extreme overloading and cause further problems? or has anyone got a similar working setup? the number of users at each site varies from approx 6 to 60

Many Thanks

 
Further to my previous reply

I asked what type of physical MPLS circuits you had.

IE ADSL or Dedicated private circuits

I have had problems with ADSL based MPLS circuits.

ADSL uses ATM protocols which use fixed 53 byte packet sizes
which generate loads of packets which are then stripped dowm before transiting the ethernet networks

This causes big delays and i have seen 100ms delays even with no other data passing over the links/

What are your round trip delays on each link
 
DMP will come in play on the Phone to phone and also the site to site. I have found in the past either they all need to be on or all off. a mix and match causes issues. it will work on site to site with analog phones. they way it works is the remote site calling another remote will use the central site for call set up then it will drop out the central site and speak direct with the other remote.

Kevin Wing
ACA- Implement IP Office
Carousel Industries
 
spridge, As we do not look after the MPLS i am not entirely sure of the exact circuit type. As i mentioned above it is using cisco routers to connect to an MPLS cloud with a provider.

 
going down in flames :)

i agree but, i just find it has caused so many issues in the past. Admitially usually due to the network not allowing packets through or routing issues. But i find taking it off proves wether the IPo to IPo calls work correctly then if adding it back on it causes issues then you know where the issue lies.





voiceondata
 
ha, getting two way voice now across all sites and one of the original sites that were experiencing echo does not appear to have echo anymore HOWEVER the second one that was experiencing it is still getting echo both ways whereas it was previously only one way and another previously unaffected site is now getting echo.

The first site to experience echo was upgraded to 3.2 61 so that we can adjust the echo cancellation. The other sites are all on 3.2 55 so I am going to upgrade the other sites tonight.

Could the echo be there because of using g.711 as it is compressed. is it worth changing it to g.729 tonight when we do the upgrade? as thinking maybe if its uncompressed the speech quality will be better i.e no echo?!?

Also when we get the VCM Echo cancellation option, what should I actually be setting it to across all sites?! 0 or 9 as a rule?

Thanks

 
i would personally set it to g729 to reduce the ammount of traffic going back and forward. but the call quality might suffer


depends if your circuits can handle the traffic on uncompressed




voiceondata
 
It is currently set to g.729 across all sites. There should be enough bandwidth for g.711 as it is only voice going across the MPLS we are told (?) The question is whether changing a codec will affect the echo, as it hasnt really in the past. Maybe changing the codec to g.711 and setting the echo cancellation correctly together will resolve the issue...

is that a pig flying?
 
Echoes are typically generated by impedance mismatches when a signal is converted from one type of circuit to another. To resolve this issue, an estimated echo signal can be created from one output and then subtracted from the input to hopefully remove any echo of the output.



Echo Return Loss (dB): Default = 6dB
Allows adjustment of expected echo loss that should be used for the echo cancellation process. The options are 0dB, 3dB, 6dB and 9dB


Taken from the manager help

voiceondata
 
I saw that in the help. just wonder if any knows which way to tweak it? drop to 0 or raise to 9? its a bit of a sensitive contract and I'd like to keep the number of reboots down to a minimum. We will be able to tweak this from the upgrades next week
 
The voice compression channel improves call quality and can be used to compress voice down to either 6k3 (G723) or 8k (G729/Netcoder) and provides echo cancellation (required for high latency circuits).

The bandwidth required for a VoIP call is made up of two parts, one of which is due to the actual digitization of the analog voice the other is required by the protocol which is used to wrap the digitized voice up and transport it to the remote site. VoIP calls require an overhead of 40 bytes per packet (RTP/UDP/IP Header overhead). This overhead is increased on a LAN by a further 12 bytes Ethernet or by 7 bytes over a PPP WAN link.


Have you tested the round trip delays. e.g ping between sites ??


what were the results ? - sorry if this is answered earlier




voiceondata
 
also does anyone know what the Nonlinear Processor Mode should be set to in this case?

(Allows selection of the echo cancellation algorithm between);

Adaptive (default)

Silence (attempt to mute background noise caused by echo cancellation)

or Disabled.
 
i see....

Ping results;

remote site 1 to central site;

Min 25ms Max 25ms TTL: 119

remote site 2 to central site;

Min 26ms Max 28ms TTL: 119

remote site 3 to central site;

Min 23ms Max 29ms TTL: 119

remote site 4 to central site;

Min 22ms Max 31ms TTL: 119



 
Those results were pinging from a server at the central site to the IP Offices at the remote sites
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top