Talk:Real-Time Messaging Protocol

RTMPT

RTMP - what is RTMPT - a RMPT Tunnel I beleive? Any info on this? They have also created RTMPE which is an RTMP + Encryption stream. —Preceding unsigned comment added by 212.83.71.69 (talk • contribs) 13:00, 25 February 2007

rtmp ripper?

Is there a rtmp rip application (enter a rtmp url, get a flv file on your hd)? For OS X? Thanks for any pointers, Peter S. 02:17, 1 September 2007 (UTC)

Free server

I've only just begun working with RTMP in ActionScript 3 (Flex 2 SDK), but I'm using FluorineFx (http://www.fluorinefx.com) for the server and it's free / open source rather than the other commercial implementations listed. I don't know that it "fully" implements the protocol, but it seems to do all the things RTMP is for (RPC, Shared Objects, etc.). Neilob 14:45, 26 October 2007 (UTC)

Do note it's made for Microsoft .NET Framework. -Lwc4life (talk) 11:09, 5 March 2008 (UTC)

Sunil Kumar Gupta (talk) 08:59, 6 June 2008 (UTC)==Protocol Flavour== RTMP protocol Flavour

The information on this Link is related to Wiki and its not just a link, Its useful information. Please include this and revert the changes made

Full Implementation

As there is no public specification, what qualifies a "full implementation"? —Preceding unsigned comment added by 84.139.199.17 (talk) 20:00, 2 October 2008 (UTC)

A full implementation is one that performs all the functions that the original Adobe Media Server performs and not just a sub set of it such as streaming simple files. A server then needs to be able to record live stream, stream multiple formats etc. Mmick66 (talk) 09:49, 25 December 2011 (UTC)

Original research?

Some of the notes on elements missing from the spec appear to be original research (or at least non-cited). A look at the current version of the spec suggests that this information is no longer accurate. As one example, the little-endianness of the stream message IDs are clearly documented in the spec. I'll wait a few days for comments, then reduce it to something like the following:

Adobe has released a specification (cite-link) that documents RTMP (except for the portions relating to copy protection). The specification includes a limited patent grant (which does not apply to 'prohibited uses', such as recording streamed content to disk).

The bit about 'Adobe is liable for initiating a false action under the Act' is likewise non-cited. It is also, as far as I know, untested in the courts. I'm inclined to just remove it (the section already documents the conflict between Adobe and some competing clients).

Drrakn (talk) 08:06, 20 September 2011 (UTC)

I definitely think that there is some original research here. The very notion of 'missing parts' from the specs is research outside the main source and I believe should be referenced extensively. I deleted the part about the fact that the message id is little endian is not mentioned in the spec since it is wrong. It is mentioned on page 8 of the June 2009 release of the spec. I also strongly believe that there author meant Message ID rather than Stream ID as was written since the latter is a 6 bit number that is definitely big endian. It is usually a 0x03 (interpreted normally as 3 dec). I also deleted the omission of aggregate messages since they are referenced in page 21 of the same spec, maybe not very extensively I agree and would back up the claim that the spec is badly written. Mmick66 (talk) 10:01, 25 December 2011 (UTC)

As this discussion hadn't moved in a while, I WP:BOLDed and tried for a clarification in the lead-in, as well as fixing up a couple other issues. If you don't like my wording, feel free to modify it, of course. Jouster  (whisper) 18:27, 3 June 2012 (UTC)

I have deleted the unsourced and probable WP:OR criticism. Someone didn't read the cover document carefully, because it says that not all details are made public. Also, it appears someone thought that a full implementation is needed for some (unspecified) "license" to be granted, when no such thing is in the Adobe license agreement. (Of course it would be silly since they don't disclose the whole thing.) JMP EAX (talk) 22:44, 4 August 2014 (UTC)

Re requested clarification

"Other RPC services are made asynchronously with a single client/server request/response model, so real-time communication is not necessary"

request/response happen pretty much in real time, so it would be better to say here, that "maintaining a persistent communication channel is not necessary upon arrival of response".

