Also, the RTMP specification 1.0 that is widely available online is "outdated". The reason it is "outdated" because this specification defined the handshake only for flv streaming. If you use this handshake for connecting H.264 stream, it will never work. Below are from RTMP specification 1.0 handshake
In the RTMP 1.0 specification, 5th to 8th bytes are zero bytes in the first client and server message. That in turn saying that it only support flv stream. The client will not play the H.264 stream even if you have sent correct onMetaData and configuration information. So, if you are working on a flash media server for serving H.264 stream, you should take note of this handshake.
Client versions equal to or greater than Flash 9,0,124,0 require a nonzero value as the fifth byte of the handshake request. Furthermore, Flash 10.0.32.18 seems have changed the handshake again.
I will describe the handshake with my best knowledge with the 3 way handshake
1. Client send a 1537 bytes message to server. The first byte in the message is still the version byte. Now, it have 2 types, 0x03 (normal RTMP) and 0x06 (encrypted RTMP). The next four bytes are timestamp. The next four bytes are flash client version. The remaining bytes are challenge bytes for the server to validate the client connection using SHA 256 Hash digest.
2. If the server validate the client correctly, it should reply a 3073 bytes message to client. The first bytes is version byte, 0x03. The next 1536 bytes are challenge bytes from server (first 4 bytes are timestamp, next four bytes are server version and the remaining bytes are challenge bytes). The next 1536 byte contains 1504 bytes of pure random data and 32 bytes for comparison hash value.
3. If the client validate the server correctly, it will reply a 1536 bytes message. The first byte is version byte, 0x03. The remaining bytes are the first 1536 bytes of the server challenge message.
Reference: Adobe Official RTMP Specification