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. 

[snagelipphone]

In addtion to the information above I have also noticed that the 8941 specifically do not support Mobility and DND as a soft key.  You can configure them as a phone button but depending on the user requirements and extension there may not be available buttons.  Maybe a future firmware release will address this issue and is on the road map.  Can someone confirm this?

[xuameng]

Hi,

you are right, Mobility and DND have to be configured on a programmable line key right now. But we will have these two keys as well as some other feature keys like Barge, MCID, QRT, included into our softkey template in 9.2(3) release.

[sgavan]

A couple more oddities / observations that we've uncovered during a recent install:

1)  Shared lines on 89XX phones do not work like shared lines on 79XX phones.  If two people are sharing a DN (say a boss and a admin assistant)...  if the assistant answers a call or places a call using the shared line, the boss's DN will go busy (red) and they are unable to place a new call from that boss's DN.  This could be something simple we are not configuring (best case) or intended behavior (worst case).  Just curious if someone has been able to make shared lines work or if this is a future firmware update fix.

2)  Background images...  phones have this awsome VGA quality screen and the first question we get is "how can I change the background image or upload a photo to my phone"....  ummm  sorry you can't.  Future feature?

3)  Still testing this one...  but if 2 video enabled phones attempt to call one another over a WAN link and they exceed the location bandwidth setting, will the phones complete the call without video (negotiate down to say G729)?  Or will the call fail?  If it does throttle back to a voice call only, is there a message telling the caller there is not enough bandwidth for video?  Again, we will know the answer when we can test this (installation is ongoing). 

4)  Agree 100% with others that video needs to be an option that can be added on the fly during a call without consuming bandwidth if possible...  not all or nothing.  Most users (including me) will want video to be an occasional option...  not automatically come on as soon as the call is placed or administratively disabled due to bandwidth limitations. 

[xuameng]

Hi Sgavan,

pls find my comments to your questions one by one below:

1) Share line issue: Yes, we do have this problem with the current f/w load. But we will get this fixed in the upcoming 9.2.2 release which is end of this Oct. You can get the new load from CCO then.

2) Customized wall paper: yes, a feature in 9.2.3 release which is by end of Dec or early of Jan.

3) The phone won't throttle back to a voice call if there is bandwidth limitation. We are going to have a feature to allow the phone to adopt the resolution and frame rate automatically, but right now we still rely on the admin to modify these parameters on CUCM admin page based on the real network situation.

4) pls see my reply to Michael. Will investigate a solution.

[Matthew Hall]

To clarify part 3 of your question, if the location runs out of video bandwidth the phone will negotiate down to an audio only call and will behave as though video on the phone has been disabled (low bandwidth usage).

The troubling part is, if you have a region that also uses HD devices and thus region video bandwidth is set to say...1024 for video calls, instead of the 8945 realizing it can't transmit that high...it freaks out and falls back to audio only....doh!!!!  This is a MAJOR issue if you have a mix of video devices.  You have to create lots of different device pools and regions for each site to segregate the 8945s into their own special..video 512 region.

At least the above scenarios are what I've seen from my testing lab.

[xuameng]

Hi,

When the phone is set up with Video Capability Enabled on CUCM admin page, no matter whether the "Auto Transmit Video" is set to NO or not, the phone will just behave as a video phone. Therefore as you mentioned above there will be a black screen with "Video Mute" icon on it and will still consume network bandwidth.

We are going to offer a video capability enable/disable functionality to the end user via phone Preference menu in f/w 9.3(1) release. By this new feature, end user can completely disable the video capability from the phone UI and use the phone just as a normal audio phone. It will solve all your concerns in point 1 and 2.

[mgavan]

Xuameng, that is not exactly true, this won't resolve issue 1 and 2.   All you will have done is given the user the ability to do an all-or-nothing.

I have the same issue.

The problem is that and admin, or a user, can only dictate that EVERY call is audio, or that EVERY call is video.  This is not a freindly feature.   If i don't want a call to have video, my only option is to mute at start, which effectively uses the same amount of bandwidth as a regular real video call. that's wasteful for one, and as paul mentioned, A big annoying black box.

What would be a much better way to design this is so that the end user can escalate an audio call to video with a softkey or with answering a pop-up screen, or pressing the video mute key etc.  The audio call should recongize that both parties have the ability to do a video call, and the end user is then given the option after the fact to escalate to video.  I can't imagine that an organization would want to adopt 100% video on every call from the receptionist, or when I'm just trying to let someone know their mail arrived, etc. Right now, it's all or nothing video.

Imagine a home user in their pajamas witha 99xx phone. Today these phones say you get a video call, pajamas and all, or you don't get video at all.

Cisco's CUPC works from the escalation method for example. I can either start as a video call, with a remote accept from the called party, or I can ask to escalate a call to video that I originally started as an audio only call.  Even if every call is started as video, there's still a remote accept feature from the called party to deny video. 

[xuameng]

Hi Michael,

thanks for these detail information. You are right, right now our phone can only support all-or-nothing mode. For the requested per call mode, we will investigate and get back to you guys with more details later.

But, one thing I can't agree: You mentioned when the video call is put on hold, the consumed bandwidth to transmit the static block box with mute icon is same as a regular real video call. In our design, it's very clear that the consumed bandwidth for the static picture should be much smaller. Can you double check in your real deployment?

Thanks

[skilambi]

When is VPN client targeted for these phones? It's a shame to see the 79x2,x5 series have it and this phone doesn't have it right from the get go...

Srini

[w.carpenter]

I also have a question regarding phone designer. When I am trying to update either the ring tone or the wall papaer on the 8941 set that I am associated with I see the progress bar and then it stops. Am I doing something wrong or missing a setting in the device configuration? I am using the latest phone designer 7.1(3) SR2.

[skilambi]

Maybe I am mistaken but if you cannot change the wall paper right now not sure how PD would work around that, see post above.

2) Customized wall paper: yes, a feature in 9.2.3 release which is by end of Dec or early of Jan.

Srini

[mgavan]

Xuameng,

The video bandwidth during mute issue seems to vary by phone and firmware. I've noticed these numbers even vary from one implementation to another (Call manager 8.5.1 vs 8.6.1a make a difference it seems). Here's some examples i found:

These are all with 512 kb video bandwidth selected in the Region setting in Call Manager. 

SIP 9.2.1:  8945 to 8945. Live video call: ~512 KB video bandwidth

SIP 9.2.1:  8945 to 8945. Live video call, both ends muted: ~160 KB on both ends

SIP 9.2.1:  8945 to 9951. Live video call, both ends muted: ~100 KB on 9951, 120-160 on 8945

SIP 9.2.1:  9951 to 9951. Live video call, both ends muted: ~100 KB on both ends

SCCP 9.1.2SR1:  8945 to 8945. Live video call, both ends muted: ~400 KB+ on both ends

You are correct that it is less. but awefully high for something that is otherwise 'off' or not being used, in my opinion.

Honestly though if there is a user-centric feature to elect, or escalate an audio call to video as needed, then bandwidth consumption on mute is not really an issue any more. The case i'm making here is that for two video phones to do audio only, they consume much more bandwidth than necessary.  You can see that right now, if 2 phones are configured for video, then every muted video call will consume roughly 200 KB in both directions. That's 200KB for a essentially an 'audio' call.  Over a LAN this isn't an issue, but over a WAN with a 6 MB or 3 MB pipe, a couple 'audio' calls can really hurt some bandwidth.

[mgavan]

And thank you very much for all the helpful responses!

[michaethompson]

Is there a tentative release date for phone load 9.3(1)?