Autonomous Call Admission Control, admit-traffic?

On the autonomous APs, you can configure Call Admission Control (almost) like on the WLC. This feature allows you to decide how much bandwidth is allocated to Voice traffic on your radio.
But there are 2 places where you can set CAC (thus this article): in the QoS page and at the SSID level... so what is the difference?
To get what is going, a bit of background. You can setup Call Admission control in Services > QoS > 802.11b/g (or 802.11) Access Categories, by the bottom of the page:

This configuration adds the following line to the radio configuration:

dot11 qos class voice local
   admission-control
   admit-traffic narrowband max-channel 75 roam-channel 6

The result is that admission control is set on this radio. Voice can use up to 75% of the available bandwidth (based only on the AP dot11 traffic. To also use the noise and other APs activity, you need to get a controller and use Load based CAC). From these 75%, 6% are kept for roaming users (so that users roaming from other APs do not get disconnected when jumping to this AP).
This configuration applies to the radio, not to an SSID in particular. So any traffic matching voice classification (802.11e UP 6 and 7) on this radio for all SSIDs will be seen and controlled.
As this refers to 802.11e UP, the underlying expectation is that WMM is enabled on that radio. WMM is enabled by default, but could be disabled from Services > QoS > Advanced, for 802.11b/g or 802.11a. On the CLI, WMM is disabled with the radio command:
no dot11 qos mode

If you disable WMM, then the AP does not care anymore about the QoS field in the clients frames, and although WMM clients could still internally prioritize voice packets, the AP would not apply any admission control of any kind anymore.

Okay, but what if you do not set Call Admission Control? Could that be a problem? Well, yes. Many phones (and in particular the 7921) send TSPEC (traffic specification) information in a ADDTS QoS frame when roaming. If this is Greek to you, let's translate by saying that the phone tells the AP to which it is roaming that it wants to use a certain class of service. If CAC is not set, the AP does not really care about the type of traffic the client wants to send (as it is not going to filter the clients based on what type of traffic they send). The result is that, in the early days of this WMM adventure (in 2009!), the AP was responding to the phone reassociation request with a reassociation response that was not containing the CCKM information element, informing the phone about how fast roaming was handled (remember my default 6% bandwith left for roaming users? That's what we are talking about, the phone needs to know if there is space left on this new AP or not). Without this CCKM IE, the phone was lost and was hanging there, wondering what to do (wondering in fact if any other, better AP would be in range), before finally joining the AP anyway. This created a gap in conversations of about 1 to 1.5 seconds.
To go around this issue, you could then configure the SSID itself to say: "even though I do not set any specific call admission control or limitation on how much bandwidth can be used by this or that type of traffic, I do welcome VoIP traffic and BTW I do CCKM". This message was sent by setting the admit-traffic command under the SSID:

dot11 ssid XYZ

admit-traffic

On the Web interface, this is done at the bottom of the SSID page:

In other words, the admit-traffic SSID command allows you to improve your CCKM clients roaming performances, without the need to limit the bandwidth allocated to voice users (local voice users or roaming voice users).
Now, what if you do have CAC enabled?... do you still need to set admit-traffic under the SSID? The answer depends on the IOS code and the associated AP hardware. The short answer is: if the admit-traffic (Call Admission Control) command is available under the SSID, always set it. Otherwise, you may have CAC set at the radio level, but the SSID blocking the TSPEC SCCP messages, in other words not answering with the CCKM IE anyway.

In a pure lab mindset, the prerequisite is that your AP runs a code where this feature is possible. The second requirement is that roaming is involved. If there is no roaming, you may want to set CAC to limit the VoIP bandwidth consumption, or you may not care about CAC. In all cases, a 1 to 1.5 second initial delay does not mater. It is an issue only when roaming is involved. So... read your lab scenario carefully.

Last tip: the default rate for TSPEC on the 7921/7925 is 12 Mbps, which should be enabled on the AP.  Make sure that 12 Mbps is always allowed on the radio that those phones use, otherwise your will be missing those messages, and you would be back to the voice gap issue.