We have a new deployment with a Cisco 4402 and 1131 AP's. The phones are 7921's and the network consists of a 3560 (network routing device), and 2960's as the access devices. The wireless phones are on their own VLAN as are the wired phones. We are using Berbee's push to talk application server which resides on on VLAN 200 (wired phones vlan). All VLAN's have sparse-dense mode running on the interfaces and the wireless controller has multicast enabled (igmp disabled on the WLC). The push to talk application works but there are quality issues going from wireless phone to wireless phone and wireless phone to wired phone.
The issue appears to be the wireless controller (running 5.2.196). The audio from the 7921 push to talk app sounds really choppy on the receiving side. All voice calls between 7921's and any phone work great, no issues at all. The issue is just the 7921 using push to talk.
There is no traffic on the wired or wireless network today so I highly doubt this is a QoS issue.
Solved! Go to Solution.
I would upgrade the code on your controller as a first, 6.0 has better multicat capabilities and may solve the prob.
Check out the release notes.
Code prior to code 6.0 sends multicast frames at the highest configured data rate which means clients at lower data rates may not hear the frames.
I set the only mandatory data rate to 12 on the 2.4GHz radios and this appears to have fixed our problem. I turned the wifi phones off and changed it back (having 1,2,5.5,11 as mandatory) and the issue came back up. As soon as I changed the mandatory back to 12 (and only 12), the issue was gone. I'm aware that no B clients will be able to connect but that would only affect guests which aren't of a huge concern. Thanks for your help, I really appreciate it!
Do you know of any good documents that explain how wireless clients use mandatory/supported data rates? Mainly I just want to understand exactly why having more than one mandatory data rate would cause an issue.
thanks for your rating and glad your problem was solved. I do not see any short document on this principle, but this is how it works:
Speeds can be mandatory, supported or disabled.
"Mandatory" means that the client HAS to be able to support that speed to be allowed to associate. "HAS" does not mean NOW, it's just a driver support.
"Supported" means that whether the client driver supports that speed or not, the client can associate.
"Disabled" means that this speed cannot be used on this AP.
That's the background. Usually, several speeds are "mandatory" by default. Each of them matches one modulation method (how you encode the frames you send). Making them mandatory ensures that all clients understand what the other clients are saying.
The AP tells its clients which speeds are mandatory, supported and disabled, and clients comply (if they can).
So one thing you are sure of, is that all clients support all mandatory speeds.
The issue is that clients close to the AP will use high speeds (mandatory or supported), clients far from the APs will revert to slower (but safer) speeds (mandatory or supported).
So when you want to send a message to all clients in the cell, you are going to use a mandatory speed (so that ALL clients understand it), and a low speed (so that far away and close clients can get it). You typically use the lowest mandatory speed.
When you want to send a multicast message, you think it as a type of broadcast, as you send it to more than one client. To be on the safe side, you would send it at the lowest mandatory speed.
The problem is that Cisco, when this feature started to be supported, sent it at the HIGHEST mandatory speed instead of the lowest. Why? Long story... but in any case, this "abnormality" is corrected in 6.0.
For all codes before 6.0, the trick I mentioned is the way to go around the problem.
Just a warning: the lowest mandatory speed is also the speed used to send beacons... so you probably want to set the lowest mandatory speed to the lowest speed you support, for example 6 Mbps. If you set your mandatory speed to 12 Mbps, but still allow 9 and 6 Mbps, you will have clients that will associate to your cell and that will not get beacons and multicasts when they move away from the AP (from the 12 Mbps zone to the 9 or 6 Mbps zone), and this will create problems. So you can disable 6 and 9 (and leave mandatory to 12), or push mandatory to 6 (and set 9 and 12 to supported). The second choice is usually better (because you may have wireless devices in your 6 Mbps area, trying to discover the network, and sending probe requests without realizing that they are colliding with your AP messages).
Hope it's clear enough!
For changing the basic rate to ony 12 Mbps, we have seen that multicast doesn't work well at the higher rates (i.e. 24 Mbps and above).
Per the 7921/7925 Deployment Guide, it is recommended to set the single basic rate to 12 Mbps.
We have the same issue with 7925 and WLC 5500 soft 6.0.
First about 5 sec sounds choppy and is unacceptable. This is only if direction is to 7925, does not matter from. Our workaroud is to disable the power save mode in phone configuration.
We are not recommending to use the 6.0 release for the WLC if using the 7921/7925 phones.
We recommend to use 22.214.171.124.
For the choppy audio issue, are you using CM or CME?
There is an open issue with CME where this can happen due to RTP packets getting classified as UP4 due to CME using the same port for SCCP and RTP.
That issue will be addressed in our 1.3(4) release.
But if you disable power save mode, that is basically telling the phone to use active mode when on a call, but will still use power save when in idle.
With that config, the battery life will be impacted significantly.
I see. Would suggest to reach out to TAC for assistance then and see if you are encountering any known issues and then if any ES is available.
"But if you disable power save mode, that is basically telling the phone to use active mode when on a call, but will still use power save when in idle.
With that config, the battery life will be impacted significantly."
I think it is true for VoIP but with PTT phone is in active mode all the time so battery time is about 4 hours :-(