cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3316
Views
9
Helpful
30
Replies

7921 problem stops responding etc

jbarger
Level 1
Level 1

Edit: I am going to clean this up a bit to try to get a response.

I am having a bit of trouble with these phones. They connect and work but within 5 minutes the call audio becomes one way. It is always the 7921g phone, it stops receiving audio. The issue is very strange. I have verified many many configuration items and have no where to go. The old part of this post didn't read so well so I cleaned up the detail.

EDIT: cleaned up old post below...

We have Call Manager 4.1. The APs are 1310 running IOS 12.4(10b)JA3. We use WLSE to manage access points. The phones work using EAP-Fast or PEAP on ACS 3.3. I have tried the voice vlan on both the 802.11a and b/g with the same results. I have enabled CAC by using the "Optimize for voice" button and the two check marks for WMM. "Dot11 phone dot11e" and "dot11 arp-cache" are also set on the AP. I don't understand how the power is supposed to work but I set "power level client" on the AP as well as both to lower power levels and such, I will read more about this standard since I am now thinking this is the issue. Anyhow when I turn on the phone it connects and obtains an ip address attaches to the call manager and obtains it's configuration. The firmware also updates if it is not firmware 1.1(1).

As I said above the phone works fine for a little while then it seems like it stops processing packets. When the phone stops working the other party can still hear me speak but I can't hear them. In testing I was pinging the phone and was getting responses until the problem starts then pings starts to fail. While still on the call if I hit a number key on the phone I will hear a few seconds of audio and pings start working but about 2 seconds later it stops again. I was sniffing the traffic on the AP and I could see that both directions of the conversation were getting to the AP and the call still looks normal even after I can't hear. After stopping the call I see the phone sending ARP requests for the routers IP and it is still not responding to pings. If I hit a key on the phone at this time it will respond to pings for a couple seconds. If I try to make a call right away the call will be setup but the audio is still one way. If I wait a while I will see it lose its connection to CM and eventually it will give up it's IP address. The phone will just sit there trying to obtain an IP address. I verified it is still a CDP neighbor of the AP and a capture of traffic reveals that there are DHCP responses to the requests but the phone never accepts the offer. The AP still shows the phone association with 0.0.0.0 for the ip address.

The phone just stops processing packets but hitting a key causes it to process packets for a few seconds.

I have the same issue on both 1.1(1) and 1.0(5) firmware.

I have tested 2 phones and they both experience the same issue.

I am going to try to remove the power management settings from the phone to see if that is causing the issue. I will let you know on Monday but if you have any ideas please please chime in and thanks in advance!!!

30 Replies 30

jbarger
Level 1
Level 1

Power managemnt is not the problem. Here is a log file from bootup then I made a call and the one way audio problem started a little while into the call.

