|
|
Acme Packet, Inc. |
I posted this a while ago but it disapeard with a weeks worth of posts
on googe.
I first met the Acme Packet folks at spring VON 2006, at the time I
didn't fully understand the value of Session Boarder Controllers
(SBCs) but I did understand that I was going to need them for NAT
traversal and to scale the hosted IP voice solution that I was
designing for a client of ours. I was impressed with their very
knowledgeable staff, they worked closely with us to assist in the
advisory relationship with our client and helped us understand the
benefits and the need for Acme Packet SBCs.
Eventually I left that company to join a hosted IP Telephony start-up.
Our goal was to build a highly redundant, fault tolerant,
geographically diverse and scalable (to 50 000 subscribers +) hosted
IP Centrex solution.
Basically this consists of two geographically-diverse data centers,
firewalls, routers, switches, call servers, media servers, a
Metaswitch (through a third party via SIP Peering, this is the
interface to the PSTN), WAN, etc.
Initially we had attempted to do this without SBCs (due to cost/price)
however we found it is just not possible to reasonably secure and
scale a large-scale and/or publicly accessible IP Telephony solution
without SBCs.
We had everything in place and all we needed was our SBCs and without
warning our SBCs arrived (NOT Acme Packets). For all the hype around
what SBCs would do for us I was disappointed as they looked and felt
like generic 1U servers and ran what appeared to be fairly generic
Linux.
I had seen this type of "product" before, the type where someone takes
Linux, cranks out some java, installs it on a generic 1U server (maybe
even silk-screens it to make it look unique) and calls it a product. I
do believe it was somewhat more than this but that was my first
impression.
As I was busy designing and implementing other parts of the solution I
was not involved in the configuring/purchasing of our first set of
SBCs so I don't know the granular details but we were unable to use
them in our solution due to limitations related to SIP peering and
media routing (IIRC).
So... out goes our first attempt at integrating SBCs and in comes the
Acme Packets, we had avoided them initially due to price, however you
do get what you pay for.
Opening the boxes revealed an absolutely stunning piece of hardware.
It was very dense, polished, custom designed and built from the ground
up with every little detail in mind from the slick dual power supplies
to the modular gigabit SFPs on the front. I have an unusual
appreciation for quality plastics, metals and rubber used in phones,
routers, switches, firewalls and other appliance like devices, the
Acme Packets satisfied that appreciation in every way.
The physical implementation was very straightforward with a few simple
instructions we had them racked up, powered on and remotely
accessible. We had a consultant configure the basics for us and we
were up and running in a matter of hours.
We purchased them in HA (highly available) redundant pairs, one pair
for each data center. The failover testing went flawlessly.
We needed to be able to manage, configure and support our Acme Packets
as much as possible in house to determine whether or not the SBCs were
playing a role in any issue we might have and to better understand how
we can leverage them in our environment so I was sent to Acme Packet
HQ in Cambridge for training. It's about an 8 to 10 hour flight for
me, I hate flying!
The Acme Packet HQ is very sharp in appearance but not lavish as some
startups were back during the dot-com, you get the impression of an
image conscious and efficient organization.
As we got into training I was blown away to find the Acme Packet
command line, was very similar to Cisco, being a bit of a "Cisco
whore" I was very comfortable navigating my way around, figuring
commands out by using the help function and some intuition from my
extensive experience with Cisco routers and switches. This makes the
Acme Packets very accessible to those of us with Cisco IOS experience
and a relatively deep understanding of SIP (or one of a number of
other supported protocols).
The Acme Packet OS and hardware is entirely unique to Acme Packet,
this is not a Linux application on "win-tel" hardware, it's not even
in the same universe. This is a completely specialized and industrial
solution. Much of what the Acme Packets do is done in hardware,
making them scaleable, efficient and relatively heavy.
Our instructor was very knowledgeable in many aspects of technology,
from packet-level TCP/IP to operating system code and routers,
switches, firewalls, etc.
Back from my training I ordered some books from Acme, they were
shipped almost instantly, Acme Packet even emailed me to let me know
that the delivery had failed because no one was there to accept it,
they were tracking my package for me, now that's customer service!
The Acme Support team has been amazing, they are extremely responsive
and have been able to give us a solid answer or solution for all of
our requests. Each analyst has been impressively competent.
After dedicating months to gaining an intimate understanding of our
SBCs I am still very impressed. The Acme Packets may lack some of the
"fluffier" features that I have seen in some of the other SBCs but
they are such a solid solution and they are adding many of these
features now that they have built an incredibly solid foundation.
We have a couple thousand-ish subscribers loaded and continue to load
more as fast as we can, our SBCs have not even started to breathe yet.
My experience with Acme packet has spanned a year now with about half
of that being high-level design and 6 months implement, operate,
support, manage, configure, etc...
To summarize:
Very high quality, useful and necessary product/solution.
Impressive support and customer service.
Training was excellent.
As the Telcos grow so does the revenue for Acme, reoccurring revenue
from licensing and maintenance.
Eventually SBCs will either replace or be paired with traditional
firewalls to manage signaling and media in corporate, public and Telco
networks.
Lets not forget Cisco ISRs (routers) have built-in firewalls yet most
corporations prefer to use a dedicated device(s) such as the Cisco ASA/
PIX or Juniper SSG, etc.
There is room for more than one player but they will likely each find
their own niche, Acme will be the Checkpoint of SIP security IMHO (not
that I am a Checkpoint fan, but regardless of price it was the de
facto enterprise firewall for years)...
Acme also seems to be taking a stronger focus on features now that
they have a SOLID solution.
I am not an active investor, I have some mutual funds, I have bought
stocks once before and did ok. I was hoping to find a decent
technology related mutual fund but there weren't any attractive ones
available (IMO). Having worked in technology on both the business/
sales side and the technical solution design and implement side I am
very leery of technology investments. I didn't want to invest in
something that looked good or sounded good, I wanted to invest in
something that I could quantify to anyone as to why I believed it was
a good investment. Acme Packet is a solution I use, love and believe
in so I have taken l the money set aside for investment in technology
and bought Acme Packet with huge confidence.
I can't see how they won't do well unless they fumble the finances,
SEC, etc, but it seems to me that this is always a risk anyways...
If you have any question please ask, I can offer a real hands-on
perspective on Acme Packet SBCs (NET-NET SDs), I am still getting the
hang of investing, economics, finance, etc so I really appreciate your
postings related to those aspects...
Cheers,
J
***( This is all opinion, do your own research, and if you can, build
your own highly available, scalable, secure, redundant, feature-rich,
hosted IP Telephony solution with Acme Packets before you make your
decision ;) ***