8941 Behavior

[paulblakie]

We have now completed several roll-outs that included the new 8941 phone, and are noticing some "interesting" behavior.  The things we are seeing may be intended behavior (if so I would recommend that Cisco make changes), or they may be anomalies that should be corrected. 

1.) Within the phone firmware, there is an option to have a phone is set up as a video phone in CUCM default to video off on the phone.  This is the same with both the 8900 and 9900.  However, when a video enabled user, with video defaulted to off at the phone makes a call to another video enabled phone, the display of the phone changes to a black screen with a video disabled icon.  This forces the user to have to push a button to remove the black box to see their phone display screen.  Compounding the issue in the 8900, if a second call is received, the black box remains and the user has to push the button to remove the video simply to see who is calling.  Users HATE this. 

2.) So, assuming (as described above), the users are all defaulted to muting video on video enabled devices, you would think that when muted, the video enabled phones would not consume any additional bandwidth on the network for video traffic.  Not so.  Even when video is muted on the phone, the phones are still sending and received video frames.  This means, for a company that has many locations over an IP WAN that want to have video phones enabled for occasional video use, ever call will be consuming unnecessary bandwidth.  Several hundred K per call. 

3.)This last point is a small issue, but the new lines of phones have no consistancy accross the different product families.  One screen in one menu on an 8900 will be called something completely different in a 9900 even though they have the same function.  While not necessarily service affecting, this is highly annoying and does make it much more difficult to support a large user base of various instruments. 

I'm hoping that our experience with points 1 and 2 above are either something that is changing, or possibly there are configuration changes we can make to CUCM mitigate our experiences. 

Any thoughts would be greatly appreciated. 

[xuameng]

Tentative CCO date for 894x 9.3(1) load is June 5th US time. Probably a couple of days delay because we are still waiting for a bug verification at a customer site, and then go through the approval process to get the publishment really done.

[michaethompson]

Perfect. Any idea if perpetual reboots has anything to do with the bug? Loaded it in a couple test phones and they are just cycling. Have done no troubleshooting yet.

Thank you again

Sent from my phone, apologies for any typos.

[xuameng]

Which bug are you talking about? Is it 8941 perpetual reboot related?

From: community(mailer list)

Sent: 2012年6月4日 18:08

To: Sandy Meng (xuameng)

Subject: - Re: 8941 Behavior

Cisco Communities <https://communities.cisco.com/index.jspa>

Re: 8941 Behavior

created by michaethompson <https://communities.cisco.com/people/michaethompson> in Unified Communications - View the full discussion <https://communities.cisco.com/message/96666#96666>

[skilambi]

Xuameng

Is there a reason the C2C Plugin release notes don't mention 8941/45?

http://www.cisco.com/en/US/docs/voice_ip_comm/cupa/click_to_call/8.0/english/release/ReleaseNote_c2c.html#wp2485392

Is this because it won't work or did someone not test it and hence it hasn't been updated?

Srini

[xuameng]

I believe it’s because the document was not updated to include these phones. I will try to contact the corresponding team for a fix.

Thanks

Sandy

From: community(mailer list)

Sent: 2012年6月5日 3:57

To: Sandy Meng (xuameng)

Subject: - Re: 8941 Behavior

Cisco Communities <https://communities.cisco.com/index.jspa>

Re: 8941 Behavior

created by Srinivasan Kilambi <https://communities.cisco.com/people/skilambi> in Unified Communications - View the full discussion <https://communities.cisco.com/message/96714#96714>

[skilambi]

Thanks for the update

Thanks

Srini

[Matthew Hall]

Just an update Running CUCM 8.5 and 9.2.3.5.

Just as an advisory I did these quickly in my lab which means I was actually monitoring bandwidth utilization of an ASA L2L tunnel that the call was passing through.  Some time in the future I'll pull the phone out of the Lab environment and get direct LAN bandwidth measurements.  I only listed the max bandwidth recorded during the testing period on each call.

Video G722 x 512k Video-

  Video Muted - 141.7 Kbps (asa ipsec encoded)

          Unmuted - 628.2 Kbps (asa ipsec encoded)

Video G722 x 384k Video-

  Video Muted - 159.2 Kbps (asa ipsec encoded)

          Unmuted - 495.6 Kbps (asa ipsec encoded)

Video ILBC x 384k Video-

  Video Muted - 109.5 Kbps (asa ipsec encoded)

          Unmuted - 495 Kbps (asa ipsec encoded)

Video G729A x 384k Video-

  Video Muted - 103.3 Kbps (asa ipsec encoded)

          Unmuted - 505.3 Kbps (asa ipsec encoded)

IF video disabled on phone or video portion of the call fails due to location bandwidth lower than region:

g729A - 60Kbps (asa ipsec encoded)

ILBC - 66.8Kbps (asa ipsec encoded)

G711 - 118.4Kbps (asa ipsec encoded)

G722 - 117.7Kbps (asa ipsec encoded)

This needs to get fixed, or we can at least give them a video disable soft key.  25 to 40 Kb overhead is BAD.

There is another issue, if you try and save bandwidth by setting the phone to auto mute all video and only do a video call as requested, then they are all staring at black screens by default, instead of their normal phone info screen.  Bad design.  I would rather have a video off by default option and an escalate to video button like the old 7900 series...even if it requires a soft key.