Setting up port 80 on Windows 2008 server for FMS or Wowza running IIS7 alongside

It’s been a long time since I wrote any article. It was more of being laziness on my part and also because sometimes you have NDA’s not allowing you to share your technical misadventure(s) with the folks of your community.

So this one is just setting up port 80 for FMS and Wowza (Red5 maybe didn’t tried setting up port for it) and for that matter any application which you want to setup on port 80 alongside other ports for the particular IP on which you want to setup that particular application.

The pre-requisites here are that you have more then 1 IP on the Windows 2008 server on which you are going to install your streaming server In case you want to keep IIS running alongside on the same server. BTW if you are looking for setting up port 80 on Windows 2000 or Windows 2003 server please visit Stefan’s blog he has a very well written post updated for both 2000 and 2003 windows server Running Flashcom Server alongside IIS.

Technical part:

I have searched around and found this article by Steve Schofield. He setup apache alongside IIS on another IP and assigned port 80 to that.

As we know Windows always assign port 80 by default to IIS on all IP setup on a machine. So whenever we setup any application on any IP we have to first remove IIS from its port 80 only then we can assign the port 80 to our other application on that particular IP.  I will just copy paste the steps written on Steves blog for straight reference here:

  1. Added or make sure your machine has at least two IPs (just for example 192.168.0.90 and 192.168.0.91)
  2. “Open an [elevated] command prompt”. i.e. you need to run command prompt as an administrator as UAC will block this command.
  3. Type netsh
  4. Type http
  5. Type sho iplisten.  It should be blank
  6. Type add iplisten ipaddress=192.168.0.90 You should get IP address successfully added
  7. Type sho iplisten again. It should sho 192.168.0.90 in the list
  8. Type exit to get out of netsh
  9. Type netstat -an. See if you notice 192.168.0.90:80 in the list.  If you see 0.0.0.0:80, do an iisreset

Now Install Wowza or FMS and then you can mention port 80 against a particular IP on which you want to setup your these streaming servers.

For Wowza:

goto: conf>vhost.xml – In IpAddress tag mention the 2nd IP on which you want to setup wowza in this case it’s 192.168.0.91.

In Port tag mention port 1935,80 using comma as a separator and after saving vhost file restart the Wowza service.

For FMS:

In FMS you can edit listening ports at two places, one at

conf>fms.ini -> In this file look for ADAPTOR.HOSTPORT tag there place port 80 after 1935 using comma separator. Add IP in front of color for example 192.168.0.91:1935,80 Make sure you don’t have # in front of ADAPTOR.HOSTPORT as it comment out the line.

The other place you can edit is directly in Adaptor.xml which is there inside folder conf\_defaultRoot_ look for HostPort add IP:Port(s) using comma separate as giving in the commenting section of adaptor.xml file. So in our example case it will be like 192.168.0.91:1935,80 in place of ${ADAPTOR.HOSTPORT} which is using variables defined in fms.ini.

You just make sure you update it only at single place in fms.ini or in adaptor.xml.

After updating the file restart both FMS services.

After installing your streaming server and configuring port 80 for them you can check if the respective IPs are listening to their port 80 by using netstat -an at command line.

In our example case it should show up something like:  192.168.0.90:80 and 192.168.0.91:80.

Then you can test out by connecting to your streaming server from your machine using rtmp://ip:80/appname. It should work.

Just hope it helps…

Advertisements

Stop using DuplicateDir tag for failover support architecutre in FMS!

I was working on fail-over architecture for our application and came across this <duplicateDir> tag in application.xml which, I am quite sure that many of you advanced FMS users already know or some of you might be already using it in your FMS based applications to support Fail-over.

I designed an architecture for our application in this architecture I was trying to keep the same folder hierarchy on both server.  So that if FMS (machine 1) stops working and users connects to same running instance from FMS (machine 2) they get the last updated data on FMS (machine 2) dumped through duplicate functionality from FMS1. There is a property in tag to attach application directory name to the path on other server or not i.e. by assigning value true you can add application directory name to the path or it will just copy the files at instance path. But when I was switching off the app directory name by assigning false it was just copying all sharedobject/streams at the root instead of at instance path. If I keep the app directory by assigning it  true.  It copies at correct path including instance path but attaching application directory path at beginning.

