Troubleshooting for echo issues
To start troubleshooting echo issues, it is important to identify specifically which device or devices are experiencing it, and to determine if the echo is only an issue for a specific call scenario. The following is a list of questions to ask to help determine the cause of the echo. In most cases, you will be able to pinpoint a specific cause for the echo and take steps to resolve it. Some cases may still require additional investigation through E-MetroTel Support engineers to identify the source and potential mitigation options. However, E-MetroTel requires that the following basic analysis be conducted and noted in any trouble ticket opened for echo issues.
If you have analog trunks on your system, you must run ectune tool (refer to Optimizing Trunk Settings) before doing any further troubleshooting!
Note that anytime you move analog trunk connections from one FXO port to another on the system, you must run ectune again as the tool determines the optimal settings for each port based on the unique line characteristics of each incoming trunk.
Characterize the Problem
Beginning by narrowing down where the echo is occurring. Have the answers to these questions before engaging in any support call.
- Is there any analog circuit in the voice path
- Is it actually echo? (Some users refer to almost any voice impairment as echo, even it is an issue with packet loss, jitter, latency, robotic voice, etc.)
- Does only one user, a group of users, or all users experience the echo?
- Does it occur only on a specific phone type (or types)?.
- Does it happen for all calls made by those experiencing the echo, or for calls only to certain destinations.
- Is it present on extension to extension calls? Within the same building or across the internal network?
- Does it occur on a specific trunk type, or more than one type. Is it on all trunks of that type, or just a subset?
Collect the Pertinent Information
- Get a detailed description of the call scenario.
- Create a detailed list of devices involved in the call at the customer site (phones, trunks, and gateway devices) and the specific configuration of each device as well as the service provider information (what equipment do they use to connect to the central office).
This information will be required to be collected and submitted in the ticket if you require E-MetroTel Support assistance.
Attempt to Reproduce the Issue
Attempt to reproduce the issue by substituting other devices that you know do not experience the same issue into the call scenario identified in the previous step. For example, if you have identified that the call scenario occurs for someone using a particular telephone model, try to substitute a different model, or even a different manufacturer phone into the same call scenario. Do this for each device/path of the call scenario to see if you can narrow down to a specific portion of the call where the customer issue is created. Document the process and submit it in the ticket if you require E-MetroTel Support assistance.
Check for Basic potential problems
Phone Specific Issues
- Problem is with a single user:
- Determine if it is heard for all calls while on one particular phone interface (hands-free, headset, or handset)
- Hands-free mode only:
- Face the phone in another direction away from walls or other surfaces that could reflect directly back to the phone base. If the issue is resolved, it may be something specific to the phone itself.
- If that doesn’t resolve the issue, try another phone in hands-free in this same location. If that fails to resolve the echo, then that location may not be a candidate for speaker phone use and a headset should be considered as a hands-free alternative.
- Headset or handset:: Connect the headset or handset of a phone not experiencing echo directly into the problem phone. If the problem is experienced on the second phone that did not have issues. If there is no echo, the problem is likely with the original headset or handset. If it still exists, the problem may be with the phone using those devices. Try another phone with the same devices at the same location.
- If the problem is not resolved, and its an E-MetroTel phone, follow the Troubleshooting Guide for Infinity phones.
- If it is another manufacturer’s device, contact that manufacturer for assistance.
- Hands-free mode only:
- If only a for a subset of calls, determine if there is any consistency in the type of calls where echo is experienced – this may point to a specific trunk or trunk type, or other service provider issue. See Trunk Specific Issues below.
- Determine if it is heard for all calls while on one particular phone interface (hands-free, headset, or handset)
- Problem is with a single user:
- Group of users experience the echo:
- Does the group have any device or calling patterns in common?
- If the echo is experienced on the other phone type, then determine if the echo is only experienced when calling a particular phone number (or numbers) or call via a particular trunk. If so, see Trunk Specific Issues below.
- If the group all use the same type of phone and no other users have that same type, identify the specific type of phone the issue is experienced on.
- Is the echo only on calls between these phones? Try a different model phone at one location experiencing the echo. If the echo is non-existent on the different phone type note the problem phone type.
- If the echo is only experienced between E-MetroTel Infinity 5xxx series phones follow the Troubleshooting Guide for Infinity phones.
- If the echo is only experienced by analog or digital phones connected to an E-MetroTel FXS port or Digital interface (DSM16), then resort to troubleshooting the E-MetroTel device.
- If the group of problem phones are IP telephones provided by a third party, contact the manufacturer of that phone for assistance.
- If the echo is only experienced between E-MetroTel InfinityOne clients, follow the InfinityOne – Troubleshooting Guide
- Is the echo only on calls between these phones? Try a different model phone at one location experiencing the echo. If the echo is non-existent on the different phone type note the problem phone type.
- Does the group have any device or calling patterns in common?
- Group of users experience the echo:
- Do all users experience the echo?
- Is the echo present on internal extension-to-extension calls?
- Is the echo only present on external calls. If so, identify which trunks are being used and then see Trunk Specific Issues below.
Trunk Specific Issues
Check Configurations
Check for trunk configuration issues.
- If DAHDI trunks are used, is the country code set correctly (see Optimize Trunk Settings, PSTN Cards – Settings).
- If there is an external SIP to Analog gateway device used, check the country codes settings on it, and make sure you run any impedance matching tool available on it as well.
- On Galaxy Mini, make sure that the Configured Taps setting is set to 512 taps (see Optimize Trunk Settings)
- Check all the volume level settings – are the TX and/or RX levels to high?
Other Suggested Actions
- A single analog trunk:
- Connect an analog phone or butt-set directly to the incoming FXO line.
- If echo still persists it is an issue with the Central Office side. You will need to call your service provider for assistance.
- If there is no echo on the analog phone or butt-set, then repeat the ectune process (refer to Optimize Trunk Settings) and check again. If it still persists, then stamp the log (Feature 9*9, refer to Stamp Log and System Log Files) and record a call where echo is present. Open a ticket, and attach the recording, the system log file, and the details of the call scenario (how and from where the call was placed, which device answered it, the time of the call), and indicating how the echo was narrowed down to this particular incoming trunk based on the above analysis.
- Connect an analog phone or butt-set directly to the incoming FXO line.
- A group of analog trunks
- Connect an analog phone or butt-set directly to each of the incoming FXO lines.
- If echo still persists on all trunks it is an issue with the Central Office side. You will need to call your service provider for assistance.
- If there is no echo on the analog phone or butt-set on one or more trunks but is only noticeable on a subset of trunks, repeat the ectune process (refer to Optimize Trunk Settings) and check again. If it still persists, then stamp the log (Feature 9*9, refer to Stamp Log and System Log Files) to record at least two calls where echo is present, each arriving on a different trunk. Open a ticket, and attach the recording, the system log file, and the details of the call scenario (how and from where each call was placed, which device(s) answered them, the times of the call), and indicating how the echo was narrowed down to this particular group of trunks based on the above analysis.
- Connect an analog phone or butt-set directly to each of the incoming FXO lines.
- A PRI trunk
- If you are experiencing echo on a PRI trunk, check the setting of the Echo Cancellation for that trunk as described in PRI Card – General Configuration Process.
- If setting the parameters as described does not resolve the echo, then stamp the log (Feature 9*9, refer to Stamp Log and System Log Files) and record a call where echo is present. Open a ticket, and attach the recording, the system log file, and the details of the call scenario (how and from where the call was placed, which device answered it, the time of the call), and indicating how the echo was narrowed down to this particular incoming trunk based on the above analysis.
- If you are experiencing echo on a PRI trunk, check the setting of the Echo Cancellation for that trunk as described in PRI Card – General Configuration Process.
- A SIP trunk from a particular service provider
- In many cases you will have just a single SIP trunk service provider. If possible, temporarily configure a SIP trunk from another service provider or another device that will direct calls to the system with the echo issue.
- If the echo is resolved on calls on that temporary SIP trunk then check your SIP Trunk settings on the UCX and work with your SIP trunk service provider for further diagnosis.
- If the echo persists across calls on the temporary SIP trunks, reconnect your actual SIP trunks and then stamp the log (Feature 9*9, refer to Stamp Log and System Log Files) and record a call where echo is present. Open a ticket, and attach the recording, the system log file, and the details of the call scenario (how and from where the call was placed, which device answered it, the time of the call), and indicating how the echo was narrowed down to this particular incoming trunk based on the above analysis.
- In many cases you will have just a single SIP trunk service provider. If possible, temporarily configure a SIP trunk from another service provider or another device that will direct calls to the system with the echo issue.
- Only on calls to a one or more specific area codes
- This may be a sign that the service provider is connecting to an improperly configured gateway at the far end of the call. Work with your service provider to resolve.
Recording an Analog Channel
An important tool for troubleshooting echo issues is to record the incoming audio on the actual analog interface, The UCX includes a mechanism to do this, creating individual recording files for both the incoming and outgoing audio stream. Refer to Recording Dahdi Calls for Troubleshooting UCX Systems for details on how to create, download, and view/listen to the recordings.
Next Steps
If none of the above steps resolved the customer issue or at least pinpoint the problem to a specific device, additional investigation may be required through E-MetroTel support. When opening a ticket, ensure that all information collected in the initial analysis is included in the ticket. Attempt to get a call recording that captures the echo issue experienced by the customer and attach to the ticket. For any calls involving UCX SIP trunks or extensions or DSM16 devices, record a packet capture with the RTP streams on any of the LAN interfaces involved.
Additional Considerations
- Do not use a jitter buffer if only local devices are used; use the jitter buffer when remote devices are connected
- Do not change the echo related TAPS settings on any interfaces without proper testing
- Do not change gains on the system without a good reason and proper testing.
Background
Echo is simply hearing your own voice as you engage in a call, which means that some of the voice being transmitted along the path from the person hearing echo and the far end is being injected back into the path to the that is sent from the far end. Since this injection can be caused at any point along the path where the signal is converted between analog and digital signals, it requires a structured approach to identifying the source of where the echo is being injected into the call.
Echo can be introduced by a variety of situations which can be created because of acoustical or electrical issues.
- Acoustic echo – occurs when the speech is fed back from the receive path to the microphone through the air and is usually specific to an individual user, unless all the users are in the same basic calling environment (say an open office concept). However, it can be caused by the audio output of a handset or headset reaching the microphone of the same device.
- Electrical echo – occurs when the transmit signal leaks over into the incoming signal along the path to the far end. This typically happen at points where analog to digital conversion occur.
Note that some echo is always desired on a call. Most telephones will inject a certain amount of the near-end user’s voice directly into that persons listening path. This echo is called sidetone and is usually presented with essentially zero delay. Most people’s reaction to the absence of this sidetone – i.e. when they do not hear themselves talking – they are unsure if the far end user can hear them either. Therefore, this sidetone is purposely injected. Echo becomes more of a problem when there is any kind of delay between when the person talks and when they hear themselves. Even delays as long as about 25 milliseconds can normally be tolerated within a conversation.
A search of the internet will provide a significant amount of additional detail regarding echo in voice over ip based systems which may also include other troubleshooting steps or techniques not captured here.