Re: [cisco-voip] SBC/SIP Trunk Design queries

[David Lin]

I think one of important things is the capacity you are looking for.ACME does 
give you better scalability and better troubleshooting capability, but if you 
are only looking for couple hundreds of concurrent calls, you probably can live 
with CUBE to keep your cost lower.

D.
From: tim.sm...@enject.com.au
To: terry.che...@gmail.com; cisco-voip@puck.nether.net
Date: Wed, 11 Mar 2015 04:19:22 +
Subject: Re: [cisco-voip] SBC/SIP Trunk Design queries









Hi Terry,
 
I do quite a bit of CUBE, and have done a bit of Acme as well.
 
There were some recent partner sessions that talk about some interesting things 
coming for CUBE, so it’s worth making sure you are
 getting latest roadmap info.
 
My main comparison points..
 
# HA
 
In enterprise there was HA on CUBE, and it was improving in each release (but 
there are caveats with it)
Have found Acme HA to be seamless and rock solid.
 
# Deployment
 
Cisco has some great interop guides – if you go with a carrier that has spent 
the money, a lot of the hard work has been done for you
 in terms of testing (as you know SIP can be implemented and configured in many 
different ways – if someone hasn’t done a lot of testing up front, you do 
sometimes end up adding SIP profiles and tweaks as you discover issues)
 
Acme has some very thorough guides – I’m not sure if they have interop testing 
with carriers – given they are in SP’s a lot, there
 is a good chance they do. I’d look into it that with the Acme SE. Talk to 
prospective ITSP’s about their testing, and supported SBC’s.
 
# Ops
 
CUBE enterprise is great, IOS, most people are familiar. You will most likely 
need to train people on Acme
I find troubleshooting a bit of a let down with CUBE. Basically log to buffer, 
copy to file, or packet captures. Wireshark with ladders
 or TranslatorX are great, but it’s getting the files there that bugs me.
Alternatively, there did seem to be a few 3rd party tools out there, but you 
are probably looking at $$$
 
Acme has web interface, list of calls and then ability to drill down with 
ladder diagrams, messaging capture etc. You should see this
 before making decision.
 
Some good knowledge on Acme forums
Acme has very flexible manipulation – CUBE is quite good too (and they have 
great profile testing tool) – plus you can also use CUCM
 LUA on the SIP trunk
 
# On your other notes
 
Centralised – this is great for flexibility DR etc, standard stuff be aware of 
the call volumes over the WAN, caller ID considerations
 for emergency and local pizza shop type services
 
WAN – we terminate on existing equipment, and Acme is in a VLAN, I think this 
is most flexible.. you have a very flexible set up in
 Acme in regard to networking, lots of zones, interface options etc.
 
Transcoding – I think you could still utilise CUCM registered transcoders for 
the ASR scenario..

 
Virtual - We use virtual Acme, it had some teething problems in very first 
versions (and a clunky license on USB stick thing going
 on) but it seems to be good now
We don’t have transcoding / media resources in the virtual 
edition
 
Flow through / around – a lot of designs the carrier doesn’t have connectivity 
into the rest of the network, so flow through is quite
 typical.
However, we do have carriers here that have SBC’s on your WAN, 
so flow through can be nice here – it also then makes
 CUBE HA less important, i.e. if call is set up, media is from end point to 
carrier SBC already (if no xcoding involved)
 
So I won’t say one way or the other, just my thoughts on things you can 
consider.
I like both, and will continue to work on both!
 
Cheers,
 
Tim
 
 
From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net]
On Behalf Of Terry Cheema

Sent: Wednesday, 11 March 2015 1:10 PM

To: cisco-voip voyp list

Subject: [cisco-voip] SBC/SIP Trunk Design queries
 

Hi List,
 
I am working on to finalize the SBC vendor for one of our environments. I have 
a couple of queries related to the SIP Trunk design and SBC vendor 
choices(basically CUBE vs Acme
 Packet). I would really appreciate if anyone with SIP Trunking/SBC expertise  
(Cisco/Acme Packet) can provide some input on the below queries:
 
1) 
CUBE vs Acme Packet: First of all Cisco has marked the CUBE SP Edition product 
line for EoL, exiting the SBC Service Provider segment, so leaving only SBC 
Enterprise as the option. Although at this stage we are looking for an 
enterprise grade
 SBC but it will be a plus if it has the potential to step up into a SP SBC in 
a multi-tenanted environment. I was comparing AP 3820 with the CUBE Ent ASR1k-x:
 
CUBE provides no HA (though in some documents it says, came out from a meeting 
with the Cisco SME informing HA is not available), No transcoding (due to lack 
of DSP on ASR1K), No
 Multi-tenancy support  with all of these features supported in a 3820 SBC 
Any feature better in CUBE that I may have overlooked? I am aware that CUBE 
configuration etc. can be easy compared

Re: [cisco-voip] Upgrade 9.1.2 to 10.0 fails...

[Jonathan Charles]

It was really straightforward, deploy OVA vApp, set IP and login, upload
ISO, point at cluster, point at ESXi host, upgrade...


Jonathan

On Wed, Mar 11, 2015 at 4:23 PM, Martin Schmuker  wrote:

>  I didn’t try PCD yet. Is it really that easy?
>
>
>
> Update to 9.1.2 was good, now jumping to 10.5
>
>
>
> *Von:* Ryan Huff [mailto:ryanh...@outlook.com]
> *Gesendet:* Dienstag, 10. März 2015 17:44
> *An:* Martin Schmuker; Jonathan Charles
> *Cc:* cisco-voip@puck.nether.net
> *Betreff:* RE: AW: [cisco-voip] Upgrade 9.1.2 to 10.0 fails...
>
>
>
> Martin,
>
> I have done a 7.1.3 to 10.5.1 before; I bit the bullet and setup PCD, and
> it went off without a hitch.
>
> Thanks,
>
> Ryan
>
>   --
>
> From: m...@bilobit.com
> To: jonv...@gmail.com; ryanh...@outlook.com
> CC: cisco-voip@puck.nether.net
> Subject: AW: [cisco-voip] Upgrade 9.1.2 to 10.0 fails...
> Date: Tue, 10 Mar 2015 16:32:28 +
>
> At the moment i have the same problem with a jump upgrade from
> 7.1.3.1-11 to 10.5.2. It also does not work to 10.5.1.
>
>
>
> The same: Removed all subs, all network etc. is ok, NTP reachable and
> synchronized and so on.
>
>
>
> *arghl*
>
>
>
> *Von:* cisco-voip [mailto:cisco-voip-boun...@puck.nether.net
> ] *Im Auftrag von *Jonathan Charles
> *Gesendet:* Dienstag, 10. März 2015 16:23
> *An:* Ryan Huff
> *Cc:* cisco-voip@puck.nether.net
> *Betreff:* Re: [cisco-voip] Upgrade 9.1.2 to 10.0 fails...
>
>
>
> It is a jump upgrade (we are moving from a pizza box to vmware), I am
> doing the upgrade offbox to then import data to a 10.5.1 BE6K...
>
>
>
> I have rebooted it dozens of times... there is just one server (I have
> removed the other subs)...
>
>
>
>
>
> Jonathan
>
>
>
> On Tue, Mar 10, 2015 at 9:59 AM, Ryan Huff  wrote:
>
>  In your email below it seemed you were trying an update from 10.0.1 to
> 10.5.1
>
> If you are coming *FROM* 9.1.2, you may be hitting this bug
> https://tools.cisco.com/bugsearch/bug/CSCup45923
>
> On page 3 of the 9.1.2 SU2 release notes (
> http://www.cisco.com/web/software/282074295/113937/cucm-readme-912su2-Rev2.pdf)
> it warns of this bug. The reported work around is to go directly to 10.5.1.
>
> f you are suggesting that you are still receiving the unknown error when
> trying to directly upgrade 9.1.2 *TO* 10.5.1, then I'd go ahead and raise
> a TAC case.
>
> If this isn't a production cluster or I didn't mind taking it down, I'd
> reboot the cluster then try a 9.1.2 -> 10.5.1 upgrade and if I still got
> the error, I'd raise a TAC case.
>
> Thanks,
>
> Ryan
>  --
>
> Date: Tue, 10 Mar 2015 09:41:10 -0500
> Subject: Re: [cisco-voip] Upgrade 9.1.2 to 10.0 fails...
> From: jonv...@gmail.com
> To: ryanh...@outlook.com
> CC: agrec...@gmail.com; cisco-voip@puck.nether.net
>
>
>
> I applied the RSA cop file... the version from is 9.1.2.11900-12
>
>
>
> I have tried going to:
>
>
>
> 10.0.1.11900-2
>
> 10.5.1.1-7
>
>
>
> Same errors every time.
>
>
>
> All of them are the non-bootable ISO.
>
>
>
>
>
>
>
> Jonathan
>
>
>
> On Tue, Mar 10, 2015 at 6:22 AM, Ryan Huff  wrote:
>
> Jonathan,
> Have you applied any other cop or engineering special files besides the
> version 3 keys?
> Is your cluster based on the unrestricted export version or the restricted
> export version? Does the update your applying match (restricted versus
> unrestricted)
> Can you list out the specific version of 10.0.1 you are using and the
> specific version version of 10.5.1 that you want to go to?
> If you do a "show version active" on all the cluster nodes; what do you
> see? Is it the same on all nodes?
> I assume you tried to download a new image file from CCO and use that?
> Thanks,
> Ryan
>
>
>
>  Original Message 
> From: Jonathan Charles 
> Sent: Tuesday, March 10, 2015 01:30 AM
> To: Andrew Grech 
> Subject: Re: [cisco-voip] Upgrade 9.1.2 to 10.0 fails...
> CC: Cisco VoIP Group 
>
> Well, that didn't work... SFTP'd the ISO to the box, same error...
>
>
>
> Same error message...
>
>
>
>
>
>
>
> Jonathan
>
>
>
> On Mon, Mar 9, 2015 at 11:45 PM, Jonathan Charles 
> wrote:
>
>  It is re-running after SFTPing from a Windows box (FreeFTPd)...
>
>
>
>
>
> Jonathan
>
>
>
> On Mon, Mar 9, 2015 at 11:31 PM, Andrew Grech  wrote:
>
> Hi john, I've had a ISO from Linux to prime with bad permissions and had
> this error
>
> On 10/03/2015 1:13 PM, "Jonathan Charles"  wrote:
>
>  OK, let me try via SFTP (Windows box)... see what happens...
>
>
>
>
>
> Jonathan
>
>
>
> On Mon, Mar 9, 2015 at 9:26 PM, Charles Goldsmith 
> wrote:
>
>  Given that it is complaining about accessing the upgrade file, are you
> using dvd image/dvd on the host or sftp?  I'd try a different method to see.
>
>
>
> Not a whole lot of information, but I have seen SFTP cause similar issues,
> I think it was a permissions problem on a linux setup using openssh.
>
>
>
> On Mon, Mar 9, 2015 at 8:16 PM, Jonathan Charles 
> wrote:
>
>   Getting error:
>
>
>
>
>
> Error encountered: An 

Re: [cisco-voip] SBC/SIP Trunk Design queries - Acme Packet vs CUBE

[Terry Cheema]

Yes - definitely will like to have views from the community where things are 
heading these days.

I have updated the title slightly, lets see if it gets further response.

-Terry

Sent from my iPhone

> On 11 Mar 2015, at 5:17 pm, Tim Smith  wrote:
> 
> No problems, I'm also keen to hear other peoples experience too.
> 
> It's an interesting topic!
> 
>  
> 
> Cheers,
> 
>  
> 
> Tim.
> 
>  
> 
>  
> From: Terry Cheema 
> Sent: Wednesday, 11 March 2015 5:09 PM
> To: Tim Smith
> Cc: cisco-voip voyp list
> Subject: Re: [cisco-voip] SBC/SIP Trunk Design queries
>  
> Tim,
> 
> Thanks for your detailed and a quick response, much appreciated.
> 
> Thanks,
> Terry
> 
>   
> 
>> On Wed, Mar 11, 2015 at 3:19 PM, Tim Smith  wrote:
>> Hi Terry,
>> 
>>  
>> 
>> I do quite a bit of CUBE, and have done a bit of Acme as well.
>> 
>>  
>> 
>> There were some recent partner sessions that talk about some interesting 
>> things coming for CUBE, so it’s worth making sure you are getting latest 
>> roadmap info.
>> 
>>  
>> 
>> My main comparison points..
>> 
>>  
>> 
>> # HA
>> 
>>  
>> 
>> In enterprise there was HA on CUBE, and it was improving in each release 
>> (but there are caveats with it)
>> 
>> Have found Acme HA to be seamless and rock solid.
>> 
>>  
>> 
>> # Deployment
>> 
>>  
>> 
>> Cisco has some great interop guides – if you go with a carrier that has 
>> spent the money, a lot of the hard work has been done for you in terms of 
>> testing (as you know SIP can be implemented and configured in many different 
>> ways – if someone hasn’t done a lot of testing up front, you do sometimes 
>> end up adding SIP profiles and tweaks as you discover issues)
>> 
>>  
>> 
>> Acme has some very thorough guides – I’m not sure if they have interop 
>> testing with carriers – given they are in SP’s a lot, there is a good chance 
>> they do. I’d look into it that with the Acme SE. Talk to prospective ITSP’s 
>> about their testing, and supported SBC’s.
>> 
>>  
>> 
>> # Ops
>> 
>>  
>> 
>> CUBE enterprise is great, IOS, most people are familiar. You will most 
>> likely need to train people on Acme
>> 
>> I find troubleshooting a bit of a let down with CUBE. Basically log to 
>> buffer, copy to file, or packet captures. Wireshark with ladders or 
>> TranslatorX are great, but it’s getting the files there that bugs me.
>> 
>> Alternatively, there did seem to be a few 3rd party tools out there, but you 
>> are probably looking at $$$
>> 
>>  
>> 
>> Acme has web interface, list of calls and then ability to drill down with 
>> ladder diagrams, messaging capture etc. You should see this before making 
>> decision.
>> 
>>  
>> 
>> Some good knowledge on Acme forums
>> 
>> Acme has very flexible manipulation – CUBE is quite good too (and they have 
>> great profile testing tool) – plus you can also use CUCM LUA on the SIP trunk
>> 
>>  
>> 
>> # On your other notes
>> 
>>  
>> 
>> Centralised – this is great for flexibility DR etc, standard stuff be aware 
>> of the call volumes over the WAN, caller ID considerations for emergency and 
>> local pizza shop type services
>> 
>>  
>> 
>> WAN – we terminate on existing equipment, and Acme is in a VLAN, I think 
>> this is most flexible.. you have a very flexible set up in Acme in regard to 
>> networking, lots of zones, interface options etc.
>> 
>>  
>> 
>> Transcoding – I think you could still utilise CUCM registered transcoders 
>> for the ASR scenario..
>> 
>>  
>> 
>> Virtual - We use virtual Acme, it had some teething problems in very first 
>> versions (and a clunky license on USB stick thing going on) but it seems to 
>> be good now
>> 
>> We don’t have transcoding / media resources in the virtual 
>> edition
>> 
>>  
>> 
>> Flow through / around – a lot of designs the carrier doesn’t have 
>> connectivity into the rest of the network, so flow through is quite typical.
>> 
>> However, we do have carriers here that have SBC’s on your 
>> WAN, so flow through can be nice here – it also then makes CUBE HA less 
>> important, i.e. if call is set up, media is from end point to carrier SBC 
>> already (if no xcoding involved)
>> 
>>  
>> 
>> So I won’t say one way or the other, just my thoughts on things you can 
>> consider.
>> 
>> I like both, and will continue to work on both!
>> 
>>  
>> 
>> Cheers,
>> 
>>  
>> 
>> Tim
>> 
>>  
>> 
>>  
>> 
>> From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
>> Terry Cheema
>> Sent: Wednesday, 11 March 2015 1:10 PM
>> To: cisco-voip voyp list
>> Subject: [cisco-voip] SBC/SIP Trunk Design queries
>> 
>>  
>> 
>> Hi List,
>> 
>>  
>> 
>> I am working on to finalize the SBC vendor for one of our environments. I 
>> have a couple of queries related to the SIP Trunk design and SBC vendor 
>> choices(basically CUBE vs Acme Packet). I would really appreciate if anyone 
>> with SIP Trunking/SBC expertise  (Cisco/Acme Packet) can provide some input 
>> on the below queries:
>> 
>>  
>> 
>> 1)   

Re: [cisco-voip] Upgrade 9.1.2 to 10.0 fails...

[Brian Meade]

For Prime Collaboration Deployment, you need the full VMWare ESXi Standard
license or to be running off the trial.  The free ESXi license doesn't work
for PCD.

Cisco now has an add-on license (*Cisco UC Virtualization Foundation*) that
gives you this functionality for cheaper than a full ESXi Standard License.

On Wed, Mar 11, 2015 at 3:28 PM, Tommy Schlotterer <
tschlotte...@netechcorp.com> wrote:

> Do you still need to paid version of VMware to use PDC?
>
>
>
> Tommy
>
>
>
> *Tommy Schlotterer* | Systems Engineer
>
> CCNA, CCNA Voice
>
> 48325 Alpha Dr. Ste. 150
>
> Wixom, MI 48393
>
> *p* 248.468.0710
>
> *e* tschlotte...@netechcorp.com
>
> *w **netechcorp.com* 
>
>  [image: cid:DE00F175-A6C9-45A6-B3AC-D658551F1586]
>
> [image: cid:62EB95BF-20B4-4A1B-98FE-9E042594730A]
> 
>  [image: cid:47C21B6C-578D-4D72-BFF4-8A482CE7A978]
>  [image:
> cid:A362BD4D-9EC8-47CC-96A8-8A17AF38C15C] 
>  [image: cid:F52A69B8-DA49-4CD7-91E9-C057917D90C2]
> 
>
>
>
> *From:* cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] *On Behalf
> Of *Jonathan Charles
> *Sent:* Wednesday, March 11, 2015 2:56 PM
> *To:* Ryan Huff
> *Cc:* cisco-voip@puck.nether.net
>
> *Subject:* Re: [cisco-voip] Upgrade 9.1.2 to 10.0 fails...
>
>
>
> OK, so just an update for anyone else having this problem... I used Prime
> Collaboration Deployment 10.5.2 and the upgrade worked fine... it was
> actually really easy.
>
>
>
> One caveat though, you must install the ciscocm.version3-keys.cop.sgn
> update prior to attempting the upgrade.
>
>
>
> I used the same UCSInstall_UCOS_10.5.1.1-7.sgn.iso file I was trying
> to use before... no idea why it worked with PCD.
>
>
>
> PCD is really easy to setup and use too.
>
>
>
>
>
>
>
>
>
>
>
> Jonathan
>
>
>
> On Tue, Mar 10, 2015 at 12:05 PM, Jonathan Charles 
> wrote:
>
> Yeah, I a went thru the Cisco Live upgrade to 10 thing, it said PCD may be
> the way to go... let me try it... see what it does...
>
>
>
>
>
> J
>
>
>
> On Tue, Mar 10, 2015 at 11:44 AM, Ryan Huff  wrote:
>
> Martin,
>
> I have done a 7.1.3 to 10.5.1 before; I bit the bullet and setup PCD, and
> it went off without a hitch.
>
> Thanks,
>
> Ryan
>
> --
>
> From: m...@bilobit.com
> To: jonv...@gmail.com; ryanh...@outlook.com
> CC: cisco-voip@puck.nether.net
> Subject: AW: [cisco-voip] Upgrade 9.1.2 to 10.0 fails...
> Date: Tue, 10 Mar 2015 16:32:28 +
>
>
>
> At the moment i have the same problem with a jump upgrade from
> 7.1.3.1-11 to 10.5.2. It also does not work to 10.5.1.
>
>
>
> The same: Removed all subs, all network etc. is ok, NTP reachable and
> synchronized and so on.
>
>
>
> *arghl*
>
>
>
> *Von:* cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] *Im Auftrag
> von *Jonathan Charles
> *Gesendet:* Dienstag, 10. März 2015 16:23
> *An:* Ryan Huff
> *Cc:* cisco-voip@puck.nether.net
> *Betreff:* Re: [cisco-voip] Upgrade 9.1.2 to 10.0 fails...
>
>
>
> It is a jump upgrade (we are moving from a pizza box to vmware), I am
> doing the upgrade offbox to then import data to a 10.5.1 BE6K...
>
>
>
> I have rebooted it dozens of times... there is just one server (I have
> removed the other subs)...
>
>
>
>
>
> Jonathan
>
>
>
> On Tue, Mar 10, 2015 at 9:59 AM, Ryan Huff  wrote:
>
> In your email below it seemed you were trying an update from 10.0.1 to
> 10.5.1
>
> If you are coming *FROM* 9.1.2, you may be hitting this bug
> https://tools.cisco.com/bugsearch/bug/CSCup45923
>
> On page 3 of the 9.1.2 SU2 release notes (
> http://www.cisco.com/web/software/282074295/113937/cucm-readme-912su2-Rev2.pdf)
> it warns of this bug. The reported work around is to go directly to 10.5.1.
>
> f you are suggesting that you are still receiving the unknown error when
> trying to directly upgrade 9.1.2 *TO* 10.5.1, then I'd go ahead and raise
> a TAC case.
>
> If this isn't a production cluster or I didn't mind taking it down, I'd
> reboot the cluster then try a 9.1.2 -> 10.5.1 upgrade and if I still got
> the error, I'd raise a TAC case.
>
> Thanks,
>
> Ryan
> --
>
> Date: Tue, 10 Mar 2015 09:41:10 -0500
> Subject: Re: [cisco-voip] Upgrade 9.1.2 to 10.0 fails...
> From: jonv...@gmail.com
> To: ryanh...@outlook.com
> CC: agrec...@gmail.com; cisco-voip@puck.nether.net
>
>
>
> I applied the RSA cop file... the version from is 9.1.2.11900-12
>
>
>
> I have tried going to:
>
>
>
> 10.0.1.11900-2
>
> 10.5.1.1-7
>
>
>
> Same errors every time.
>
>
>
> All of them are the non-bootable ISO.
>
>
>
>
>
>
>
> Jonathan
>
>
>
> On Tue, Mar 10, 2015 at 6:22 AM, Ryan Huff  wrote:
>
> Jonathan,
> Have you applied any other cop or engineering special files besides the
> version 3 keys?
> Is your cluster based on the unrestricted export version or the rest

Re: [cisco-voip] Upgrade 9.1.2 to 10.0 fails...

[Tommy Schlotterer]

Do you still need to paid version of VMware to use PDC?

Tommy

Tommy Schlotterer | Systems Engineer
CCNA, CCNA Voice
48325 Alpha Dr. Ste. 150
Wixom, MI 48393
p 248.468.0710
e tschlotte...@netechcorp.com
w netechcorp.com
 [cid:image001.png@01D05C0F.F7FCA960]
[cid:image002.png@01D05C0F.F7FCA960]
 [cid:image003.png@01D05C0F.F7FCA960] 
  
[cid:image004.png@01D05C0F.F7FCA960]   
[cid:image005.png@01D05C0F.F7FCA960] 


From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Jonathan Charles
Sent: Wednesday, March 11, 2015 2:56 PM
To: Ryan Huff
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] Upgrade 9.1.2 to 10.0 fails...

