Geekly Articles each Day
📜 ⬆️ ⬇️

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 about its capabilities. I want to stir up interest in this topic and dispel existing illusions. I didn’t find anything better for broadcasting in real time, and decided to write this post.

Prehistory


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

What's wrong with RTMP?

RTMP is not a real-time broadcast protocol:

Given the speed of development of mobile networks, buying Amicima was a rather logical and promising decision.

RTMFP Prejudice

  1. This is a proprietary protocol.

    Adobe decided to publish it in the form of RFC7016 in order to warm public attention, but somehow it did. Oddly enough, this is not like the RTMP specification curve and is more like MFP.
    ')
    The protocol itself is modular: the exchange of certificates, encryption, synchronization of streams are implemented as a separate profile. What happens in Flash remains in Flash. For third-party developers, such as Cumulus , Flash remained a black box; somehow, quietly and unnoticed in April 2014, Adobe's RTMFP Profile for Flash Communication came out.

  2. This is UDP - no delivery guarantee.

    Quite a lot of real-time protocols use UDP, add network checksum and selective delivery checks to guarantee delivery. They check only what must come, not everything in a row. For audio / video control of packet delivery does not make more sense. The window size (MTU) is usually maximum and static, which increases the likelihood of a situation of playing voids and then receiving outdated data when a packet is lost.

  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 an RTP stack into a browser. If you cross into a bunch of RTP, SRTP, SCTP, RTCP, ZRTP, RTSP - you get RTMFP. But in some cases, such bundles have redundancy and addressing problems that are not in the RTMFP.

    RTMFP has both forwarding through NAT, window size control, metadata for the application-controlled flow of redundancy, forwarding / redirect sessions, and its DHT.

    How many RTP-like protocols do you need to encapsulate in order to implement it all? .. I think there are about 4-5 pieces.

    The current implementation of broadcasting protocols is reminiscent of the situation:
    "There are 6 protocols, but they all have a fatal flaw, and we will develop another one ..."
    It takes a year.
    "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 it available to users.

RTMFP and OSI model


So, let's consider what levels of the OSI model the RTMFP protocol covers.

Security in RTMFP



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

Where is the killer function?


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

So imagine that one client receives an incoming stream and transmits it to two more or more (if possible), and so - as long as the maximum possible delay allows. At the same time, real-time permutations and sorting occur in the client tree in order to minimize delays and optimize the package window. As a result, you can achieve a multiple decrease in the outgoing traffic of the broadcast server.



And everyone will see him ...

Use cases


  1. Real-time content broadcast
    Actually, this is the purpose of the protocol itself, and it copes very well with this task.
    It can be used not only to transmit 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. RTP Stack is poorly suited for broadcasting in such an environment.

  4. Transfer of real-time data within private networks
    The main advantage for this use case is the possibility of a flexible routing policy, minimizing delays, optional packet delivery checks, and built-in traffic prioritization tools. All this can be configured individually for each specific application.


How are things with existing RTMFP solutions?


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

I will be glad to constructive comments.

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

Source: https://habr.com/ru/post/239299/

More articles:


All Articles