Re: Paper on Flash-based Audio and Video Communication in the Cloud

[Kundan Singh]

[cc'ing support mailing list]

Hi Vhal,

In another project, I did RTMFP first and then within 500 ms (instead of 5 sec) attempt RTMP without stopping RTMFP. If RTMFP succeeds later, stop or disconnect RTMP. But other approaches (where you attempt RTMP first and then do RTMFP) should work as well. The main challenge is to provide a smooth user interface which seamlessly transitions different video elements or attaches the same video with different stream objects.

In the past I used http://cc.rtmfp.net/ to detect NAT issues. I hope it still works. If it works from your client then hopefully RTMFP should work.

With RTMFP there are two types of NAT issues: (1) if UDP is blocked it won't work at all. (2) If UDP is allowed by the NATs are of type symmetric NATs then it won't be able to establish peer-to-peer media path. In the latter case (2) it may still work if you use a server that supports RTMFP (such as Adobe FMS), in which case the media path will be client-server but over UDP. The free cirrus/stratus service (used in VideoIO sample code) does not allow client-server media path though. If your NATs are of symmetric type that allow UDP you may benefit if you install your own version of FMS instead of using free cirrus/stratus service for RTMFP rendezvous. The media path over UDP has still lower latency than over TCP even if it is client-server, although it does not save on server bandwidth.

Please send future questions to the mailing list.

Regards

On Tue, Apr 23, 2013 at 8:52 PM, Vhalerie Lee <vhal...@gmail.com> wrote:

Hi Kundan, Carol,

Greetings! My name is Vhal from the Philippines and I am currently part of a team developing a flash-based media communications application using RTMFP and RTMP protocols. I stumbled upon your paper on "Flash-based Audio and Video Communication in the Cloud" in Google and am interested to know more about the stream failover portion.

I understand in theory based on your paper is to first establish a connection over P2P then if the attempt fails, a client-server TCP transport is then made. I would like to ask if you have explored the option of first connecting over server-based RTMP then if P2P service is available, the application switches to the TCP connection. The reason I am asking is because my team and I have encountered at least 99% failed attempts to connect using P2P RTMFP over a 5 second connection attempt and eventually falls back to the server-based RTMP connection. As a result, the service has around 5 second connection initiation delay, which is not good for the service. We have resulted to defaulting to client-server TCP transport instead for the meantime. This may be due to blocked UDP ports or NAT, as your paper suggests, but our tests were made over mobile networks (3G) and Wi-Fi, where UDP ports were opened. We are hoping we could still establish more P2P connections using RTMFP as this has a lower latency and reduces our bandwidth costs as opposed to using RTMP.

We hope you could kindly share your insights. Any feedback would be helpful to our developments.

Thank you.

Best Regards,

Vhal

--
Kundan Singh    kund...@gmail.com  http://kundansingh.com