OK, so just an update for anyone else having this problem... I used Prime 
Collaboration Deployment 10.5.2 and the upgrade worked fine... it was actually 
really easy.

One caveat though, you must install the ciscocm.version3-keys.cop.sgn update 
prior to attempting the upgrade.

I used the same UCSInstall_UCOS_10.5.1.1-7.sgn.iso file I was trying to use 
before... no idea why it worked with PCD.

PCD is really easy to setup and use too.





Jonathan

On Tue, Mar 10, 2015 at 12:05 PM, Jonathan Charles 
mailto:jonv...@gmail.com>> wrote:
Yeah, I a went thru the Cisco Live upgrade to 10 thing, it said PCD may be the 
way to go... let me try it... see what it does...


J

On Tue, Mar 10, 2015 at 11:44 AM, Ryan Huff 
mailto:ryanh...@outlook.com>> wrote:
Martin,

I have done a 7.1.3 to 10.5.1 before; I bit the bullet and setup PCD, and it 
went off without a hitch.

Thanks,

Ryan


From: m...@bilobit.com
To: jonv...@gmail.com; 
ryanh...@outlook.com
CC: cisco-voip@puck.nether.net
Subject: AW: [cisco-voip] Upgrade 9.1.2 to 10.0 fails...
Date: Tue, 10 Mar 2015 16:32:28 +


At the moment i have the same problem with a jump upgrade from 7.1.3.1-11 
to 10.5.2. It also does not work to 10.5.1.



The same: Removed all subs, all network etc. is ok, NTP reachable and 
synchronized and so on.



*arghl*



Von: cisco-voip 
[mailto:cisco-voip-boun...@puck.nether.net]
 Im Auftrag von Jonathan Charles
Gesendet: Dienstag, 10. März 2015 16:23
An: Ryan Huff
Cc: cisco-voip@puck.nether.net
Betreff: Re: [cisco-voip] Upgrade 9.1.2 to 10.0 fails...



It is a jump upgrade (we are moving from a pizza box to vmware), I am doing the 
upgrade offbox to then import data to a 10.5.1 BE6K...



I have rebooted it dozens of times... there is just one server (I have removed 
the other subs)...





Jonathan



On Tue, Mar 10, 2015 at 9:59 AM, Ryan Huff 
mailto:ryanh...@outlook.com>> wrote:

In your email below it seemed you were trying an update from 10.0.1 to 10.5.1

If you are coming FROM 9.1.2, you may be hitting this bug 
https://tools.cisco.com/bugsearch/bug/CSCup45923