Anyway thinking that it’s some kind of bug or I might be doing something wrong. I posted a query regarding it on Flashcomguru mailing list and here comes the reply from FMS team member:

The <DuplicateDir> functionality for SharedObjects has been deprecated; it probably shouldn’t have been documented, my apologies. I’ve added a note to the online docs (comments appear at the bottom of the page):
http://help.adobe.com/en_US/FlashMediaServer/3.5_AdminGuide/WS5b3ccc516d4fbf351e63e3d119f2926bcf-7ff0.html

So what do we do now? I mean how do we achieve the duplicate directory functionality for fail-over in case we have planned for future? Or in case some of you were using it in past? So here is the reply from Adobe engineering team:

<DuplicateDir> won’t be supported moving forward and existing bugs won’t be fixed, so it’s not a good idea to use it.
You can use the File plug-in to build a fail-over architecture for streams.

So good luck for all the FMS developers who were or are in process of implementing failover architecture and were planning to or already using this duplicate directory in their architecture.

Some other good way to implement failover is to follow architecture suggested by Rober A. Colvin

I am just curious to know that will NAS/SAN introduce any kind of latency?  Compared to the files being stored on and delivered from same  machine?

Please let me know if anyone has any idea about it.

JScrCap screen capture utility for both FMS and Wowza Media Server

I have been evaluating JScrCap for a while now and finally i got something to write about. I got it working with both FMS and Wowza.  There are few pros and cons I am detailing below in the article.

Quality and memory usage is pretty good compare to the VH Capture which, we (flash media community) were used to use for screen-sharing applications.

You just have to put the JScrCap bundle on any web-server and use the JScrCap as an Applet in html page to start with. Just call the web page and it will prompt the client that there is an applet you want to run it or not. As soon as user clicks the run he is ready to share his screen through Flash media server or Wowza Media server.

FMS (Flash Media Server)

  1. You can’t use the default code i.e. SVC1 and also free codec used for screencapture with JScrCap utility as FMS doesn’t recognize this codec. Actually FMS  drops connection after first frame. Access log shows 419 x-status code, which means “License to receive screen sharing video failed”See more info or feedback from Flash community as Steafen puts in his blog.
  2. You can only use H264 codec for screencapture which does have licensing limitations.
  3. Using H264 you can’t reocrd flv file on server you can only create mp4 files. So in case you want to use FMS for screensharing using JScrCap and want to record the stream on server as well you have to make sure you record the incoming stream as mp4 stream not flv. Following is the error i see in log file if I try to record the h264 data as flv “2009-07-09 15:07:30 7180 (w)2611179 Warning from libflv.dll: Recording H264 to FLV is unsupported, tried in FLV :
    F:\RnD\FlashCom\FlashComm Applications\livestreamrecord\streams\_definst_\livestream.flv.
    2009-07-09 15:09:03 7180 (e)2601163 Failed to record F:\RnD\FlashCom\FlashComm Applications\livestreamrecord\streams\_definst_\livestream, no space left on device -“

  4. You can record metadata in mp4 file using FMS.

Wowza Media Server

  1. You can use both codec i.e. default one SVC1 or H264 for screencapture.
  2. You can record flv or mp4 files using h264 codec in Wowza.
  3. Wowza doesn’t record data in mp4 stream. So if you want to access data across in recorded stream make sure you only record the stream as flv.
  4. JScrCap sent mouse coordinates data as onMouseData so in case you are using Wowza with JScrCap you have to listen on onMouseData on Netstream object. This was an update Vladimir done recently on request as earlier the way data was being sent across using JScrCap was only recognized by FMS not Wowza. It was pointed to me by Charlie that the wowza doesn’t record the metadata the way JScrCap is sending so he suggested the way it should be and thankfully Vladimir did it very quickly.
  5. The other major benefit of using Wowza is that you can use EC2 instance of wowza which has very less cost compared to the upfront cost you have to pay to get FMS.

I tested it on Windows and Mac and it worked fine. I think any user’s platform which will be able to run java applet through JVM etc. can have screensharing working through his system.

The other important thing I noticed in JScrcap notes is that SVC1 – works on all platforms, H264 – works only on Windows and MacOSX. So as FMS can only interpret h264 stream not SVC1  that means we wont be able to use screensharing on Linux machines with FMS we have to use Wowza there as it does recognize SVC1 compressed stream.

Please post your views regarding this article or if there is anything missing I can update it here.