zenomt / rtmp-errata-addenda Goto Github PK

Hey there! Thanks for taking the time to actually write these errata - finally having an official reference for these is great. 👍

Handshake

An omission from the RTMP spec that I do not see addressed is the handshake: the original RTMP spec says to send random bytes and then return a copy of the received random bytes from the other side (I simplified a little for sake of brevity), while in reality the handshake hides an additional verification that you're connected to a "genuine" Adobe server/client. If this verification fails, H264 capabilities are disabled (at least by the official flash client versions I've personally tested - but this is all many years ago and testing it again today is... painfully complicated, to say the least).

Considering that...

• Flash player has effectively gone the way of the dodo, leaving only "non-official" player implementations in actual use (which usually ignore this verification - but not always).
• The verification process is now public knowledge (the algorithm is easily found with a little searching in unofficial places, and also part of many open source media server implementations)

... I think it would be worthwhile to actually note this algorithm and the effect it had/has on playback in Flash Player in these errata, or at the very least to include some wording that the returned handshake data should never be checked for integrity (being an actual echo of the sent data; since it may not be). And perhaps - if verification is implemented at all - discourage checking for success, since limiting the use of H264 in this day and age seems a little moot.

Auth

Another omission is the username/password authentication mechanism. Specifically, the method when the server may return an error message with a description field containing ?authmod=adobe, which seems to be the "official" way to handle username/password authentication and has de-facto become the standard in the industry as far as I'm aware (I think there exists only one alternative, which is not in widespread use).
In particular, I'd like to see a note that the description field does not make use of the usual query param encoding for regular URLs. The + symbol should not be decoded to space (common practice for URL params), but instead used as-is. Considering base64 encoding is used in these fields and the + symbol is part of the base64 character set, I'd say this is an important detail.