Media Sessions Markup Language is a protocol that allows an application server to control a media server; in other words a media server (in the network core) can offer services like conferencing; announcements; IVR and call recording, and the application that controls this functionality can exist in another box, perhaps even outside the network core. In the IMS world, this is going to be a great way for telcos to allow their service partners to offer value-added services outside the walls of the traditional telco.

On the wire, MSML is a text-based language, structured with XML and travelling inside SIP messages. Piggybacking protocols inside SIP is becoming a frequent thing these days (for example CSTA does the same), and similarly having XML based APIs and protocols is also a common thing.

But is MSML an API? I’ve heard people talk about it as an API recently, but what is an API today? When I started work out of university, APIs usually consisted of putting values into Intel registers (we’re talking Intel 8086 now) and calling a software interrupt. If you were lucky, someone had already written the ‘glue’ code so that could directly call a function in “C” or Turbo Pascal. When Windows came along, working with DLLs meant that the “C” function approach grew in popularity, and this is the way APIs worked, notably of course the Windows API itself.

In recent years, the web has caused further abstraction of APIs, and with web services an API can be described by a WSDL script (another XML spin-off), with protocol messages being in XML and transmitted via TCP/IP. This was one of the agonising aspects of traditional APIs, that once you had written the app, for sure someone would ask if you could use it remotely to another machine. Often the answer was “no”, and applications had to be rewritten for the distributed environment. With web services, the location of the server relative to the app is no longer important, as the network transport system is “built-in”.

So MSML is working very much along the same lines, with potted functionality (in this case media services) being available at a distance via TCP/IP. So there is an argument to call it an API as well as a protocol.