If you ever worked with Flash media server or any other media server for that matter you probably know they are not working with the regular Internet protocol which is HTTP, all of the media servers (almost all at least) are working on top of a protocol called RTMP.
Now, if you have users working behind a firewall, they probably can’t get passed it’s restrictions and they will (in most cases) be blocked and unable to see your application / video.
If you are working on a server like WebOrb (I’m working with it) then the data will also be blocked, and that is a bug issue
Here’s a way to solve this
Well, let’s first talk a bit more about RTMP, before ditching it and moving on.
With flash media server you can use RTMP over a few ports (1935, 80), 1935 will probably always be blocked because it is not a known port and even simple routers often block it.
port 80 makes things a bit more complicated, you have to make FMS listen to a specific IP or your web-server (if on the same server) will not work.
So, first rule is always use port 80, this is one way to make more users be able to connect to your application, watch your videos and interact with your service.
The connection is being made like so:
rtmp://your_ip_address:80/app_name
DO NOT use any type of arrays of ports, simply use port 80, if the client can’t connect to RTMP on port 80, he will no be able to connect on RTMP no matter the port you are using.
So, What am I actually saying over here…?
I’m saying you should only make 1 connection attemp, this attempt is on port 80 using RTMP, this should be your first choice, if the connection is unsuccesful, you should move the connection to use RTMPT which is RTMP encapsulated over HTTP, firewalls will not block this connection becuase it makes RTMP “hide” behind HTTP traffic on port 80.
The connection is made practically the same way
rtmpt://your_ip_address:80/app_name
Why not use RTMPT at all times?
You should not use RTMPT at all times because there’s a performance issue, there is an overhead on top of each packet sent.
Why not go through all the possible ports with RTMP first, Why only 80?
In most cases, firewalls will block every port (but 80), the timeouts the user will have to go through will be very long before he will finally be redirected to RTMPT.
I will post some code on how to fallback more efficiently later on this week, this post was actually inspired from a client’s solution I did this week during a consulting session.
Good luck
My name is Avi Tzurel. I'm a professional web developer from Israel. I spend most of my day developing both web products and RIA applications as well as imparting my experience onto others. I speak, teach and write about my passions, and develop applications according to what I preach. I specialize in Flex, Adobe Air, HTML, XHTML, Javascript, jQuery and other Javascript libraries, on the server side I do .net along side with Ruby on Rails. You can connect with me on Twitter or email me through the contact page on this blog.
[quote]
DO NOT use any type of arrays of ports, simply use port 80, if the client can’t connect to RTMP on port 80, he will no be able to connect on RTMP no matter the port you are using.
[/quote]
What are the possible reason for this?
Did you ever post the fallback code somewhere?
Did you ever post that fallback code?
@aj:
That’s because firewalls usually behave like so:
block any other port then 80 (meaning nothing will work)
block any other traffic other then http
So, falling back from port 1935 to port 80 is useless (usually)
falling back from rtmp to rtmpt is useful.
@Ed:
No I didn’t post the code just yet, I will post it very very soon.
Thanks
@aj:
That’s because firewalls usually behave like so:
block any other port then 80 (meaning nothing will work)
block any other traffic other then http
So, falling back from port 1935 to port 80 is useless (usually)
falling back from rtmp to rtmpt is useful.
Still curious if you’ve posted that code snippet yet. I’m guessing it uses an interval to define a timeout after which it gives up on the RTMP connection attempt and tries RTMPT. But I was wondering if you have to do anything special to cancel and cleanup after the 1st hanging connection attempt.
@Ed: I didn’t post that code yet, it’s not only based on a timer, it’s also based on the failure of the first connection.
You don’t have to do any cleanup what so ever, you only assign a new value to the URL of the connection and connect again.
It seems that our company proxy blocks also RTMPT traffic and not only RTMP!!! (Of course it allows HTTP).
Is it possible or am I doing something wrong?!
Basically the .FLV is streamed via RTMPT through a .SWF file
Thank you very much!
@Max: RTMPT behind the scenes is actually HTTP.
it could be that the proxy is blocking it.
if this is the case, I would go the extra mile and create an HTTP streaming.
Hi Avi – I found your article very good because I have had streaming video for a long time on my web and just found out last week that many can´t see it because of firewalls. I have therefore changed my videos into progressive at the media service provider. I was thinking about having files of different bitrates for auto-detection but that needs port 1935 and because you wrote: “1935 will probably always be blocked because it is not a known port and even simple routers often block it.” I will not do that. Best regards, Kristjan