IP 8821 phone "network busy"

[SDSDFWEEWR]

IP 8821 phone "network busy"  no incoming no outgoing calls

firmware: sip8821.11-0-5-17

wifi Cisco AIR-CAP2602I-A-K9

Sip debug shows

.....H.\SIP/2.0 400 Bad Request

Via: SIP/2.0/TCP 10.6.9.16:5060;branch=z9hG4bK2182cc59

From: "1105" <sip:1105@10.6.9.16>;tag=as015825bc

To: <sip:1102@10.3.1.151:51017;transport=tcp>;tag=0029c295d77e006a5a11c524-24543e71

Call-ID: 1e7c5e7e150f86880372b5cc21a0e426@10.6.9.16:5060

Session-ID: 67f9ece600105000a0000029c295d77e;remote=00000000000000000000000000000000

Date: Wed, 22 May 2019 12:39:53 GMT

CSeq: 101 INVITE

Server: Cisco-CP8821/11.0.5

Contact: <sip:1102@10.3.1.151:51017;transport=tcp>;+u.sip!devicename.ccm.cisco.com="SEP0029C295D77E"

Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER,REGISTER,UPDATE,SUBSCRIBE,INFO

Allow-Events: dialog

Content-Length: 0

[Leo Laohoo]

If I recall correctly, "network busy" means CAC is not enabled.

[SDSDFWEEWR]

Turned on now, it didnt help

[Leo Laohoo]

What is the QoS settings for the SSID?

[SDSDFWEEWR]

qos platinum

[Leo Laohoo]

Read the deployment guide (see attached).

[SDSDFWEEWR]

i have same phone on UBIQUITI UAP-AC-LR, and it work nice. Problem is only with Cisco AIR-CAP2602I-A-K9

[jeremyseielstad]

I had the same, or at least a very similar experience with our 8821's.  The phones would get on the network and show as registered in CUCM, however when there was a call to or from the 8821 phone (running either firmware Active Load ID: sip8821.11-0-6SR5-5 or Inactive Load ID: sip8821.11-0-6SR2-4) they would experience a network busy error.  We tracked it down to a specific access point in our network.  Any time the phones were associated to this one specific ap (Cisco C9136I-B Software Version17.9.5.47 ) the issue would occur but when they would roam away from it the phones worked as expected. There were no issues showing on the controller or in DNAC.   In the end we rebooted the AP and the issue was corrected. 

[Leo Laohoo]

There are several known bugs affecting Cheetah OS (x800, Catalyst 9k) and the best workaround is to reboot the APs.  Daily.  2800/3800/4800/1560 is known to have a design bug and has been in a "broken" state since the introduction of 8.5MR3.  Cisco has originally promised that this bug would be fixed in IOS-XE but has not.  Instead, the bugs have migrated to IOS-XE.  The most common feature of these bugs would cause the affected AP to randomly drop packets and (regular) reboot is the known workaround.

Lately, I've been seeing the same behaviour appearing to affect Catalyst 9k APs.  

If the switch infrastructure is Cisco, let me know.  I have an EnergyWise configuration that turns PoE off and then on daily.

[PaulBarlow]

Thanks for the response @Leo Laohoo  I work with @jeremyseielstad  and we continue to see this error. Do you happen to have bug ids that we can push with cisco? I like the idea of the energy wise poe drop but we work at a hospital so we have to be careful power cycling devices.

[Leo Laohoo]

The list of known Bug IDs affecting 2800/3800/4800/1560 can be found HERE.

I have not made any effort to make a compilation list of Bug IDs for the Catalyst 9k.  Yet.