Wireless voice applications are much less forgiving than data applications. Where data will retransmit a packet that is not acknowledged and the end user is none the wiser, a voice end user will certainly hear a delay or lost or choppy audio.
The controller, Wireless Control System (WCS), and third-party spectrum analysis tools can provide you with information to locate the source or sources of poor audio.
Basic Troubleshooting/Connectivity
You can resolve the majority of wireless voice issues simply by verifying the configuration of the controller and network connectivity. Verify that the phone is registered to CallManager and whether you can ping the phone from the network.
Note Pings should only be used to verify network connectivity, not latency. If a 792x phone is not on an active call, ping times can be as high as 2000 ms even if the Call Power Save Mode is set to None.
Tip To quickly analyze a controller configuration for voice, you can use the Cisco WLC Configuration Analyzer with the voice checks enabled. You can download this tool at http://supportwiki.cisco.com/wiki/index.php/WLC_Config_Analyzer.
Also check the firmware build running on the phones. In most cases, the latest firmware build available for the phone is the best version and has fixes for problems found in earlier releases.
From the phone graphical user interface (GUI), you can check the firmware release running on the phone by going to Settings > Model Information > App Load ID. Here you should see the build such as CP7921G-1.3.2.LOADS. Should you see a build such as CP7921G-MFG-D.1LOADS, the phone is running a manufacturing build, and you should upgrade the phone to an official release.
If the problem is association or authentication, verify that the phone has the correct SSID and authentication configured. SSIDs are case sensitive. If the WLAN is using an SSID of "Voice" and the phone has the SSID configured as "voice," the phone will fail to associate.
Tip It is easy to add an unintentional space after entering the SSID, username, or password when configuring the phones using the phone keypad. Be mindful of this when configuring the phone settings.
The 792x phones by default require that the 12 Mb data rate be enabled. If you disable the 12 Mb data rate on the controller and do not change the phone settings, you will not be able to make calls.
Use the site survey tool built into the phone to see the channel, Received Single Strength Indicator (RSSI), and Channel Utilization of the AP the phone is associated with. Remember that the phone should always see at least one AP at -67 dBm or greater.
The output of debug client taken from the controller command-line interface (CLI) provides insight into why the phone is failing authentication. Example 11-3 is partial output from debug client showing a 7925 trying to authenticate using PEAP.
Example 11-3 debug client with 7925 Using PEAP
In this debug you see 802.1x timeout events for the phone. This means that the controller has forwarded a request from the RADIUS server to the phone and the phone is not responding quickly enough. When you are using EAP methods to authenticate the phones, it takes more processing power and the phones are just not fast enough, so the controller times them out. To prevent this, you can increase the advanced EAP request timeout values to provide the slower clients more time to respond.
To increase the EAP timeout values on the controller, use the controller CLI:
config advanced eap identity-request-timeout 20 config advanced eap request-timeout 20 save config
Caution Although you can adjust the retry values as well, increasing the retries can disrupt the network, so use caution when doing so.
You can see the current timer settings using show advanced eap from the CLI, as shown in Example 11-4.
Example 11-4 show advanced eap Command Output
As you can see here, the EAP identity and request timeouts are only 1 second by default. This is not nearly enough time for a wireless phone to process a certificate or Protected Access Credential (PAC) file.
Note In older code, the EAP timers were aggressive. Starting in code Release 5.2, these timers now default to 30 seconds. That should be more than enough time for most clients.
Keep in mind that if you are using CCKM, you will want to use TKIP and not AES encryption because the 792x phones cannot use CCKM with AES. If you are using TKIP, you will want to disable the TKIP hold-down timer for MIC errors. The TKIP counter-measure is triggered when an AP detects two MIC errors within 60 seconds. When the countermeasure takes place, all TKIP clients are deauthenticated, and no TKIP clients can connect for the duration of the hold-off period. By default, the TKIP countermeasures are enabled with a hold-off period of 60 seconds.
You can disable the TKIP countermeasure from the controller CLI using the following commands:
If just a single phone seems to be having issues but the rest of the deployed units do not, you can try resetting the problem phone to factory default and reconfiguring it.
To reset a 792x to factory default using the phone keypad, go to Settings > Phone Settings. While on the Phone Settings main page, enter **2. You then see a message on the screen stating, "Start factory reset now?" Choose Yes to reset the phone.
Choppy/Lost Audio
Choppy or lost audio sounds like a robotic voice to the listener. If packets are lost, the phone tries to retransmit four times but then stops and you lose audio. Lost packets can be caused by RF conditions or incorrect QoS configuration on the wire, the controller, or the voice device.
Even if you have a single phone, the channel utilization can be quite high because of other devices. Non-802.11 devices such as microwaves or cordless phones, other legitimate wireless devices like laptops, general background noise, and so on all contribute to channel utilization. High-channel utilization can prohibit the phone and AP from hearing each other. For example, if you are using a phone near a working microwave that is poorly shielded, the entire 2.4 spectrum can be affected and severely degrade voice quality. Figure 11-14 shows the effect of a microwave on the 2.4-GHz band.
As you can see, all channels in the 2.4 band show extremely high utilization while the microwave is running.
Figure 11-14 Effect of a Microwave in the 2.4-GHz Band
If you have never had a professional site survey conducted, you might have an AP density issue. Not only could the wireless deployment not be dense enough, it could be too dense. Although you want to have 20 percent cell overlap to ensure proper roaming with the phones, if the APs are too dense, the phones will have too many roaming options. High AP density can cause the phones to constantly roam between several APs, resulting in lost ACKs and contributing to choppy audio.
If you have not correctly configured QoS end to end on the wired network and the controller is not running 5.1 code with TCLAS enabled, you might have incorrect forwarding of the voice packets, increasing delay. If the voice application is not correctly marking packets leaving the device, the wired network will not correctly prioritize them.
Figure 11-15 shows a wireless packet from a third-party wireless phone using PTT. Looking at the DSCP marking, you can see that the phone is not marking the packets with EF.
Figure 11-16 shows that the LWAPP packet does have a DSCP marking of EF because the WLAN QoS setting is Platinum, but the encapsulated packet from the phone shows a DSCP marking of unknown.
When the controller bridges the PTT packet to the switch (Figure 11-17), the packet has a default DSCP marking, and the switch will not expedite the forwarding of this packet. This scenario can result in choppy or lost audio.
Figure 11-15 PTT Packet from Third-Party Phone Not Setting EF Bit
Figure 11-16 LWAPP Encapsulated PTT Packet From Third-Party Phone
Figure 11-17 Third-Party Phone PTT Packet on the Switched Network One-Way Voice
When a user experiences one-way audio, the usual culprit is a large power discrepancy between the AP the phone (see Figure 11-18).
Figure 11-18 AP and Phone Power
If the AP is blasting at 100 mW and the phone is at a maximum power of 50 mW (2.4 GHz) or 40 mW (5 GHz), the phone can hear the AP, but the AP cannot hear the phone. This results in one-way audio.
Ideally, you would have Dynamic Transmit Power Control (DTPC) enabled on the controller so that the phone auto-adjusts its power accordingly. The power setting on the APs and the power settings on the phones do not match exactly. If an AP has set its power level to 25 mW on the 5-GHz band, for example, the phone has to adjust its power to 32 mW Table 11-4 shows the different transmit power levels for the phones.
Table 11-4 792x Transmit Power Levels
|
802.11b CCK |
802.11g OFDM |
802.11a OFDM |
|
50 mW (17 dBm) |
40 mW (16 dBm) |
40 mW (16 dBm) |
|
20 mW (13 dBm) |
32 mW (15 dBm) |
32 mW (15 dBm) |
|
8 mW (9 dBm) |
20 mW (13 dBm) |
20 mW (13 dBm) |
|
3.2 mW (5 dBm) |
8 mW (9 dBm) |
8 mW (9 dBm) |
|
1 mW (0 dBm) |
3.2 mW (5 dBm) 1 mW (0 dBm) |
3.2 mW (5 dBm) 1 mW (0 dBm) |
With DTPC, if Client Transmit Power is set in the AP, the phone automatically uses the same client power setting. If the AP is set for the maximum setting, the AP uses the Transmit Power setting on the phone.
You can also experience one-way audio if a firewall or any Network Address Translation (NAT) is in the path of the RTP packets.
If your controller is running 5.0 or lower code, check to make sure that ARP unicast is disabled using show network summary from the controller CLI, as shown in Example 11-5.
Example 11-5 show network summary Command Output
Should ARP unicast be enabled, you can disable it using the following CLI command:
If ARP unicast is enabled, the controller responds to an ARP query on behalf of the client instead of unicasting the request directly to the target host. This behavior can cause oneway audio with voice clients.
Starting in the 5.1 code release, this command is deprecated. Furthermore, the proxy ARP nature of the controller cannot be modified and is always turned off.
