I earlier made a note of the fact that when the MediaPlayerSprite has an FMSURL instance as its source and the useInstance flag as true. It seems to take a very long time to connect to the server. No user would stay that long on a frozen screen. I examined the FMS admin panel while I was waiting for the connection and discovered there were 2 entries for the a single client. The protocols for both though were different - one rtmp, the other rtmpt. Why was there a tunnelling call - I definitely did not offer an rtmpt URI as the FMSURL? Can someone please tell me what is happening here?
Port-protocol negotiation takes place in the NetNegotiator class. Here's a portion of the ASDoc comment for the buildPortProtocolSequence (which you can override if you want different behavior):
* Assembles a vector of NetConnection Objects to be used during the connection attempted.
* The default protocols attempted when a "rtmp" connection is specified are
* "rtmp","rtmps", and "rtmpt". When a "rtmpe" connection is requested, both "rtmpe"
* and rtmpte" protocols are attempted. When "rtmps","rtmpt" or "rtmpte" are requested,
* only those protocols are attempted. The default ports are 1935, 443 and 80. If a specific port
* is specified in the URLResource, then only that port is used.