First Look: Flash Media Server 4

"Reliable data transmission in TCP is achieved by re-transmission of lost data, which introduces latency," Adobe states in an FAQ on RTMFP. "Because minimizing end-to-end delay is one of the most important goals in real-time communications (a few hundred milliseconds delay may render a conversation unusable), TCP is not well suited for this purpose."

One way to handle error correction, or what Adobe calls "transmission error resilience and recovery," is to integrate a level of error correction into the codecs themselves. Both Adobe's Speex audio and H.264 video codec implementations offer error recovery, according to the company, rendering the need for TCP in real-time communications mostly irrelevant.

"Reliable delivery provided by TCP is therefore not needed," the FAQ states. "As a result, UDP, which provides an efficient and rapid data delivery, is popularly used in real-time collaboration applications where minimizing end-to-end delay is of paramount importance."

Interactivity
In other words, the interactivity in Flash Media Server 4 moves beyond just the concept of basic gaming interaction with low bandwidth requirements-think playing online games between seatmates on an airline flight-and into full-blown interactivity found in most massive multiplayer online role-playing games (MMORPG).

Until now, most MMORPGs have required a platform-specific application to handle the majority of content delivery, and they have used game-specific servers to allow players to chat back and forth with one another from their individual locations.
Adobe hopes to change that, noting that UDP provides a way to handle end-to-end peering, or "direct data transmission between two clients located behind network address translators (NATs)," which is useful for those who want to do everything from video chat all the way up to full-blown videoconferencing.

"Media is sent directly between two Flash Player instances without routing through a central relay server," according to Adobe. "When compared to RTMP, where all data is sent through Flash Media Server, RTMFP not only further reduces end-to-end delay, but also eliminates costs associated with a central data relay, thus lending itself to extremely scalable deployments."

Server or Service?
When it comes to multiple Flash Players, though, there is a need for a service or a server to act as a rendezvous point for peers to find one another.

On the services front, the Stratus beta is provided on a noncommercial test basis, while Adobe's LiveCycle Collaboration Services has offered a paid service for several months.

"Stratus on Adobe Labs is an Adobe-hosted service that previews upcoming technology for Peer Assisted Networking," an Adobe Labs FAQ states. "The technology will appear in the next version of Adobe Flash Media Server, but it is already used today within Adobe LiveCycle Collaboration Services."

In an interesting ROI-model twist, for those who don't want to buy up to a Flash Media Enterprise Server, LiveCycle provides an option to use the peer-to-peer networking capabilities of Stratus inherent to Flash Player 10.1 at a nominal pricing level. (A pricing and service level chart can be found at http://forums.adobe .com/message/2292267#2292267.)

Voice or Video?
Another key element of application-level multicast is the use of data prioritization. While this is not exactly the quality of service (QoS) that many videoconferencing and voice over IP (VoIP) solutions use, the choices that Adobe has made on prioritizing particular types of packets reveals the company's anticipated usage of the solution.

"Audio is transmitted with higher priority than video and non-time critical data (such as instant message, etc.)," Adobe states. "This can significantly enhance user experience over a bandwidth constrained communications channel."

Yet the company is not placing all its UDP eggs in one basket: Besides providing what it calls both "reliable and unreliable service" delivery options, the company also addresses the issue of UDP blockage at some corporate routers.

"It is important to note that RTMFP provides both reliable and unreliable service," an Adobe FAQ states. "When sending data between two Flash Player instances (for example, using the NetStream.send() method), reliable data transmission is used. When sending Speex audio between two Flash Player instances, unreliable delivery is used, providing the smallest possible latency."

Implementation
The choice of audio data prioritization over a "bandwidth constrained communications channel" is in keeping with VoIP. But what about those who want to focus on video chat?

It appears to be Adobe's thinking that uninterrupted audio is better than uninterrupted video. There is some historic basis for this: A survey that Andrew Davis, Christine Perey, and I did of videoconferencing users a decade ago showed that, given bandwidth constraints, users would rank online screen sharing or collaboration first, audio second, and video a distant third, on the assumption that they could use a phone bridge to do an audio call and that video chat was less important than the other two.

Yet times have changed enough that users expect to be able to both see and hear with equal quality, as well as enjoy simultaneous collaboration or screen sharing. So it will be interesting to see if Adobe's choice of audio-centric delivery sits well with those who invest time and effort into live adaptive bitrate video encoding solutions.

Viewers on a "bandwidth constrained communications channel" that is part of the application-level multicast also receive another benefit, according to Greg Pulier, CTO of MediaPlatform, who has been working with FMS 4 for several months.
I asked Pulier if Fusion and application-level multicasting might replace a videoconferencing multipoint control unit, which serves as the connection point for a number of videoconferencing end points and which can service end points on various bandwidths, without resorting to every videoconferencing end point having to use the video signal quality of the weakest bandwidth link endpoint.

"There's a very unique idea in Adobe's approach to multicasting," said Pulier, "in which native multicast works together with application-level multicasting. If a certain corporate office needs a low bandwidth (e.g., 400Kbps) due to its current bandwidth constraints, there's no reason to penalize the rest of the viewers who are on a multicast-enabled portion of the network. The ability to send both high-bandwidth IP multicast and varying bandwidth peer-assisted multicast is one of FMS 4's strong points."

UDP Blocking
For all the benefits of UDP for low-latency delivery, the fact that UDP takes the "bad cop" stance when it comes to data delivery means that some corporations have chosen to block all UDP traffic.

"In order for RTMFP to work, your firewall must be configured to allow outgoing UDP traffic," Adobe states. "While this is the case with most consumer or small office/home office firewalls, many corporate firewalls block UDP traffic altogether. One solution is to configure Flash Player to use a TURN proxy (Traversal Using Relays around NAT)."

TURN is a proxy that allows particular UDP content to flow through the corporate firewall. Unfortunately, the use of TURN requires a bit of configuration work.