TryLearn More

Use SIP trunks, WebRTC & Apps

Slash your Phone Bill by 80%

Using *777 Echo Test for Troubleshooting


This article explains what the Echo Test is and how it can be used for troubleshooting. Imagine that you are configuring a new extension. Being an Administrator, you would normally be doing this after office hours meaning nobody is around to help you test the new extension. You need to ensure that the extension is working fine and this is where *777 Echo Test comes in handy.

*777 Echo Test Overview

*777 Echo Test extension is a built in system extension, also available in the free edition of 3CX Phone System. When you dial *777, a connection is made to the PBX, and the PBX will open a connection to your extension. In addition, anything you say will be echoed back to you. This allows you to ensure that calls can be made and received successfully on the new extension.

*777 Echo Test performs a simple call scenario and does not implement any extra call/audio handling. If you were to review a network traffic capture of a call to *777, you would see a text-book example of how a SIP and RTP exchange happens at protocol level.

Calls to *777 can be put on hold or transferred to another destination using blind or attended transfer. After the transfer is made, the echo test should continue to work with the new participant.

*777 Echo Test answers the incoming call and returns audio stream back to the caller exactly as it was received. This provides a simple tool to help with troubleshooting extensions whether connected via the 3CX Tunnel Protocol, or connected as direct (STUN) remote extensions.

Troubleshooting Using *777

A call to *777 can answer the following questions:

  • Is the PBX reachable from the phone location?
    • The call should be accepted by the PBX if there are no other calls to *777 active at the same time.
  • Is there an “ACK not received” problem?
    • If the call remains active for more than 40 seconds after the caller is connected, then you can confirm that this problem is not present. We recommend leaving the call running for at least one minute.
  • Are there any problems related to audio delivery?
    • The caller should hear any audio captured by his microphone back through his speaker.
    • If you DO get the audio back to your speaker:
      • The delay between the moment you talk and moment you hear your voice back in your phone’s speaker is basically the round-trip time for audio delivery.
      • Any gaps in the audio are typically symptoms of bandwidth issues or QoS (lack of) issues – typically over the WAN link.
      • If you get audio gaps even when the *777 call is made from a phone inside the same LAN as the PBX, then it means that the local LAN is experiencing congestion, and the client will very likely need to implement QoS on the LAN.
    • If you DO NOT get the audio back to your speaker:
      • Drop the call and check the server activity log for “No Packets were received…”.
        • If you see “No Packets were received…” from the phone when examining the Server Activity Log in the 3CX Management Console, it means that the RTP stream sent by the phone is not reaching the PBX. If you do not see the “No Packets were received…” message, then it means that the RTP traffic sent by the PBX cannot reach the phone.
        • Possible causes for remote extensions:
        • Possible causes for in-LAN extensions:
          • Extension is incorrectly configured for in-LAN use. Special attention should be made to ensure that an in-LAN extension does not have STUN enabled. Configuration guides for various models can be obtained from our support page.
      • To accurately diagnose the situation, it will be necessary to examine the SIP headers and the SDP parameters in the INVITE/200/ACK exchange, either using a network traffic capture tool (typically Wireshark), or by examining the 3CX logs, with special consideration for the output of the SIP Packet Analyser, which can provide some pointers to where issues may be, and hinting at what configuration adjustments may be necessary.
      • A network traffic capture can also decode the audio streams (inbound and outbound, if present), allowing you to confirm which of the streams is present, and also allowing you understand how big an audio quality issue may be. One should keep in mind that audio quality issues (meaning bad audio, but NOT an audio stream completely missing) are almost always bandwidth related, and will require action by implementing QoS, and possibly also increasing bandwidth if the number of calls is large enough to justify it.

All extension settings function as normal with calls to *777, including:

  • If extension is configured to “Record all calls”, then the call will be recorded.
  • If the phone is configured with the checkbox “PBX delivers audio” enabled, the call’s audio streams will be exchanged in TRANSCODING mode.
  • If the phone is not configured with the checkbox “PBX delivers audio” enabled, then the call’s audio streams will be exchanged in PROXY mode.
  • If the phone has SRTP enabled, and the call is negotiated to exchange audio streams with SRTP, then *777 will exchange the call with the audio streams encrypted.
By |December 3rd, 2012|Comments Off on Using *777 Echo Test for Troubleshooting

Free for up to 1 year! Select preferred deployment:


for Linux on a $200 appliance or as a VM

Get the ISO


for Windows as a VM

Download the setup file

On the cloud

In your Google, Amazon, Azure account

Take the PBX Express