[VoiceOps] Offtopic (SBC recommendations)

Thu Sep 3 11:32:24 EDT 2009

4.x has been GREAT and so far 6.x hasn't posed any issues, granted the few SD pairs running on the 6.x code are light on traffic, but we've got 13 more SD pairs to upgrade.....which are high traffic boxes!!!

I do know that Acme does NOT like us staying on 4.x.  Just had a sync issue last week and they basically said that the code is at the end-of-life and they won't go into further troubleshooting. :(

We'll see how it all works out on 6.1.0

-----Original Message-----
From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of David Hiers
Sent: Thursday, September 03, 2009 9:41 AM
To: Balmik Soin
Cc: voiceops at voiceops.org
Subject: Re: [VoiceOps] Offtopic (SBC recommendations)

We were really happy with acme on 4.x, we talked them up at every chance.

Once we got on  5.x and 6.x, however, it seems that we've been
lurching from one traffic-killing crash to the next in search for a
stable version.

I get the sense that their business model refuses to fully countenance
the criticality and complexity of their product and its associated
ecosystem, and therefore under-funds quality of design and
implementation, as well as the breadth and depth of testing.

David

On Wed, Sep 2, 2009 at 8:21 PM, Balmik Soin<balmik at staff.iinet.net.au> wrote:
> We're extremely happy with our Acme 4250s - but then again we started with the original Kagoor product (pre-Juniper), so almost anything was an improvement. Been on the 4.1 codebase for a while now, in the process of moving to 6.1.
>
> Acme support speed varies noticeably based the priority you set - when we've had a serious case (thankfully rare) their support has been fantastic, they've been all over it and provided us solutions very fast. As others have mentioned, for config assistance/lab stuff they can take their time (compared to our other vendors) but we've found that our Acme SE will turn things around pretty quick so we tend to use him for that sort of thing if we need it faster.
>
> --
> Balmik Soin [CCIE #19255]
> Voice Operations Manager
> iiNet Limited
>
> ________________________________
> From: Brandon Buckner <BrandonB at netins.com>
> Date: Thu, 3 Sep 2009 06:30:12 +0800
> To: <voiceops at voiceops.org>
> Subject: Re: [VoiceOps] Offtopic (SBC recommendations)
>
> We're also using Acme 4250s. I agree with Jarrett, though: Acme support can be rather slow to respond at times. Although in the few years we've been running them we've never had the boxes themselves fail, so it's mainly just been asking for config suggestions when we wished to implement or test new services at lower ticket priority levels.
>
> ----
> Brandon Buckner
> Switching Technician / VoIP Admin
> Iowa Network Services
> brandonb at netins.com
>
>
> -----Original Message-----
> From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Watkins, Jarrett
> Sent: Wednesday, September 02, 2009 4:09 PM
> To: Sorensen, Marty; J. Oquendo; voiceops at voiceops.org
> Subject: [LIKELY JUNK]Re: [VoiceOps] Offtopic (SBC recommendations)
>
>
>
> Same here.  We are primarily using the Acme 4250's but have had the
> Sonus NBS implemented for some time now and haven't had any issues
> there. The Acme's are simple and generally trouble free but we did have
> issues with some of their earlier codes. [random reboots, high cpu, fun
> stuff, etc]
>
> The main thing is that Sonus support is much better than Acme support!!!
>
> We're on the 6.1.0 Acme code and all is well so far......
>
>
>
> -----Original Message-----
> From: voiceops-bounces at voiceops.org
> [mailto:voiceops-bounces at voiceops.org] On Behalf Of Sorensen, Marty
> Sent: Wednesday, September 02, 2009 3:00 PM
> To: J. Oquendo; voiceops at voiceops.org
> Subject: Re: [VoiceOps] Offtopic (SBC recommendations)
>
> We have Acme 4250s and 4500s presently.  If we were to go out NOW, we
> would take a good hard look at the Sonus Network Border Switch (NBS).
> We looked at them early on during our build out and found them less
> appealing than the Acmes.  Since that time, the appear to have improved
> significantly in terms of capabilities at least on paper.  We have not
> actually tested them yet however in our staging environment.
>
> -----Original Message-----
> From: voiceops-bounces at voiceops.org
> [mailto:voiceops-bounces at voiceops.org] On Behalf Of J. Oquendo
> Sent: Wednesday, September 02, 2009 11:42 AM
> To: voiceops at voiceops.org
> Subject: [VoiceOps] Offtopic (SBC recommendations)
>
>
> Hey all, (I'm sure for those who I criss-cross lists with - you've seen
> it before)...
>
> We're definitely looking to replace our outgoing Nutrakes
> (pre-audiocodes assimilation) and we've been looking at a few. While I
> will say I'm impressed with Acme and Covergence (which is now Acme
> anyway), anyone care to either off or on list comment about others
> you've had success with. Any particular one with perhaps a pre-paid
> system/spinoff/module/compartment/* (don't ask) is a plus.
>
> Keep in mind, the less interops (big 4, VZ, GLBX, L3, AT&T) we can do,
> the better! (hooray for less work on the plates).
>
> So far, as stated, I personally liked Covergence's offering as have I
> Acme, haven't looked at Sonus yet, but was wondering what else are we
> (myself and colleagues) missing. Newport Networks is pretty much gone
> the puppets.com, socks.com, VirtualAvenue, Xoom route of the dinosaur.
> So without further a rambling... Suggestions.
>
>
> --
>
> =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
> J. Oquendo
> SGFA, SGFE, C|EH, CNDA, CHFI, OSCP
>
> "It takes 20 years to build a reputation and five minutes to
> ruin it. If you think about that, you'll do things
> differently." - Warren Buffett
>
> 227C 5D35 7DCB 0893 95AA  4771 1DCE 1FD1 5CCD 6B5E
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E
>
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
>
> This message and any attachments are intended only for the use of the
> addressee and may contain information that is privileged and
> confidential. If the reader of the message is not the intended recipient
> or an authorized representative of the intended recipient, you are
> hereby notified that any dissemination of this communication is strictly
> prohibited. If you have received this communication in error, please
> notify us immediately by e-mail and delete the message and any
> attachments from your system.
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
>
> This email and any attachments ("Message") may contain legally privileged and/or confidential information.  If you are not the addressee, or if this Message has been addressed to you in error, you are not authorized to read, copy, or distribute it, and we ask that you please delete it (including all copies) and notify the sender by return email.  Delivery of this Message to any person other than the intended recipient(s) shall not be deemed a waiver of confidentiality and/or a privilege.
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
_______________________________________________
VoiceOps mailing list
VoiceOps at voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

This email and any attachments ("Message") may contain legally privileged and/or confidential information.  If you are not the addressee, or if this Message has been addressed to you in error, you are not authorized to read, copy, or distribute it, and we ask that you please delete it (including all copies) and notify the sender by return email.  Delivery of this Message to any person other than the intended recipient(s) shall not be deemed a waiver of confidentiality and/or a privilege.