On page 3 of the 9.1.2 SU2 release notes 
(http://www.cisco.com/web/software/282074295/113937/cucm-readme-912su2-Rev2.pdf)
 it warns of this bug. The reported work around is to go directly to 10.5.1.

f you are suggesting that you are still receiving the unknown error when trying 
to directly upgrade 9.1.2 TO 10.5.1, then I'd go ahead and raise a TAC case.

If this isn't a production cluster or I didn't mind taking it down, I'd reboot 
the cluster then try a 9.1.2 -> 10.5.1 upgrade and if I still got the error, 
I'd raise a TAC case.

Thanks,

Ryan



Date: Tue, 10 Mar 2015 09:41:10 -0500
Subject: Re: [cisco-voip] Upgrade 9.1.2 to 10.0 fails...
From: jonv...@gmail.com
To: ryanh...@outlook.com
CC: agrec...@gmail.com; 
cisco-voip@puck.nether.net



I applied the RSA cop file... the version from is 9.1.2.11900-12



I have tried going to:



10.0.1.11900-2

10.5.1.1-7



Same errors every time.



All of them are the non-bootable ISO.







Jonathan



On Tue, Mar 10, 2015 at 6:22 AM, Ryan Huff 
mailto:ryanh...@outlook.com>> wrote:
Jonathan,
Have you applied any other cop or engineering special files besides the version 
3 keys?
Is your cluster based on the unrestricted export version or the restricted 
export version? Does the update your applying match (restricted versus 
unrestricted)
Can you list out the specific version of 10.0.1 you are using and the specific 
version version of 10.5.1 that you want to go to?
If you do a "show version active" on all the cluster nodes; what do you see? Is 
it the same on all nodes?
I assume you tried to download a new image 

Re: [cisco-voip] Upgrade 9.1.2 to 10.0 fails...

[Jonathan Charles]

OK, so just an update for anyone else having this problem... I used Prime
Collaboration Deployment 10.5.2 and the upgrade worked fine... it was
actually really easy.

One caveat though, you must install the ciscocm.version3-keys.cop.sgn
update prior to attempting the upgrade.

I used the same UCSInstall_UCOS_10.5.1.1-7.sgn.iso file I was trying to
use before... no idea why it worked with PCD.

PCD is really easy to setup and use too.





Jonathan

On Tue, Mar 10, 2015 at 12:05 PM, Jonathan Charles 
wrote:

> Yeah, I a went thru the Cisco Live upgrade to 10 thing, it said PCD may be
> the way to go... let me try it... see what it does...
>
>
> J
>
> On Tue, Mar 10, 2015 at 11:44 AM, Ryan Huff  wrote:
>
>> Martin,
>>
>> I have done a 7.1.3 to 10.5.1 before; I bit the bullet and setup PCD, and
>> it went off without a hitch.
>>
>> Thanks,
>>
>> Ryan
>>
>>
>> --
>> From: m...@bilobit.com
>> To: jonv...@gmail.com; ryanh...@outlook.com
>> CC: cisco-voip@puck.nether.net
>> Subject: AW: [cisco-voip] Upgrade 9.1.2 to 10.0 fails...
>> Date: Tue, 10 Mar 2015 16:32:28 +
>>
>>
>>  At the moment i have the same problem with a jump upgrade from
>> 7.1.3.1-11 to 10.5.2. It also does not work to 10.5.1.
>>
>>
>>
>> The same: Removed all subs, all network etc. is ok, NTP reachable and
>> synchronized and so on.
>>
>>
>>
>> *arghl*
>>
>>
>>
>> *Von:* cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] *Im
>> Auftrag von *Jonathan Charles
>> *Gesendet:* Dienstag, 10. März 2015 16:23
>> *An:* Ryan Huff
>> *Cc:* cisco-voip@puck.nether.net
>> *Betreff:* Re: [cisco-voip] Upgrade 9.1.2 to 10.0 fails...
>>
>>
>>
>> It is a jump upgrade (we are moving from a pizza box to vmware), I am
>> doing the upgrade offbox to then import data to a 10.5.1 BE6K...
>>
>>
>>
>> I have rebooted it dozens of times... there is just one server (I have
>> removed the other subs)...
>>
>>
>>
>>
>>
>> Jonathan
>>
>>
>>
>> On Tue, Mar 10, 2015 at 9:59 AM, Ryan Huff  wrote:
>>
>>  In your email below it seemed you were trying an update from 10.0.1 to
>> 10.5.1
>>
>> If you are coming *FROM* 9.1.2, you may be hitting this bug
>> https://tools.cisco.com/bugsearch/bug/CSCup45923
>>
>> On page 3 of the 9.1.2 SU2 release notes (
>> http://www.cisco.com/web/software/282074295/113937/cucm-readme-912su2-Rev2.pdf)
>> it warns of this bug. The reported work around is to go directly to 10.5.1.
>>
>> f you are suggesting that you are still receiving the unknown error when
>> trying to directly upgrade 9.1.2 *TO* 10.5.1, then I'd go ahead and
>> raise a TAC case.
>>
>> If this isn't a production cluster or I didn't mind taking it down, I'd
>> reboot the cluster then try a 9.1.2 -> 10.5.1 upgrade and if I still got
>> the error, I'd raise a TAC case.
>>
>> Thanks,
>>
>> Ryan
>>
>>   --
>>
>> Date: Tue, 10 Mar 2015 09:41:10 -0500
>> Subject: Re: [cisco-voip] Upgrade 9.1.2 to 10.0 fails...
>> From: jonv...@gmail.com
>> To: ryanh...@outlook.com
>> CC: agrec...@gmail.com; cisco-voip@puck.nether.net
>>
>>
>>
>> I applied the RSA cop file... the version from is 9.1.2.11900-12
>>
>>
>>
>> I have tried going to:
>>
>>
>>
>> 10.0.1.11900-2
>>
>> 10.5.1.1-7
>>
>>
>>
>> Same errors every time.
>>
>>
>>
>> All of them are the non-bootable ISO.
>>
>>
>>
>>
>>
>>
>>
>> Jonathan
>>
>>
>>
>> On Tue, Mar 10, 2015 at 6:22 AM, Ryan Huff  wrote:
>>
>> Jonathan,
>> Have you applied any other cop or engineering special files besides the
>> version 3 keys?
>> Is your cluster based on the unrestricted export version or the
>> restricted export version? Does the update your applying match (restricted
>> versus unrestricted)
>> Can you list out the specific version of 10.0.1 you are using and the
>> specific version version of 10.5.1 that you want to go to?
>> If you do a "show version active" on all the cluster nodes; what do you
>> see? Is it the same on all nodes?
>> I assume you tried to download a new image file from CCO and use that?
>> Thanks,
>> Ryan
>>
>>
>>
>>  Original Message 
>> From: Jonathan Charles 
>> Sent: Tuesday, March 10, 2015 01:30 AM
>> To: Andrew Grech 
>> Subject: Re: [cisco-voip] Upgrade 9.1.2 to 10.0 fails...
>> CC: Cisco VoIP Group 
>>
>> Well, that didn't work... SFTP'd the ISO to the box, same error...
>>
>>
>>
>> Same error message...
>>
>>
>>
>>
>>
>>
>>
>> Jonathan
>>
>>
>>
>> On Mon, Mar 9, 2015 at 11:45 PM, Jonathan Charles 
>> wrote:
>>
>>  It is re-running after SFTPing from a Windows box (FreeFTPd)...
>>
>>
>>
>>
>>
>> Jonathan
>>
>>
>>
>> On Mon, Mar 9, 2015 at 11:31 PM, Andrew Grech  wrote:
>>
>> Hi john, I've had a ISO from Linux to prime with bad permissions and had
>> this error
>>
>> On 10/03/2015 1:13 PM, "Jonathan Charles"  wrote:
>>
>>  OK, let me try via SFTP (Windows box)... see what happens...
>>
>>
>>
>>
>>
>> Jonathan
>>
>>
>>
>> On Mon, Mar 9, 2015 at 9:26 PM, Charles Goldsmith 
>> wrote:
>>
>>  Given that it is complaining about accessing the upgrade f

Re: [cisco-voip] CUE 8.6.5 notification to gmail...

[Rob Dawson]

Have you tried a full SMTP AUTH and send test via telnet or just that the port 
responded?

Rob


From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Jonathan Charles
Sent: Wednesday, March 11, 2015 11:43 AM
To: Brian Meade
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] CUE 8.6.5 notification to gmail...

Telnet to smtp.gmail.com on 465 from that subnet works 
fine...


Jonathan

On Wed, Mar 11, 2015 at 9:40 AM, Brian Meade 
mailto:bmead...@vt.edu>> wrote:
Port 465 blocked?

On Tue, Mar 10, 2015 at 10:19 PM, Jonathan Charles 
mailto:jonv...@gmail.com>> wrote:
We loaded the gmail settings and we keep getting...

Test Result: Could not connect to SMTP host: 
smtp.gmail.com, port: 465

We can ping GMAIL from the CUE:

se-192-168-124-2# ping smtp.gmail.com
PING gmail-smtp-msa.l.google.com 
(74.125.193.109) 56(84) bytes of data.
64 bytes from 74.125.193.109: icmp_seq=1 ttl=48 
time=12.5 ms
64 bytes from ig-in-f109.1e100.net 
(74.125.193.109): icmp_seq=2 ttl=48 time=12.4 ms
64 bytes from ig-in-f109.1e100.net 
(74.125.193.109): icmp_seq=3 ttl=48 time=12.4 ms
64 bytes from ig-in-f109.1e100.net 
(74.125.193.109): icmp_seq=4 ttl=48 time=12.3 ms
64 bytes from ig-in-f109.1e100.net 
(74.125.193.109): icmp_seq=5 ttl=48 time=12.3 ms

--- gmail-smtp-msa.l.google.com ping 
statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 71ms
rtt min/avg/max/mdev = 12.329/12.411/12.550/0.124 ms, ipg/ewma 17.804/12.477 ms
se-192-168-124-2#

We have also verified our credentials... any idea why we keep getting the error?



Jonathan

___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip


___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] CUE 8.6.5 notification to gmail...

[Brian Meade]

Port 465 blocked?

On Tue, Mar 10, 2015 at 10:19 PM, Jonathan Charles 
wrote:

