Antonio Perez

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
======TROUBLESHOOTING DEAD AIR/ONE-WAY AUDIO AFTER CALL SETUP======


**Symptoms:** Remote IP device - Troubleshooting dead air/one-way audio after call setup  
  * Hear audio on both ends during calls  
  * Calls connect but no voice  
  * One-way audio  
  * Dead air  
  * No audio  
  * Router, VPN or firewall setting not configured correctly to allow entire range of subnets involved in the call setup and audio packet delivery  
 

**Facts:**
  * SuperStack 3 NBX  
  * NBX 100  
  * 3C10110  
  * NBX CALL PROCESSOR  
  * NBX Analog Line Card  
  * Remote IP phone  
  * IP phone  
  * NBX 1102 Business Phone 10 Mb  
  * 3C10121  
  * 3C10122  
  * SuperStack II Switch 1000  
  * SuperStack 3 Switch 3300  
  * UDP ports  
 

--------------------------------------------------------------------------------
 
**Causes:** Duplicate IP address  
  * NBX device not bound to IP after call setup; bound Ethernet but still using an IP address (reboot individual device doing this)
  
SuperStack II Switch 1000's have intermittent audio problems with NBX telephones and are NOT supported. They have been obsoleted since before the NBX was produced. Try setting all up-link ports to "backbone" designation. 
 
Data network may be blocking UDP ports 2093, 2094, 2095, 2096. Be sure no UDP filtering or Firewalling is being done on these ports throughout the entire connection.  
 

--------------------------------------------------------------------------------
 
**Fixes:** Steps to troubleshoot no audio or one-way audio after call setup is complete:


These steps pertain to call setup being complete.    This means that phones/devices ring, and otherwise connect OK, meaning, the device appears to be on a call and off-hook after answering. No audio or one-way audio ensues. If either end hangs up, and the other stays off-hook, the NCP properly tears down the call, meaning, the phone or device that remained off-hook when the other end hung up does properly disconnect automatically. This is the specific symptom troubleshooting presented here. If the call does not properly set up or tear down, that is a different issue.


  * **1.** This step, if it fails, proves a routing issue on the customer's network, and not the NBX configuration:
    * Establish the call, and keep both devices (remote IP device and local-to-NCP device off-hook for this test
    * In NetSet, Device Configuration, examine the IP SETTINGS for each of the two devices currently still connected (both devices should still be off-hook in the middle of the test call). 



Record the "IP address reported by device" for both devices.        

If there are settings in the "manually assigned settings" be sure they MATCH the "IP settings reported by device". If they don't match, it means that the device has received a new IP address, either via DHCP, or manually programmed. If they are different, stop this troubleshooting and resolve the issue. Target - DHCP and NAT as culprits.

  * From a PC local to the NCP, PING the remote IP phone/device's IP address as REPORTED IN NETSET. 
  * From a PC at the remote site, PING the local-to-NCP phone/device IP address as REPORTED IN NETSET.


//Note: If ICMP protocol traffic (required for pinging) is blocked on the customer's firewall or router, remote pinging may not be possible for test purposes. Tell them to temporarily enable ICMP for troubleshooting if this is the case.//


If either of these pings fail, and you've verified that the IP addresses of each NBX device to be correct, it means the customer's Network is not routing correctly, and the Customer will need to resolve the routing problem before the NBX devices can communicate. 

Remember, when the call is set up, the calling device connects to the NCP, not the terminating device. In turn, the NCP will tell each end device to send its Voice Packets to the other device' IP address AS SHOWN IN NETSET, "IP SETTINGS REPORTED BY DEVICE". So after both devices are off-hook and the call established, each end device must be able to send (route) packets to the other end, hence this test. If a device is not hearing audio after call setup it means the Voice Packets, although leaving one device, are not routing correctly to the other device. See Step 3 for info on SMS Packet Tracing.


  * **2.** If PINGS are returned both directions, continue with this step:
    * Again in NetSet, Device Configuration, for remote end devices, IP SETTINGS button, confirm the BINDING mode of the device. With the test call in progress, the remote device should have the check mark just to the left of the word IP indicating that the device is currently bound in IP mode. 



The Local or Layer 2 device will have the check next to ETHERNET mode even though the device has an IP address assigned.


  * **3.**If Steps 1 &2 reveal correct configuration, the next step is to positively determine if the fault is with the NBX or the Customer's network:



If the fault is with the NBX, it means that during a call, either UDP voice packets are not being sent by both devices, or they are not being processed despite the fact that they are received. Use SMS/Packet Tracing on the network to confirm where the issue lies:


**How to prove loss of audio is due to Customer's Network or NBX:**


  * SMS / Packet Trace ( Microsoft Systems Management Server). Use a hub as a pass-though to collect your trace samples. Prove that UDP Voice Packets are leaving one device by capturing the packets with a trace hub between the NBX device (phone) and its up-link connection to the network. If UDP voice packets are being sent (and thus seen in the capture at the phone), this proves the phone/device is sending voice packets. They should have a destination IP address of the other end device IP address as it was reported in NetSet.
  * SMS / Packet Trace again, this time with a hub connected in series to the other end phone/device pass-through to the up-link connection. Verify that the UDP packets sent from the other end with a Destination IP of this end are in fact being received, and thus literally arriving at the destination NBX phone/device connection. Most often these UDP packets are not present at the receiving end, and thus, lost or blocked on the Customer's network.



The customer must resolve this issue, not 3Com or you as a Reseller (unless you also manage their network). 3Com Tech Support is not available to troubleshoot network issues once determined.


If the UDP packets are arriving at both ends transmitted from the other side, this indicates a problem with the NBX configuration or device. Again, be certain that UDP packets sent from the OTHER NBX device are ARRIVING at the other side, right at the actual up-link point with a hub connected to the NBX device.        

At this point, if this is the case, double check Step 2 (Binding Mode), followed by rebooting, removing and re-discovering and configuring, or replacing the NBX device that was receiving the UDP voice packets but not hearing them, or, if this is a newly upgraded version of code, reboot back to the old version of NBX and see if the problem is version-related. Call NBX Tech Support if the problem persists and this troubleshooting still does not resolve the issue.
 

--------------------------------------------------------------------------------
 
  * Product(s):  NBX, SuperStack II Switches, SuperStack 3 Switches  
  * Sub Product(s): NBX 100, NBX Analog Line Card, NBX Call Processor, NBX Phones, SuperStack II Switch 1000, SuperStack 3 Switch 3300, SuperStack 3 NBX  
 


 --- //[[nce@itclatam.com|David Gonzalez]] 2021/04/10 11:39//