Inbound Call Troubleshooting
Table of Contents
Scope
The following are steps for troubleshooting failed inbound calls.
Intended Audience: White Label Partners & Tier 1 Technicians or higher
Requirements
- Access to PBX call history
- Access to web GUI of phone
Obtain Basic Information
- Call examples (Date, Time, Numbers Involved)
- DID(s) and/or users affected
- Expected behavior vs actual behavior
Check PBX Call History
- Check the domain's call history. If the call is hitting our switch then we would show an entry in the call history page.
- Test On-net and Off-net inbound calling.
- Check the root call history if the inbound calls aren't available in the domain's call history.
- If Off-net calls are found in history, verify that phones are online.
- Review call routing and verify that the features below are set to their correct settings.
- DID treatment
- Time Frames applied (see Set-Up Time of Day Routing)
- Answering Rules (see Answering Rules and Change Answering Rules)
- Auto-Attendant/Call Queue Configuration (see Create an Auto Attendant (IVR), Create a Call Queue, and Extension Numbering & Reserved Number Space
- Open and review the call trace for any failures (see Obtain a Call Trace). Provide it to your service provider if necessary for further troubleshooting.
- Look for error codes (see Common SIP Response Codes).
- If Off-net calls are not found in call history. Lookup calling numbers to locate ULC, identify a pattern, make sure to include call details, ULCs, and call traces.
Check Phone Logs
Most phones have their own logs but have to be turned on. Yealink, Grandstream, and Cisco have specific sections for logging. You would turn these to a functional level of DEBUG or similar. It is safe to leave this on for a few days until the user experiences the issue again. Once they do be sure to turn logging off as it does stress the CPU of the device. The log function usually performs circular logging which means it will delete the oldest entries to make space for new ones. Don't wait too long to view the necessary logs. While reviewing logs you'll want to look for errors such as NOT FOUND, BUSY HERE, PERMANENTLY MOVED, or ACCESS DENIED. This will give you clues as to what error is causing the failed calls.
Check Packet Captures
Many phones are capable of performing packet captures, as are most firewalls. This will give you a complete view of the traffic between the phone and our servers. Thankfully you do not need to review all of the traffic. You can limit the traffic by type (I.E. UDP/5060) or by IP address (see IP Addresses & Ports). You should see two-way traffic. If you are only seeing traffic one way it is an indicator of traffic filtering somewhere in the chain. The firewall is most likely.
Ask for Help
If you still can't find the source of the issue just send us a support request via 611 or email. Remember to include any information you've gathered using the above steps.