Why RTMFP
RTMFP is protocol based on UDP, developed by Adobe for low-latency streaming.
Flash platform uses RTMFP for peer to peer connections and media relay between Adobe Flash Player instances. This feature supported since Flash Player 10.
RTMP protocol is implemented in many streaming solutions like Wowza Media Server, Flash Media Server and other servers designed for streaming and broadcast targets.
RTMP is good and open protocol. You can find RTMP specification on Adobe website. Anybody can talk about lacks and errors of that specification, but anyway it gives good start to understand RTMP and implement own streaming server.
RTMP has one major lack due it’s nature. This is the latency.
If your service just play video stream, you can admit latency 2-3 seconds (up to 10-60 seconds).
This is normal latency for on-demand streaming, but that`s not good for realtime communicating cases.
For example:
A bank has web-camera, which monitor cashpoint of this bank.
We assume that latency is 1 minute.
So, security department watches situation with 1 minute latency.
Somebody can steal cashpoint, but security department will know about stealing just after 1 minute.
Quite critical, isn`t it?
Yes, that case is very synthetic… but many a true word is spoken in jest, right?
Now lets take simple usually call.
You have business conversation and your partner hear you with 2 seconds delay.
Is it suitable? May be. Is it convinient? No.
Comfortable conversation in IP telephony is about 200 ms delay.
That how you hear your friend from your mobile phone.
So, why RTMFP?
Because latency is VERY important for communicating, and RTMFP decreases it greatly.
RTMP vs RTMFP
Lets imagine that you make call over RTMP, and your connection has lags.
Then your webphone will retransmit audio packets which falls in lags, and latency will grow,
because we will send next packet only when previous packet will be delivered well.
That mean if previous packet will fall into a lag, it will be sends again and again,
until it will be delivered well.
Such mechnism guarantee you that ALL packets will be delivered, and exactly in given sequence
as it was sent. This is very good for sending files, but not very good for realtime communicating.
Because, more lags – more latency.
That is how TCP works, and that is how TCP-based RTMP works.
| Protocol | How it works | Result | Difference |
|---|---|---|---|
| RTMP | – Client send packet_1 – Server send ACK – Client send packet_2 – Server send ACK – Client send packet_3 – Packet_3 is lost – 50 milliseconds left (where 50 ms is about RTT route trip time) – Client does not receive ACK from server – Client sends packet_3 again – Server sends ACK |
– Total sent unique packets: 3 – Packet lost: 0 – Latency grow: 50ms |
– Reliable – Latency grow |
| RTMFP | – Client send packet_1 – Client send packet_2 – Client send packet_3 – Packet_3 is lost – Client send packet_4 |
– Total sent unique packets: 4 – Packets lost: 1 – Latency grow: 0ms |
– No reliable – No latency |
No additional latency here. But packet lost is suitable.
And that is the main differences between RTMP and RTMFP protocol.
What else
- RTMFP is encrypted protocol. It uses AES and other cryptographic algorithm to secure audio and other data going through RTMFP.
- RTMFP is peer-to-peer oriented protocol, but we use it as peer-server-peer in RTMFP to SIP gateway project.
RTMFP alpha is RTMFP to SIP two-way media gateway, which translates Flash RTMFP protocol to
SIP for signaling puporse and RTP for media. So, you can make and receive audio/video calls to/from softhphones,
hardphones, GSM and other SIP endpoints on top RTMFP protocol to get lower latency for professional communications.
You can try it here.
