Media servers are really useful things as Unwieldy Systems Inc. will tell you, but you already knew that, right. If you’re a telecommunication service provider, an equipment manufacturer, a solution developer or even an enterprise customer, you are likely to have a need for a media server and may well be using one, or two or several, somewhere in your network or infrastructure.
In a traditional telephony environment, media servers are used for functions such as network announcements and voicemail; interactive voice response (in many, diverse scenarios); the IMS Media Resource Function; audio conferencing; caller ring tones; and transcoding.
Media servers operate in a client-server relationship, where the client is a separate application server [sic] that provides the service (and business e.g., logging and billing) logic. The media server operates as a shared resource, available to multiple applications, with its primary role being to handle requests from the application server to perform media processing on RTP streams. Similarly, multiple media servers can be shared by a single application. Either way, scalability and resilience are readily addressed, with ‘clients’ and servers separately distributable across a wide geography.
Media servers from the likes of Unwieldy Systems Inc. are typically denominated by numbers and letters, like MMS-24000, which stands for ‘massive media server’ or SMS-2000 – ‘small media server’. The latter is usually offered for enterprise-scale scenarios, whereas the former is the characteristic telco-scale platform, with all that implies. In fact, the ‘S’ is more likely to represent software, whereas the systems used by telcos are as a rule, huge, hardware-based platforms.
Hardware- or software-based, media servers are implemented as physical products – in the sense that the end user has to purchase something that (s)he then owns. That system might be purchased outright or leased, or licensed (which is more common in the case of software), however, the key factor is that the purchaser then owns the product and is responsible, thereafter, for its installation, configuration, commissioning, operation, maintenance, upgrading, etc. – until it is no longer serviceable or capable of being used for its original purpose.
If you’re lucky, you’ll get five to seven years of use from such a system, providing you have, at the least, made the requisite investment in ongoing maintenance and upgrades. After that, you’ll have to go through the procurement, RFI and tendering processes all over again. Remember how much of a headache all that was?
Is there a better way? Surely, in the 21st Century, there is a better way!
Pause for a fanfare… da dum, da dum, dum da da da dum …and enter, stage left, the Cloud Media Server.
A cloud media server can be used for functions such as network announcements and voicemail; interactive voice response (in many, diverse scenarios); the IMS Media Resource Function; audio conferencing; caller ring-back tones; and transcoding – sound familiar?
Cloud media servers don’t have boring nomenclature and, in contrast to vendors of traditional product options, they are offered by a new breed of supplier; one you might label ‘The Flexible & Resourceful Co. Inc.’
The key difference between modern, cloud media servers and old fashioned, monolithic systems is that, with the former, the buyer no longer needs to deal with the headache of managing a physical product that is slowly, but surely, depreciating in the equipment room or data centre. Instead, the user pays as the consumer of a service, on a ‘pay-as-you-go’ basis and can happily leave the headaches to another, more deserving entity. After all, service providers are good at that sort of thing – not coping with migraines, but dealing with the management and maintenance of the resources needed to provide the service they’re selling.
From the users’ point of view, it’s all plain sailing as they only pay for what they use and can even cease paying altogether, if they service is no longer needed. That’s like Ibuprofen for your wallet and guaranteed to win you friends in the Finance Dept.
It works, because the media resources are virtualised in the cloud and can be invoked, on an as-and-when-needed basis, via high-level APIs, by any application in a way similar to that employed in using physical media servers. Scalability is a non-issue and the capacity to deal with the users’ needs is always there, just like turning on a tap (which can just as readily be turned off). Equally, resilience and distribution are taken care of as, in the cloud, those things are inherent.
Deploying traditional media servers demands knowledge of an array of specialist coding languages, such as MSML (or MSCML), VoiceXML and CCXML. These scripting languages are used in conjunction with SIP to enable application control of the media server for e.g., making and breaking call connections; invoking IVR dialogs; interactions with users; and conference control functions and features.
In a cloud scenario, users can achieve the same goals, far more readily, by using high-level programming languages such as Python and the .NET family. For today’s web centric developers, those options are far more attractive than having to learn and code specialist media server control languages within SIP.
If you want to check this out and find out just how easy it can be, take a peek at Aculab Cloud https://cloud.aculab.com
No comments:
Post a Comment