Multicasting is another way of reducing the number of streams in use. It requires a specially configured network.
Multicasting is a way of sending a single live stream to multiple clients, rather than sending a stream to every single client. Clients connect to the stream, rather than to the RealServer.
In contrast, regular unicasting transmission sends a stream to each client that requests it:
To take advantage of multicasting, both RealServer and clients, as well as the routers, switches, and other devices between them, must be multicast-enabled. For this reason, multicasting is mostly used with intranets where network devices can be configured for multicasts. However, multicast delivery can be done over the Internet where intermediary network devices have been multicast-enabled.
The live material being multicast can be a live event encoded by an encoder such as RealProducer Plus, or it can be a prerecorded live event which is broadcast by G2SLTA. Only live or simulated live content can be delivered with multicasting. Refer to Chapter 11, "Unicasting Live Presentations" for information on configuring the live source.
The following are factors in deciding whether to use multicasting:
RealServer includes two methods of multicasting: back-channel multicast, and scalable multicast. You can use both methods at once.
Back-channel multicast maintains an accounting control channel between the client and RealServer. RealServer uses this channel to provide information about the presentation and to query the client for a user name and password, if authentication is in use. The client uses the control channel to send password information and commands such as "play" and "stop". With this information, RealServer can track how many clients are viewing a presentation. Monitoring tools such as the Java Monitor in RealSystem Administrator show client activity.
Back-channel multicast can be accessed using the RTSP or PNA protocols. In this type of multicast, authenticated material, client statistics, and quality of service information can be sent because the exchange between the client and RealServer is bi-directional.
This method of multicasting uses the RTSP protocol to send control information over a TCP channel. RealServer maintains a control connection for each client. The data channel is multicast to all clients using RDT, RealNetworks data transport.
RTSP multicast provides these features:
 |
Note |
|---|
| RTSP multicasting works only with RealSystem 6 clients. |
PNA multicast uses the PNA protocol over a TCP connection to exchange information between the client and RealServer.
PNA multicast is used when transmitting to pre-G2 clients. RealServer maintains a control connection for each client. The data channel is multicast to all clients.
PNA multicast provides these features:
SureStream is not supported in PNA multicast.
Unlike back-channel multicasting, scalable multicasting does not use a control channel; thus it takes up far less bandwidth and administrative overhead and system resources on RealServer. Monitoring tools such as Java Monitor will not track client activity. Client statistics can be sent, but only at the end of the multicast or when the user stops the presentation or the RealPlayer.
Scalable multicasting enables you to transmit to an unlimited number of clients because the transmission from the RealServer is completely one-way; there is no connection from each client to RealServer at all. All data is multicast on the network once. Each client connected to this multicast receives all data packets.
It is thus suitable for situations that would otherwise consume much bandwidth.
Scalable multicasting uses a different URL format than either RTSP multicast or PNA multicast.
|
|
Note |
|---|
| This method supports version 6 and later clients only; those clients version 5 and older will not receive any presentations, and will receive an error message instead. |
Scalable multicast provides these features:
Users connect to scalable multicasts by clicking a link to a Session Description Protocol (SDP) file. This file is automatically generated by RealServer when a user clicks the scalable multicast link.
It's a good idea to enable back-channel multicast, because it applies to all streams broadcast by your Server. All client software is pre-configured to automatically try to connect in multicast mode if possible, so enabling back-channel multicast ensures that those clients that can use multicast will do so, leaving more bandwidth available for other clients.
Scalable multicast makes sense when you are broadcasting a high-bandwidth presentation, or if a large number of multicast-enabled clients will be viewing the presentation.
The following table summarizes the benefits of each multicast method.
The following table shows the multicasting methods as they apply to clients.
| Back-Channel Multicast | Scalable Multicast |
||
|---|---|---|---|
| Feature | RTSP | PNA | |
| RealSystem version 6 clients only | · | · | · |
| Older clients | · | ||
| RealSystem 6 clients or any RTP-enabled clients | · | ||
You can only take advantage of multicasting (either type) on networks that are multicast-enabled. If you are not certain whether your network is set up for multicasting, contact your network administrator.
This section describes the ways in which multicasting works together with other features.
Multicasting only broadcasts live events; on-demand files cannot be multicast.
Both types of multicasting allow clients to switch to unicasting if the multicast becomes unavailable for some reason. In back-channel multicasting, this happens automatically; for scalable multicasts, you must set up this feature explicitly. Refer to "Using Unicasting as a Backup Method" for instructions.
As with all live broadcasts, you can configure RealServer to automatically create on-demand archived files of live multicasts.
A multicast uses a live encoded event as its source; this can be an in-process encoded event or it can be a simulated live event created by G2SLTA using on-demand clips.
Use receivers to send data across the Internet to intranet sites, wide area networks, or local area networks, and then configure the receivers to multicast the streams to clients within the intranet. Clients will receive a multicast from the receiver.
Receivers cannot receive the source material using multicast, but when they re-transmit the material to clients, they can use multicast.
 |