> We loaded the gmail settings and we keep getting...
>
> Test Result: Could not connect to SMTP host: smtp.gmail.com, port: 465
>
> We can ping GMAIL from the CUE:
>
> se-192-168-124-2# ping smtp.gmail.com
> PING gmail-smtp-msa.l.google.com (74.125.193.109) 56(84) bytes of data.
> 64 bytes from 74.125.193.109: icmp_seq=1 ttl=48 time=12.5 ms
> 64 bytes from ig-in-f109.1e100.net (74.125.193.109): icmp_seq=2 ttl=48
> time=12.4 ms
> 64 bytes from ig-in-f109.1e100.net (74.125.193.109): icmp_seq=3 ttl=48
> time=12.4 ms
> 64 bytes from ig-in-f109.1e100.net (74.125.193.109): icmp_seq=4 ttl=48
> time=12.3 ms
> 64 bytes from ig-in-f109.1e100.net (74.125.193.109): icmp_seq=5 ttl=48
> time=12.3 ms
>
> --- gmail-smtp-msa.l.google.com ping statistics ---
> 5 packets transmitted, 5 received, 0% packet loss, time 71ms
> rtt min/avg/max/mdev = 12.329/12.411/12.550/0.124 ms, ipg/ewma
> 17.804/12.477 ms
> se-192-168-124-2#
>
> We have also verified our credentials... any idea why we keep getting the
> error?
>
>
>
> Jonathan
>
> ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] CUE 8.6.5 notification to gmail...

[gentoo]

Possibly an SSL/TLS issue.

Can you get a packet capture of the CUE trying to connect?

CUE traces of the process as well?

Just a guess, but if you don't have a trusted CA installed on the CUE 
that trusts Gmail's SSL cert, this probably won't work.  Haven't played 
with SMTP/ssl on CUE, but this would certainly be an issue for just an 
SMTP client/server.


Is SSL a requirement?  Does gmail offer a non-SSL connection (to atleast 
test with)?


On 2015-03-11 10:43, Jonathan Charles wrote:

Telnet to smtp.gmail.com [1] on 465 from that subnet works fine...

Jonathan

On Wed, Mar 11, 2015 at 9:40 AM, Brian Meade  wrote:


Port 465 blocked?

On Tue, Mar 10, 2015 at 10:19 PM, Jonathan Charles
 wrote:


We loaded the gmail settings and we keep getting...

Test Result: Could not connect to SMTP host: smtp.gmail.com [1],
port: 465

We can ping GMAIL from the CUE:

se-192-168-124-2# ping smtp.gmail.com [1]
PING gmail-smtp-msa.l.google.com [2] (74.125.193.109) 56(84) bytes
of data.
64 bytes from 74.125.193.109 [3]: icmp_seq=1 ttl=48 time=12.5 ms
64 bytes from ig-in-f109.1e100.net [4] (74.125.193.109):
icmp_seq=2 ttl=48 time=12.4 ms
64 bytes from ig-in-f109.1e100.net [4] (74.125.193.109):
icmp_seq=3 ttl=48 time=12.4 ms
64 bytes from ig-in-f109.1e100.net [4] (74.125.193.109):
icmp_seq=4 ttl=48 time=12.3 ms
64 bytes from ig-in-f109.1e100.net [4] (74.125.193.109):
icmp_seq=5 ttl=48 time=12.3 ms

--- gmail-smtp-msa.l.google.com [2] ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 71ms
rtt min/avg/max/mdev = 12.329/12.411/12.550/0.124 ms, ipg/ewma
17.804/12.477 ms
se-192-168-124-2# 

We have also verified our credentials... any idea why we keep
getting the error?

Jonathan
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip [5]




Links:
--
[1] http://smtp.gmail.com
[2] http://gmail-smtp-msa.l.google.com
[3] http://74.125.193.109
[4] http://ig-in-f109.1e100.net
[5] https://puck.nether.net/mailman/listinfo/cisco-voip

___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] vMotion w/o Shared Storage

[Anthony Holloway]

Daniel,

Could you give a little more detail about your experience with this
process?  The confusion you faced is likely the same confusion many of us
would face.

Which document(s) did you follow?  Which files did you copy?  What were the
high level steps? etc.

On Tue, Mar 10, 2015 at 9:02 PM Daniel Pagan  wrote:

>  Thanks Dave. I also came across these details, but it too states shared
> storage:
>
>
>
> “A Virtual Machine (VM) file on network/shared storage can be booted on
> any physical server hosting ESXi that has access to that network shared
> storage.”
>
>
>
> But perhaps *my* confusion was vMotion vs cold migration. My original
> thought was using Enhanced vMotion since the objective was to bring the VM
> config and disk to another host and unshared datastore.
>
>
>
> http://www.vladan.fr/vmware-enhanced-vmotion/
>
>
> http://www.ntpro.nl/blog/archives/2118-Enhanced-vMotion-with-vSphere-5.1.html
>
>
>
> I wasn’t sure if this was Cisco supported since all mention of vMotion
> migrations in the VMware requirements document state shared storage, but it
> seems this doesn’t quite fit the process of vMotion (Enhanced or not) since
> the virtual machine is powered off anyway. This would certainly fall under
> the category of cold migration, which is definitely Cisco supported.
>
>
>
> Some confusion on my part between the two migration methods but all is
> clear.
>
>
>
> Thanks!
>
>
>
> - Dan
>
>
>
>
>
> *From:* Dave Goodwin [mailto:dave.good...@december.net]
> *Sent:* Tuesday, March 10, 2015 8:47 PM
> *To:* Daniel Pagan
> *Cc:* Ryan Huff; cisco-voip@puck.nether.net
>
>
> *Subject:* Re: [cisco-voip] vMotion w/o Shared Storage
>
>
>
> Keep in mind that moving a VM from one host to another (whether the VM's
> storage is being moved or not) is not considered a vMotion. That is why you
> can do it even without enabling any NICs on the host for the vMotion
> feature. Therefore, the VMWare feature you'd want to look for in the matrix
> is probably "Restart Virtual Machine on Different ESXi Host" and not
> vMotion.
>
> http://docwiki.cisco.com/wiki/Unified_Communications_VMware_Requirements
>
>
>
> On Tue, Mar 10, 2015 at 6:18 PM, Daniel Pagan  wrote:
>
> Thanks - that’s what I figured and just tested with no issues. Seems the
> non-shared storage caveat for vMotion is a non-issue in ESXi 5.1 and
> higher.
>
>
>
>
> http://pubs.vmware.com/vsphere-51/index.jsp?topic=%2Fcom.vmware.vsphere.vcenterhost.doc%2FGUID-9F1D4A3B-3392-46A3-8720-73CBFA000A3C.html
>
>
>
> I was also concerned of partition alignment but I guess that would be a
> non-issue as well since the vmdk is already provisioned. The move to the
> stand-alone datastore is nearing completion so I’ll double check the start
> block size once it’s done just to be sure!
>
>
>
> - Dan
>
>
>
>
>
> *From:* Ryan Huff [mailto:ryanh...@outlook.com]
> *Sent:* Tuesday, March 10, 2015 5:08 PM
> *To:* Daniel Pagan; cisco-voip@puck.nether.net
> *Subject:* Re: [cisco-voip] vMotion w/o Shared Storage
>
>
>
> Shutdown, yes. Running, no.
>
> Thanks,
>
> Ryan
>
>
>
>  Original Message 
> From: Daniel Pagan 
> Sent: Tuesday, March 10, 2015 05:06 PM
> To: cisco-voip@puck.nether.net
> Subject: [cisco-voip] vMotion w/o Shared Storage
>
> Quick question…
>
>
>
> vMotion of a shut down UCM between two hosts without shared storage using
> vCenter. Is this supported? The virtualization document for UC platforms
> says vMotion is supported on shared storage, so I figured to ask. Is this
> migration method supported?
>
>
>
> - Dan
>
>
> ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>   ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] SBC/SIP Trunk Design queries

