Real-Time Media Flow Protocol

<h2 id="operation">Operation</h2>
<p>RTMFP allows users of live, real‐time communications, such as <a href="/facts/Social_networking_service/qFIh6VT1">social networking services</a> and multi‐user games, to communicate directly with each other using their computer's microphone and webcam. RTMFP is a <a href="/facts/Peer-to-peer/wCCdPb0H">peer-to-peer</a> system, but is only designed for direct end user to end user communication for real-time communication, not for file sharing between multiple peers using segmented downloading.<a class="footnote-ref" id="fnref:2" href="#fn:2"><sup>2</sup></a> Facebook uses this protocol in its Pipe application<a class="footnote-ref" id="fnref:3" href="#fn:3"><sup>3</sup></a>
</p><p>RTMFP enables direct, live, real‐time communication for applications such as audio and <a href="/facts/Videoconferencing/Ya9TMFQD">video chat</a> and multi‐player games. RTMFP flows data between the end‐user
clients and not the server, bandwidth is not being used at the server. RTMFP uses the <a href="/facts/User_Datagram_Protocol/dxLU0D6q">User Datagram Protocol</a>, (UDP) to send video and audio data over the Internet, so needs to handle missing, dropped, or out of order packets. RTMFP has two features that may help to mitigate the effects of connection errors.
</p><p>Rapid Connection Restore: Connections are re‐established quickly after brief outages. For example, when a <a href="/facts/Wireless_network/yr4SWTdl">wireless network</a> connection experiences a dropout. After reconnection, the connection has full capabilities instantly.
</p><p>IP Mobility: Active network peer sessions are maintained even if a client changes to a new <a href="/facts/IP_address/z9V22Sw9">IP address</a>. For example, when a laptop on a wireless network is plugged into a wired connection and receives a new address.
</p>
<h2 id="difference-between-rtmp-and-rtmfp">Difference between RTMP and RTMFP</h2>
<p>The principal difference is how the protocols communicate over the network. RTMFP is based on
<a href="/facts/User_Datagram_Protocol/dxLU0D6q">User Datagram Protocol</a> (UDP),<a class="footnote-ref" id="fnref:4" href="#fn:4"><sup>4</sup></a>  whereas <a href="/facts/Real-Time_Messaging_Protocol/6rpAXGgk">Real-Time Messaging Protocol</a> (RTMP) is based on <a href="/facts/Transmission_Control_Protocol/WW4sPrt9">Transmission Control Protocol</a> (TCP).
UDP‐based protocols have some specific advantages over TCP‐based protocols when delivering live <a href="/facts/Streaming_media/4rPhSq0Y">streaming media</a>, such as decreased latency and overhead, and greater tolerance for dropped or missing packets, at the cost of decreased reliability.
Unlike RTMP, RTMFP also supports sending data directly from one <a href="/facts/Adobe_Flash_Player/IvnaoU7v">Adobe Flash Player</a> to another,
without going through a server. A server‐side connection will always be required to establish the initial connection between the end‐users and can be used to provide server‐side data execution or gateways into other systems. The user of a <a href="/facts/Adobe_Flash_Media_Server/Pz03aq1w">Flash Media Server</a> will also be required to authorize network address lookup and <a href="/facts/NAT_traversal/HVds5bqC">NAT traversal</a> services for the clients to prevent Flash Player from being used in an unmanaged way.
</p>
<h2 id="application-level-multicast">Application-level multicast</h2>
<p>Flash Player 10.0 allowed only one-to-one communication for P2P, but from 10.1 application-level <a href="/facts/Multicast/D9IspSfl">multicast</a> is allowed. Flash Player finds appropriate distribution route (<a href="/facts/Overlay_network/NCJoCs7P">overlay network</a>), and can distribute to the group, which is connected by P2P.
</p>
<h2 id="history">History</h2>
<p>RTMFP's underlying protocols are the result of Adobe's acquisition of <a href="/facts/Amicima/avuWuN2J">Amicima</a> in 2006; strong architectural similarities exist between RTMFP and Amicima's <a href="/facts/GNU_General_Public_License/S75KhLSX">GPL</a>-licensed Secure Media Flow Protocol (MFP).
</p>
<h2 id="see-also">See also</h2>
<ul><li><a href="/facts/Adobe_Flash_Player/IvnaoU7v">Adobe Flash Player</a></li>
<li><a href="/facts/Real-Time_Messaging_Protocol/6rpAXGgk">Real-Time Messaging Protocol</a></li></ul>

<h2 id="references">References</h2>

<ol>
<li id="fn:1"><p>Michael Thornburgh (November 2013). "Adobe's Secure Real-Time Media Flow Protocol". RFC. Internet Engineering Task Force. Retrieved March 6, 2014. <a href="https://tools.ietf.org/html/rfc7016" target="_blank">https://tools.ietf.org/html/rfc7016</a> <a href="#fnref:1" class="footnote-back-ref">↩</a></p></li>
<li id="fn:2"><p>RTMFP FAQ <a href="https://www.adobe.com/products/flash-media-enterprise/rtmfp-faq.html" target="_blank">https://www.adobe.com/products/flash-media-enterprise/rtmfp-faq.html</a> <a href="#fnref:2" class="footnote-back-ref">↩</a></p></li>
<li id="fn:3"><p>"Pipe". Archived from the original on 2013-12-03. Retrieved 2013-11-23. <a href="https://web.archive.org/web/20131203000113/http://www.pipe.com/how/" target="_blank">https://web.archive.org/web/20131203000113/http://www.pipe.com/how/</a> <a href="#fnref:3" class="footnote-back-ref">↩</a></p></li>
<li id="fn:4"><p>Michael Thornburgh (November 2013). "Adobe's Secure Real-Time Media Flow Protocol". RFC. Internet Engineering Task Force. Retrieved March 6, 2014. <a href="https://tools.ietf.org/html/rfc7016" target="_blank">https://tools.ietf.org/html/rfc7016</a> <a href="#fnref:4" class="footnote-back-ref">↩</a></p></li>
</ol>

Real-Time Media Flow Protocol open-in-new

Real-Time Media Flow Protocol