We have a new deployment where we have 5 total 7921G wifi phones connected via 2 AP541n access points, one connected to a ESW520p switch and then to the UC540 and the other connected directly to the UC540. The wifi phones are intermittently giving no audio when calling each other, however, calls to the PSTN consistently do have 2 way audio. Is this a security issue perhaps? We are running the latest CCA software pack as this is a brand new deployment, also the AP's were upgraded to the latest firmware. HELP.
Hmmm. We have a new 7921 and 7925 phone load (1.3.4) which corrected some one way audio issues.
You would have to download the phone load from CCO and then follow this procedure, which shows 7925 as an example. Both would need to be done if you want to try.
I looked through the resolved caveats for the 792x 1.3.4 FW and I don't see any that appear to match this problem. When this problem occurs, it is not like quality issues caused by intermittent packet loss or delay. Instead, when this occurs, there is NO audio in at least one direction of the call for a prolonged period of at least 10 to 30 seconds. Most often, this will occur until the call is disconnected.
Also, Cisco Small business support is telling me that the 1.3.4 FW for the 7921G has not been tested with the UC540 yet. I want to make sure we don't add any additional problems into the mix here. Can you confirm if this FW is tested and working on the 7921? Thanks.
I can tell you that I had at least 3 Partners who 'had to' download the FW to correct the audio drops, which I agree is somewhat different from what you mentioned as the manefestation of your problem. They reported it corrected the problem.
The SBSC is procedurally accurate in that until you see that phone load in a bundle zip for UC 500, its not 'officially' supported. When 8.0.2 came out yesterday, I spoke with the BU about those phone loads (7921 and 7925) not being in the zip (they are still 1.3.3), and was told it may have been a timing thing that prevented their inclusion, perhaps to the fact that solution test didnt soak them in long enough.
Remember I produced that cheat note on how to manually add the phone loads? It is a beast to do, no doubt. And the kick in the head is if you SW upgrade to a bundle like 8.0.2, it will wipe out those changes, unless you dont select those phone loads (thinking out loud, havent tried yet). if it did, you'd have to do it again...
But this is something we do in UC500 land, where to make it easier, we bundle what you can otherwise find on CCO yourself. This phone load is on CCO, so its a good one. I am running it in my home as well and in my lab.
If I were you, I would try it. I think its a calculated risk I would take to see if it fixes this...
I have the exact same issue but with different hardware on the infrastructure side. I am running 1.3.4SR1 firmware (this is the lastest release available from CCO) on all of our 300+ 7921 phones in our hospital campus. We are on 7.1.5 CM and up until recently we had not had this problem, when it was reported to me about a month ago we were on 1.3.3 firmware at the time and I opened a TAC case describing this very issue, they immediatly asked me to upgrade to 1.3.4SR1 which I was told had numerous fixes it in, I deployed this and waited about 2 weeks. Then I started getting complaints again that while it definitely seemed to be happening less often there were still intermittent reports of one-way audio on calls between 7921 handsets, usually on calls from the same floor or area. The problem NEVER happens when PSTN calls are made inbound or recieved to the 7921, only on calls between like handsets which makes me think the call manager setup is correct and the wired infrastructure as well. My gut tells me this is a wireless problem (likely in the phone itself) but Cisco Professional Services designed and implemented this WLAN from the ground up and best practices were followed throughout. This problem is becoming quite painful to me, I have several managers wanting answers and so far I have not been able to give concrete responses. I asked TAC if I should upgrade my 4404 wireless controllers to newer code and their response was that they don't make those recommendations unless a specific bug is identified and to date there is not one "officially" identified. So I am stuck, here is the hardware involved, if anyone has any other ideas or thoughts please let me know, thanks. I have opened about 3 seperate TAC cases on this and can dig up the SR numbers if anyone else is interested.
3ea Wireless controllers 4404 running 220.127.116.11 code, connected in LAG to 3ea Catalyst 3750-12G switches in 3 different port-channel groups (1 per LAG group per controller per switch) all in the same mobility group
150ea 1131 LWAPP access-points connected to 20 different Cat 3650 24 port POE switches scattered across the campus
Call Manager 7.1.5.0000-12 (1 PUB and 1 SUB)
300ea 7921 phones across 20+ different areas running 1.3.4SR1 firmware using EAP-FAST authentication
We are also having the same issue. We replaced out Cisco 1242 APs with new ones from Meraki and are intermittently getting one way audio for 10-30 seconds. I was able to narrow down the cases when it happens and almost 100% of the time it occurs when the two 7921g phones are associated to the same AP but one (or both) roam to another one. If the two phones at the beginning of the call are associated to different APs both phones can roam and it is extremely unlikely for that audio gap to occur and even if it does it is sub-1 second at the most... Would you be able to test that scenario and see if I am on the right track
And you are right - PSTN calls are unaffected - only 7921 to 7921. I also tested a call between a 7921 and my Nokia E71 (SIP) which is registered with the call manager and it is unaffected as well.
I can also tell you that I have tested scenarios with no authentication since I suspected that the delay was caused by that but still had the same result.
Tested also with all the APs on the same channels 1 and 44 and configured all the phones to only look for these channels to no avail... Also had the phones use b/g only, a only, auto a, auto b/g and autorssi and that had no effect either. Also through the call manager (we just upgraded to ver 8) I configured the phones to do Continuous AP scan (default was Auto which scans for new APs only during an active call) and that had zero effect....
I have also tested this scenario in the past and I found that phones associated to the same ap
did seem to have a higher incidence of the one-way audio condition but not every time. We have 3 4404 controllers and I did note that every time I a complaint the phones involved were on the same controller. I could not reproduce the problem EVER if the phones were associated to aps on different controllers, TAC assured me that this was unlikely related to the issue but I have my doubts. Since upgrading the phones to the latest firmware 1
.3.4SR1 initially I was still getting complaints of the condition occuring so I decided to reboot the POE switches involved with the problem areas since they had in some cases been up for 2+ years, this was just a last ditch effort but for whatever reason that seems to have cleared up the issue. I have not had the issue reoccur in the past 2 weeks since rebooting those switches, I also believe that some of the phones in question had not yet received the update and because of this I was getting false reports of upgraded phones still having the issue. I found two seperate cases where one of the phones in question still had 1.3.3, after forcing the upgrade they were fine. So first thing I would do is make sure the phones have 1.3.4SR1, then I would check to see how long the switches connected to your AP's have been up and also perhaps the IOS version, if they are Cisco switches it may not hurt to contact TAC and see if they can recommend an IOS that would be a good candidate. Another thing to make sure is that your QoS settings on all the switches involved are set correctly. We had tons of problems initially when we first started using the phones on the wireless network. We thought our QoS was set correctly but what we found was there was some IOS bugs on some of the switches downstream that required special switchport commands to "fix". Most dealt with the qos trust dscp command, some switches had to have the dscp tag and some had to have the cos tag, very strange and it took several CCIE's several days to come up with the final solution after many wireshark traces to make sure the QoS tags were making it all the way through.
Watch, now that I am writing you that my problems seem to be fixed, I am sure Murphy will raise his ugly head and ruin my Friday
Thank you for the prompt reply. I logged into each phone and even physically inspected them to make sure they have received the latest firmware. It seems like the only thing left is to reboot the switches (they are all cisco and were professionally installed by a Cisco gold partner along with the call managers, unity and the phones so I'd like to believe the the QoS is configured correctly but who knows a few CCIEs might disagree ..) . I also work for a hospital and even though our deployment is much smaller than yours I can relate to the hassle associated with user complaints, scheduling downtime and tracking down elusive wireless issues ...
Have you found a solution to this problem?
I also have the same issue with 7925G ip phones. I have an UC540 with 3 AP 541N and have a 10-15 seconds delay occuring on internal calls from or to a 7925G phone. All my AP are connected directly to the UC540. Can you report what you did to resolve the issue (if you have been able to resolve).
I use software pack 8.1.0 on the UC540, firmware 1.9.2 on the AP and 1.3.4SR1 on the phones.
I am having the same intermittent issues (phones not ringing, calls not completing, loss of audio, etc.) using the 7921 with the AP541s.
Using a UC560 running 8.10, (3) AP541Ns running 1.92, ESW24P running 2.1.19
1.3.2 through 1.4(1)
In my case however ownership of the issue was taken by our wireless AP vendor - Meraki and after some information gathering, testing, etc. it tuned out to be an issue with how the APs hand off the call to each other and more specifically when two phones initiate a converastion while associated to the same AP and one of them later roams to a another one. Strangly if the parties would start the conversation with phones associated to different APs, even if both of them roam there was no issue.
Eventually the problem was resolved by the Meraki developers and a new firmware for the APs.
I downloaded 1.4.1 from CCO. You may want to check the download area again.
I ended up opening up a TAC case on this and here's how the problem was 'semi-resolved'. The engineer disabled trunking and reconfigured the switch ports as access ports, putting the AP ports in the voice VLAN only and using the Other port role vs. the Access Point role. This effectively eliminated the ability for the customer to use the AP541s as a mode for data connection, which is not a resolution in my book, but they were wanting the wireless phones operational, which it did rectify. Luckily, they had other APs to use for data access and given the continuous problems with the 541s, they did not want any of the SBCS gear connected to their data network.
I think the problem lies in the ESW code as I replaced the 541s with 1130 APs and the problem remained with the switch ports configured as trunk ports.
With the issues I have seen with the Small Business products, I am reluctant to offer this line to any of my customers in the future.