[Tim Smith]

Hi Terry,

I do quite a bit of CUBE, and have done a bit of Acme as well.

There were some recent partner sessions that talk about some interesting things 
coming for CUBE, so it’s worth making sure you are getting latest roadmap info.

My main comparison points..

# HA

In enterprise there was HA on CUBE, and it was improving in each release (but 
there are caveats with it)
Have found Acme HA to be seamless and rock solid.

# Deployment

Cisco has some great interop guides – if you go with a carrier that has spent 
the money, a lot of the hard work has been done for you in terms of testing (as 
you know SIP can be implemented and configured in many different ways – if 
someone hasn’t done a lot of testing up front, you do sometimes end up adding 
SIP profiles and tweaks as you discover issues)

Acme has some very thorough guides – I’m not sure if they have interop testing 
with carriers – given they are in SP’s a lot, there is a good chance they do. 
I’d look into it that with the Acme SE. Talk to prospective ITSP’s about their 
testing, and supported SBC’s.

# Ops

CUBE enterprise is great, IOS, most people are familiar. You will most likely 
need to train people on Acme
I find troubleshooting a bit of a let down with CUBE. Basically log to buffer, 
copy to file, or packet captures. Wireshark with ladders or TranslatorX are 
great, but it’s getting the files there that bugs me.
Alternatively, there did seem to be a few 3rd party tools out there, but you 
are probably looking at $$$

Acme has web interface, list of calls and then ability to drill down with 
ladder diagrams, messaging capture etc. You should see this before making 
decision.

Some good knowledge on Acme forums
Acme has very flexible manipulation – CUBE is quite good too (and they have 
great profile testing tool) – plus you can also use CUCM LUA on the SIP trunk

# On your other notes

Centralised – this is great for flexibility DR etc, standard stuff be aware of 
the call volumes over the WAN, caller ID considerations for emergency and local 
pizza shop type services

WAN – we terminate on existing equipment, and Acme is in a VLAN, I think this 
is most flexible.. you have a very flexible set up in Acme in regard to 
networking, lots of zones, interface options etc.

Transcoding – I think you could still utilise CUCM registered transcoders for 
the ASR scenario..

Virtual - We use virtual Acme, it had some teething problems in very first 
versions (and a clunky license on USB stick thing going on) but it seems to be 
good now
We don’t have transcoding / media resources in the virtual 
edition

Flow through / around – a lot of designs the carrier doesn’t have connectivity 
into the rest of the network, so flow through is quite typical.
However, we do have carriers here that have SBC’s on your WAN, 
so flow through can be nice here – it also then makes CUBE HA less important, 
i.e. if call is set up, media is from end point to carrier SBC already (if no 
xcoding involved)

So I won’t say one way or the other, just my thoughts on things you can 
consider.
I like both, and will continue to work on both!

Cheers,

Tim


From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Terry 
Cheema
Sent: Wednesday, 11 March 2015 1:10 PM
To: cisco-voip voyp list
Subject: [cisco-voip] SBC/SIP Trunk Design queries

Hi List,

I am working on to finalize the SBC vendor for one of our environments. I have 
a couple of queries related to the SIP Trunk design and SBC vendor 
choices(basically CUBE vs Acme Packet). I would really appreciate if anyone 
with SIP Trunking/SBC expertise  (Cisco/Acme Packet) can provide some input on 
the below queries:

1)  CUBE vs Acme Packet: First of all Cisco has marked the CUBE SP Edition 
product line for EoL, exiting the SBC Service Provider segment, so leaving only 
SBC Enterprise as the option. Although at this stage we are looking for an 
enterprise grade SBC but it will be a plus if it has the potential to step up 
into a SP SBC in a multi-tenanted environment. I was comparing AP 3820 with the 
CUBE Ent ASR1k-x:

CUBE provides no HA (though in some documents it says, came out from a meeting 
with the Cisco SME informing HA is not available), No transcoding (due to lack 
of DSP on ASR1K), No Multi-tenancy support  with all of these features 
supported in a 3820 SBC
Any feature better in CUBE that I may have overlooked? I am aware that CUBE 
configuration etc. can be easy compared to Acme Packet but apart from that any 
solid reason to choose CUBE over AP?
2)  HA vs Non-HA: HA is obviously the preferred approach and looks like 
only possible with AP. Can anyone confirm the HA works as claimed by AP? Due to 
the costs involved in double the equipment – whats the common approach followed 
here HA or non-HA?
3)  Centralised Design: We are planning on a centralised SIP solution (with 
SBCs at both the DCs), anything to be careful of?
4)  Transcoding: CUBE ASR1K d

Re: [cisco-voip] SBC/SIP Trunk Design queries

[Tim Smith]

No problems, I'm also keen to hear other peoples experience too.

It's an interesting topic!



Cheers,



Tim.




From: Terry Cheema 
Sent: Wednesday, 11 March 2015 5:09 PM
To: Tim Smith
Cc: cisco-voip voyp list
Subject: Re: [cisco-voip] SBC/SIP Trunk Design queries

Tim,

Thanks for your detailed and a quick response, much appreciated.

Thanks,
Terry



On Wed, Mar 11, 2015 at 3:19 PM, Tim Smith 
mailto:tim.sm...@enject.com.au>> wrote:
Hi Terry,

I do quite a bit of CUBE, and have done a bit of Acme as well.

There were some recent partner sessions that talk about some interesting things 
coming for CUBE, so it’s worth making sure you are getting latest roadmap info.

My main comparison points..

# HA

In enterprise there was HA on CUBE, and it was improving in each release (but 
there are caveats with it)
Have found Acme HA to be seamless and rock solid.

# Deployment

Cisco has some great interop guides – if you go with a carrier that has spent 
the money, a lot of the hard work has been done for you in terms of testing (as 
you know SIP can be implemented and configured in many different ways – if 
someone hasn’t done a lot of testing up front, you do sometimes end up adding 
SIP profiles and tweaks as you discover issues)

Acme has some very thorough guides – I’m not sure if they have interop testing 
with carriers – given they are in SP’s a lot, there is a good chance they do. 
I’d look into it that with the Acme SE. Talk to prospective ITSP’s about their 
testing, and supported SBC’s.

# Ops

CUBE enterprise is great, IOS, most people are familiar. You will most likely 
need to train people on Acme
I find troubleshooting a bit of a let down with CUBE. Basically log to buffer, 
copy to file, or packet captures. Wireshark with ladders or TranslatorX are 
great, but it’s getting the files there that bugs me.
Alternatively, there did seem to be a few 3rd party tools out there, but you 
are probably looking at $$$

Acme has web interface, list of calls and then ability to drill down with 
ladder diagrams, messaging capture etc. You should see this before making 
decision.

Some good knowledge on Acme forums
Acme has very flexible manipulation – CUBE is quite good too (and they have 
great profile testing tool) – plus you can also use CUCM LUA on the SIP trunk

# On your other notes

Centralised – this is great for flexibility DR etc, standard stuff be aware of 
the call volumes over the WAN, caller ID considerations for emergency and local 
pizza shop type services

