Using Wireshark to Troubleshoot (VoIP Deployment)

Wireshark allows you to see the messaging and signaling banter between your VoIP LAN and your carrier’s SBC. This visibility was restricted in the days before VoIP to only large customers who used SS7 signaling to connect to their carriers and large dedicated circuits equivalent to 672 phone lines. Even if you had SS7, you still had to have capture software and a technician who could make sense of it all.
VoIP and Wireshark place the power in your hands. The more comfortable you are with pulling information in Wireshark and dissecting your calls, the more quickly you can resolve issues — and the less frustrated you feel.
You can best use Wireshark to troubleshoot call completion issues. You can’t as easily identify call quality issues (for example, clipping, echo, and static) by using Wireshark, so either your carrier or your VLM software needs to pursue those issues.
Your VoIP carrier requests specific information from you when you report the issue. You may not have direct access to this information without a capture. You might not know exactly which outbound port it took. If you have a complex, least-cost routing configuration established, which routes calls by the area code and the first three digits in the phone number and includes roll-over to other providers if your primary VoIP carrier is maxed out, the Wireshark capture may be the only way to definitively identify which carrier processed the affected call.
When troubleshooting a failed VoIP call with Wireshark, follow these steps:
1. Open a packet capture and redial the failing number.
If the call completes, then you have an intermittent issue. Continue to make test calls until you capture another failed call.
2. Open the failed call in Wireshark.
Open the file that contains the packet capture and identify all VoIP calls within the capture by choosing StatisticsOVoIP Calls from the main menu bar. Select the specific failed call in the pop-up window that appears.
3. Graph the failed call, review the SIP methods and responses passed between your SIP proxy and the SBC of your carrier, and identify the source of the failure.
It may be as simple as your VoIP carrier responding to your invite with a 4XX response code or one end of the call issuing a CANCEL order. If the call failed because of a 4XX response from your carrier, open a trouble ticket with it engaging it for resolution. If the issue originated with your hardware, investigate the Dial Plan in your VoIP phone system.
4. If the information in the graph is inconclusive, prepare a filter for the specific call and apply it.
Return to the main screen and review all sections of the packet to isolate any mismatch in the handshaking or negotiation by expanding all sections to include
• Session Initiation Protocol — Message Header: Check the SIP URIs, IP addresses, and port numbers in the FROM, TO, and
CONTACT sections.
• Message Body — Session Description Protocol: Focus on the IP addresses and port numbers listed for the RTP, as well as the specifics of the media description, including the codecs offered and negotiated, as well as specifics for the RTP required in the media attributes section.
If you must open a trouble ticket with your VoIP carrier, it may ask you for specific information on the failed call. Figure 11-9 shows the information your carrier may ask you to provide.
Here’s the information circled in the SIP message header, by location:
FROM field: Origination IP address and phone number for the call
‘ TO field: Destination phone number and IP address for the carrier’s SBC to which the call was sent
TO field (below the destination phone number and IP address): The
Call ID of the failed call
Your carrier also needs the basic information required in a call ID, which I talk about in topic 13, as well as one final piece of VoIP specific information — the 4XX or 5XX SIP response that results in the call failure. Not every VoIP call failure is rejected with a clean SIP response, but if one is presented, your carrier may ask for it.
Common trouble ticket information.
Figure 11-9:
Common trouble ticket information.


Next post:

Previous post: