We are completely re-designing our video-conferencing infrastructure and deploying Cisco's Telepresence solution. We have been trying to follow's Cisco's roadmap concentrating everything on the CUCM.
I have to say so far CUCM has proven not to be ready to host (register) Telepresence endpoints. When registered on the CUCM, we face to many problems are obvious things simply doesn't work. The main problems we have seen are:
A Telepresence endpoint registered on the CUCM cannot get the TMS phonebook. Only the CUCM directory. So the users cannot have the video-conference/Telepresence endpoint directoy...
There are no default SIP routes on the CUCM! So it is not possible to default unknown domain to the VCS-C which will route it to the VCS-E.
Can't dial an IP address. You have to use a bypass explained in the documentation using an IP dialing prefix following pattern <ip prefix>AAABBBCCCDDD. Like if 7 is the prefix and 1.23.456.7 the IP address you have to dial: 7001023456007. I mean. sure it can work. But find me a single non IT end-user who can understand it and do it him/herself.
We are facing curently on our 8.6 CUCM a SIP bug which make the endpoint fail dialing a Telepresence Server multipoint meeting using SIP (bug CSCty07061) (behavior described here). Should be solved in 9.1 but not sure yet (all our attempts to upgrade CUCM from 8.6.2. to 9.1 have failed so far)
MCU & TP server are recommended to be registered on the VCS-C and not on the CUCM (so it can be used by Webex, external devices and internal legacy h.323 devices registered on the VCS-C) but when doing so, CUCM registered endpoints cannot escalate 2 ad-hoc meeting into a multipoint meeting as there are no video multipoint bridge ressources registered on the CUCM itself and it is not capable of grabbing them through the TMS it is registered on...
Not to mention that there are still so many H.323 device and endpoints everywhere and that the CUCM doesn't handle it and apparently Cisco has no plan for it. So if we have to register endpoints on the VCS-C for H.323 anyway, what's the point of registering them as SIP endpoints on the CUCM. Simpler to have them registered both as SIP and h.323 endpoints on the VCS-C
Anyway, all in all, although Cisco is pushing CUCM as the center of everything, voice and video, it just looks to me that it is not ready for it. It is missing too many basic capabilities.
Does Cisco has any plan to fix any of these issues ?
2 & 4 - I heard that 9.1 might solve these issues mentioned above and we would love to upgrade to 9.1.
We just spend 9 days, including 2 week-ends in a row full-time, trying to upgrade and guess what... it still fails. And we are talking about an upgrade from 8.6.2(a)-SU3 to 9.1.1 or 9.1.2. And we went back on forth with TAC support changing all sorts of settings redoing the install many times from scratch and we are still unable to upgrade... the worst upgrade I've experienced so far !
So so far I'm unable to test if 9.1 will solve our issues and to which point...
3- Regarding point 3, yes there are many bypass. We've been trying couple, but none of them is transparent for the end user. I mean the bypass in the Cisco documentation described before does work but try to get a user to understand it and to it right...
And still as long as the endpoint is only registered as a SIP endpoint on the CUCM how do you dial an H.323 endpoint on the internet. VCS h.323-SIP interworking transcoding features works for registered endpoints, but I've failed to get the VCS translating a CUCM-registered SIP endpoint to an external H.323 endpoint.
1- for point 1 do you know when that new version is planned to be released ?
5 - For point 5, I'd like to use Conductor but in our case I'm making a deployment over 3 CUCM clusters, 3 VCS and 2 MCUs and 2 TPS. So conductor will not be free for us...
You can definitely use VCS for SIP to H323 interoperability from CUCM endpoints. Just make sure you have interworking turned on on the VCS, not just for locally registered endpoints.
There's no special configuration needed, just make sure that you have an appropriate search rule to change what CUCM sends (e.g. 1234@vcs-IP) into something that matches the H323 endpoints you are trying to dial.
By the way - the lack of TMS phonebooks is exactly why I haven't migrated yet - I hope they come soon!
With the tests I made so far, even with the VCS interworking set to ON (not just locally registered endpoints), a SIP call coming from a CUCM-registered endpoint to an H.323 endpoint outside on the internet was not working. Might be something else.
By the way - then it goes back to my point saying that Cisco is pushing towards the CUCM when everything is not ready to go that direction. I guess it's all about waiting but for us who are deploying a solution now we wanted to do it according to Cisco's plan from the beginning (hence put all endpoints on the CUCM). Because if we register endpoints on VCS and have to move them to the CUCM later it will create problems with bookings as you purge the endpoints and re-add them and there's no way that I know to purge the scheduling and have TMS&TMSXE resync everything starting from a blank page
ad 5. There is now a new midmarket conductor for up to 50 calls, which will not be that expensive. For 2 MCUs and 2 TSes a Conductor would make sense to better use you the infrastructure. Or are there some reasons why you don't want to share resource, like different parts of the company own different infrastructure aso.
I requested budget for a Conductor for next year but in the mean time I look like an idiot n front of my users. Look we just spend a hell lot of money on brand new video-conference systems and guess what you can't escalate ad-hoc meetings to multipoint on those new systems because we registered them on the CUCM as recommended ... We'll have to spend more money to do something we could have done should we have register the endpoints to VCS... but it works on the old stuff...
Again, I understand were Cisco is going and that integrating all those Tandberg and Cisco systems can not happen in a day but it has been years already and their documentation is recommending CUCM today.
The short answer is that you don't.... That isn't entirely true while at
the same time it kind of is, but for the most part you don't configure
the softkeys. You enable or disable them via TCL. Here is the long
answer. Be sure to read the whole thing or e...
Topology: IP Phone > Switches > Microsoft NPS setup to forward 802.1x
proxy to > ISE 2.1 patch 3 Authentication: EAP-TLS using Cisco MIC SANs
Phone Models 802.1X support? 802.1x flavor Addtl Comment EAP-MD5 EAP-TLS
Cisco 3905 Y Y N Cisco 6911 Y Y N Cisco ...
This document describe how DST changes and how time changes are
implemented in DST. Daylight Saving Time (DST) is the practice of
setting the clocks forward 1 hour from standard time during the summer
months, and back again in the fall, in order to make b...