Here is another log file with a few more lines in it. To get this log file I have to attempt to make a call and the the phone to start responding to pings by hitting keys on the phone... If I don't hit keys on the phone I can't get to the web page to get the file and ping fails until I start hitting keys. This is just nuts :( Here is a sample of the messages after the issue has started...

2008-08-11 08:48:11:0480 CP-7921G user.err SCCP: TRP Timer Expired

2008-08-11 08:48:36:0120 CP-7921G user.err SCCP: pri-tcp timeout<-47>

2008-08-11 08:48:36:0320 CP-7921G user.err netd: SCCP Requested a network status check

2008-08-11 08:48:50:0340 CP-7921G user.err GUI: set LCD -1

2008-08-11 08:48:53:0190 CP-7921G user.err SCCP: Skinny_get_tftpIp: Could NOT getGNetutilVarVal!

2008-08-11 08:48:53:0200 CP-7921G user.err SCCP: Skinny_get_alt_tftpIp: Could NOT getGNetutilVarVal!

2008-08-11 08:48:55:0100 CP-7921G user.err SCCP: Skinny_get_IPconnect: Could NOT getGNetutilVarVal!

2008-08-11 08:48:55:0110 CP-7921G user.err SCCP: fallback to CCM<1 2="" 0="">

2008-08-11 08:48:55:0290 CP-7921G user.err netd: SCCP Requested a network status check

2008-08-11 08:48:57:0080 CP-7921G user.err SCCP: Skinny_get_tftpIp: Could NOT getGNetutilVarVal!

2008-08-11 08:48:57:0080 CP-7921G user.err SCCP: Skinny_get_alt_tftpIp: Could NOT getGNetutilVarVal!

2008-08-11 08:52:40:0350 CP-7921G user.err SCCP: TRP Timer Expired

2008-08-11 08:53:06:0980 CP-7921G user.err SCCP: pri-tcp timeout<-47>

2008-08-11 08:53:07:0260 CP-7921G user.err netd: SCCP Requested a network status check

Umm that sentence should read: Here is another log file with a few more lines in it. To get this log file I have to attempt to make a call and then ocasionally press buttons on the phone to get it to start responding to pings.

Note this is after the phone 'breaks'. Before it breaks I can get the web pages fine for as long as I want. It only breaks during a call. After it breaks...

If I don't hit keys on the phone I can't get to the web page to get the file and ping fails until I start hitting keys.

If issues in the rx path, check the network stats on the 7921 webpage for any discarded packets to see if the phone is receiving the RTP packets or not. Really not much the phone can do from the rx side of things, except when using power save, it must send a trigger packet to rx the packet (i.e. U-APSD). If you set the On Call Power Save mode to None in the network profile, then this shouldn't be the issue.

I see that you have opened a TAC case and saw the picture for the call stats showing the MOS 2.0 reflecting 1 way audio and the loss was on the rx side. Also saw that packets are holding the correct DSCP value as well, but also want to ensure they are being sent downstream from the correct queue. In 1.1(1) in the network stats local menu, can see rx stats for each queue. Should see the VO queue #s increasing when on call.

I have disabled U-APSD power management on the phone and still have the same issue.

I will grab the network stats page after a failed call tomorrow and post it in my tac case.

And thanks for the reply. The TAC case is progressing well I hope I will be getting 1.2(1) firmware for testing. But I can say the engineer has not had the time to really look at all the data I have posted and I have had to recommunicate these details... Now where are all the other folks having this issue?

HAHA

I am not certain I know which screens you wanted to see... I put a wireless and a network statistics image in my ticket.

The

I am upgrading to 1.2(1) right now to test that firmware.

jbarger
Level 1
Level 1

Well it turns out to be POWER!!

The AP would decide that the client was in power save mode and buffer packets instead of forward them to the phone.

They are sending the issue to the developers... No solution yet. Probably have to downgrad the AP but hopefully they will supply an upgrade.

When you do a show dot11 association mac the line power save is ON.

It may show that power save on even if not using U-APSD or PS-POLL, where the on call power save mode in the network profile is set to "None". It could be off channel scanning for ap discovery, where it would have to send a null data frame with the power save bit set.

Yes, even when I disable U-APSD the power save mode the AP still switches to power save ON.

That is why I thought it was not power until I was working with TAC who helped me find the exact issue.

A possible workaround for the 7921G phones on an 1131 AP. I was able to have a 20 minute call stay working by by disabling U-APSD on the phone and removing dot11e from the AP.

"dot11 phone" instead of "dot11 phone dot11e"

#1 With the AP set for “dot11 phone” not “dot11 phone dot11e” and the 2971 has U-APSD turned on the AP Shows power-save ON during a call.

The one way audio issue happened in about 5 minutes.

#2 With the AP set for “dot11 phone” not “dot11 phone dot11e” and the 2971 has U-APSD turned OFF the AP Shows power-save OFF during a call.

The one way audio issue did not happen for 20 minutes and I quit trying to get it to happen...

If anyone is interested disabling dot11e and U-APSD did work. Calls have stayed connected for over 1 hour.

Dot11 phone dot11e is QBSS, which is the CU (channel utilization) # you see in the 7921 neighbor list. This has absolutely nothing to do with power save or would prevent the phone from working. The 7921 only uses this for possible roaming and not per say CAC.

It appears that you are having some issues with U-APSD in your environment. I know it was working well in previous AP IOS versions (i.e. 12.3(4g)JA1 and 12.3(8)JEC).

I did look at your sniffer trace and with WMM enabled U-APSD was negotiated properly, but for some reason the AP was not forwarding packets until it entered active mode, which is when you press the keypad (by design). However, you can see the 7921 sending RTP packets all the time, but not getting anything return. With U-APSD, the client must send a trigger packet in order for the AP to send queued packets, which it is doing that. I heard the trace was between 2 7921s, but the other 7921 was on another ap / channel, so couldn't see what it was doing, but because all the packets were spit out after entering active mode, I can assume that the other client was transmitting RTP the whole time as well. So appears there is an AP issue with U-APSD on this code version or some issue in the wired network. I think it's on the ap side though since power save disabled enables it to forward the packets successfully.

So if you disable WMM, "no dot11 qos mode", then PS-POLL will be used instead if the 7921 is configured for U-APSD/PS-POLL for on call power save mode in the network profile. If you set it to "None", then will use active mode, however in client status it may still show up as power save due to going off channel via ps-null power save packet to scan other channels for ap discovery.

So disabling WMM is a temporary workaround for you, but definitely not a recommended solution as now there is no QoS.

Thanks for the detailed explaination and sorry for the late response. I had to give the phones to the users so I can't do any more testing right now but I have asked for a loaner RMA phone and will test it with 12.3.8 when I get a chance... I do have some of the old style QoS but the whole QoS thing just need to be looked at in detail once we are happy with the power management.

I find it crazy that Jake was unable to reproduce the trouble since I had so much trouble getting a work around. :)

Anyhow I will update when I get the test phone...

We had an issue where our 7921 phones kept locking up, we had to downgrade to firmware 4.2.130.0 on our controllers to clean it up. We were running 5.0.148.0

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: