RTMP Part 4 - Command Message

This part will describe RTMP command message. Server and client in RTMP communicate and request for RPC using command message. Command messages are encoded using Action Message Format (AMF)

AMF have 2 version AMF 0 and AMF 3

Command Message - AMF 0 have a message type id 20 and AMF 3 have a message type id 17.

A command message consist of command name, transaction id and command object.

These command messages can be used to perform connect, createStream, play, etc... It will also be used to update status for the command.

Data Message - AMF 0 have message type id 18 and AMF 3 have message type id 15

These data message are used to send meta data regarding the information of the stream. The meta data can be the configuration data for video and audio.

Shared Object Message - AMF 0 have kMessageContainerEx=19 and AMF 3 have kMessageContainerEx=16

These shared object message are Flash share objects. A flash share object is a collection of value pair information for synchronization across multiple clients.
The following event type are supported

Audio Message - AMF 0 and AMF 3 message type is 8

This message is used to send audio data to peers


Video Message - AMF 0 and AMF 3 message type is 9

This message is used to send video data to peers. As video message is huge and would delay sending of other type of messages, it should set with low priority

Aggregate Message - AMF 0 and AMF 3 message type is 22

It is a single message that contains many sub-messages

There are many type of commands for exchanging communication between peers. The following are the general rules

1. Sender will send a command with a transaction ID and some parameters
2. Receiver process the command and reply a response with same transaction ID
3. The response string can be _result, _error or a method name

2 class objects are used to send various commands

1. NetConnection - it gives a high level representation of connection between server and client
2. NetStream - it represents the channel (video/audio/data) over which data are sent. Control flow command (play, pause, etc...) are sent via NetStream

Comments

  1. Do you know the feild format of a shared object?
    How many bytes of "Current Version" and "Flags"?

    Below is a shared object "presentation":

    03 00 00 8A 00 00 1F 13 00 00 00 00 00 0C 70 72 65 73 65 6E 74 61 74 69 6F 6E 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00

    The event type might be "00 00 00 01" (Use).
    The event data length might be "00 00 00 00".

    There are 9 bytes (all 0s) after "presentation" and before event type "Use".

    ReplyDelete
  2. Both should be a 32 bit integer value

    Under my observation, flags is use to denote whether this shared object is persistent and it seems to be always 2 when shared object is persistent. Otherwise, it will be 0.

    ReplyDelete
  3. Below is your decoded message.

    03 00 00 8A 00 00 1F 13 00 00 00 00 00 0C 70 72 65 73 65 6E 74 61 74 69 6F 6E 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00

    Header:

    03 - FMT 0 with chunk stream id 3
    00 00 8A - Timestamp
    00 00 1F - Message length 31 bytes
    13 - AMF 0 Shared Object message
    00 00 00 00 - Message stream id

    Payload:

    00 0C - 12 bytes of shared object name
    70 72 65 73 65 6E 74 61 74 69 6F 6E - ASCII word (presentation)
    00 00 00 00 - Current Version 0
    00 00 00 00 - Flag 0
    00 00 00 00 - Unknown bytes
    01 - Event type - Server Connect or Use
    00 00 00 00 - Event data

    ReplyDelete
  4. Thanks for the relies.

    I sent that shared object ("presentation") to a wowza server and I got -

    04 00 00 00 00 00 6F 13 00 00 00 00 00 0C 70 72 65 73 65 6E 74 61 74 69 6F 6E 00 00 00 03 00 00 00 20 00 00 00 00 0B 00 00 00 00 08 00 00 00 00 04 00 00 00 2C 00 07 63 75 72 72 65 6E 74 02 00 20 34 39 39 65 34 65 31 39 30 31 34 64 34 32 39 39 39 35 65 32 32 61 37 61 37 31 31 38 63 32 38 61 04 00 00 00 15 00 0A 70 6C 61 79 42 75 66 66 65 72 00 00 00 00 00 00 00 00 00

    As I guess, the current version (00 00 00 03) might also be an alias for paramter count?

    I also sent two other shared objects ("chatPermission" and "announcement") to that server and I got -

    04 00 00 00 00 00 46 13 00 00 00 00 00 0E 63 68 61 74 50 65 72 6D 69 73 73 69 6F 6E 00 00 00 02 00 00 00 20 00 00 00 00 0B 00 00 00 00 08 00 00 00 00 04 00 00 00 0E 00 0A 70 75 62 6C 69 63 43 68 61 74 01 01 04 00 00 00 08 00 04 63 68 61 74 01 01 04 00 00 00 00 00 47 13 00 00 00 00 00 0C 61 6E 6E 6F 75 6E 63 65 6D 65 6E 74 00 00 00 02 00 00 00 20 00 00 00 00 0B 00 00 00 00 08 00 00 00 00 04 00 00 00 0E 00 07 6D 65 73 73 61 67 65 02 00 02 4F 4B 04 00 00 00 0B 00 07 65 6E 61 62 6C 65 64 01 01

    ReplyDelete
  5. above repsone of "presentation" from wowza in ASCII :

    ......o.......present
    ation....... ........
    ..........,..current.
    . 499e4e19014d429995e
    22a7a7118c28a.......p
    layBuffer.........

    above repsone of "chatPermission" and "announcement" from wowza in ASCII :

    ......F.......chatPer
    mission....... ......
    ...............public
    Chat.........chat....
    ....G.......announcem
    ent....... ..........
    ...........message...
    OK.......enabled..

    ReplyDelete
  6. Hmmm... It might not be a paramter count.

    ***Decode above resposes***
    In shared object "presentation", there are properties(?) :
    current - "499e4e19014d429995e22a7a7118c28a" (string : type 2)
    playBuffer - 0 (number : type 0)

    In shared object "chatPermission", there are properties :
    chatPermission - true (boolean : type 1)
    chat - true (boolean : type 1)

    In shared object "announcement", there are properties :
    message - "ok" (string : type 2)
    enabled - true (boolean : type 1)

    ReplyDelete
  7. Thanks for clarifying the format of the "Shared Object Message." The Adobe specification document didn't give any insight at all.

    ReplyDelete
  8. @J.J Thanks for the additional information.

    @admin Grad that it helps

    ReplyDelete

Post a Comment

Popular Posts