Real Time Messaging Protocol

From Wikipedia, the free encyclopedia

Real Time Messaging Protocol (RTMP) is a proprietary protocol developed by Adobe Systems for streaming audio, video and data over the Internet, between a Flash player and a server.

The RTMP protocol has three variations:

The "plain" protocol which works on top of TCP and uses port number 1935
RTMPT which is encapsulated within HTTP requests to traverse firewalls
RTMPS which works just like RTMPT, but over a secure HTTPS connection.

While the primary motivation for RTMP was a persistent protocol for Flash, it is also used in some other applications, such as the Adobe LiveCycle Data Services ES.

On 20 January 2009 Adobe announced it will publish the RTMP specification.^[1]

[edit] Operation

The raw TCP-based RTMP maintains a single persistent connection and allows real-time communication. To guarantee smooth delivery of video and audio streams, while still maintaining the ability to transmit bigger chunks of information, the protocol may split video and data into fragments. The size of the fragments used can be negotiated dynamically between the client and server, and even disabled completely if desired, although the default fragment sizes are 128 bytes for video and most other data types, and 64-bytes for audio data. Fragments from different streams may then be interleaved and multiplexed over a single connection. With longer data chunks, the protocol would then only carry a one-byte header per fragment, thus incurring very little overhead. In practice however, individual fragments are not typically interleaved. Instead, the interleaving and multiplexing is done at the packet level, with RTMP packets across several different active channels being interleaved in such a way to ensure that each channel meets its bandwidth, latency, and other quality of service requirements. Packets interleaved in this fashion are treated as indivisible, and are not interleaved on the fragment level.

The RTMP defines several channels on which packets may be sent/received, and which operate independently of each other. For example, there is a channel dedicated for handling RPC requests and responses, a channel for video stream data, a channel for audio stream data, a channel for out-of-band control messages (fragment size negotiation, etc.), and so on. During a typical RTMP session, several channels may be active simultaneously at any given time. When RTMP data is packetized, a packet header is generated. The packet header specifies, among other things, the id of the channel that it is to be sent on, the timestamp at which it was generated (if necessary), and the size of the packet payload. This is then followed by the packet payload, which is fragmented according to the currently agreed-upon fragment size before it is serialized over the connection. The packet header itself is never fragmented, and its size does not count towards the data in the packet's first fragment. In other words, only the actual packet payload data is subject to fragmentation.

At a higher level, the RTMP encapsulates MP3 and Flash Video multimedia streams, and can make remote procedure calls (RPCs) using the Action Message Format.

Other RPC services are made asynchronously with a single client/server request/response model, so real-time communication is not necessary.^{[clarification needed]}^[2]

[edit] HTTP tunneling

RTMP packets can be exchanged via two HTTP tunneling protocols:

In RTMP Tunneled (RTMPT), RTMP data is encapsulated and exchanged via HTTP, and messages from the client (the media player, in this case) are addressed to port 80 (the default for HTTP) on the server.

In RTMP Secure (RTMPS), RTMP data is encapsulated and exchanged via HTTPS, and messages from the client are addressed to port 443 (the default for HTTPS) on the server.

While the messages in RTMPT and RTMPS are larger than the equivalent non-tunneled RTMP messages due to HTTP and HTTPS headers, RTMPT and RTMPS may facilitate the use of RTMP in scenarios where the use of non-tunneled RTMP would otherwise not be possible, such as when the client is behind a firewall that blocks non-HTTP and non-HTTPS outbound traffic.

[edit] RTMP client software

The most well-known RTMP client is Adobe's Flash player which can stream video and audio from RTMP servers. Recently, the open source media player XBMC has acquired preliminary support for playing RTMP streams in its SVN version (see the patch).

[edit] RTMP server software

Currently, the only full implementation RTMP servers are the Adobe Flash Media Server, Wowza Media Server and WebORB Integration Server (free and available for .NET, Java and ColdFusion) both commercial and closed source implementations.

There is a reverse engineered open source project called Red5 which aims to produce a feature-complete implementation written in Java. As of October 2007, the majority of the functionality is implemented, although the project is still in the beta stage. There are some other RTMP-servers with basic functionality available at Google Code