Change default RTMPT fallback port to something other than port 80

Do you have a need for it, other than it being "nice"? It can probably be added, but I'm reluctant to go change this fallback logic, since it is so fragile.

Many server/stream state messages need to be caught and evaluated, plus the Flash plugin itself does some port fallback "magic" one cannot control in AS.

JeroenW,

We've encountered a number of cases where this would be helpful.

Specifically corporate networks where outbound 1935 is dropped (as opposed to rejected) and the browser is configured with a proxy that does not support RTMPT on port 80.

In this case the player attempts RTMP 1935, falls back to RTMPT 80 and then errors with "Server not found: rtmpt//...".

I suggest that RTMPT on 443 is preferable to 80 because these proxy devices generally allow it. I suspect because they cannot inspect the HTTP headers encrypted w/SSL.

One more thing.. in this same situation RTMP 80 is often open too.

But the issue is that RTMP 1935 is silently dropped rather than blocked so the player gets stuck waiting for a response. When this happens the JW Player failover to RTMPT occurs before the internal Flash failover to RTMP 80 is triggered.

I'm really not sure what the best solution here is overall but I hope I've given you an accurate view of this situation so that you may make a judgement.

I am seeing the same situation as react. I'd love to have the ability to specify port 443 instead.

I'll look into making the fallback port configurable. Right now, there's an "rtmp.tunneling=true" option in the player, I could add an option that's e.g. "rtmp.tunneling=443".

I'd rather not do RTMP:80 but go straight to RTMPT:80 (or RTMPT:443). A multi-step fallback is harder to manage, and the majority of viewers will be able to see RTMP:1935.

That would be awesome. I would be happy to drop them back to rtmpt and 443. Is there a bug for this and some timeline? Welcome back from vacation :-)

errr...not bug but enhancement :-)

We can look into that as part of 5.8 - the next release. Coming after the summer (early september):

http://developer.longtailvideo.com/trac/ticket/1375

This would be great. I'll be looking forward to seeing this :-)

I too would really like to see this feature. We currently serve http over port 80, and would like an alternative to rtmp for our clients on corporate LANs. Unfortunately 80 is already in use, so 443 would be ideal. Any idea on when this feature might be coming? I see it's been moved to backlog in the tracker...

443 will automatically be used by the player. The order it tries in is 1835>443>80. This setting would be more for adding yet another port.

Yes. Me, too.

Primary reason for having any other port for fallback is where the corporate server is already serving other websites (using IIS or Apache) so port 80 is not available.

There is an option in FMS to change the listening port. Need same in JWPlayer.

We'll look into this.

Thanks for the reply.

According to Netstat on my server, port 80 is being used by IIS while ports 1935 and 443 are by FMS. I had changed FMS's configuration to use 443.

Now, my test video, when I block 1935 immediately gives an error:
Server not found: rtmpt://server.domain.com:80/videos/

As you can see, there are two things wrong here:
Firstly, it didn't try 443 and, secondly, why doesn't it show the full URL of rtmpt://server.domain.com:80/videos/video.mp4 and just stop after the folder name?

BTW, is there any way to get Chrome/Firefox to show which rtmp/rtmpt requests Flash is sending? I see the http:// requests for player.swf, preview.jpg, etc., but not the rtmp requests.

Hmm.. I should make an account here so I can see when you reply.

Hi Hussain,

I have visitors experiencing similar issues today. ("Server not found: rtmpt://"...)

Out of curiosity, are you using an intermediate CNAME record? (I note you masked the hostname.)

From a machine unable to view your test video, what results do you get for this test?

http://clients.mediaondemand.net/bpp/fporttest/

cheers,