Diagnosing one-way or no-way talk path

Last Updated : Jan 11, 2024 |

Before you begin

For the resolution of this symptom, disable shuffling (if turned on), which forces traffic to use the media processor, and simplifies the analysis of the network. Among other steps, check whether audio/dial-tone can be received by the IP Telephones involved in the call. If necessary, the media gateway can check the connectivity of the IP Telephones and their local subnetwork using pings. Layer 1 errors can also be checked.

About this task

Use this procedure to diagnose a one-way or no-way talk path problem.

Procedure

  1. If network assessment has been done recently and the network not been modified after the assessment, there may be a network problem, or the IP telephone may have outdated software.

    Go to Step 2. If not, the network may not be compliant with the Avaya’s network requirements. If the problem cannot be resolved by using the procedures described below, a (re-)assessment may need to be done.

  2. If IP Telephones on the same VLAN/subnet/floor experience the same problem, there might be a network problem, or multiple IP Telephones might have outdated firmware.

    If the IP telephone firmware version is outdated, download and install the correct firmware (see Software, firmware, and BIOS update or the Avaya Support Web site http://support.avaya.com). If this solves the problem then no further steps are needed, otherwise verify if the call is shuffled. Refer to Verifying if the call is shuffled.

  3. If the call is shuffled, turn off shuffling with the change station ext# command.
  4. Set the Direct IP-IP Audio Connections field to n.

    If this resolves the problem, then there is a network problem that prevents the two IP Telephones from communicating directly. Refer to, Verifying if the media module can ping the IP Telephones.

    Note:

    The remote PING and remote trace-route commands can be used to help pinpoint the location in the network where shuffled calls experience problems.

    If this does not resolve the problem, then there could be a network problem or a media module problem. Although a network problem is still most likely, keep shuffling disabled.

  5. Verify if the IP telephone receives a dial-tone.

    If the IP telephone receives a dial tone, verify if there are any Communication Manager errors logged for media module or the IP telephone. If the IP telephone does not receive a dial tone, refer to Diagnosing the no-dial-tone problem section.

  6. Run the display errors command to verify if there exist hardware error log and the denial event log for errors against the IP telephone with the particular extension.
  7. If the errors exist, use the information in the error log and the Avaya Aura® Communication Manager Alarms, Events, and Logs Reference to correct the errors.

    If this solves the problem, no further steps are needed. Otherwise, verify if media module receives voice audio from both IP Telephones in the call. Refer to, Verifying if the media module can ping the IP Telephones.

  8. If the IP telephone is sending audio, go to Step 5. If the IP telephone is not sending audio or the network is blocking audio packets, exchange the IP telephone.

    If it does not resolve the problem, then there is a network problem that the customer needs to resolve.

  9. Verify if the media module is operating correctly and has sufficient media module audio resources.

    Refer to Verifying if the media module operates correctly and has sufficient media module audio resources.

  10. If there is a media module dynamically allocated to the IP telephone call, go to the Station form (status station ext#) and check the Last Tx Sequence field.

    This field shows the RTP sequence number of the last packet sent by the media module to the IP telephone. This sequence number should increase at a regular rate when you run the status station ext# command repeatedly. If it does not increase, then there is likely a media module hardware or firmware problem. Use the Avaya Aura® Communication Manager Alarms, Events, and Logs Reference to resolve the issue. If packets are being transmitted normally, Refer to Verifying if media module receives voice audio from both IP Telephones in the call .

  11. If the AUDIO CHANNEL section on the status station form is blank, this might be because the media module cannot allocate resource for the call.
  12. Run the list measurements ip dsp-resource command to determine whether there are sufficient media module resources in the system.
  13. Check for denials, blockage and out-of-service condition.

    If any of those measurements are greater than 0, this this may indicate that there might exist a problem with the media module. Refer to Media module issues for the list of problems that might exist with the media module.

  14. If there are no media module problems, verify if the IP telephone that experiences the 1-way problem or both IP Telephones that experience the no-way problem be pinged from the media module.

    Refer to Verifying if the media module can ping the IP Telephones.

  15. If the ping is sent, find out the location where the ping terminated by executing the trace-route ip 135.9.42.105 board 07D17 command.

    The customer needs to resolve the network problem in the router that terminated the trace-route command. Go to Step 21 after the problem has been resolved.

  16. Verify if the call traverses through a firewall/ACLs. Refer to Verifying if the call is going through a firewall/ACLs.
  17. If the call traverses, relax the packet/port filtering constraints in the firewall if they are too strict.
  18. Check if there are any Layer 1 errors detected in the IP telephone, the intermediate switches/ routers or in the media module, by logging into the switches and routers.
  19. Check the port statistics.
    Note:

    Some customers will not allow this. In such case, the customer should be requested to provide this information.

  20. If the errors exist, there is a network problem (customer responsibility).

    If there are no errors, put a Protocol analyzer on both ends of the call by using switch port mirroring to see where packets are being dropped and resolve the problem. Go to Step 21 after the problem has been resolved.

  21. If needed, return to the original state again by turning shuffling/hairpinning on.

    Refer to Returning to a shuffled state. However, returning to a shuffled state may bring the problem back. However, returning to a shuffled state may bring the problem back.