Using CUBE instead of a VCSe ?

[chatura]

Hi,

Is it possible to  use CUBE instead of  using VCSe and VCS in the below topology,

3rd Party VCON <------> Internet <-----> VCSe<----->Firewall<------->VCS<------>  VCON Endpoints

Instead what i want to do is,

3rd Party VCON <------> Internet <-----> CUBE<-------->CUCM<------>  VCON Endpoints

Thanks

-Chatura

[Michael Boscia]

Tecnically, nothing would stop you from doing it, but how would you protect the CUBE, and what security elements would you put in line, between the CUBE and the CUCM?

Are you talking CUBE (SP) or CUBE (ENT)?

[chatura]

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 ?

Thanks

[jmunoz19]

A VCS Expressway can do traversal for endpoints on the Internet.  Can a CUBE-ENT do that?

Thanks, Jeff

[jspilde]

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.

Thanks,

Jason

[Michael Boscia]

Jason,

I'll ask you the same basic question as above:

Why?

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.

[jspilde]

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?

Thanks,

Jason

[jspilde]

In regard to URI dialing, I think this is CUCM 9.0 functionality that was just announced.  I seem to recall discussion on the SRV _sip record in the CUBE config guide or similar location online.

[Nick Halbert-Lillyman]

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.