The word troubleshooting may trigger memories of desperation when a critical system was down and you couldn't figure out why. Troubleshooting often justifies high-priced consultants . The mere mention of it can make fainthearted IT executives squirm ... because if you're troubleshooting, that means something's wrong. Regardless, troubleshooting tools are an important ingredient in the VoIP success recipe.
If you're building your standards-based VoIP network from the ground up today, then you're probably using SIP and not H.323. SIP is clearly the prevailing standard for VoIP call signaling, as it provides more interoperability and easier troubleshooting. The tools used to troubleshoot SIP and H.323 are largely the same, though: packet sniffers, log analysis, and softphones.
Since SIP is a framework for real-time media applications, the stability of one SIP-based system to the next can vary greatly. Problems are most likely at the application layer. Troubleshooting them may require a specific knowledge of the application, or even access to its source code. This isn't always practical or available. Many system engineers aren't hard- core C programmers. Of course, for those who want to probe the mechanics of IP telephony with C, a great book to read is O'Reilly's Practical VoIP with VOCAL .
This chapter therefore focuses on generic, more common, troubleshooting scenarios: inspecting SIP registration and call-setup exchanges using a packet analyzer and interpreting log output to find the root cause of interoperability problems.