Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

7921G wireless phones drop audio when roaming

Hi all,

 

We had this issue originally over 5 years ago.  Deploying 7921G firmware "CP7921G-1.4.1SR1.LOADS" sorted the problem out. Thus, for over 5 years we have had trouble-free 7921G roaming/audio. The original issue was our use of CCKM authentication and older firmware not allowing seemless audio between AP roams.

 

Our setup:

CM 6.1(2)

7921G using firmware v1.4.1SR1

WCS and WLC  7.0.230.0

 

 

A little over a month ago (despite nothing changing on our CM or wireless system) we started to experience bad audio again when roaming - audio drops out, returns, or just drops out totally. (The only recent changes have been to migrate DNS to an InfoBlox platform hosted at our USA site. I can't see how this would cause a roaming issue though)

We have pulled logs from the following devices (all set to 'Debug' or 'Detailed' setting)

  1. CallManager RTMT (capturing the subscribers CM Service where the phone homes to, then filtering via 7921G IP address using TranslatorX)
  2. CallManager packet capture from the CLI (filtering on the IP of the 7921G phone)
  3. 'Debug' level trace logs (all logs) from the 7921G phone web GUI
  4. Cisco WCS logs

 

Log set 1 doesn't show any detail other than keepalive/handset OnHook detail etc.  Nothing is shown before the audio drop out occurs.

Log set 2 doesn't show anything either at the time of the audio drop out.  The log seems to consist of SCCP keepalives and ACK responses.  

Log set 3 does show something odd at the time of the audio dropouts.  When the audio drop occurs, the Wireless LAN driver debug changes from this:

2014-09-03 10:46:54:0220 CP-7921G user.warn kernel: WLAN_DRVR: 4038.109810: Current AP MAC Address:00:25:46:83:e3:5d

2014-09-03 10:46:54:0220 CP-7921G user.warn kernel: WLAN_DRVR: 4038.116111: CurrentAP channel utilisation=13, call admission limit= 105, QBSSDiff = 0 AAL = 5b8d

 

To this:

2014-09-03 10:46:54:0940 CP-7921G authpriv.debug AUD: KTM_SetTimer: timer_id: c172bea0 -checkHeadsetTimer- oneshot_time:1000 0 en 1 

2014-09-03 10:46:54:0950 CP-7921G user.warn kernel: WLAN_DRVR: 4038.826800: Current AP MAC Address:00:25:46:83:e3:5d

2014-09-03 10:46:54:0950 CP-7921G user.warn kernel: WLAN_DRVR: 4038.833092: CurrentAP channel utilisation=c, call admission limit= 105, QBSSDiff = 0 AAL = 5b8d

 

The differences seem to be that utilisation=13  changes to utilisation=c.  There also appears to be a KTM_SetTimer notification too (this may be irrelevant)

 

Log set 4 (Cisco WCS) also shows something odd at the time the audio drops out. The message below seems normal:

Time :09/02/2014 16:22:37 BST Severity :INFO Controller IP :10.164.253.12 Message :Mobility role update request. from Unassociated to Local Peer = 10.164.253.11, Old Anchor = 10.164.253.12, New Anchor = 10.164.253.12

Time :09/02/2014 16:22:37 BST Severity :INFO Controller IP :10.164.253.12 Message :Mobility role changed. State Update from Mobility-Incomplete to Mobility-Complete, mobility role=Local, client state=APF_MS_STATE_ASSOCIATED

 

However it becomes the following at the point the audio drops out (note that the Anchor IP becomes 0.0.0.0, and there is a message about WPA2 algorithm issue too)

Time :09/02/2014 16:22:28 BST Severity :INFO Controller IP :10.164.253.14 Message :Mobility role update request. from Local to Handoff Peer = 0.0.0.0, Old Anchor = 10.164.253.14, New Anchor = 0.0.0.0

Time :09/02/2014 16:22:28 BST Severity :INFO Controller IP :10.164.253.14 Message :Client Moved to DHCP Required State.

Time :09/02/2014 16:22:39 BST Severity :INFO Controller IP :10.164.253.14 Message :Controller association request message received.

Time :09/02/2014 16:22:39 BST Severity :INFO Controller IP :10.164.253.14 Message :Association request received from a client has an invalid RSN IE.(One reason could be mismatch in WPA2 algorithm).

Time :09/02/2014 16:22:39 BST Severity :INFO Controller IP :10.164.253.14 Message :The WLAN to which client is connecting requires 802 1x authentication.

Time :09/02/2014 16:22:39 BST Severity :INFO Controller IP :10.164.253.14 Message :Client moved to associated state successfully.

Time :09/02/2014 16:22:39 BST Severity :INFO Controller IP :10.164.253.14 Message :802.1x authentication was completed successfully.

Time :09/02/2014 16:22:39 BST Severity :INFO Controller IP :10.164.253.14 Message :Client Moved to DHCP Required State.

Time :09/02/2014 16:22:39 BST Severity :INFO Controller IP :10.164.253.14 Message :DHCP successful.

Time :09/02/2014 16:22:39 BST Severity :INFO Controller IP :10.164.253.14 Message :Client has got IP address, no L3 authentication required.

Time :09/02/2014 16:22:39 BST Severity :INFO Controller IP :10.164.253.14 Message :Client IP address is assigned.

Time :09/02/2014 16:22:39 BST Severity :INFO Controller IP :10.164.253.14 Message :Mobility role update request. from Unassociated to Local Peer = 10.164.253.12, Old Anchor = 10.164.253.14, New Anchor = 10.164.253.14

Time :09/02/2014 16:22:39 BST Severity :INFO Controller IP :10.164.253.14 Message :Mobility role changed. State Update from Mobility-Incomplete to Mobility-Complete, mobility role=Local, client state=APF_MS_STATE_ASSOCIATED

 

 

Because of the difficulty in generating all four sets of logs at the same time, I've recreated the audio drop-out error on numerous occasions, gathering individual logs each time (hence differing timestamps between logs). I've looked thru differing sets of logs from the same source and cannot see any differences in one capture set to another which might have explained the problem.

 

At this stage I'm not certain where or what to try next.  A firmware upgrade on a single 7921G is one avenue I want to try, but at the same time I cannot understand why the firmware would be an issue after it's been working fine for over 5 years?

 

 

Any thoughts appreciated. At this stage i think the issue lies with out APs/WLCs and is a wireless-based issue rather than CM or 7921 firmware.

 

 

Rgds

 

 

 

 

91
Views
0
Helpful
0
Replies