also, rtmp supports publisher/subscriber model, which is different from video/audio streaming, still requires a persistent connection so messages can be pushed to client. —Preceding unsigned comment added by 99.253.212.246 (talk) 01:33, 15 April 2010 (UTC)

RTMFP

The RTMFP section should be moved to the Real Time Media Flow Protocol article, where it belongs, shouldn't it? Or is there a reason to keep it here? ehn (talk) 13:47, 31 August 2010 (UTC)

I moved the section away from the article. The contents of it was a reverse engineer effort which is now moved to the Sotware section at the end of the article. Mmick66 (talk) 09:48, 25 December 2011 (UTC)

Packet structure - Ambiguity in explanation.

"b01 = 8 bytes - like type b00. not including message ID (4 last bytes)."

What is message ID? The last four bytes of the header are listed in the reference table as being "Message Stream ID". The byte previous to those is "Message Type ID". I'm assuming the ambiguous text is referring to the Message Stream ID as those are the last 4 bytes? However this is not 100% clear and may lead to confusion. Please clarify the explanation. If this receives no attention in the next week, I'll go ahead and edit the article to read: "b01 = 8 bytes - like type b00. not including Message Stream ID (4 last bytes)." This article is also totally inaccurate based on some RTMP traffic I intercepted.

RTMP Data From Client
      0 1 2 3  4 5 6 7  8 9 A B  C D E F  0123456789ABCDEF
0000 03000051 7C800007 02D20C5B 27CEC997  ...Q|......['...
0010 A3888F53 4F22F209 FBA14E42 9D0E6BDE  ...SO"....NB..k.
0020 3EB877E6 B709BC6E 8E939331 7FA72AEE  >.w....n...1..*.
0030 4F419915 25B98397 D074296C E3933789  OA..%....t)l..7.
0040 23D4D1B6 0250896A 2753C6A5 C62A25D7  #....P.j'S...*%.

109.146.171.95 (talk) 22:07, 18 January 2015 (UTC)

I wrote the original section. It was definitely accurate with what I saw and implemented myself, so it was tested in practice. The protocol could have changed in the past 4 years, it is very likely and probably what you see now is correct. Feel free to make any amends and deletions as you see fit, I only tried to put something that I knew was correct at the time out there in the hopes that it will be extended further. Thank you. Mmick66 (talk) 11:59, 5 June 2015 (UTC)

Should we be not misleading readers that propertiary solutions solve already solved TLS "issues"?

Could we please delete this paragraph:

It is generally understood that the TLS/SSL handshake at the beginning of a session is very computationally intensive. Adobe developed RTMPE as a lighter weight alternative,[3] to make it more practical for high-traffic sites to serve encrypted content. Adobe advertises RTMPE as a method for secure content delivery, protecting against client impersonation[4] but this claim is false. RTMPE only uses[1] Anonymous Diffie-Hellman which provides no verification of either party's identity, and as such is vulnerable to trivial man-in-the-middle attacks at session initialization.

It is so unspokenly wrong to suggest some broken, proprietary solution, where TLS already solves slow negotiations with session resumption mechanism - tickets. (https://www.ietf.org/rfc/rfc5077.txt) — Preceding unsigned comment added by 83.3.91.154 (talk)

Delete code snippets

var stream:NetStream = new NetStream(connectionObject);

It does not say anything to the users. It looks like JavaScript, but one can't be sure, Googling it actually will led user to believe it's ActionScript. Now, it uses some kind of proprietary API, which no-one (well, 99% landing on this page) has no prior experience with. What's the purpose of it? — Preceding unsigned comment added by 83.3.91.154 (talk)

Video covering the RTMP history and implementation(s)

There is an excellent video by Nick Chadwick from Mux (previously at Twitch) on the RTMP protocol. It may be a good source for citing. In addition Nick may be able to provide more references for citation. — Preceding unsigned comment added by Donal.hunt (talk • contribs) 10:21, 1 October 2020 (UTC)