RTMPT protocol

Overview

This document describes the RTMPT tunneling protocol as implemented by the Red5 Open Source Flash Server. Please note that this document is _not_ an official specification by Macromedia but hopefully helps other people to write software that makes use of RTMPT.

RTMPT basically is a HTTP wrapper around the RTMP protocol that is sent using POST requests from the client to the server. Because of the non-persistent nature of HTTP connections, RTMPT requires the clients to poll for updates periodically in order to get notified about events that are generated by the server or other clients.

During the lifetime of a RTMPT session, four possible request types can be sent to the server which will be described below.

URLs

The URL to be opened has the following form:

http://server/<comand>/[<client>/]<index>

<command>

denotes the RTMPT request type (see below)

<client>

specifies the id of the client that performs the requests (only sent for established sessions)

<index>

is a consecutive number that seems to be used to detect missing packages

Request / Response

All HTTP requests share some common properties:

• They use HTTP 1.1 POST.
• The content type is application/x-fcs.
• The connection should be kept alive by the client and server to reduce network overhead.

The HTTP responses also share some properties:

• The content type is application/x-fcs.
• For all established sessions the first byte of the response data controls the polling interval of the client where higher values mean less polling requests.

Polling interval

The server always starts with a value of 0x01 after data was returned and increases it after 10 emtpy replies. The maximum delay is 0x21 which causes a delay of approximately 0.5 seconds between two requests.

Red5 currently increases the delay in the following steps: 0x01, 0x03, 0x05, 0x09, 0x11, 0x21.

Initial connect (command “open”)

This is the first request that is sent to the server in order to register a client on the server and start a new session. The server replies with a unique id (usually a number) that is used by the client for all future requests.

Note: the reply doesn’t contain a value for the polling interval! A successful connect resets the consecutive index that is used in the URLs.

Client updates (command “send”)

The data a client would send to the server using RTMP is simply prefixed with a HTTP header and otherwise sent unmodified.

The server responds with a HTTP response containing one byte controlling the polling interval and the RTMP data if available.

Polling requests (command “idle”)

If the client doesn’t have more data to send to the server, he has to poll for updates to receive streaming data or events like shared objects.

Disconnect of a session (command “close”)

If a client wants to terminate his connection, he sends the “close” command which is replied with a 0x00 by the server.