Troubleshooting WLANs and VoIP - Two tips for the price of one
By Jim Thor – WildPackets Professional Services
Before we get to the tip, I want to focus for a minute on a tip that is much broader in nature, but still revolves around WLAN Analysis. And this tip focuses on the question of "Where and when should I capture traffic, in the air or on the wire?" The answer to that question usually depends on what the problem or issue is that you are focusing on, or what you are trying to accomplish.
Let me start by asking a simple question. When capturing WLAN traffic, is it necessary to see the payload of the packets, encrypted or otherwise? And the answer to that question is usually (there may always be some exceptions) a resounding NO. And the reason for this is that if you are troubleshooting specific WLAN issues, then the payload is generally insignificant and unrelated to the issue at hand. If the WLAN has performance or quality issues, then you are generally interested in just the WLAN packets and headers, not the data payload of those packets. If the issue you are looking into is an application issue, then remove all the WLAN variables like signal strength, interference, and encryption and do your captures on the wired side of the AP. You will be much quicker at determining the fault, or lack thereof, if you remove a majority of the unknown from your work, mainly the variables of wireless communications.
Let's now focus on tip two on how to validate that WMM is being used bi-directionally for your real time traffic like VoIP. And one of the reasons that we need to do this is because WMM depends not only on the devices like clients and Access Points being properly configured to support WMM and QoS, but more importantly the application itself must be coded by the developer to take advantage of them. If the application does not support WMM/QoS, then it will not use it regardless even if you enable WMM on your devices. So often, one side of the communication may support it (VoIP Gateway or Proxy), while the other side (client or soft phone) may not. And this can cause a lot of quality issues for your real time traffic.
Basically, what we need to do is build ourselves a filter to watch for WMM classifications. The filter below is a good example. With this filter, we are looking for packets that are "not a CRC error, they are 802.11 QoS Data packets, and the Value is Not 0 at offset 24". This means we are looking for any classifications other than Best Effort. You should notice that we have the Mask set in this filter to only look at the last three bits of offset 25. If you need to find a specific classification, just change the value as necessary.
Then, when we select a particular VoIP call or calls, we can apply our filter, and see if both media flows for each call are still in the trace after we are done. Many screens will show us the information we are interested in, but the two primary ones for this exercise would be the Nodes view (Hierarchy), and the Media view.
By looking at the above two screen shots (Left is before filtering, right is after filtering) we can see that now the traffic pattern is uni-directional traffic from the Trixbox to the Client SoftPhone. So, the client is not using WMM in this case, even though he is configured to. This is due to the fact that the SoftPhone software does not support WMM.
In the two screen shots above (top is before filtering, bottom is after filtering), we can see that one Media flow is missing, once again showing us that only the traffic from the Trixbox Server to the Client SoftPhone is using WMM.
And lastly, here we can even validate what protocols are using WMM and what classifications are being used for them. Here we see in the Protocols view, after filtering, that the only protocol still present is RTP, specifically G.711.
We have seen in this paper a couple of tips to help deal with some specifics in WLAN and VoIP analysis. But remember, these tips are mostly just thought processes. You can take these processes, modify them appropriately and apply them in different ways to help you find answers to the questions you have about your environment, regardless what the protocol or application specifics are.