Compiled Protocols vs. Script Protocols

There is a huge difference between compiled languages and scripting languages: the former are first entirely compiled and then executed, the latter are interpreted as they progress. I will use this terminology to discuss two types of protocols: the more common is made up of readymade messages or methods; each message type indicates a predetermined course of action. The less common type, and one I think deserves more attention, sends messages made up of many simple commands that do very simple things.

I will illustrate the script protocols using MEGACO (recently revived as it was added to IMS). MEGACO is a protocol between a Media Gateway (MG) to a Media Gateway Controller (MGC). The MGC handles call establishment and routing, the MG handles media exchange, something like a central switchboard and a residential gateway. The MG is a “dumb” entity, which receives basic instructions from its MGC, and acts on them to the best of its ability. The instructions come as nested instructions: for these contexts, for these terminations (or for terminations with these properties), perform these actions. The actions may be “Add to context”, “Remove from context”, “Move between contexts”, “Service change”, “Modify attribute”, “Query attribute”. What we have is a set of commands with their syntax, the ability to create for-loops, conditional expressions, in short, everything you need for a programming language. The MGC programs the MG in real-time to enable calls, conferences, special services and reports generation. Through “packages”, the MEGACO scripts have expanded to include timed actions, interactive menus and even pre-programmed responses to simple events.

In the MEGACO world, the MGC is a bilingual entity; it speaks some other VoIP protocol, H.323 or SIP, for instance, but does not process the protocol’s media streams. Instead, it programs the MG with the media information and leaves any needed transcoding and mixing to the MG. The MG is dedicated to media streaming and processing, and so, it is designed to have simple state machines and no logic - it just does what it’s told. This architecture achieves three goals:

1. Compatibility
2. Flexibility
3. Power

Compatibility

Since the implementation relies on execution of simple commands, there is not a lot of room for interpretation. How can one implementation of “Add fax to context 1″ be much different from another? One MG will respond much like another MG, with only little variations, making the protocol reliable. The protocol allows the MGC to get the list of supported packages form the MG, and the MG does nothing without being instructed to by the MGC, so the two will only use the extensions common to both implementations.

Flexibility

Adding a package is relatively simple, allowing the protocol to become very versatile, adapting to handle any device type (e.g. fax, ip-phone, set-top box, etc.). The use of very basic commands allows very fine-tune control of the way a message is executed. Subtle, incremental changes creates new approaches, all without changes in the protocol. This protocol, in fact, evolves and grows through usage.

Power

Combining the simple commands creates powerful scripts, is made more powerful by the versatility and abundance of packages. The MG needs only to do media - it is built and optimized to the extreme point of specialization in media, and provides whatever kind of a service in the MGC through the protocol which is in fact an “API” in front of the MG which is simple on one hand and powerful on the other. It’s similar to providing a platform on the web and letting people develop their applications (MGCs) on top of it.

However, MEGACO is not without its flaws. Some packages require changes in the interpreter. Some powerful features were only added in version 3 for the standard, meaning that you can’t rely on MGs to support them, and some are still missing. Sometimes packages are added to compensate for missing basic commands (like a nested set of commands to execute on an event), making the implementation awkward. The basic set of commands could have been reworked, why have “add” and “delete” where “move” could substitute both?

The real question is, can script protocols be used in different scenarios? MEGACO is used between a defined “master” and a “slave”, could a script protocol be used between peers? Would such an implementation be powerful or just complicated? I believe it can be done, but it would require a very carefully designed set of commands.