Flash fat belly

One of the interesting enhancements to the XMPP toolkits portfolio is the porting of the XIFF Flash library to ActionScript3. There is say in the software industry that a product only reaches full readiness at its third release. ActionScript seems to fit perfectly into that category. Its latest version has enabled Nick Velloff and Derrick Grigg to take advantage of the language better structure and network support to build a very promising XMPP library. As a bonus, with the native socket support now part of ActionScript, the null terminating character so specific of the previous Flash clients is now gone.
XIFF and Flash together make a very strong contender for building rich client XMPP enabled application without suffering this dreaded message one see on so many web 2.0 mashups "your browser is not supported, you must use [insert browser name here] instead" when trying to bring up the chat window.

And then there are the recent speculations about the forthcoming enhanced VoIP support in the Flash player. On paper it looks a promising move, as the number of possible applications build on the combination of Rich Interface/Multimedia/Presence backed by a powerful interface library seems endless.
As the player already supports voice and video, tying into the emerging VoIP ecosystem is a natural extension. Obviously, the announcement has spurred several comments amongst the regular VoIP aficionados. Many, such as this one for example, mentioned the challenges related to this entreprise.

The Adobe start-up team faces quite a few challenges. For instance, it would have to support multiple VoIP protocols, and it will also have to figure out how to keep the overall size of the Flash client size small. Sources say that touching Flash Player is like messing with God inside Adobe, and the start-up team needs to figure out how to embed a SIP stack inside the player without making it bloated.

Effectively, the team working at bringing better VoIP support to the Flash player faces several challenges. But not necessarily those mentioned in this typical excerpt of the dominant VoIP meme. This is my first worry, as it sounds like a reductive fallacy to me.

The team first challenge would be to get away form the hype, and focus on building a usable, simple and standard compliant product. For sure, to be effective the resulting product will have to support multiple VoIP protocols. That said, one should remember that a VoIP communication is always the result of combining a session negotiation between parties and the transport of the voice media. If we exclude proprietary closed protocols such as Skype, which will inevitably die out, the only viable remaining standard VoIP contenders left are:

• SIP and Jingle associated with SDP/ICE on the signaling side
• RTP on the media transport side.

It just happens that these two signaling protocols support the same voice media transport, and the same way to negotiate it. As a consequence, only the media transport has to be integrated into the Flash player, with the signaling being provided as plugins. Using this kind of design brings multiple advantages from the standpoint of extensibility and evolution. An immediate benefit would be to allow any application to choose its own signaling and implemented media transport combination. Doing so will defuse many subjective "I don't like [insert you favorite hated VoIP protocol here]" reaction and offer the proper flexibility to help building solutions to real users issues.
Furthermore, if the transports are built into the player and the signaling available as plugins, they will be part of the player installation and not of the resulting client. As such they will not "bloat" the resulting client side application.

The team second challenge would be handling the media transport negotiation. It happens that RTP uses UDP at the network level, and is therefore handicapped when crossing firewalls and other NAT devices. To be effective, the resulting product would have to exchange voice media streams with existing and near future VoIP softphones, hardphones and IPBX. This implies that the player will have to incorporate a raw SDP transport to cater for legacy installations, as well as ICE for the upcoming generations of VoIP devices.
Several solutions have been proposed to allow VoIP calls to cross firewalls, but each class of NAT firewall requires a different technique. To complicate matters further, the different NAT traversal techniques address only one class of NAT device. For example, Simple Traversal of UDP through NAT (STUN) will not work with symmetric NATs, which you find most often in enterprise. The Interactive Connectivity Establishment (ICE) is designed to provide a framework unifying the various NAT traversal techniques. This in turn allows VoIP clients' media streams to traverse the variety of firewalls between a remote user and a network. ICE defines a standardized method for both SIP and Jingle clients to determine the type of NAT firewalls on the path between clients and propose a set of IP addresses by which clients can establish contact. ICE learns about the network topology using a number of protocols and network connectivity mechanisms, such as STUN, Traversal Using Relay NAT (TURN) and Realm Specific IP (RSIP) and deduces the various sets of IP addresses by which the devices can communicate.

The team last challenge would be to stay open minded. This is probably the toughest one. This kind of project usually involves mixing together strong business interests with strong egos. For example, maintaining and increasing the business value of existing agreements with powerful players in the telecommunication industry will no doubt have the balance lean toward SIP. Similarly, I would be cautious relying on the "teaching" provided by VoIP gurus that were brought up at baby bells, as these carriers are not known to favor the Internet. I believe only considering SIP for VoIP would be a mistake. But most importantly, the ultimate value will be driven by the way presence will fit into the resulting product. And today, nothing on the SIP side is up to the simplicity and ease of use provided by XMPP. The way they will arbitrate between the subjective interests at play will condition the success of the product. As usual the only winning combination will be the one providing a solution to the end user, without locking it into a particular way of thinking. Wisdom of the end user is certainly more real than wisdom of the crowd…

In the end, these are huge challenges, requiring wise and savvy leadership. But if they can overcome them, they could be onto something valuable. In an open standard platform strategy play, by preventing the technical hell that comes with today's VoIP clients, and offering choices to application developers, they could become the next VoIP media layer, accessible to any desktop.

When combining a standard based VoIP Flash player with libraries such as XIFF, you can just imagine the host of wide ranging and superb looking social applications it opens up. But so far we just have the XIFF library. And that alone makes it worth trying Flash based XMPP applications.

Technorati Tags: XMPP, Jabber, SIP, Jingle , Presence, VoIP, Flash, Antecipate