Check RTMP Protocol [DRAFT] for more info.

• SVN - http://svn1.cvsdude.com/osflash/red5

(click to view full size image)

• TheAMF.pdf file

• MSN Chat where Mick starts to explain RTMP protocol

• Full capture of RTMP with Ethereal (for Mick's discussion)

• Text version of dump

The header comes in 4 sizes:

• 12 bytes
• 8 bytes
• 4 bytes
• 1 byte

The 2 most significant bits (of this first byte) determine the header size

• 03 ← initial AMF id byte

• 00 00 01 ← unknown bytes. don’t seem to be important

• 00 01 05 ← body size (24 bit)

• 14 ← AMF function call (sort of an AMF type... video == 09, audio == 08, sharedObject == 13)

• 00 00 00 00 ← AMF Caller Source (00 00 00 00 is the flash player itself. each NetStream object will have its own value here)

• main.asc (clean)

load( "components.asc" );

application.onConnectAccept = function( client) {
	trace( application.name + ":onConnectAccept ");
}

application.onConnect = function( newClient) {
	trace( application.name + ":onConnect " + newClient);
	application.acceptConnection(newClient);
}

The following informations have been found out by looking at the traffic that is sent between the flash client and the FCS in the “sample_noteroom” application.

To request or update a SO, the client sends the following RTMP request:

• [RTMP Header]
• [SO Name (2+n bytes)]
• [SO Version to operate on (4 bytes)]
• [SO Encoding (4 bytes, usually “2”)]
• [unknown (4 bytes)]
• [SO Request Type (1 byte)]
• [SO Request Size (4 bytes)]
• [SO Request Body (n bytes)]

To get an initial SO, the version and the request size are set to “0”. Therefore the request body is absent. To update a SO, the version is set to the version of the local SO, the request type is “3” and the body contains key / AMF object pairs. Be aware that you may not change the attributes of your local SO yourself as the FCS will generate messages for each of your changes.

Depending on the requests the FCS receives from the different clients, it sends update events to all the clients that requested a SO. The format is described below.

• [RTMP Header]
• [SO Header]
• [SO Body Header]
• [SO Body n]
• [SO Body Header]
• [SO Body m]
• [...]

• 2+n bytes: name of the SO
• 4 bytes: version of the SO
• 4 bytes: encoding of the SO (seems to be “2” always)
• 4 bytes: unknown

• 1 byte: type of body part
  • 4: update data
  • 5: update attribute
  • 7: status (usually returned with error messages)
  • 9: delete data
  • 11: initial data
• 4 bytes: size of body part

(the following entries may appear multiple times; check using size of body part)

• 2+n bytes: name of attribute
• read amf object as value of attribute

• 2+n bytes: name of attribute to update

This is sent by the FCS after you sent a request to update your local copy of the SO to make your changes effective.

• 2+n bytes: status message
• 2+n bytes: status type (sometimes “error”)

• 2+n bytes: name of attribute to delete

(the following entries may appear multiple times; check using size of body part)

• 1 byte: subtype
• 4 bytes: subsize (if 0, the following fields don’t exist)

  if subtype != 9 (delete data):
    read amf object as value of attribute
  else:
    delete attribute
  

• Charles

• Ethereal is for any OS - with WinPcap for Win included in current release

• Lot of tools for windows

• Charle's start on RTMP

• Ruby RTMP test - Thanks Yannick Connan! - Yannicks Readme
• John's Flash8 RTMP test file for use with Yannick's RTMP server sample

• Windows Install