Additional Information |
|---|
| Read Chapter 12, "Splitting Live Presentations" for information on setting up splitting. Push splitting and pull splitting can be used with both back-channel and scalable multicasting. |
There are four stages to configuring a combination of splitting and multicasting:
Depending on how the network is configured and the streams are listed in RealServer, clients whose requests are forwarded by a RealProxy may receive different results.
RealProxy cannot join a multicast. Instead, it will try to receive the multicast using pull splitting. If pull splitting is enabled on the source RealServer, the RealProxy will use that broadcast, instead of connecting to the multicast. The client will receive the broadcast in unicast mode. If there is a multicast-enabled network between the RealProxy and the client, the RealProxy can be configured to re-send its pull split stream via multicast instead.
|
|
Additional Information |
|---|
| Refer to RealProxy Administration Guide for information on configuring RealProxy. See http://service.real.com/help/library/index.html. |
Multicasts usually take place within an intranet, where broadcasts are not travelling outside a firewall. If a multicast is occurring through a firewall, the firewall must be specially configured to allow multicast traffic.
As with all delivery methods, RealServer verifies that the client requesting a broadcast is allowed to receive it before proceeding to send the multicast.
In scalable multicasting, the user connects to the multicast via an automatically created SDP file. If you include the authentication mount point in the link (/secure/), RealServer will verify the user's identity when the user clicks the link to the SDP file.
However, if the user saves the SDP file, she will not go through the authentication process if she later uses the saved SDP file to connect to the multicast.
In back-channel multicasts, you can see the clients that are connected, just as with regular unicasts.
Clients who are viewing a presentation via scalable multicast will not appear in the Java Monitor.
Material served via back-channel multicast appears in the access log just like unicast material. The access log shows which method was used to transmit the stream.
Scalable multicasts can be identified in the access log by their mount point in the GET statement. If RealServer is configured for requesting client statistics (see "Controlling Client Statistics"), the log file will also contain statistics for each client.
RealNetworks' implementation of multicasting is based on open industry standards. You may be interested in the following resources:
Before you set up either type of multicasting, you need to do two things:
Once you have the network configured and have determined which addresses you'll be using, the next steps are:
Before setting up RealServer, verify the following items with your network administrator:
In addition to network settings, for clients to take full advantage of multicast transmissions, they must be configured to request multicast transmission of live material. Consult the client software's user guide for information on configuring the client.
As noted earlier, both RealServer and clients, as well as the routers and all other network infrastructure between them, must be multicast-enabled in order for you to distribute presentations using the multicast features. This section describes only what is required to enable RealServer for multicast broadcasting.
There are two factors to take into account when establishing the addresses and port numbers that RealServer will use for multicasting:
Although the information in this document will help you calculate the number of addresses and ports you'll need for scalable multicasting, you'll still need to consult with your network administrator regarding the actual IP addresses you'll use.
For each clip that you are transmitting via multicast, you must calculate the number of addresses you'll need. The number of addresses is based on the number of bit rates in the SureStream clip.
In scalable multicasting, you'll also need to set aside port numbers; these are based on the number of streams per bit rate.
For single rate RealVideo files, figuring the number of addresses and port numbers is relatively simple. SureStream clips are more complex, as they can contain several bit rates, each with its own number of streams.
If another person is supplying the file to be multicast, that person will need to tell you how many bit rates are in the file. For scalable multicasts, you will also need to know how many streams per bit rate are present.
You can get these numbers yourself if you are encoding the file; look in the encoding software to learn the number of bit rates and streams. For example, in RealProducer Plus, you would click View>Statistics to see the number of bit rates and streams being encoded.
Once you know the number of bit rates and streams in the file, refer to "Calculating Addresses for Back-Channel Multicasts" or "Calculating Addresses and Ports for Scalable Multicasts".
If you have no way of knowing how many bit rates and streams are in the file, you'll have to guess. A safe number is six; the maximum number of bit rates that would be present in a single SureStream file is 14, yet files prepared for multicasts are likely to include only the higher encoding rates. A non-SureStream file would have at most one bit rate and two streams.
If you are preparing to transmit a file via back-channel multicast, you only need to know the number of bit rates in the file.
| Bit Rates | Addresses |
|---|---|
| 1 | 1 |
| 2 | 2 |
| 3 | 3 |
| ... | ... |
| n bit rates | n |
Figuring the number of addresses and port numbers for scalable multicasts depends on several factors.
An audio presentation consumes one stream; a video presentation uses two streams (one for audio and one for video). For highest quality, and to match the scalable multicast RTP specification, RealServer uses one address for each stream.
RealServer includes a feature that enables you to send the audio and video streams on a single address. Use this feature if you want to conserve the number of addresses you're using. Use the dual address method if you know that clients viewing the presentation may be using a low bandwidth connection and the clients are able to select a single stream, such as just the audio portion of your multicast.
Each address must use a certain range of port numbers. The numbers you choose can begin with any number, but the first port number must be an even number, and you must use a consecutive range. (RTP is used to send the data; the RTP standard requires this format.)
In the table below, n represents the number of bit rates in the file that you'll be multicasting.
Another way of calculating the number of ports needed is as follows:
No, the number of ports is 2 x addresses.
Yes, the number of ports is 2 x addresses x streams.
You can publicize your multicasts to anyone running a program that listens for the Session Announcement Protocol (SAP). These applications, such as SDR and ICAST Guide, display a list of all multicasts currently playing. RealServer creates the SAP file automatically. Programs that listen for SAP announcements will show the title, author, and copyright information encoded into the files you are multicasting.
This feature is optional; you do not need to configure it in order to use multicasting.
Yes. This instructs RealServer to create and send SAP files. The default value is No.
Yes. The default value is Yes.
If your machine has multiple network interface cards (NICs) and you want to ensure that RealServer always uses a particular NIC for multicasts, use your operating system to set a default address. In Windows NT, set the Bindings feature. In UNIX, use the route command to associate the multicast route with the appropriate NIC.
Multicasts do not use the settings in the IP Bindings list (described in "Distributed Licensing").
Follow the instructions below to set up back-channel multicasting. After you set it up, you will need to create the links that point to your multicasted events.
Instructions in this section describe how to set up RealServer for back-channel multicasting.
|
|
Note |
|---|
| These instructions describe only the steps required to set up this feature. For more options, see "Optional Back-Channel Multicasting Features". |
Yes from the Enable Multicast to turn on this feature.
7070.
554.
|
|
Additional Information |
|---|
| Refer to "Calculating Addresses for Back-Channel Multicasts" to determine the exact number of addresses you'll need. |
The value for Time to Live can range from 0 to 255. The larger the Time to Live, the greater the distance a data packet can travel.
The default value of 16 is enough to keep multicast packets within a typical internal network.
| TTL Value | Packet Range |
|---|---|
0 |
Local host |
1 |
Local network (subnet) |
32 |
Site |
64 |
Region |
128 |
Continent |
255 |
World |
True from the Resend list. This setting is optional. It adds some overhead to the traffic on your network; however, clients receive better quality multicasts.
Any
|
|
Additional Information |
|---|
| You can customize this list to reflect the addresses of specific users or ranges of users; see "Listing Ranges of Authorized Clients". |
Links to both RTSP and PNA multicast are identical to links for live unicast transmissions. This is convenient, because a single link can serve both multicast-enabled clients and unicast-only clients.
Most clients on a multicast-enabled network are configured to request material via multicast first, as this makes the most efficient use of bandwidth on your network.
Just as in links to other live content, the link to a back-channel multicast has the following format:
http://address:HTTPPort/ramgen/encoder/path/file
Links typed directly in RealPlayer or used in a Ram or SMIL file use the following format:
rtsp://address:RTSPPort/encoder/path/file
The format is nearly the same as the link used in the Web page: the protocol is different, the port number (if any) matches the protocol, and Ramgen is omitted.
The following features are available for back-channel multicast:
Session Announcement Protocol (SAP) information can be sent over the multicast-enabled network to announce your scalable multicast. See "Publicizing Your Multicasts" for instructions on configuring this option.
Clients whose addresses are listed in this section will use back-channel multicast to receive their clips.
|
|
Note |
|---|
| Access Control rules are enacted before User List rules. A client that is excluded by Access Control will not be able to connect to any multicasts, regardless of the rules you create here. (IP Access Control is described in "Limiting Access with the IP Address".) |
You can require that clients connect to your broadcast in multicast mode, and make unicast unavailable.
|
|
Note |
|---|
| A client may be unable to connect in multicast if it is not configured to use multicast transports, or if its network is not multicast-enabled. |
Normally, clients try to receive a broadcast in multicast mode, but if that is not available, the clients will use unicast mode instead. By requiring multicast, you can control bandwidth on your network.
Yes.
Clients that are not configured for multicast will not be able to receive the multicast, and will receive an error message instead. Use this feature when you are multicasting to a limited number of clients that you know can use multicast, or if you are multicasting a high-bandwidth presentation and do not want unicast to be an option.
Just as in other live delivery methods, you indicate which live broadcasts are available for delivering in this format. In scalable multicasting, however, the settings that you configure for each live event are known as a live channel.
Perform the following steps for each live broadcast that you will be transmitting via scalable multicast.
In addition, you can configure some optional features:
All scalable multicasts use the following setting:
scalable. Locate by clicking Multicasting>Scalable in RealSystem Administrator.
Other settings are used, but they are different for each live channel. They are defined in the next section.
|
|
Note |
|---|
| The steps in this section set up a live channel. You'll need to know which addresses are available to you and how many to use; see "Determining the Number of Required Addresses and Ports"These instructions describe only the steps required to set up this feature. For more options, see "Optional Scalable Multicast Features". |
A generic channel name appears in the Edit Channel Description box.
Yes from the Enable Channel list.
 |
