Table of Contents

  1. 1. Introduction
  2. 2. Flavours
      1. RTMP (default)
      2. RTMPT (RTMP Tunneled)
      3. RTMPS (RTMP Secure)
      4. RTMPE (Encrypted RTMP)
      5. RTMPTE (Encrypted RTMP Tunneled)
      6. RTMFP (Real Time Media Flow Protocol)
  3. 3. Handshake
  4. 4. Data Types
  5. 5. Shared Object Data Types
  6. 6. Packet Structure
  7. 7. Streaming
  8. 8. Links

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.

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 Flash Player uses the standard, unencrypted Real-Time Messaging Protocol over the default 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. Port 1935 is a registered IANA port.

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)

Secure Sockets Layer (SSL) is a protocol for enabling secure communications over TCP/IP. Flash Player provides support for both incoming and outgoing SSL connections. This is RTMP tunnelled via HTTPS, with a default port of 443. When SSL is configured, to use SSL, applications must specify the RTMPS protocol in the NetConnection.connect() URL; for example, nc.connect("rtmps://www.example.com/myMediaApplication").

RTMPS adheres to SSL standards for secure network connections and enables connections through a TCP socket on a secure port. Data passed over the secure connection is encrypted to avoid eavesdropping by unauthorized third parties. Because secure connections require extra processing power and may affect the server's performance, use RTMPS only for applications that require a higher level of security or that handle sensitive or critical data.

RTMPE (Encrypted RTMP)

RTMPE is a version of RTMP which is an 128-bit encrypted protocol. RTMPE is more lightweight than SSL and does not require certificate management as SSL does. In some scenarios, you might want to disable RTMPE (encrypted Real-Time Messaging Protocol). Because RTMPE uses encrypted channels, there is a minor impact on performance; RTMPE requires more processing power than RTMP.

To request an encrypted or encrypted tunneling channel, applications specify rtmpe or rtmpte, respectively, in the NetConnection.connect() URL, for example, nc.connect("rtmpe://www.example.com/myMediaApplication"). If an application specifies RTMPE without explicitly specifying a port, Flash Player scans ports just like it does with RTMP, in the following order: 1935 (RTMPE), 443 (RTMPE), 80 (RTMPE), 80 (RTMPTE).

RTMPTE (Encrypted RTMP Tunneled)

The RTMPTE protocol encrypts the communication channel, tunneling over HTTP. The default port is 80 (supported with 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 provides a UDP-based secure network transport alternative to RTMP-over-TCP. UDP (User Datagram Protocol) is an efficient and standardized Internet protocol for delivering media assets because of its support for lossy delivery, improving performance of real time communication. RTMFP is always encrypted which helps protect media delivery.

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

0×01 Chunk Size changes the chunk size for packets
0×02 Unknown anyone know this one?
0×03 Bytes Read send every x bytes read by both sides
0×04 Ping ping is a stream control message, has subtypes
0×05 Server BW the servers downstream bw
0×06 Client BW the clients upstream bw
0×07 Unknown anyone know this one?
0×08 Audio Data packet containing audio
0×09 Video Data packet containing video data
0x0A - 0×11 Unknown anyone know?
0×12 Notify an invoke which does not expect a reply
0×13 Shared Object has subtypes
0×14 Invoke like remoting call, used for stream actions too.

5. Shared Object Data Types

0×01 Connect
0×02 Disconnect
0×03 Set Attribute
0×04 Update Data
0×05 Update Attribute
0×06 Send Message
0×07 Status
0×08 Clear Data
0×09 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)