Avaya Aura 7.0 is the latest platform to become an “adopter” of the Avaya Aura Media Server. This Avaya Aura Media Server is used, not coincidently, for media resources and services. This has been a very hot topic for almost every customer I talk to lately. I thought it might be a good time to do a deeper dive into this server to better understand why it is so cool, but also why it doesn’t always let you replace all of your existing media resources.
One of the major uses of media resources is as a DSP (Digital Signal Processor). DSP’s in your Avaya Communication Manager were used for two things and two things only. First, was to convert VoIP things to TDM things. Meaning something like a Medpro card attached to the TDM bus in a gateway, could allow you to convert VoIP packets such as G.711 or G.729 to something that can talk TDM. Once on the TDM bus, you can talk to anything else that live on the TDM bus (think Analog ports, T1’s, DCP phones, even the dial tone you hear on an H.323 phone, etc). The second thing a DSP can do, is to perform codec transcoding, converting one flavor of VoIP to another (like from G.711 to G.726). Prior to R7, these kinds of media resources were only available as circuit cards added to a gateway. Maybe it was a TN2302 or a TN2602 added to a G650 gateway, or maybe it was an MP80 module that was socketed into a G450/G430 gateway. This made total sense, when there was a significant mix of both IP and TDM. Being directly tied to a gateway allowed you to talk to the rest of the TDM stuff in that gateway.
But what has become increasingly common, is that people are using significantly less TDM stuff. DCP phones are getting replaced by H.323 or SIP phones. T1’s are getting replaced with SIP trunks. And while we’re needing less and less DSP’s that can talk to a TDM bus in a gateway (because we have less and less TDM stuff), we’re needing more and more DSP’s for Codec Transcoding and “Media Anchoring” that is used for things like Call Recording, ad-hoc and Meetme Conferencing, Group Paging, Service Observing, and IVR’s. Customers are finding themselves having to buy empty G450’s, just so they have a place to put their DSP’s. Earlier this week, I had a customer tell me they were planning to order 4 new, completely empty, G450’s simply because they needed 1000 more DSP’s for their expanded rollout of call recording (each G450 maxes out at 320 DSP)’s. We’re also seeing more “pure” SIP deployments for net-new customers who have no existing investment to protect. And while they can be 100% “software” for everything else, we’d still have to awkwardly sell them the needed G450’s to give them the media resources they need.
Now, as of Aura 7.0, we can use the Avaya Aura Media Server that has actually been around a very long time in the legacy Nortel world. It is used for all kinds of things such as the AACC, the AS5300, etc. So, this is not a new platform. It’s just that Communication Manager is a new “adopter” of the current version of the Avaya Aura Media Server (version 7.7). This version is sold as software that can be put on Avaya hardware, customer provided hardware, or even virtualized in vmWare. In a dedicated server “appliance” it can support up to 4000 channels (capacity could be less, depending on computing resources). And it can do the things you need it to do like codec transcoding, media anchoring, and even announcements. Need more than 4000 channels? Just add more AAMS’s. Communication Manager can support up to 250 Media Servers.
What can it do that our traditional media resource (TN2302, TN2602, MP80’s) can’t (besides being software based, and not needing to be in a gateway)? For one, it can do media anchoring with codecs other than G.711. Today’s CM-based adhoc and Meetme conferencing is limited to crappy “toll quality” voice. Once thought the gold standard, is quickly being viewed as old school. G.722, known as a wideband audio codec, or even newer codecs popular with high quality Internet media streaming, like Opus, can be using for conferencing and call recording (as long as those platforms support it). You can also have a single Avaya Aura Media Server serve multiple Communication Managers.
But what CAN’T you do with the new Avaya Aura Media Server that you can do with our traditional media resources? The biggest is that you can’t talk to a TDM bus. So, if you still have 4 T1’s in a gateway, you will still need 96 gateway-based DSP channels to let VoIP-based phones talk to those T1’s. Avaya Aura Media Server doesn’t replace the IP to TDM converter functionality needed in a gateway. Avaya Aura Media Server channels also aren’t applicable to things like VoIP based Fax (T.38) or Modems (V.150.1).
Even though the Avaya Aura Media Server is SIP based, it connects directly to a Communication Manager (ie via a network), not using a Session Manager in the middle. It’s not administered as a SIP trunked adjunct. For that reason it is really easy to implement, since there’s no funky routing to have to worry about. While administration is not exactly the same as a MedPro, it’s very consistent to how you’d configure traditional DSP resources, making it a very familiar experience. And you can absolutely mix and match between Avaya Aura Media Server and gateway DSP resources. This definitely isn’t an all or nothing thing. So, if you can benefit from Avaya Aura Media Server in R7, adding it is relatively easy. If there isn’t a benefit to your deployment, then there’s no requirement to add it. But if you're like most people I talk to, you’ll find good reasons to deploy some.