I assumed that CUBE would be the security device acting as a session border controller...as in typical SBC deployments there isnt any other security device inbetween the SBC and an Applications server.
Was thinking CUBE (SP) .... but shoudnt it work for both if it works for one ?
I have the same question. I'm interested in using CUCM / CUBE vs. VCSe / VCS for our offnet video. Does anyone have experience with this? It sounds possible, but there is little CUBE training or documentation available on video.
If it is a simple question of "we don't have VCS-C and VCS-E, and we have CUCM and CUBE", then that makes sense.
You'd need to have a lot of very deterministic call routing in the CUBE, and that is making the assumption that you're only going to call (and be called by) known parties/entities.
You'd need to have a dial-peer for almost every single unit you wanted to call outbound to, unless whomever you were calling was nice enough to have a continuous E.164 number range so you could do it with a wildcard.
You may want to look into the functionality of the IME instead of CUBE, but based on the conversations I've had at Cisco Live the last two years, the IME is likely going to go away and be replaced by the VCS-E, simply because is solves so many more problems in a much easier way.
We have CUCM 8.6.2 and will have CUBE for PSTN connectivity. We have MXP's and C20's registered to CUCM, we do not have VCS-E or VCS. I do not like the idea of registering some video endpoints to CUCM (8900/9900 series), and others to VCS and having dual CAC - Call Admission Control for video. I'd like to have one video QoS queue and one CAC to manage it. It seems like a good area to consolidate especially if we don't have the "Tandberg" products. Wouldn't URI dialing and a DNS SRV _sip record take care of the calling parties?
I've done it quite a bit with both VCS-E and CUBE. There are advantages and disadvantages to both....
CUBE is OK if you want to peer directly with another organisation but as far as I know you can't do anything like DNS zones, which means you can't dial SIP URI's etc of companies that you don't already have a dial peer to. In some situations (particuarly with CTS to CTS) it can also be a bit tricky to configure.
VCS-E is easier to configure, with a nice GUI, good search rules etc. However it's really designed to work in conjunction with a VCS-C, with CUBE you only really need one - you can even run IOS firewall on the same device.
Really I would say that if there's only one or a few companies that you want to connect to and it will be a fairly static deployment, CUBE is the way to go if just for simplicity and cost reasons (you may already have a suitable router lying around). If you want to remain flexible and allow room for expansion and addition of further capabilities, VCS would be better.
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...