WAN – we terminate on existing equipment, and Acme is in a VLAN, I think this 
is most flexible.. you have a very flexible set up in Acme in regard to 
networking, lots of zones, interface options etc.

Transcoding – I think you could still utilise CUCM registered transcoders for 
the ASR scenario..

Virtual - We use virtual Acme, it had some teething problems in very first 
versions (and a clunky license on USB stick thing going on) but it seems to be 
good now
We don’t have transcoding / media resources in the virtual 
edition

Flow through / around – a lot of designs the carrier doesn’t have connectivity 
into the rest of the network, so flow through is quite typical.
However, we do have carriers here that have SBC’s on your WAN, 
so flow through can be nice here – it also then makes CUBE HA less important, 
i.e. if call is set up, media is from end point to carrier SBC already (if no 
xcoding involved)

So I won’t say one way or the other, just my thoughts on things you can 
consider.
I like both, and will continue to work on both!

Cheers,

Tim


From: cisco-voip 
[mailto:cisco-voip-boun...@puck.nether.net]
 On Behalf Of Terry Cheema
Sent: Wednesday, 11 March 2015 1:10 PM
To: cisco-voip voyp list
Subject: [cisco-voip] SBC/SIP Trunk Design queries

Hi List,

I am working on to finalize the SBC vendor for one of our environments. I have 
a couple of queries related to the SIP Trunk design and SBC vendor 
choices(basically CUBE vs Acme Packet). I would really appreciate if anyone 
with SIP Trunking/SBC expertise  (Cisco/Acme Packet) can provide some input on 
the below queries:

1)  CUBE vs Acme Packet: First of all Cisco has marked the CUBE SP Edition 
product line for EoL, exiting the SBC Service Provider segment, so leaving only 
SBC Enterprise as the option. Although at this stage we are looking for an 
enterprise grade SBC but it will be a plus if it has the potential to step up 
into a SP SBC in a multi-tenanted environment. I was comparing AP 3820 with the 
CUBE Ent ASR1k-x:

CUBE provides no HA (though in some documents it says, came out from a meeting 
with the Cisco SME informing HA is not available), No transcoding (due to lack 
of DSP on ASR1K), No Multi-tenancy support  with all of these features 
supported in a 3820 SBC
Any feature better in CUBE that I may have overlooked? I am aware that CUBE 
configuration etc. c

Re: [cisco-voip] SBC/SIP Trunk Design queries

[Terry Cheema]

Tim,

Thanks for your detailed and a quick response, much appreciated.

Thanks,
Terry



On Wed, Mar 11, 2015 at 3:19 PM, Tim Smith  wrote:

>  Hi Terry,
>
>
>
> I do quite a bit of CUBE, and have done a bit of Acme as well.
>
>
>
> There were some recent partner sessions that talk about some interesting
> things coming for CUBE, so it’s worth making sure you are getting latest
> roadmap info.
>
>
>
> My main comparison points..
>
>
>
> # HA
>
>
>
> In enterprise there was HA on CUBE, and it was improving in each release
> (but there are caveats with it)
>
> Have found Acme HA to be seamless and rock solid.
>
>
>
> # Deployment
>
>
>
> Cisco has some great interop guides – if you go with a carrier that has
> spent the money, a lot of the hard work has been done for you in terms of
> testing (as you know SIP can be implemented and configured in many
> different ways – if someone hasn’t done a lot of testing up front, you do
> sometimes end up adding SIP profiles and tweaks as you discover issues)
>
>
>
> Acme has some very thorough guides – I’m not sure if they have interop
> testing with carriers – given they are in SP’s a lot, there is a good
> chance they do. I’d look into it that with the Acme SE. Talk to prospective
> ITSP’s about their testing, and supported SBC’s.
>
>
>
> # Ops
>
>
>
> CUBE enterprise is great, IOS, most people are familiar. You will most
> likely need to train people on Acme
>
> I find troubleshooting a bit of a let down with CUBE. Basically log to
> buffer, copy to file, or packet captures. Wireshark with ladders or
> TranslatorX are great, but it’s getting the files there that bugs me.
>
> Alternatively, there did seem to be a few 3rd party tools out there, but
> you are probably looking at $$$
>
>
>
> Acme has web interface, list of calls and then ability to drill down with
> ladder diagrams, messaging capture etc. You should see this before making
> decision.
>
>
>
> Some good knowledge on Acme forums
>
> Acme has very flexible manipulation – CUBE is quite good too (and they
> have great profile testing tool) – plus you can also use CUCM LUA on the
> SIP trunk
>
>
>
> # On your other notes
>
>
>
> Centralised – this is great for flexibility DR etc, standard stuff be
> aware of the call volumes over the WAN, caller ID considerations for
> emergency and local pizza shop type services
>
>
>
> WAN – we terminate on existing equipment, and Acme is in a VLAN, I think
> this is most flexible.. you have a very flexible set up in Acme in regard
> to networking, lots of zones, interface options etc.
>
>
>
> Transcoding – I think you could still utilise CUCM registered transcoders
> for the ASR scenario..
>
>
>
> Virtual - We use virtual Acme, it had some teething problems in very first
> versions (and a clunky license on USB stick thing going on) but it seems to
> be good now
>
> We don’t have transcoding / media resources in the virtual
> edition
>
>
>
> Flow through / around – a lot of designs the carrier doesn’t have
> connectivity into the rest of the network, so flow through is quite typical.
>
> However, we do have carriers here that have SBC’s on your
> WAN, so flow through can be nice here – it also then makes CUBE HA less
> important, i.e. if call is set up, media is from end point to carrier SBC
> already (if no xcoding involved)
>
>
>
> So I won’t say one way or the other, just my thoughts on things you can
> consider.
>
> I like both, and will continue to work on both!
>
>
>
> Cheers,
>
>
>
> Tim
>
>
>
>
>
> *From:* cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] *On Behalf
> Of *Terry Cheema
> *Sent:* Wednesday, 11 March 2015 1:10 PM
> *To:* cisco-voip voyp list
> *Subject:* [cisco-voip] SBC/SIP Trunk Design queries
>
>
>
> Hi List,
>
>
>
> I am working on to finalize the SBC vendor for one of our environments. I
> have a couple of queries related to the SIP Trunk design and SBC vendor
> choices(basically CUBE vs Acme Packet). I would really appreciate if anyone
> with SIP Trunking/SBC expertise  (Cisco/Acme Packet) can provide some input
> on the below queries:
>
>
>
> 1)  *CUBE vs Acme Packet*: First of all Cisco has marked the CUBE SP
> Edition product line for EoL, exiting the SBC Service Provider segment, so
> leaving only SBC Enterprise as the option. Although at this stage we are
> looking for an enterprise grade SBC but it will be a plus if it has the
> potential to step up into a SP SBC in a multi-tenanted environment. I was
> comparing AP 3820 with the CUBE Ent ASR1k-x:
>
>
>
> CUBE provides no HA (though in some documents it says, came out from a
> meeting with the Cisco SME informing HA is not available), No transcoding
> (due to lack of DSP on ASR1K), No Multi-tenancy support  with all of these
> features supported in a 3820 SBC
>
> Any feature better in CUBE that I may have overlooked? I am aware that
> CUBE configuration etc. can be easy compared to Acme Packet but apart from
> that any solid reason to choose CUBE over