This content has been marked as final. Show 4 replies
In short, I guess I'm basically asking for an ICE (STUN2+TURN) implementation that performs:
1) Several STUN binding requests on a range of local ports (to bypass local firewalls),
2) fallback on TLS or TCP for TURN relay in case no UDP packet reached its destination.
3) Of course it would make people's life easier if the STUN2/TURN server was implemented at the stratus level, but that is not mandatory.
I'm afraid that implementing the above is the only way to make rtmfp available to all users both from the corporate and the home worlds.
In order to provide the major advantages RTMFP has over RTMP (partially-reliable delivery, flow prioritization, advanced congestion control, IP address mobility, etc.) we must use UDP for client-server communication. Peer-to-peer communication must also use UDP, because almost all machines are now behind NAT devices and establishing TCP peer-to-peer connections works much less often than UDP peer-to-peer connections.
The TURN proxy support was added for those enterprises that wish to open up Flash Player's ability to send/receive UDP without opening up UDP for all client applications.
If you wish to build an application that uses a media relay that you (as the developer) provide for relaying media over TCP, we already have that support in the form of RTMP and RTMPT and using FMS as the media relay. That performs much better than trying to tunnel a protocol with its own congestion control and retransmission, like RTMFP, over a TCP channel.
I was already in the process of implementing a fallback on rtmp/rtmpt, but what I have experienced so far is that rtmpt from corporate networks was not good enough in terms of latency to use for VOIP communications; sometimes it was ok for a little while, but most often it was just not good enough.
Google's videochat on the contrary obtains good results with H264-SVC over TLS to bypass UDP-blocking proxies, so I guess I was hoping that Adobe would go in the same direction...
Also what google is able to do with its TCP connection to a server, is to enable P2P trafffic within a corporate network although UDP is blocked between the enterprise and Internet.
The current Adobe implementation cannot provide that, unless each company installs its own TURN server (but without auth it is going to be difficult to convince the IT departments).
We are currently building our own Google like plugin for the very reasons you mentioned in this post. I would be interested in getting your views on it, firstname.lastname@example.org if you are interested.