[cisco-voip] vCUBE Experiences

Thu Jun 4 19:28:14 EDT 2020

Ah yeah but it wasn't the AWS people were thinking of or asking for (I think)

This is the dedicated VMWare offering on/in AWS.

So it's not really CUCM on AWS, it's still CUCM on VMWare in AWS.. (CUCMOVMWAWS I guess would be the acronym?)

So AWS is basically housing and running your VMWare compute environment.
It's dedicated to you.
And as you would expect, pretty pricey.

I think when everyone thinks CUCM on AWS
They are thinking more of going into marketplace.. click Start Instance.. boom 🙂

Cheers,

Tim.

________________________________
From: Anthony Holloway <avholloway+cisco-voip at gmail.com>
Sent: Friday, 5 June 2020 12:33 AM
To: UC Penguin <gentoo at ucpenguin.com>
Cc: Tim Smith <tim.smith at enject.com.au>; Cisco VoIP Group <cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] vCUBE Experiences

EXTERNAL SENDER WARNING. This message was sent from outside your organisation. Please do not click links or open attachments unless you recognise the source of this email and know the content is safe.

I was just hearing from a Cisco person, who was saying something like "Everybody said they had to have it, but when we finally had an offer, there were literally ZERO people who did it."

And here I was thinking that my customer base was just cloud adverse and everyone else was jumping on the AWS band wagon.  Guess not.

On Thu, Jun 4, 2020 at 9:28 AM UC Penguin <gentoo at ucpenguin.com<mailto:gentoo at ucpenguin.com>> wrote:
Shared resources like AWS on the surface seem like a great idea for lab stuff. Looks like a great solution for on demand scaling etc though.

It just doesn’t seem to that useful for UC purposes and even if it were it would still be cheaper to buy one server and run it all on one box.

It’s interesting to watch management push for cloud everything and then slowly back away when they see the increased cost.

[cid:1727fbcb42ca98d53961]

On Jun 4, 2020, at 09:11, Tim Smith <tim.smith at enject.com.au<mailto:tim.smith at enject.com.au>> wrote:

Back to CUCM on prem in lab via VPN.

The CUCM AWS deployment is out of reach for lab purposes.
That one is basically CUCM on VMWare in AWS (which is like the dedicated resources) - it's not AWS AMI format.

That said, I've got a great provider here in Australia that does VMWare based cloud (NSX).
That would be good for lab.

Cheers,

Tim

________________________________
From: Anthony Holloway <avholloway+cisco-voip at gmail.com<mailto:avholloway%2Bcisco-voip at gmail.com>>
Sent: Thursday, 4 June 2020 11:20 AM
To: Tim Smith <tim.smith at enject.com.au<mailto:tim.smith at enject.com.au>>
Cc: Cisco VoIP Group <cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>>
Subject: Re: [cisco-voip] vCUBE Experiences

EXTERNAL SENDER WARNING. This message was sent from outside your organisation. Please do not click links or open attachments unless you recognise the source of this email and know the content is safe.

Was that trunk to Twilio for CME?  If not, what was on the backside of your gateway?  CUCM?  If so, was that in AWS too?

On Wed, Jun 3, 2020 at 6:54 PM Tim Smith <tim.smith at enject.com.au<mailto:tim.smith at enject.com.au>> wrote:
Great question, also interested in hearing production stories.

I've deployed Virtual Acme Packet's previously - same limitations - no DSP's etc.
It was a little early and we had teething issues of appliance to virtual machine type stuff.. but through the updates this improved.

I've played with CUBE on CSR1000V on AWS - SIP trunks to Twilio - and it works great.
It's certainly so nice and easy to spin up.
I've also run CSR1000V in AWS for dynamic VPN's.. which again works great.

The DSP's are a nice fallback. You don't need them 99% of the time.. but when that 1% case comes up later - then it's certainly handy.
I think that's a big reason vCUBE is not quoted in customer land.
I assume it could be popular in service provider land though.

With that Acme deployment (and this was actually years ago now) - we were migrating, so we still had PRI gateways with plenty of free DSP's, which we could use for Transcoders if required.

Cheers,

Tim.

________________________________
From: cisco-voip <cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at puck.nether.net>> on behalf of Anthony Holloway <avholloway+cisco-voip at gmail.com<mailto:avholloway%2Bcisco-voip at gmail.com>>
Sent: Thursday, 4 June 2020 7:06 AM
To: Cisco VoIP Group <cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>>
Subject: [cisco-voip] vCUBE Experiences

EXTERNAL SENDER WARNING. This message was sent from outside your organisation. Please do not click links or open attachments unless you recognise the source of this email and know the content is safe.

Anyone have some vCUBEs out in production for a while, and willing to share their feelings and/or experiences with it?

Anything from deployment, to restrictions, to licensing, to upgrade processes, lessons learned, etc?

I think the obvious thing is the lack of DSP/PVDM since this is a virtual machine, but what else?

I don't come across these in the field at all, and I don't see them being proposed or quoted these days, despite vCUBE having been around for a few years now.
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip<https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flinkprotect.cudasvc.com%2Furl%3Fa%3Dhttps%253a%252f%252fpuck.nether.net%252fmailman%252flistinfo%252fcisco-voip%26c%3DE%2C1%2C1w7UWB3wbO36t4arobXgguDW8lgmF-IrT8nOTDNGOYX2q7kmW6AAjKVeVPClZFVou_X1l3ak9YWoJTQ6vlKteZwMFLk7jymBA_Vm09M3Fkidvg4%2C%26typo%3D1&data=02%7C01%7Ctim.smith%40enject.com.au%7Ccf0564d4b8094b3a112c08d808945026%7Ce676c09ff1b242488a361f228b8620f8%7C0%7C0%7C637268780392223928&sdata=d4eibjxj1hF3QlG0Yh6Aa9U67NrjZ39WIlGPa%2FycpIk%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200604/c05cdb8b/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tenor.gif
Type: image/gif
Size: 1600550 bytes
Desc: tenor.gif
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200604/c05cdb8b/attachment.gif>