Recently, I was working on a VOIP over Wi-Fi issue for a Japan customer. The complain from the user is that the VOIP calls over Wi-Fi goes static or disconnects often. I started to Debug this issue analyzing the station log to see the behavior of the client while its associated to wireless network. I couldn’t find the issue straight forward.
Checked to Confirm the RF Numbers and Network configuration with best practices for VOIP over Wi-Fi is already in place. So, i though its better to sniff the Air and read the packets to narrow down the issue.
VOIP SETUP IN PLACE: Android phone running VOIP application.
-Android client 4.4.2
-VOIP Application :Covia Networks(softphone)
My first level of Troubleshooting analysis on the aircapture took a different direction while analysis the packets in Ominpeek with the time frame of issue mentioned (I was bit lazy at this point)
Attached the Wi-Fi packet capture for your reference. Packets to look for are #45571,#65972
>I felt, haaa why is the AP sending CTS frame with a 10000 Microsecond of duration time.
>You see Omnipeek EVENT/LOG viewer tells so. The AP has sent this CTS frame to the client device with 10000 microsecond
Then i was looking at the same capture on wire shark protocol analyser(no event or log view ) and realized that client has never sent an RTS frame requesting for channel access.
>I then realized its a CTS TO SELF frame from Android client with high duration values set and that’s causing all the problem for VOIP application running over it.
>I felt, i gone so lazy that i almost decided that the issue is because of the AP sending high duration value by comparing EVENT/LOG in Omnipeek.(that was definitely incorrect).
>The android client build with Broadcom SOC chipset , so no quick fix from client side on this issue. Customer was asked to run the VOIP application on a different client device to sort this client side issue(Workaround i was able to suggest for)
Packet capture download link: