Future of Flash Communication through RTMFP
This is the third post of my Adobe MAX Milan 2008 notes.
Read the first one about Adobe FMS 3.5 and multi-bitrate streaming and the second one about Searchable Video Content.
RTMFP, Real Time Media Flow Protocol, we have heard about this feature a few times, some weeks ago, at the Adobe MAX sneak previews and it got silently introduced in Flash Player 10.
At the moment we have some implementations for communicating with Flash Media Server and other third-party real-time servers: RTMP, RTMPT (for HTTP tunneling, but has a bad overhead), RTMPS (Secure comm. over HTTPS, so is in fact RTMPT + the S), RTMPE (light-weight encryption for stream protection), RTMPET (RTMPE plus tunneling). But they all have some downsides: they have a certain latency, only client-server communication possible, lossless and only TCP based.
Real Time Media Flow Protocol
RTMFP introduces a UDP based protocol for client to client communication. With the release of Flash Media Server 3.5 today, we have the ability to actually use it in combination with Flash Player 10. You might not be able to install FMS 3.5 yet but you can use an online service called Stratus from Adobe to start experimenting with RTMFP.
To use RTMFP we always need a Flash Media Server. The FMS server needs to introduce the clients to each other before the clients can connect to eachother. There is very good reason for this: clients only connect through a unique ID, and not the ip address for obvious security reasons.
After two clients connect there is direct communication between them. But what now?
What about:
- direct streaming of your webcam and microphone to another client: video/telephony.
- multiplayer games without a server hosting the game communication logic
- file sharing: sending one file to another like you would with a IM client/service
As you can see, the functionality is already possible right now with p2p communication but the advantage in this situation is that the FMS server doesn’t need to handle all the data flowing in each application. All data transfer will happen directly between clients.
Some other key features of RTMFP:
- Prioritizing media and in particular the Speex protocol for audio communications (Speex: audio priority, live and unbuffered, video always follows audio)
- IP address mobility when losing connection, switching network connection: session can stay up. After connection loss: fast recovery.
- Encrypted with AES-128, SSL if needed and Diffin-Hellman key exchange for encryption
- UDP 1935 for connection establishment, afterwards higher UDP port possible
I will start playing with Stratus very soon and might post some more about this later.
Thanks for the post.
I have one interesting update. I did try this Stratus service,however I found that the since the P2P connectivity is based on Unique client ID and directly the IP address it was not possible to connect to the service if the client was behind the firewall.
I am looking forward to the solution that Stratus has the capability to provide unique Client ID which can even traverse through the firewall in order to reach the endpoint. Will this be possible?