//This document seeks to clear some of the ambiguity and FUD (fear uncertainty and doubt) floating around by documenting our history and methods. If you have any questions please contact the mailing list or project managers.//

===== Discovery through Observation =====

In retrospect we think the term "reverse engineering" has generated quite a lot of confusion and misunderstanding. When people hear it they think we are somehow illegally cracking
something. This isn't the case. We simply look at unencrypted bytes captured over a public network. No software is ever decompiled. Reverse engineering of protocols for the purpose of interoperability is legal and even protected by the DCMA in the USA. A better term for what we do would be "discovery through observation", as that's exactly what we have done.

==== How it all started ====

The RED5 project started in August with a call to action posted on the OSFlash mailing list by John. It had been discussed before but nobody had actually managed to put a team together. This time things were different. Lots of people offered their help, we chatted on the list, choose some technologies, and put together the initial team.

[[http://osflash.org/pipermail/osflash_osflash.org/2005-August/002979.html|[osflash] New Flash Comm Open source project - line starts here]]


A week or two after starting the project Claus helped the project immensely by introducing us to Mick. Mick had successfully discovered the RTMP protocol way back in the days of flash 6. He used the same methods as us and even started before FCS was released. Over a rather long msn group chat he took us through some bytes describing the basic structure of the RTMP packet headers. We tried to take it all in, but it was over our heads at that point. So John asked him to put together a simple spec based on what he remembered. A few days later we received this document.

[[http://www.acmewebworks.com/Downloads/openCS/TheAMF.pdf|Packet structure document in PDF]]


==== Connecting the dots … ====

Based on the document we quickly put together a crude a packet decoder and socket server. This basically took care of the handshake, read the packet headers and joined chunks of body data back together.

We knew that AMF was the data format, and so started work on an AMF marshaling code. Using publicly available (alas unofficial) AMF specs published online we put together a generic object serializer / deserializer and abstracted the AMF format into data input and output objects. The idea being to add support for more formats in future. We tested the AMF code with some unit tests and a simple http server. 

Now it was simply a matter of putting the two things together and it didn't take long before we had RTMP packets decoding. In fact I think it was about half an hour. It was a little bit of a shock to see it working. It really wasn't that complicated after all.

[[http://osflash.org/pipermail/red5_osflash.org/2005-September/000134.html|[Red5] Decoding packets :)]]

After that point it didn't take long to get services (which are basically remoting over RTMP) working. This can be seen in an early test app we created to echo different data types using a simple echo service. 


==== Getting in the flow of things ====

Next thing on the to-do list was obviously streaming. Before we could do this we needed to understand the network conversation. The way we did this was some members of the team captured bytes using Ethereal and emailed them for manual decoding by the rest of the team. This email gives a good example of the way we discovered the structure / conversation of the packets. As far as we are aware this is the same kind process taken by those who discovered AMF and is not illegal.

[[http://osflash.org/pipermail/red5_osflash.org/2005-October/000872.html|[Red5] Decoding the stream conversion]]

Once we understood the packets we improved the discovery workflow by creating a RTMP debug proxy that can print out raw bytes or decoded packets to a log file. This helps a lot with debugging byte level issues.

==== In the end its only bytes ====

One final thing we would like to clarify is that RED5 does not encode or decode any proprietary audio / video codec. The server sends and receives FLV format data. The FLV format is a container format that wraps the encoded data chunks along with headers and metadata into a single file. As far as the RED5 server is concerned it’s just pushing bits.