Media Flow Controller Overview : Media Flow Controller Functions : Delivery Methods

Delivery Methods
Media Flow Controller can deliver content simultaneously to a large audience across 3 screens (PCs, TVs and Mobile devices), by supporting a wide range of delivery protocols and container formats. Media Flow Controller dynamically adapts to the change in traffic pattern across 3-screens without re-provisioning. Media Flow Controller supports on-demand and live streaming of videos and consolidates multiple delivery protocols such as HTTP, RTSP and RTMP. See Figure 2, next for illustration.
Media Flow Controller supports the entire spectrum of adaptive streaming methods for on-demand and live streaming such as Apple iPhone Streaming, Microsoft Smooth Streaming, Move Adaptive Streaming and Adobe Dynamic RTMP streaming. Media Flow Controller supports SmoothFlow™ for on-demand streaming.
Juniper Networks Media Flow Controller works with HTTP progressive download (PDL) and RTP/RTSP delivery methods.
Figure 2 Media Flow Controller Ingest and Delivery Options
Streaming with HTTP
A standard Web server streams media data with HTTP on top of TCP, which handles the data transfers. TCP is optimized for delivering non-real-time applications such as file transfers and tries to maximize the data transfer rate while ensuring stability and high throughput. One of the ways TCP achieves reliable data transfer is by re-transmitting lost packets; however, it cannot ensure that all re-transmitted packets arrive in time to be played in the media stream.
When streaming media with a standard HTTP Web server, compressed media files can be delivered just like any other HTML file in a download-and-play case; however, media players that support PDL cans start playing the audio or video while it is downloading, and retrieve the remaining data as quickly as possible.
HTTP Methods
Table 3 describes the HTTP methods supported for Media Flow Controller in Release 2.0.2.
Table 3 HTTP Methods  
Streaming with RTSP
Streaming media servers can use the HTTP/TCP protocols as well as specialized protocols such as the User Datagram Protocol (UDP). UDP does not do re-transmission or data-rate management functionality, making it ideal for transmitting real-time audio and video data, which can tolerate some lost packets. Streaming media servers can use an intelligent retransmission scheme to ensure that only lost packets that can be sent to the client in time to get played are retransmitted.
A compressed media file is produced and copied to a specialized streaming media server instead of a Web server. Data is sent to the client at the exact rate associated with the compressed audio and video streams, rather than at a set rate. The server and the client communicate during the delivery process allowing additional services to be applied.
RTSP/RTP can dynamically respond to client feedback, adjusting delivery rates appropriately, increasing the likelihood of uninterrupted viewing. Advanced features such as detailed reporting of streams played, VCR controls (seek, fast-forward, rewind), live video delivery, and delivery of multiple streams to the client are available.
Because Web server streaming typically creates a local cached copy of every media file played, there is no way to prevent end users from keeping the media. With an RTSP/RTP delivery scheme, users can only stream data and cannot download a media file directly to their hard disk.
RTSP Methods
Table 4 describes the RTSP methods supported for Media Flow Controller in Release 2.0.2.
Start playback via the transport mechanism established with SETUP
Connection Pooling
A connection pool is a list of origin-side open connections maintained so they can be reused for additional data requests. Connection pools enhance the performance of executing requests made to a dynamic database-driven Website application. In connection pooling, connections from Media Flow Controller to origin are placed in a pool and used over again so that a new connection does not have to be established from Media Flow Controller to origin for each client request for content not in cache. If all the origin-side connections are being used, a new connection is made and is also added to the pool. This cuts down on the amount of time a user must wait to establish a connection.
You use the delivery protocol CLI commands to control connection pooling.
Consistent Hash-Based Clustering and Origin Escalation
Media Flow Controller provides a configuration to use a consistent hashing scheme to bind objects to nodes using an XML file server map. Additionally, you can create an origin-server node map for origin escalation: if the target origin-server fails, another configured origin-server is automatically chosen. Both of these configurations are achieved through the creation of a server-map (format-type cluster-map and format-type origin-escalation-map) that is then associated with a namespace.
Note! Configuring the hash scheme and/or the origin server data distribution is outside the scope of Media Flow Controller.
A consistent hash scheme is used by the Media Flow Controller with the cluster-map node definitions (and, optionally namespace cluster-hash configuration) to map to the target origins. In the case where no origins exist due to network connectivity issues, an alternative set of origin servers can be consulted via an origin-escalation-map, and/or another cluster-map, to resolve the request. Consistent hash-based cluster properties are as follows:
After a node deletion, existing entries map to the same node and objects associated with the deleted node are uniformly distributed amongst the remaining nodes.
After an addition of a new node, an equal portion of the address space is remapped to the new node resulting in a uniform distribution amongst the nodes. Existing entries may be moved to the new node.
Origin escalation is a configuration consisting of <N> origin servers which are logically viewed as one, where requests are sequentially initiated to specific origin servers (based upon a configured weight), until the request is satisfied or all known available origin servers at request initiation time have been tried. An origin server request is re-initiated to the next configured origin server (escalation) when network connectivity errors are received or when a specific, configured, origin server response code is received (e.g. HTTP 404).
You can use these two server-map types together to create a server hierarchy of server-maps consisting of multiple instances of cluster-map and origin-escalation The order of in which the maps are added to the namespace denotes the order in which they are read.
See Appendix A, “Server Map Configuration,” for more details including requirements.

Report an Error
Media Flow Controller Administrator's Guide and CLI Command Reference
Copyright © 2010 Juniper Networks, Inc.