RTMFP Protocol Overview

Good day

Today I will talk about the wonderful RTMFP broadcast protocol . It implements many interesting approaches and there are a lot of prejudices regarding its capabilities. I want to warm up interest in this topic and dispel existing illusions. I did not find anything better for real-time broadcasting, and decided to write this post.

Background

Once upon a time in a distant galaxy ...
In 2004, Amicima, Inc. once lived . in which the GPL developed the implementation of the MFP protocol - MFPNet . Then they released amiciPhone , one of Skype's rivals, but things didn't go very well due to positioning problems. In 2007, Adobe acquired them because they needed a good real-time broadcast protocol.

What's wrong with RTMP?

RTMP is not a real-time broadcast protocol:

• the problem of minimizing delays is not solved;
• Broadcasting stops when the device address changes;
• TCP significantly increases delays and inflates messages with unnecessary delivery checks;
• no window size control.

Given the speed of development of mobile networks, the purchase of Amicima was a fairly logical and promising solution.

Prejudice about RTMFP

1. This is a proprietary protocol.

   
   Adobe decided to publish it in the form of RFC7016 in order to gain public attention, but somehow it worked out. Oddly enough, this does not look like a curved RTMP specification and looks more like MFP.
   
   The protocol itself is modular: certificate exchange, encryption, thread synchronization are performed as a separate profile. What happens in Flash remains in Flash. For developers of third-party solutions, such as Cumulus , Flash remained a black box; somehow quietly and quietly in April 2014, Adobe's RTMFP Profile for Flash Communication was released .
   
   

2. This is UDP - meaning there is no delivery guarantee.

   
   Quite a lot of real-time protocols use UDP, they add a network checksum and selective delivery checks to guarantee delivery. They only check what must come, and not everything in a row. For audio / video, packet delivery control doesn't make much sense. Window size (MTU) is usually maximum and static, which increases the likelihood of a situation of playing a void with the subsequent reception of irrelevant data in case of packet loss.
   
   

3. We don't need RTMFP - we have WebRTC

   
   WebRTC is not a protocol, it is a browser technology - an attempt to integrate SIP with RTP stack into a browser. If you cross RTP, SRTP, SCTP, RTCP, ZRTP, RTSP into a bunch, you get RTMFP. But in some cases, such bundles have redundancy and addressing problems that are not present in RTMFP.
   
   RTMFP has forwarding through NAT, window size control, metadata for flows with redundancy control from the application side, and forwarding / redirect sessions, and its own DHT.
   
   How long does it take to encapsulate RTP-like protocols in order to implement all this? .. I think, somewhere 4-5 pieces.
   
   The current implementation of broadcast protocols resembles the situation:
   

   “There are 6 protocols, but they all have a fatal flaw, and we will develop another one ...” A
   year passes.
   “There are 7 protocols, and they all have a fatal flaw ...”

   
   RTMFP is not an attempt to replace existing solutions. This is an attempt to generalize them, get rid of redundancy and make available to users.
   

RTMFP and OSI Model

So let's take a look at what layers of the OSI model the RTMFP protocol covers.

• Physical and channel

  There are no ephemeral energy fluctuations from fluttering butterflies here, and I would like redundancy by transmitting data in warp subspaces.
  
  

• Network and transport

  These are IP and UDP multicast.
  Here and Path MTU discovery and Congestion Control, already in the box, for each specific stream. There is a data transfer mode with a selective frequency by checking delivery - we check once in N packets. All packages have timestamps to measure delivery delay. Built-in ring hash addressing of endpoints like DHT.
  
  

• Presentation level

  For Flash, this, of course, is AMF3 and encapsulated RTMP, but you can transfer any other data.
  
  

• Application level

  There is support for URIs, network groups and pub / sub by stream identifiers. See the NetStream and NetGroup API documentation for more details .
  
  

Security in RTMFP

• Classic Diffie-Hellman key exchange with static and ephemeral keys.
• Cookies and certificates in sessions, with the possibility of digitally signing packages. True, by default, unsigned packages are considered valid.
• AES128 is used for encryption, but any other block algorithm can be used.
• HMAC-SHA256 or network checksums.

User authentication and authorization can be implemented by the application. The issue of malware filtering remains open.

Where is the killer function?

I think everyone remembers the failure to broadcast the latest presentation of the new IPhone 6 Plus pop phone ?

So imagine that one client receives an incoming stream and broadcasts it to two more and more (if possible), and so on - while the maximum possible delay allows. At the same time, real-time permutations and sortings occur in the client tree in order to minimize delays and optimize the package window. As a result, it is possible to achieve a multiple reduction in the outgoing traffic of the broadcast server.



And everyone will see him ...

Use cases

1. Live content broadcasting

   Actually, this is the purpose of the protocol itself, and it copes with this task very well.
   It can be used not only for transmitting audio / video, but also as the main transport in Flash games.
   
   

2. Cdn

   This is P2P and to download a file you only need to know its name, hash and size.
   You can implement the http2rtmfp gateway - the possibilities are quite entertaining.
   
   

3. Video Conferences and Chats

   In the post-Snowden era, RTMFP is an affordable and secure P2P transport. Also, the main advantage is the ability to continue broadcasting when changing the network address of the device. WebRTC may fall off when changing cells in 3G / 4G. The RTP stack is poorly suited for broadcasting in such an environment.
   
   

4. Real-time data transfer within private networks

   The main advantage for this use case is the ability to have a flexible routing policy, minimize delays, optionally verify packet delivery and have built-in traffic prioritization tools. All this can be configured individually for each specific application.
   
   

What about existing RTMFP solutions?

In short, things are very bad. Today, of the open implementations, there is perhaps Cumulus. It develops very sluggishly. It is not based on RFC, but on the first reversals of RTMFP Cirrus 1, so compatibility with the current Flash Profile Cirrus 2 is rather doubtful. It implements most of the usefulnesses, including organizing redundancy in P2P and broadcasting between devices. There is FMS, but it works like FMS ...

I will be glad to constructive comments.

In the comments, please indicate the analogues of RTMFP, if you know them.