The most important thing to remember about troubleshooting this setup is to make sure you are only testing one part at a time. I learnt this the hard way! Don't bother trying to find out why you can't call the Exchange Server from Asterisk, if you aren't 100% sure that calls directly from the sipX server to the Exchange Server are working.
Packet Captures - Wireshark
The life saving tool for you is going to be Wireshark (available as a free download from http://wireshark.org/) which is a packet analyzer. Run it on your network to look at the SIP traffic going to and from each endpoint through both of the gateways. You can filter packets in Wireshark using the filter string sip.
When running wireshark, keep in mind that if you are on a switched network, you might only see packets going to and from the computer you are running it on. Using a hub instead is preferable, otherwise, you will need to run wireshark simultaneously on multiple PCs. If you are using VMWare, you can run wireshark in a Virtual Machine, and it will see the traffic going to all VMs on that are running on the host system (provided they are all operating in bridged mode).
Make sure you read my post on understanding the relationship between SIP and RTP. This will make troubleshooting packet captures a lot easier.
Read my post on Understanding sipX dial plan configuration files. Make sure that you have confirmed that your dial plan has been merged successfully and ACTIVATED. The most common problems that people contact me about end up being caused by typos and other mistakes in the XML files. Check them all, then double check them, then active the dial plans again just to be sure.
SipX log files can be found in the folder /var/log/sipxpbx/ and the most helpful file here will be sipproxy.log. To get detailed information, you will need to change the logging level to debug from the sipX web interface.
To read the last 40 lines of these files from the command prompt, type
tail -40 /var/log/folder/filename
or to read the entire file, type
If sipX gives you some grief, you can always wipe the database. I had to do this a few times, when I made configuration changes that broke the system, but couldn't actually remember what I changed.
dropdb -U postgres SIPXCONFIG
If you need to restart the sipX services, you can type the following command
service sipxpbx restart
If you forget the superadmin password, you can reset it with the following command line
/usr/bin/sipxconfig.sh --database reset-superadmin
Asterisk troubleshoot starts with the Asterisk log files located in /var/log/Asterisk/ with the most useful being the file called full. Use tail and less to view this log file as shown above.
Additionally, you can log onto the Asterisk console by typing
at the command prompt. Add more 'v's for more debugging information (verbosity).
The Asterisk support pages are a great source of information that I often use when troubleshooting or researching how to do new things with my set up. Voip-info.org has an Asterisk wiki that is also very helpful.
Troubleshooting the Microsoft Exchange Server
As always, the Exchange Server's event logs will contain valuable information in diagnosing problems. You can increase the level of logging by the Exchange UM services by running the following commands in the Exchange Management Console
set-eventloglevel -id "MSExchange Unified Messaging\UMClientAccess" -level expert set-eventloglevel -id "MSExchange Unified Messaging\UMCore " -level expert
Check out the Technet library for more information on configuring and troubleshooting Exchange UM.
The following web sites were used as references for the information presented in this guide.
- SIP RFC
- Microsoft Technet
- sipX Wiki
- Inphonex Support Pages
- Alan Dutton's Blog
- Microsoft Exchange Team Blog
Previous: Part 6 - Configuring Asterisk/Trixbox