FMS connection Stop with rtmpt protocol.

[niteshkumar]

Hi ,

I am publishing my live stream with rtmpt protocol on port 80,to overcome network proxy.

But  after 10 to 15 minutes (telecast) video get stuck and connection get lost.But i don't

have this problem when i use rtmp protocol with port 1935. please reply if i need to do some thing else.

Regards

Nitesh Kumar

[Guest]

Nitesh,

This sounds like this could be a proxy issue at the client end.  See this article

http://kb2.adobe.com/cps/000/1ccfec30.html

Under "Proxy server configuration "

[niteshkumar · Accepted solution]

Thanks elcapitan26,

I gone through the connection using wireshark which shows repeatedly connection break, to resolve this solution I used rtmps to connect with FMS which worked.

[dpRob]

Thanks, niteshkumar,

this seems also to be very helpful for the problem we encountered recently.

But I wonder if this also works for the more light weight RTMPE protocol.

Regards

Robin

[niteshkumar]

Hi dpRob,

you are right we can use RTMPE protocol, but the RTMPE protocol is needed to get opened at client Proxy server end which restrict to do so. For that I have used RTMPS connection.

Regards

Nitesh Kumar

[dpRob]

Well, now we also established RTMPS connections on our server. It works flawlessly on our side but the client's company network have further restrictions (maybe because of their proxy configuration) so we can only use RTMPTS there (set NetConnection's proxyType to "none" instead of "best".

So we have the tunneling again and that's why we face the same problems again like when using RTMPT.

It's interesting to see that Adobe Connect is able to use RTMPS... because their app is much more stable without any kind of tunneling artefacts and it's very repsonsive, too.

Well... we don't know exactly Adobe Connect is using RTMPTS or RTMPS because we can't install an packet inspector on the client's machines of course.

Thanks,

Robin

[jwebb-compunetix]

I know this question is old, but it came up for me in search, and I wanted to add a note.

We've encountered similar problems with RTMPT. The issue seems to be that client interfaces to the Internet, especially if they have some sort of webfilter installed, treat HTTP traffic differently from HTTPS. HTTP gets subjected to more scrutiny. For example, content is examined for viruses. Just by random chance, eventually RTMPT traffic will match the virus filter, and packets will get dropped. As a result, the connection is lost (since RTMPT, using TCP, assumes all packets are delivered).

Another thing that happens in times of heavy load is that the webfilter can fall behind as it gets overloaded. With enough delay, the RTMPT connection will close.

The reason RTMPS doesn't show the same problems is that HTTPS packets aren't necessarily subjected to the same scrutiny, since it would require deep packet inspection. This is possible, and might happen at some point in the future. But for right now it appears that RTMPT is less reliable than RTMPS.