Autonomous AP voice QoS

There are a number of settings one must configure via CLI to get voice QoS working on an AAP.  This is my attempt at putting all of them in a single post...  I can already see the edits coming:

!
dot11 ssid
 admit traffic
//Enables call admission control on the SSID.
!
dot11 arp-cache optional
//Best practices.  Reduces WLAN overhead by allowing AP to respond to ARP for known clients
dot11 priority-map avvid
//Forces the AP to translate from 802.11e to 802.1p
dot11 phone [dot11e]
//Configures the QBSS IE for 7920 or 802.11e (i.e. 7921, etc)
!
!
interface Dot11Radio0
 ssid
 !
 speed basic-12.0 18.0 24.0
//Best practice datarates for 802.11a/g/n; for 802.11b use basic-11.0
 dot11 qos class voice local
    admission-control
    admit-traffic narrowband max-channel 70 roam-channel 6
//sets AP CAC to allow 64% of bandwidth to voice + 6% roaming = 70%
 !
 dot11 qos class voice cell
    admission-control
//Allows the AP to factor in client QBSS readings for CAC
!
!
class-map voice
 match ip dscp ef
class-map video
 match ip dscp cs4
class-map voicecontrol
 match ip dscp cs3
//Create class maps to identify traffic
!
policy-map QoS
 class voice
  set cos 6
 class video
  set cos 5
 class voicecontrol
  set cos 4
//Create a policy map to tag traffic
!
int d0.20
 service-policy input QoS
 servicy-policy output QoS
//Tag the traffic as it traverses your wireless interface
!
int f0.20
 service-policy input QoS
 service-policy output QoS
//Tag the traffic as it traverses your wired interface
!

It is important to ensure that your traffic is tagged on both the wired and wireless interfaces because the traffic could be coming off another SSID on the AP (int d0.10 for example).
I guess that's about it.  Not nearly as daunting when you get them all down in one place ;)

When APs don't register to a controller and have a static IP

I ran into an interesting problem last Monday (02/01/10) at work - someone had deployed APs at a remote location and configured them as autonomous APs. I performed a quick lightweight upgrade on them, and made the mistake of leaving static IPs on them.

The upgrade tool asks for your WLC address so I thought that would prime the APs with that address for the controller... Wrong. As soon as the APs booted to their lightweight IOS (the standard recovery image) I lost connectivity with them (no DHCP so option 43/60 is not available. APs are on a different domain than the switch - why it kept this but not snmp and passwords is irritating - so controller DNS didn't work). Passwords were of course reset, so telnet/ssh responded with "password required but none set." SNMP was also reset... I thought I had lost connectivity to them and would be required to ship out new APs!

In reviewing some of the Cisco literature, though, I found a cool little workaround. You can set the IP helper-address to the IP address of the controller, and then use the "forward protocol" command to forward all CAPWAP/LWAPP traffic to the IP helper-address, i.e. the controller (protocols 12222, 12223 for LWAPP and 5246, 5247 for CAPWAP)! Once connectivity was re-established to the APs, I set them to DHCP and removed the forward protocol commands and set the IP helper-address back to the DHCP server. Problem solved without sending new APs!