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.

http://www.cisco.com/en/US/docs/voice_ip_comm/cuipph/7925g/firmware/1_3_4/english/release/notes/792x_134.html#wp192837

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...

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.

Thank you.

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

7921 phone FW?

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.

Sorry, Steven...should have included that earlier.  Using 1.4.1

1.3.4 is the latest 7921 phone FW.

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.