Tip |
|---|
To make all live broadcasts available via scalable
multicast, type an asterisk (*) here.
|
False if you want to use a separate address for each stream; select True if you want to use one address for both streams.
|
|
Note |
|---|
| A video clip contains two streams: one each for audio and video. Refer to "Determining the Number of Required Addresses and Ports" for complete information. |
Scalable multicasts use a different URL format than other material; when RealServer receives a request in this format, it sends the material differently and does not expect to establish or maintain a TCP connection. Instead, RealServer automatically creates an SDP (Session Description Protocol) file. SDP is a standard file format that contains information such as the multicast address and port, and the title, author, and copyright information.
The client receives this file when the user clicks the link to the scalable multicast. The Web browser downloads this file and sends it to the RealPlayer client software. The client software reads the contents of the file and connects to the scalable multicast.
A user can save the SDP file to disk (by right-clicking on the link in the Web page) and use it to connect later (by opening it with RealPlayer), and skip the step of downloading it from your RealServer.
All links to scalable multicast content use the same format. Note that they always begin with http://and always end with the .sdp extension:
http://address:HTTPPort/scalable/path/file.rm.sdp
| Component | Meaning |
|---|---|
http |
The protocol used to initiate streaming. |
address |
Address of RealServer; IP address or machine and domain name. |
HTTPPort |
Port number where RealServer listens for requests sent via HTTP. This value is usually 80 or 8080; see "Port Numbers". |
scalable |
Scalable mount point, usually /scalable/. |
path |
Optional. |
file |
The file name itself. |
rm |
The file type or extension, such as ra, rm, or rt. |
sdp |
The .sdp extension is required for scalable multicast. |
A link would look like the following:
<a href="http://realserver.example.com:8080/scalable/vivaldi.ra.sdp">
Click here to listen to today's Vivaldi selection</a>
The same link, if typed directly in RealPlayer or included in a SMIL file, would have the same format.
Notice that the mount point /ramgen/ is not used.
The settings in this section are optional, and can be set for any live channel:
Session Announcement Protocol (SAP) information can be sent over the multicast-enabled network to announce your scalable multicast. See "Publicizing Your Multicasts" on page 195 for instructions on configuring this option.
When clients that are not multicast-enabled click the link to your scalable multicast presentation, they receive an error message. An error message also appears on a client screen when the multicast itself is interrupted at any point along the network. In both cases, the presentation halts.
The shift to unicast feature reconnects the client to a unicast version of the presentation automatically. You can also use this feature to customize the message those clients receive, or even redirect them to a multicast or unicast presentation. This backup presentation can be located on the same RealServer or on another RealServer.
You need only supply a single URL for your multicast if you enable this feature, rather than supplying a second URL for the unicast version.
You can enable this feature for individual live sources.
Do not enable this feature if you are multicasting a high bit-rate presentation where switching to unicast would flood your network.
Yes. The default value is Yes.
In cases where clients would receive a generic error message informing them that the multicast was unavailable or available only to multicast-enabled clients, you can instruct RealServer to point the client to your own HTML page. Use your HTML page to post a custom message, such as "This presentation is only available to RealPlayers that have been configured to use multicast."
http://www.example.com/mcast.html.
If you have a second RealServer which is transmitting the same broadcast, but in unicast, you can supply the source RealServer with the address of the second RealServer, and clients who are unable to receive the multicast presentation from the source RealServer will automatically be sent to the second RealServer.
Clients who cannot connect will be sent to the second RealServer, rather than receiving an error message and then halting the presentation.
|
|
Note |
|---|
| The steps in this section are the same as in "Creating Custom Messages"; use either an alternate URL or a custom HTML page per scalable multicast. |
rtsp://realserver.mycompany.com:554/encoder/vivaldi.rm
Clients such as RealPlayer have a feature that can send statistics to RealServer about the amount and quality of data they received while playing a presentation. The type of data sent by the client is controlled by RealServer's Stats Mask setting.
As in unicast presentations, client statistics are sent to RealServer at the end of a presentation, and are stored in the access log. But scalable multicasts can serve to thousands of clients at the same time, and your RealServer may not be equipped to handle that quantity of simultaneous incoming client statistics.
RealServer includes features that help you manage two aspects of client statistics sent at the end of a scalable multicast:
You can instruct clients not to send any data (set both Logging Style and Stats Mask to 0), but RealServer will still create a record for each connection, though it will record minimal data. (See the "Logging Style Effect on Access Log" table.) These settings will affect all material served by RealServer.
For scalable multicasts, RealServer has a feature that can instruct clients to not send any connection statistics at all. Enable this feature if your system cannot handle the volume of packets of data that would be sent simultaneously, or if you are simply not interested in these statistics.
In scalable multicasts, clients send statistics using an HTTP post.
Yes if you want clients to send their connection statistics at the end of a multicast presentation. Select No if you do not want clients to send any connection statistics.
/scalable/ is on the list.
When clients initially connect to RealServer for a scalable multicast presentation, RealServer can instruct them to send connection statistics to a Web server, rather than to RealServer. Web servers may be better equipped to handle volumes of simultaneously arriving data, since they are often configured to perform load balancing.
To use this feature, you will need to have a Web server available to you, and you will need to create a CGI script to receive the client statistics and to write them to a log file.
The statistics sent by the client to the alternate location are a subset of the statistics normally recorded in the access log. They have the following format (terms are defined in Chapter 19, "Reporting RealServer Activity"):
[Stat1][Stat2]#sent_time
The # symbol is used as a separator.
After the multicast event, you can look at the log file created by the cgi script and draw conclusions about the quantity of clients and quality of service.
Yes.
cgi-bin/client-stats/logstat.
/scalable/ is on the list.
RealServer 8 uses a slightly different file format for SDP and SAP files than earlier versions of RealServer. The new formats can be read by client software that is SDP-capable client (such as SDR). The old formats can be read by all versions of RealPlayer, but not from SDP-capable clients.
If you know that users will be viewing multicasts from a saved SDP file (instead of by clicking a link in a web page), and you know that they are using SDP-capable multicast clients, you will need to add a setting to your configuration file so that RealServer sends the SDP file in the new format.
In the <List Name="Scalable Multicast"> list, and within the particular channel name, add the line <Var DefaultSdpFileType="new"/>. For example,
<List Name="Scalable Multicast">
<Var MountPoint="/scalable/"/>
<List Name="Sources">
<List Name="Channel1">
<Var DefaultSDPFileType="new"/>
...
</List>
If you change this value to old, the SDP file can only be used by RealPlayer client software. Since you can make only one choice, there is also an option to override the configuration file setting by adding a switch to the URL. The switches are:
?SDPFileType=old?SDPFileType=new
The switch is appended to the end of the URL: http://realserver.example.com:8080/scalable/concert.rm.sdp?SDPFileType=new
You might want to create two links, one for each SDP file type.
If you configured multicasts to be announced with automatically-generated SAP files, (as shown by the AnnounceSAP variable in either the scalable or backchannel multicast lists), you can also make the SAP variables include information that can be read by SAP-capable clients. Add the <Var SDPFileType="new"/> variable to the <List Name="SAP"> list. For example:
<List Name="SAP">
<Var SendAnnouncementEnabled="1"/>
<Var ListenAnnouncement="1"/>
<Var HostAddress="172.23.100.113"/>
<Var SDPFileType="new"/>
</List>
The possible values for this variable are new, old, or both, where the value indicates which file format to send. Choosing both means that new and old versions of the SAP file will be sent; this option results in slightly more overhead.