RTMP Documentation

1. Introduction

Real Time Messaging Protocol (RTMP) is a proprietary protocol developed by  Adobe Systems (formerly developed by  Macromedia) that is primarily used with Adobe  Flash Media Server to stream audio and video over the internet to the Adobe  Flash Player client. Adobe is expected to post the RTMP specification on the  Adobe Developer Connection in the first half of 2009.

RTMP is not used for  Remote Procedure Calls. RTMP maintains a persistent connection with an endpoint and allows real-time communication. RPC services are made asynchronously with a single client/server request/response model, so real-time communication is not necessary.

The protocol is a container for data packets which may be AMF or raw audio / video data like found in FLV?. A single connection is capable of multiplexing many net streams using different channels. Within these channels packets are split up into fixed size body chunks.

2. Flavours

As many corporate networks and home firewalls block connections via ports and protocols they do not recognise, there are variants of the protocol that can be used successfully in environments where security measures would block RTMP. The variants are listed below.

RTMP (default)

By default, the Adobe Flash Player uses the RTMP protocol over port 1935. If that fails, it will try again over ports 443 (RTMPS) and 80 (RTMPT) in an attempt to workaround firewall settings, which prevents TCP/IP connections over non-standard ports. The default admin port is 1111.

RTMPT (RTMP Tunneled)

This protocol encapsulates the RTMP data as valid HTTP, and by default communicates on port 80. While RTMPT requires marginally higher bandwidths due to the addition of HTTP headers, the protocol can be used successfully in environments where security measures would block RTMP.

RTMPS (RTMP Secure)

This is RTMP tunnelled via HTTPS, with a default port of 443.

RTMPE (RTMP Encrypted)

This protocol is an enhanced and encrypted version of RTMP. RTMPE is faster than SSL and does not require certificate management as SSL does. If you specify RTMPE without explicitly specifying a port, Adobe Flash Player scans ports just as it does with standard RTMP, in the following order: 1935, 443, 80, and 80 (RTMPTE) (supported with Flash Player 9,0,115,0 minimum; Adobe AIR; Adobe Media Player).

RTMPTE (RTMP Tunneled Encrypted)

Adobe Flash Media Server 3 introduces an enhanced version of the RTMP protocol which encrypts the communication channel, tunneling over HTTP. The default port is 80 (supported with Adobe Flash Player 9,0,115,0 minimum; Adobe AIR; Adobe Media Player). The key benefits over SSL (RTMPS) are performance, ease of implementation, and limited impact on server capacity.

RTMFP (Real‐Time Media Flow Protocol)

RTMFP is based on  the User Datagram Protocol (UDP). RTMFP supports sending data directly from one Adobe Flash Player to another, without going through a server. A server-side connection will always be required to establish the initial connection between the end‐users and can be used to provide server-side data execution or gateways into other systems. The user of a Flash Media Server will also be required to authorize network address lookup and NAT traversal services for the clients to prevent Adobe Flash Player from being used in an unmanaged way.

3. Handshake

Client -> Server : Sends Handshake Request. This is not a protocol packet but a single byte (0?03) followed by 1536 bytes. There is a counter which goes up, so it seems to be the clients uptime (time since system started).

Server <- Client : Sends a Handshake Response. This is not a RTMP packet but a single byte (0?03) followed by two 1536 byte chunks (so a total of 3072 raw bytes). The second chunk of bytes is the original client request bytes sent in handshake request. The first chunk can be anything. Use null bytes it doesnt seem to matter.

Client -> Server: Sends 1536 raw bytes which are the second 1536 chunk of server generated handshake.

At this time, handshake is done and further packets are RTMP ones.

Client -> Server : send the Connect RTMP packet.

Server <- Client : Server responds

...and so on...

4. Data Types

0x01 Chunk Size changes the chunk size for packets
0x02 Unknown anyone know this one?
0x03 Bytes Read send every x bytes read by both sides
0x04 Ping ping is a stream control message, has subtypes
0x05 Server BW the servers downstream bw
0x06 Client BW the clients upstream bw
0x07 Unknown anyone know this one?
0x08 Audio Data packet containing audio
0x09 Video Data packet containing video data
0x0A - 0?11 Unknown anyone know?
0x12 Notify an invoke which does not expect a reply
0x13 Shared Object has subtypes
0x14 Invoke like remoting call, used for stream actions too.

5. Shared Object Data Types

0x01 Connect
0x02 Disconnect
0x03 Set Attribute
0x04 Update Data
0x05 Update Attribute
0x06 Send Message
0x07 Status
0x08 Clear Data
0x09 Delete Data
0x0A Delete Attribute
0x0B Initial Data

6. Packet Structure

RTMP Packets consist of a fixed-length header and a variable length body of up to 128 bytes. The header can come in one of four sizes: 12, 8, 4, or 1 byte(s).

The two most significant bits of the first byte of the packet (which also counts as the first byte of the header) determine the length of the header. They can be extracted by ANDing the byte with the mask 0xC0. The possible header lengths are specified in the table below.

Also, checkout  this document. Its mostly accurate, although where it talks about AMF its really RTMP. AMF is used in RTMP, but its not covered in the document.

Bits Header Length
00 12 bytes
01 8 bytes
10 4 bytes
11 1 byte

7. Streaming

For basic publish cycle this is what happens:

Client -> Server : sends a CreateStream request (is it a single RTMP packet ?)

Server -> Client : sends a response with a streamIndex number

Client -> Server : does a publish (what does it means in this context ?)

Client -> Server : send the audio video packets (the packets are sent from the source as indicated on the streamIndex via the same channel as the publish request)