Skip to main content
D
danderyd2004
Participant
April 20, 2010
Question

Crossdomain.xml request unanswered by FMS 3.5 Application

  • April 20, 2010
  • 3 replies
  • 2996 views

Hi all,

I need help with a strange issue:

I have a FMS 3.5 running a VOD service (on-line training based on videos) on what I call a "streaming server".

The client loads the Player from a secure (separate) domain, and the Player then requests the SMIL files from the webroot of the Apache server (part of the FMS installation. The Player then starts the video which is streamed dynamically.

In order for the Player to get the SMIL files, it is making a crossdomain.xml request to the Streaming Server. When it get the response, it continues the process.

PROBLEM: Sometimes, the crossdomail.xml response from the Streaming Server is SEVERELY delayed, with perhaps 5 minutes. So the end user experience is that it does not work.

I improved the situation by opening up more ports on the Windows Firewall of the Stremaing Server (now open for 1935,80,443,8134) and it works say 90%+ of the times. But there are still occations when there is no response.

I have not specified a crossdomain.xml file, so the response is the default "*" from the application.

Any ideas???? Appreciate any tips.

    This topic has been closed for replies.

    3 replies

    A
    Anonymous
    April 14, 2012

    I have the same issue with olafnew. I would like to play vod with http dynamic streaming feature on my Flex Application. I opened an iframe with embeded StrobeMediaPlayback. The movie plays well at the first time. If user closes the iframe and opens another movie, the player does not work any more. I look into Fiddler and the request for crossdomain.xml to my streaming server is never returned.

    Please help.

    D
    danderyd2004Author
    Participant
    May 3, 2010

    Howdy,

    I have done some further investigations and I have so far concluded that:

    - in the cases where the service does NOT work, the following is happening:

    I watch a video (video 1), then close the window. I start a new window with a new video (video 2). However, despite closing a window and opening a new window, the TCP session for video 1 remains open. So when I start video 2, the crossdomain.xml request is sent on the old TCP session.

    Instead of getting an "OK" reply, I simply get an "ACK" reply and the process is halted.

    - in the cases where the service does work, the following is happening:

    I watch a video (video 1), then close the window. I start a new window with a new video (video 2). For each window, a new TCP session is set up/ synchronised, and the crossdomain.xml request receices an "ACK".

    - it seems that the failure scenario happens when there are no files in the cache.

    Any ideas of what this could be?

    Asa_-_FMS
    Adobe Employee
    Asa_-_FMS
    Adobe Employee
    May 4, 2010

    Interesting, this could be a bug in how FMS handles crossdomain requests on an existing HTTP socket that's already been handling session data.  Is it possible that you can share one of these demonstratable packet captures with us here at Adobe so that we have something to work on the problem for?  You can contact me directly at awhilloc@adobe.com.

    Asa

    O
    olafnew
    Participating Frequently
    February 28, 2012

    Good day!

    We have stumbled upoon the same problem, using FMS(interactive edition) 4.5.1(latest version as i believe), new installation(clean windows 2008R2 install), and absolutely the same issue - after a person who was watching the live broadcast in flash media player refreshses a webpage - no crossdomain.xml is served. It can easily be seen using httpwatch or other similar tool.

    Is there any solution for that problem?

    V
    vgokhale
    Participating Frequently
    April 21, 2010

    Hi,

         Please open up port 843 on on the Windows Firewall of the Stremaing Server. Please let me know if you still face the issue.

    Thanks

          Viraj

    D
    danderyd2004Author
    Participant
    April 21, 2010

    Thanks, I tried

    to open that port as well but I have not seen any difference. I still have the problem.

    Asa_-_FMS
    Adobe Employee
    Asa_-_FMS
    Adobe Employee
    April 22, 2010

    This sounds like a packet capture is in order from the FMS side.  I'll wajor that the session to get the Crossdomain.xml isn't trying the proper port for starters and is eventually migrating to one that works only after timing out and failing.  The best way to determine this is, if you have it happening, use a tool like Wireshark to trace out the network activity.  Let us know what you find, if FMS is getting the request, but not responding in a timely manner - then it sounds like a bug.  If however, it's not getting there on time like I presume it bears network investigation.

    Asa

    Terms & ConditionsAccessibility statement
    Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices