Tunneling not supported for SMIL files?

[jeroen]

So I tried setting that, both as true and false (I think you meant true, as that is the point: we want tunneling to occur per the fallback mechanism if port 1935 isn't open). No dice.

We have since been able to get the video to play by changing our SMIL file from:

<meta base='rtmp://ourserver.com:1935/vod' />

to explicitly state:

<meta base='rtmpt://ourserver.com/vod' />

With the same embed code, it can find the files over port 80 this way and play the video. However this is obviously not SMTPT Fallback, but manual.

Here are some more details: If I set the SMIL file to:

meta base='rtmp://ourserver.com/vod' />

JWPlayer behind the firewall does some communication on that URL: I can't tell if it tries 1935 or not, but it does obviously try 80 and I see some send/idle/close calls. It then ends with "Stream not found" and lists the URL to the SMIL file.

If I then change the SMIL file to:

<meta base="rtmpt://oursever.com/vod' />

Then it works. So it seems that JWPlayer is trying port 80 (as Fallback? Unfortunately I'm unable to test 1935 on a computer outside the network right now to see if it's auto-trying 1935 just because of the rtmp designation, or not). However it's not converting the SMIL rtmp to rtmpt so it still fails. If I manually set ti to rtmpt for a test, it works.

It seems then that JWPlayer code might just need an update: it does fallback great for streamer flash attribute, but not when the streamer is specified as the <meta base=> attribute.

We are considering that we could ping the vod server on 1935 and see if it replies or not; if not, we can assume it's behind a firewall and tell the JWPlayer to use a different SMIL file which is hard-coded to rtmpt. However this seems easy enough that it should be something the JWPlayer does by default as supporting rtmp fallback for playlists?

[jeroen]

We're removing the tunneling feature, so this isn't a problem anymore.