Step 1: Red5 Configuration
By default, Red5 uses port 8088 for RTMPT (RTMP tunneled over HTTP). For our purposes, this port is going to host RTMPS as well.
This step is by far the simplest, all you have to do is, from your red5 installation directory, open the conf/red5.properties file in your favorite text editor and find the RTMPT section:
# RTMPT rtmpt.host=0.0.0.0 rtmpt.port=8088 rtmpt.ping_interval=5000 rtmpt.max_inactivity=60000
The only property we care about now is rtmpt.port. This port is going to be the end port for all tunnelled activity.
Step 2: Apache setup (HTTP for RTMPT)
My Red5 server lives behind a firewall, but if you want to have an Apache server running on the same server as Red5 and be able to offer Apache served pages plus RTMPT and RTMPS without too much work, we're going to have to teach Apache about RTMPT/S. For this, we modify our VirtualHost to handle RTMPT:
ServerName www.mymediahost.com ErrorLog /web/www.mymediahost.com/logs/error.log CustomLog /web/www.mymediahost.com/logs/access.log combined DocumentRoot /web/www.mymediahost.com/docs ProxyPass /open http://red5.mymediahost.com:8088/open ProxyPassReverse /open http://red5.mymediahost.com:8088/open ProxyPass /close http://red5.mymediahost.com:8088/close ProxyPassReverse /close http://red5.mymediahost.com:8088/close ProxyPass /idle http://red5.mymediahost.com:8088/idle ProxyPassReverse /idle http://red5.mymediahost.com:8088/idle ProxyPass /send http://red5.mymediahost.com:8088/send ProxyPassReverse /send http://red5.mymediahost.com:8088/send
This example is from my Apache configuration, with the names changed to protect the guilty. red5.mymediahost.com can either be an external or internal host. Serving things this way means that, to the client, it looks like everything's coming from the same host and we can avoid annoying sandbox violations. The 8088 is where we need the number from step 1, so it should match whatever you're using as rtmpt.port
Step 3: Apache Setup (HTTPS for RTMPS)
Before proceeding, there is one simple caveat: The flash player uses your web browser's HTTPS capabilities, so if you're using a self-signed certificate or one from a ghetto CA, you have to add it to your browser's trusted certificates, otherwise you're going to have to deal with it asking the permission of any and all who visit.
After doing what needs to be done, we need to create an SSL-enabled virtual host to communicate with the Flash player. Here's what mine looks like:
ServerName www.mymediahost.com ErrorLog /web/www.mymediahost.com/logs/error.log CustomLog /web/www.mymediahost.com/logs/access.log combined DocumentRoot /web/www.mymediahost.com/docs SSLEngine On SSLCertificateFile /web/www.mymediahost.com/certs/mymediahost.crt SSLCertificateKeyFile /web/www.mymediahost.com/certs/mymediahost.key SetEnvIf User-Agent "/*MSIE.*" nokeepalive ssl-unclean-shutdown ProxyPass /open http://red5.mymediahost.com:8088/open< ProxyPassReverse /open http://red5.mymediahost.com:8088/open ProxyPass /close http://red5.mymediahost.com:8088/close ProxyPassReverse /close http://red5.mymediahost.com:8088/close ProxyPass /idle http://red5.mymediahost.com:8088/idle ProxyPassReverse /idle http://red5.mymediahost.com:8088/idle ProxyPass /send http://red5.mymediahost.com:8088/send< ProxyPassReverse /send http://red5.mymediahost.com:8088/send
Warning: Apache doesn't seem to like having multiple SSLEngines running on the same port. My Apache installation was already serving an SSL-enabled site, so I moved it to a non-standard port so Red5 would be sitting on the standard HTTPS port.
Step 4: Straight RTMP (optional)
If you want to pass straight RTMP traffic directly to your Red5 server living life on the inside, you need a way to tunnel the connection from the source to the destination. I'm sure most people have figured out how to do this, but I used nc by adding this to my inetd.conf:
rtmp stream tcp nowait nobody /usr/bin/nc 192.168.1.10 1935
In order to use rtmp as a service name in inetd.conf, you have to add this line to your /etc/services:
rtmp 1935/tcp
Also, /usr/bin is where nc lives in my OpenBSD system, it might be somewhere else on yours. I also use the internal IP address not for any real reason, just out of distrust.
Step 5: Actionscript Logic
If all has gone well, you should now be able to access your Red5 server by any means possible. All that remains is teaching your ActionScript code how to handle this. Here (in a nutshell) is how I handle this:
var proto:Array = new Array( "rtmp", "rtmps", "rtmpt" );
var curprot:Number = 0;
var nc:NetConnection = new NetConnection();
nc.addEventListener( NetStatusEvent.NET_STATUS, netStatus );
function netStatus( ev:NetStatusEvent ) {
switch( ev.info.code ) {
case "NetConnection.Connect.Failed":
curprot++;
if( curprot > proto.length ) curprot = 0;
tryConnect();
break;
}
}
function tryConnect() {
nc.connect( proto[curprot] + "://red5.mymediahost.com/my_app" );
}
tryConnect();Caveat: I'm pretty sure the above code won't work properly (I don't think you can call NetConnection.connect() from that NetConnection's event handler), I only included it to show the logic I use to continually try other protocols until a connection is established.
Step 6: Profit
If all has gone well, you should now be able to access your Red5 server regardless of whether or not it's behind a firewall from a client that may or may not be ridiculously firewalled.
Post new comment