Obtain Basic Information

• Call examples (Date, Time, Numbers Involved)
• DID(s) and/or users affected
• Expected behaviour vs actual behaviour

Check Call History

• Check the domain's call history. If the call hits our switch, we will show an entry on 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 Time of Day Routing)
  • Answering Rules (see Answering Rules)
  • Auto-Attendant/Call Queue Configuration (see Working with automated attendants, Working with Call Queues,  System Extension Numbers, and Reserved Numbers).
• To obtain a call trace, review it for failures (see Troubleshooting Call Completion Issues). If necessary, provide the call trace link to Support for further troubleshooting. The linked article will also provide additional information on common SIP Response Codes. 
• If Off-net calls are not found in the call history, look up calling numbers to locate ULCs, identify a pattern, and include call details, and call traces.

Check Phone Logs

Most phones have their own logs, but you must enable them. 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, deleting 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. The logs will give clues about the error causing the failed calls.

Check Packet Captures

Many phones are capable of performing packet captures, as are most firewalls. Packet captures 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 IP address. You should see two-way traffic. If you only see traffic one way, it indicates 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 support@unitedcloud.ca. Remember to include any information you've gathered using the above steps.