[VoiceOps] Recommendations for high-cps SS7 OC-X gear?

[Kidd Filby]

I agree.  A distributed Architecture, geographically dispersed, is the best
design for what is being asked of.  The only issue I would see with the
Sonus deployment is they are very expensive.  MetaSwitch would be able to
handle this load, as far as I know.  Probably not as expensive as Sonus
but... not free either.

There are other options as well.  Some would be checking out Squire,
GenBand and AudioCodes.  Each of these vendors brings good things to the
table and I believe they could all handle the BH traffic you are looking at.

Kidd

On Fri, Apr 22, 2016 at 11:47 AM, Brandon Buckner <brandon at kamikos.com>
wrote:

> Just curious: Is there a reason to avoid Metaswitch?
>
> My main experience is in Metaswitch and Sonus, but in Metaswitch it was
> limited to the 2510 and 3510 gateways and the accompanying servers up to
> 7.4 software and none of the newer blade platforms. At the time I would
> have said that Metaswitch would have worked quite well for what is being
> asked, especially if wanting to split across many smaller gateways and
> geographically distributed. Is there something with the new hardware and/or
> software I don't know about quality-wise?
>
> Sonus killed off the GSX4000 which would have lent better to spreading
> around a bunch of smaller boxes. They still have the GSX9000 which goes up
> to single OC-3 cards (so you'd have to have a couple to split an OC-48
> still), but their main push seems to be the SBC5210 and SBC7000 which are
> IP only, no TDM. But spread across gateways the call processing can easily
> do the 500 CPS.
>
> On 4/21/2016 5:00 AM, Anthony Orlando via VoiceOps wrote:
>
> Avoid Meta at all cost.
>
> Sent from my iPhone
>
> On Apr 20, 2016, at 10:35 PM, Paul Timmins < <paul at timmins.net>
> paul at timmins.net> wrote:
>
> You're going to handle 500CPS of legacy sonet based TDM and question
> dropping 7 figures on the solution? *cringes*
>
> This is literally what platforms like metaswitch, sonus and many others
> are made for. If you're looking for low cost, Taqua's solution is decent,
> and if you need to take that entire OC-48, you're all but eyeballs deep in
> Sonus or Metaswitch land.
>
> -Paul
>
> On Apr 20, 2016, at 17:54, Brooks Bridges <bbridges at o1.com> wrote:
>
> Looking for suggestions for NEBS compliant gear that can support SS7,
> handle OC-3 or higher levels of channels, and can support (in aggregate) up
> to around 500 cps through a **good** (key word) SIP interface.  I’m
> willing to entertain the idea of a single larger device that can take a
> full OC-48 and support the full 500 cps, but I’d prefer spread the load
> across multiple devices and smaller interfaces for load balancing and
> redundancy.
>
> Any pointers?  Obviously there are products out there by the really big
> players, but I’d really rather not have to drop 7 figures on this project
> unless I have to.
>
> Thanks!
>
> *Brooks Bridges | *Sr. Voice Services Engineer
> *O1 Communications*
> 5190 Golden Foothill Pkwy
> El Dorado Hills, CA 95762
> *office:* 916.235.2097 | *main:* 888.444.1111, Option 2
> *email:*  <bbridges at o1.com>bbridges at o1.com | *web:*  <http://www.o1.com/>
> www.o1.com
>
> _______________________________________________
> 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 listVoiceOps at voiceops.orghttps://puck.nether.net/mailman/listinfo/voiceops
>
>
>
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
>


-- 
Kidd Filby
661.557.5640 (C)
http://www.linkedin.com/in/kiddfilby
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20160422/b6074343/attachment-0001.html>