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.
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?
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.
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.
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.
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.
I know this is a pretty old thread so I apologise for resurrecting it but I have a couple of questions:
1. Is it still the case that video bandwidth is consumed if both sides are muted? I had naively assumed that the call would use the 80k required for G711/G722 and then a small amount of bandwidth for the “black screens”. In my head this is 100k max for the entire call. Hopefully this is the case?
2. We obviously disable video on external calls. When we make a call users get “unable to setup video” on all of these calls. This is really annoying. Can this message be hidden?
We are using firmware 188.8.131.52 on CUCM 8.6(2)
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.
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.