Page 2 of 2 FirstFirst 12
Results 11 to 19 of 19

Thread: Proxy issues with SMIL

  1. #11
    Join Date
    May 2013
    Posts
    15

    Default

    The patch is applied "Wowza 3 Perpetual OEM Sonic Performance 3.5.2.08 build4955".

    I do not think it is the proxy returning wrong content from the cache, as I always get different numbers. See here:
    GET http://stream.instantlearning.biz/ilsgo/smil:ILS_215_0140_The_Ruler.smil/jwplayer.smil HTTP/1.1
    Accept: */*
    Accept-Language: de-DE
    Referer: http://go.instantlearning.biz/fileadmin/res/js/jwplayer.flash.swf
    x-flash-version: 11,7,700,169
    Accept-Encoding: gzip, deflate
    User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
    Host: stream.instantlearning.biz
    Proxy-Connection: Keep-Alive
    
    
    HTTP/1.0 200 OK
    Content-Type: application/x-fcs
    Server: FlashCom/3.5.7
    Cache-Control: no-cache
    Content-Length: 11
    X-Cache: MISS from PROXY
    X-Cache-Lookup: MISS from PROXY:3128
    Via: 1.0 PROXY:3128 (squid/2.7.STABLE9)
    Connection: keep-alive
    Proxy-Connection: keep-alive
    
    1229250553
    
    
    GET http://stream.instantlearning.biz/ilsgo/smil:ILS_215_0140_The_Ruler.smil/jwplayer.smil HTTP/1.1
    Accept: */*
    Accept-Language: de-DE
    Referer: http://go.instantlearning.biz/fileadmin/res/js/jwplayer.flash.swf
    x-flash-version: 11,7,700,169
    Accept-Encoding: gzip, deflate
    User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
    Host: stream.instantlearning.biz
    Proxy-Connection: Keep-Alive
    
    
    HTTP/1.0 200 OK
    Content-Type: application/x-fcs
    Server: FlashCom/3.5.7
    Cache-Control: no-cache
    Content-Length: 10
    X-Cache: MISS from PROXY
    X-Cache-Lookup: MISS from PROXY:3128
    Via: 1.0 PROXY:3128 (squid/2.7.STABLE9)
    Connection: keep-alive
    Proxy-Connection: keep-alive
    
    263577491
    
    
    GET http://stream.instantlearning.biz/ilsgo/smil:ILS_215_0140_The_Ruler.smil/jwplayer.smil HTTP/1.1
    Accept: */*
    Accept-Language: de-DE
    Referer: http://go.instantlearning.biz/fileadmin/res/js/jwplayer.flash.swf
    x-flash-version: 11,7,700,169
    Accept-Encoding: gzip, deflate
    User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
    Host: stream.instantlearning.biz
    Proxy-Connection: Keep-Alive
    
    
    HTTP/1.0 200 OK
    Content-Type: application/x-fcs
    Server: FlashCom/3.5.7
    Cache-Control: no-cache
    Content-Length: 9
    X-Cache: MISS from PROXY
    X-Cache-Lookup: MISS from PROXY:3128
    Via: 1.0 PROXY:3128 (squid/2.7.STABLE9)
    Connection: keep-alive
    Proxy-Connection: keep-alive
    
    88824327
    Whished I could force RTMPT without the proxy.

    Regards
    Henrik

  2. #12
    Join Date
    May 2013
    Posts
    15

    Default

    I know. But I was expecting a fallback to RTMPT. And it does work for the first video, looks good. Only the next request for another SMIL while the other video is still running fails. If the GET (executed via HTTP) were answered with the SMIL content, it would work, I am sure.

  3. #13
    Join Date
    May 2013
    Posts
    15

    Default

    I did some more testing. The situation is real. Here's what I found so far.

    Two people are behind a proxy accessing Wowza. They do not have direct internet access. The website they are accessing uses jwplayer 6.

    The first user tries to watch a video. The player gets a URL like this "http://ilsdevstream.sonic-ps.de/ilsdev-hz/smil:ILS_806_0990_PivotTable_erstellen.smil/jwplayer.smil" to access a SMIL file. It downloads the file successfully using HTTP GET. Then it uses RTMPT to display the video, on can clearly see that. HTTP POST is used like this:
    POST http://stream.instantlearning.biz/open/1 HTTP/1.1\r\n
    POST http://stream.instantlearning.biz/idle/1593715987/0 HTTP/1.1\r\n
    Works well. The video is displayed.

    Now the second user tries to watch a video. Again, the SMIL is requested using HTTP GET. This time unfortunately no SMIL is returned, but a number that looks like a stream id. The user gets the aforementioned error message.
    As soon as the first user stops watching the video, the second user can reload the page and watch the video.

    My conclusion:
    • The fallback to RTMPT works.
    • While Wowza is delivering a stream to one IP, it won't reply properly to HTTP GETs asking for SMILs coming from the same IP. All requests come from the same IP as they are sent via the Proxy.


    My assumption:
    If I could make Wowza return all SMILs as requested, access via the proxy would be possible, even for several users at the same time.

    Unfortunately I cannot trace the packets on the other side of the proxy. But as this is a serious issue for us, I am willing to set up a lab environment to test further.

    If anything like configuration files, logs from the server, anything else is needed, let me know.

    Thank you!
    Henrik

  4. #14
    Join Date
    Dec 2007
    Posts
    21,962

    Default

    The only way to fallback to rtmpt is in the client.

    Richard

  5. #15
    Join Date
    May 2013
    Posts
    15

    Default

    Dear Richard,

    I know the client has to do the fallback, that's not the issue. You must have misunderstood my observations.

    What I observe is that of two or more clients connecting from behind the same proxy only the first is able to load the SMIL from the Wowza server. It then tests connection options, detects that RTMP is not possible, neither via port 1935 nor 80. It then automatically falls back to RTMPT. That works fine over the proxy, the first user can happily watch the video.

    While he does so, the second client tries to do the same. But already the download of the SMIL from Wowza fails. The client is able to reach Wowza via the proxy, but instead of the expected SMIL, a number is delivered. The number suspiciously looks like the session id Wowza usually sends after a "POST http://stream.instantlearning.biz/open/1" command. The request for the SMIL is sent via HTTP (GET) to port 80. The proxy cannot be the cause, the number is different at each request, so it cannot come from the cache.

    The only reason why I asked whether it were possible to change rtmp to rtmpt in the SMIL file generated, is that I wanted to test without the proxy thus eliminating one possible cause.

    So to summarize:
    • SMIL generation by Wowza: works
    • Download of SMIL from Wowza using HTTP GET: works - as long as no RTMPT connection exists via the same proxy
    • RTMPT stream via proxy: works
    • Download of another SMIL via the same proxy while an RTMPT connection exists via the proxy: DOES NOT WORK


    My suspicion is that when the a client uses RTMPT to port 80 on a Wowza server, HTTP GET requests to Wowza coming from the same IP are no longer handled correctly. Maybe because they are not expected.

    Is there a way to make this an official support call? I don't want to be a pest, it is just extremely important for us.

    Kind regards
    Henrik

  6. #16

    Default

    The problem is Wowza Server does not support HTTP pipelining in all cases. Once a connection is determined to be RTMPT then we cannot switch that TCP connection back to serving up the SMIL file. The best course of action is to see if there is some way to force the proxy to not pipeline requests. We need the second SMIL request to be over a different TCP connection or it will not work.

    We may support pipelining in the future but at this time we have no plans to support this feature.

    Charlie

  7. #17
    Join Date
    May 2013
    Posts
    15

    Default

    Hi Charlie,

    Thank you for the clarification. Now that explains the observation. So I can a) check whether the requests are really pipelined (guess they are) b) try to make Squid open a new connection for the second client and c) tell our customers that pipelinig request via proxies isn't supported.

    That's something I can work with.

    Henrik

  8. #18
    Join Date
    May 2013
    Posts
    15

    Default

    Dear Charlie and Richard,

    I would like to make this a feature request. We are a Wowza OEM partner and are delivering VOD to a growing customer base. Quite frequently we find environments where the employees can only access the internet via proxy. Though we strongly recommend bypassing the proxy for TCP 1935 and using rtmp for performance reasons, it would be fantastic if the fallback worked, even for those environments where the proxy does pipeline the requests. We do not have that much influence on our customers' infrastructures and wouldn't want to lose a deal just because we can't offer our solution via proxy.

    Kind regards
    Henrik
    Last edited by SONIC-HZ; 05-15-2013 at 01:46 AM. Reason: typo

  9. #19

    Default

    We will consider for a future release.

    Charlie

Page 2 of 2 FirstFirst 12

Similar Threads

  1. force rtmpt in SMIL generated by jwplayer.smil?
    By SONIC-HZ in forum Video On Demand Streaming Discussion
    Replies: 2
    Last Post: 05-14-2013, 07:39 AM
  2. Stream not found [live/smil:myStream.smil/manifest.f4m]: myStream.smil
    By viet_fpt in forum Live Streaming and Encoder Discussion
    Replies: 12
    Last Post: 04-08-2013, 07:22 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •