Benefits of RTMFP

Real-Time Media Flow Protocol (RTMFP) is a new communications protocol introduced in Flash Player 10 and also available in AIR 1.5. One of its major differentiators from Real-Time Messaging Protocol (RTMP), which is based on the Transmission Control Protocol (TCP) and exclusively used in previous versions of Flash Player, is that RTMFP is built on User Datagram Protocol (UDP).

While TCP provides reliable data delivery (well applicable for file transfer, e-mail, etc.), it does not provide any end-to-end delay guarantees. Reliable data transmission in TCP is achieved by re-transmission of lost data, which introduces latency. 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. Transmission error resilience and recovery form an integral part of most advanced audio and video compression techniques—such as Speex audio and H.264 video codec, both available in Flash Player 10. Reliable delivery provided by TCP is therefore not needed. 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. Another advantage of UDP over TCP that it enables end-to-end peering—that is, direct data transmission between two clients located behind network address translators (NATs).

When compared to RTMP, RTMFP provides the following advantages for real-time communications:

• Low latency: Since RTMFP is built on top of UDP, it provides minimal latency for real-time communications. It is important to note that RTMFP provides both reliable and unreliable service. 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.
• End-to-end media delivery: Media is sent directly between two Flash Player instances without routing through a central relay server. 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.
• Data prioritization: Audio is transmitted with higher priority than video and non-time critical data (such as instant message, etc.). This can significantly enhance user experience over a bandwidth constrained communications channel.

All of these features represent tremendous benefits for real-time communications, providing a significantly greater user experience than is achievable with earlier versions of Flash Player.

Firewall traversal

RTMFP is built on top of UDP, which enables direct connection between clients even if they are located behind NATs or firewalls. In order for RTMFP to work, your firewall must be configured to allow outgoing UDP traffic. While this is the case with most consumer or small office/home office (SOHO) 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). Flash Player supports IETF Internet Draft draft-ietf-behave-turn-08 without authentication. If the network administrator configures a TURN proxy that allows outgoing UDP, Flash Player can be configured by adding the following line in mms.cfg (for more information on Flash Player configuration and the location of mms.cfg, please read the Adobe Flash Player Administration Guide for Flash Player 10):

RTMFPTURNProxy=ip_address_or_hostname_of_TURN_proxy

Direct UDP traffic is always attempted and the TURN proxy is only used as a backup: it is used for UDP traffic that cannot flow between Flash Player and Stratus (in case of UDP blocking firewall) or between Flash Player endpoints.

Even if your firewall enables outgoing UDP traffic, it is possible that end-to-end peering cannot be established due to a combination of firewalls. When one endpoint is located behind a so-called "symmetric firewall," end-to-end communications may not be possible. (For a classification of firewalls, please see the Network address translation entry on Wikipedia.) In this situation, you may use a TURN proxy to aid firewall traversal.

Stratus service

Flash Player instances must connect to the Adobe Stratus service (using rtmfp://stratus.adobe.com) in order to communicate with one another. Stratus is a hosted rendezvous service that helps Flash Player instances contact one another even if they are located behind NATs. Although connecting to Stratus service is very similar to connecting to Flash Media Server, Stratus does not provide any of the typical Flash Media Server features (media relay, shared objects, remoting, etc.). Flash Player endpoints must stay connected to Adobe Stratus during the entire time of communication. In order to access Stratus, you will need a developer key that is generated when you create your Adobe Developer ID.

RTMFP support is being planned for future version of Flash Media Server (no release date). With Flash Media Server, it will be possible to enable communications between Flash Player 9 or earlier clients (using RTMP) and Flash Player 10 clients (using RTMFP).

Security

RTMFP provides secure communications between endpoints. It uses a 128-bit AES with the key negotiated using the Diffie-Hellmann key exchange method. However, it does not provide strong endpoint authentication such as SSL or RTMPS. To aid endpoint authentication, RTMFP and ActionScript expose secure nonces to application developers. These nonces are available at both communicating Flash Player endpoints and are guaranteed to match. By verifying these nonces, end users can ensure that there is no man-in-the-middle attack. These nonces can also be used to develop key continuity mechanism.

It is important to note that Flash Player only enables sending media from your microphone and webcam devices to other Flash Player endpoints that subscribe to your media streams. Flash Player does not relay data on behalf of any other Flash Player endpoints (such as in a multicast scenario).

For more information on RTMFP, please read the FAQ on Adobe Labs:

• Real‐Time Media Flow Protocol FAQ (PDF, 166K)

Page 2 of 4

Previous Page

Next Page