↑ Introduction

Streaming relays and reflectors can be used to scale streaming infrastructure by distributing load between servers and making the most efficient use of network bandwidth. A streaming reflector “tunes in” on and incoming stream and relfects it to clients. The most common setup for a reflector is reflecting a live streams as (see the section on Live Webcasting). A streaming relay forwards an streams from a source to a destination server. One of the primary advantages of relays is segmentation of network traffic. Clients can tune in on relays that make most effective use of limited network resources instead of loading a single network segment with streaming traffic.

One of the easiest ways to distribute load between a group of servers is to reflect a multicast stream. This requires a multicast enabled network between the broadcaster/encoder and the streaming servers (see terminology below). The multicast .sdp file from the broadcaster/encoder simply needs to be placed on each streaming server. When clients open an rtsp stream to the multicast .sdp file from a server, they will receive a reflected unicast of the multicast stream. Using this method, a number of servers can reflect live webcasts. Combined with load balancing this technique can be used to distribute load for live streaming across a group of servers (a simple cgi for load balancing is presented in the Using CGI section of this site).

↑ Terminology

Network Bandwidth is the capacity of the network to move data. Bandwidth is measured in bits-per-second. Analog modems over telephone lines have a capacity of up to 56 kilobits per second. Because digital video files are large (read below), video streamed over 56 kilobit modems will be low quality. Higher quality video requires a broadband connection. Broadband generally refers to a network connection that can sustain at least 200 kilobits per second. The table below outlines the maximum bandwidth of dedicated Internet connections:

Unicast packets on typical IP networks have a single source and destination. Most traffic on IP networks between clients and servers on today’s networks is unicast. Multicast packets have a single source and multiple destinations. Multicast packets can save network bandwidth when multiple clients need to view the same streaming media simultaneously. Instead of sending out individual unicast packets to each client, a single stream of multicast packets can be viewed by multiple clients.

Today’s commodity Internet does not support multicast (Internet 2 does). The capacity of a streaming server is frequently limited by the bandwidth of the network connection. The table below summarizes the maximum number of 500 kilobit Unicast streams supported by the dedicated Internet connections listed above:

A single Xserve running QuickTime Streaming could saturate a T4/DS-4 connection. Faster connections would require additional servers set up as reflectors and relays to support more simultaneous Unicast streams.

A streaming relay server requests a stream from a broadcast or video on demand server and relays the stream to clients. Streaming relays can be used to relay live multicast streams as unicast streams or visa-versa. Relays can also be used to connect clients to streams on a local server, lowering streaming media traffic across IP Routers.

Note, content replication and content caching servers can also be used to reduce streaming network traffic. By replicating content files closer to clients, traffic across IP Routers can be minimized. Content caching servers intelligently replicate content based on client requests. This can be accomplished without relays or reflectors, which are more appropriate for live streams.

↑ Sample Relay Deployment

The following diagram illustrates a network environment with streaming servers and relays. In this diagram:

• Two primary servers are placed on the campus backbone (Internal Campus servers). One server is for production, the other is for testing/backup of the primary.
• Each subnet has it’s own streaming server (subnet A shown). The primary servers are configured to relay live streams to the subnet servers. Clients on the subnet tune into the local subnet relay, reducing traffic across the subnet routers.
• An external streaming server is placed in the network DMZ for publicly accessible content.
• Each remote campus has a streaming server that replicates video on demand content from the primary campus servers, and function as relays to reduce traffic across the Internet router/firewalls.

↑ Relaying from Server to Server

Relay Sources:

In the diagram above, the Primary Server will be configured to relay live/playlist streams to servers on each subnet and remote campus. Every relay has a source and a destination. Using Server Admin in Mac OS X Server, the Relay Source can be configured by creating a new Relay or in the web based administrative interface of QuickTime/Darwin Streaming Server:

Server Admin on Mac OS X Server/QuickTime Streaming Server

Web Administration on QuickTime/Darwin Streaming Server

The source for the relay can be:

1. Request Incoming Stream:

   The stream will be requested from the source. If the source is a .sdp file on the local machine (127.0.0.1), no username and password needs to be specified. If the source is another streaming server, you must specify the administrative username and password of that server.

2. Unannounced UDP:

   The stream will be received on a specific IP address and port. The IP address of the live encoder and port numbers must be entered. Note: there is no GUI in the web administrative interface for this source type.

3. Announced UDP:

   The server will start relaying when a new stream is announced on the source IP address. This source requires an encoder that supports “Automatic Unicast.”

It is very common for the local server (127.0.0.1) to be the source of any of the relay source types above.

Relay Destinations:

Each relay can have one or more destinations. Incoming streams from the source will be sent to the destination. Each source can have one or more destinations. Using Server Admin in Mac OS X Server, the Destinations can be configured by adding them in the Destinations pane of a relay or in the web based administrative interface of QuickTime/Darwin Streaming Server:

Server Admin on Mac OS X Server/QuickTime Streaming Server

Web Administration on QuickTime/Darwin Streaming Server

The destination(s) for the relay can be:

1. Announced UDP:

   The RTSP announce protocol will be used to automatically generate the .sdp file on the destination. This is a convenient way to automatically propagate .sdp files on the destination. Note: If your relay source and destination have firewall restrictions or network congestion, this technique is not recommended – this technique requires an active session between source and destination.

2. Unannounced UDP:

   Packets will be sent to the specified IP address and port number. This method requires manual generation of the .sdp file on the destination. This technique does not require a session between the relays, and is a better choice when firewalls or network congestion may be factors. The source .sdp file can be used as a starting point for the manually generated .sdp file on the destination. The following lines must be edited in the .sdp file:

   • The line that begins with “c=IN IP4” should be edited with the destination server’s IP address.
   • The first line that begins with “m=” should use the port number specified in the destination relay.
   • The second line that begins with “m=” should use the port number + 2 specified in the destination relay.

↑ Configuring a Unicast to Multicast Relay

It is possible to relay an incoming stream as a multicast stream. The following procedure outlines the steps required for this configuration:

1. Set up a multicast relay on the streaming server. This relay will be configured with the IP address of your Broadcaster/Encoder as the “Source Hostname or IP Address:”, the <broadcastMountPoint> specified in step 2 below as the “Mount Point:”. Check “Wait for announced stream(s)” if you are using Automatic Unicast on the Broadcaster/Encoder. The “Hostname or IP Address:” for the destination must be a valid multicast address. Select “Relay via UDP” and set the base port to an even number (something in the 9000-9996 range works well). The multicast TTL is the number of router hops the multicast will work through. Set this for the topology of the network you are working on. The server must also be configured to accept an announced broadcast. This can now be done from QTSS Web Admin General Settings by clicking on “Change Movie Broadcast Password…”
   Note: If you are not using a Broadcaster/Encoder that supports RTSP Announce, you can set the source to 127.0.0.1, select “Request Incoming Stream” and set the mount point to the path to the Unicast sdp file. The unicast sdp file must be manually copied to the server from your encoding software or device. No username and password is necessary if you use the loopback address. The mount point is relative to whatever you specify as your Movies directory.
   
2. Set up QT Broadcaster to send an “Automatic Unicast (Announce)” to the server. The “File:” you specify in broadcaster should include the “.sdp” extension – for example “webcast.sdp”. After you start the broadcast, test accessing it from the server by accessing the url rtsp://<serverIP>/<broadcastMountPoint> from QT Player. You will be tuning in on a Unicast relay of the stream.
   Note: If you are using a software/hardware encoder that does not support RTSP Announce, you must generate the Unicast sdp file and copy it to the Movies directory on the server.
   
3. To tune in on the multicast relay, you have to make a copy and edit the .sdp file that is created by the announced broadcast and or copied manually as outlined above. After you complete step 2, you should see a file with the name you specified in your streaming server’s Movie directory. Copy this file (see step number 4 below for options on where you might want to place the copy). Edit the copy of the file. Look for the line beginning with “c=IN IP4” (at the top of the file). Change the IP address to the multicast IP address specified in step 1 above. Next look for the first line beginning with “m=”. Usually this is m=audio. Change the 0 to the base port you specified in 1 above (i.e. 9000). Look for the next line beginning with m=. Usually this is m=video. Change the 0 to the base port + 2 (i.e. 9002).
   
4. The multicast sdp file can be accessed via ftp, http, from a file server, or e-mailed to clients. It cannot be accessed directly from the QTSS process. Save the file where it can be accessed via http or ftp, from a file server, or e-mail it to clients. I usually put it on a web server (see note below on mime types). If you place the file on a http or ftp server, you can access the multicast from QuickTime Player by using the url:

   http://<webServerIP>/<pathAndFileNameOfsdpFile>

   or

   ftp://<ftpServerIP>/<pathAndFileNameOfsdpFile>

   If you put the multicast sdp file on a web server, or e-mail it to clients, they can just open up the sdp file with QuickTime Player. Note that sdp files are often associated with Real Player – you might have to drag and drop the file or use File-Open from QT Player.
   Alternatively you can open up the sdp file or URL with QT Player Pro, save the file as a self-contained .mov file, send this to clients, embed in a web page, etc.

Closing Notes:

If you keep the name of the broadcast sdp file the same, you can stop and start new broadcasts using the same name. However, you will have to do steps 3 and 4 above for each new broadcast if you change any broadcast parameters that are reflected in the .sdp file. The steps outlined in steps 3 and 4 could be automated by a cgi or other script.

If you place the multicast sdp file on a web server, the mime type needs to be configured properly on the web server: