Chapter 12: Splitting Live Presentations

Splitting is a method of sending live broadcasts to other RealServers, rather than to clients. These other RealServers, configured as splitters, re-broadcast the streams to clients. By replicating streams close to users, clients receive high quality content, bandwidth usage is minimized, and audience size is maximized.

Overview

The RealServer where the live material originates, called the source RealServer, makes its live broadcasts available to other RealServers, called splitters. A splitter is simply a RealServer configured to re-broadcast streams that originate on another RealServer. Links on Web pages point to the splitter, rather than to the source. When a user clicks the link, the splitter recognizes the special URL and relays the stream from the source RealServer to the client.

For example, a concert from Japan can be broadcast over the Internet to RealServers in Australia and North America. Users in those cities connect to the closest RealServer, thereby getting better media quality and using less network bandwidth.

While serving content that originated on another computer, a RealServer-whether a source or a splitter-can still stream its own content. And because it's no longer serving to all the clients, it has more connections available for streaming its own content.

The live material being served and split can be a live event encoded by an encoder such as RealProducer Plus, or it can be a pre-recorded live event which is broadcast by the G2SLTA utility. Refer to Chapter 11, "Unicasting Live Presentations" for information on configuring the live source.

Illustration of Splitting

Web pages listing the event has different links for different locations:

Sample Web Page, Linked to a Push Split Broadcast

When to Use Splitting

The following are factors in deciding to use this feature. They are not necessarily requirements, but are important in making your decision.

• Your users are connecting to a broadcast from geographically separate locations

• You have more than one RealServer at your disposal

• You can configure the other RealServers, or can communicate with the administrators of those RealServers

• You, or the administrators of the other RealServers, can modify Web pages and create links so that users can access the other RealServers.

Splitting Methods

There are two types of splitting: push splitting and pull splitting.

Push splitting maintains a constant connection between the source and each splitter, which leads to faster connections for the first client that requests a split stream. The source sends all its live broadcasts to the connected splitters.

In pull splitting, the source RealServer doesn't transmit any streams to the splitter until the first client makes a request.

Both splitting methods support SureStream bandwidth-negotiated files.

Each method uses its own link format.

Push Splitting

In push splitting, the source RealServer and the splitter are in constant communication. As soon as the source RealServer begins streaming a live feed from an encoder, it sends the broadcasts to all splitters.

When a client requests a broadcast from the splitter, a connection has already been established between the splitter and RealServer, and the broadcast is delivered to the client immediately.

You can selectively split live broadcasts with push splitting. You can choose to split all broadcasts, or just a few. Of course, users can only play the broadcasts for which a link has been created.

Pull Splitting

In contrast to the constant communication in push splitting, the connection between the source and splitter in pull splitting stays quiet until a client makes a request, thereby using less bandwidth. When the splitter gets a request for the live broadcast, it opens a connection to the source. RealServer sends the broadcast to the splitter, which in turn broadcasts it to the client.

Unlike push splitting, in this form of splitting you cannot specify which broadcasts on the source RealServer can be split. If you enable pull splitting, you enable it for all live events on your RealServer. In practice, however, users can only play the broadcasts for which a link exists.

Configuration for pull splitting entails fewer steps than push splitting.

Choosing Which Splitting Method to Use

The splitting method you choose-push or pull-depends on the frequency and types of connections you anticipate from users.

Using Push Splitting and Pull Splitting Together

You can combine these methods to make the best use of your bandwidth.

Use of push and pull splitting can be divided according to time zones, for example. Use push splitting to send an event to splitters in the same or nearby time zones, and make pull splitting links available to users in time zones on the other side of the world, where potential viewers are likely to be asleep.

Push splitting is best suited for popular events, when you know all the splitters will be accessed.

Pull splitting is suitable for smaller events, for local or smaller audiences.

Controlling Splitter Access to the Source RealServer

In both push splitting and pull splitting, you can limit which splitters can access your source RealServer by adding the splitters' addresses and port numbers to the Access Control list. For information on the access control list, see "Limiting Access Via IP Address".

In addition, the source RealServer maintains a list of push splitters that are allowed to requests its broadcasts. For more information, see Step 8. The Access Control list (if any) is also limiting access. The Access Control list takes precedence over the Splitter Control List. If you are using Access Control, be sure that you have a rule that allows splitter access on the HTTP port, as push splitters make requests using this port.

Using Splitters as Sources

While serving as a splitter for material originating on a source RealServer, a splitter can also serve its own content, using the standard broadcasting and on-demand streaming methods. To set up a splitter to also act as a source, first set up the splitter portion, using the steps in "Setting Up the Splitter for Push Splitting". Then set it up as a source, using the instructions in "Setting Up the Source for Push Splitting".

You may also be interested in the daisy-chaining feature, in which each splitter acts as both splitter and source for the same material. Refer to "Chaining Splitters" for information.

Splitting and Other RealServer Features

This section describes the ways in which splitting works together with other features.

On-Demand Streaming and Splitting

Neither splitting method works with on-demand streaming; splitting only delivers live broadcasts. You can use G2SLTA to convert on-demand clips to live broadcasts. See "G2SLTA and Splitting" later in this section.

Live Unicasting and Splitting

Unicasting can happen automatically from a source or a splitter-when you create a link that points directly to the stream on the source, you're using unicasting. In the diagram titled "Illustration of Splitting", the three clients shown in the upper right are receiving unicasts from the source RealServer in Japan.

Multicasting and Splitting

By combining splitting with multicasting you can make efficient use of bandwidth. See "Splitting and Multicasting" in Chapter 13, "Multicasting Live Presentations" for information and an illustration.

Live Archiving and Splitting

Splitters cannot archive broadcasts they receive from a source RealServer. If you want to archive a broadcast, you must archive the live broadcast on the source RealServer.

G2SLTA and Splitting

You can use a live event as the source for your split broadcast, or you can use G2SLTA to simulate a live event from a pre-recorded clip. Using G2SLTA can be a good way to test your splitter configurations before you broadcast the real event.

RealProxy and Splitting

RealProxy cannot cache live broadcasts, because there is no actual file to cache. But RealProxy includes an ability to "share" live streams among clients, and thus reduce the bandwidth required from a source RealServer. They communicate through pull splitting; RealServer is pre-configured to act as a source, and RealProxy is automatically set up to act as a pull splitter.

Firewalls and Splitting

The source and the splitter use UDP for fast, efficient communication, but some firewalls do not allow this type of traffic. If your source RealServer and the splitter are on opposite sides of a firewall, change the Protocol option to TCP.

	Additional Information
	Firewalls, and the best arrangements of sources and splitters, are described in "Communicating with Splitters Behind Firewalls".

Access Control and Splitting

As with other features, RealServer uses the rules in the Access Control list to determine which systems can receive broadcasts. In addition, push splitting has its own Splitter Control List, which lists the splitters that are authorized to receive broadcasts from the source RealServer.

Authentication and Splitting

If you are sending a stream to a RealServer that is acting as a splitter, you must put copies of all the databases that store authentication information on the splitter. This distributes the authentication load.

Monitoring and Splitting

If your RealServer is a source, Java Monitor will display only the splitter's connection to the source. Individual client connections to a splitter are shown on the splitter's Java Monitor.

Once a source RealServer is configured correctly for push splitting, the Files tab of Java Monitor will show the message:

"farm/givemeallyourstreams.IP.port", where IP is the splitter's IP address or name as typed in the Host Name or IP Address box of the Push Splitter page, and port is the splitter's port as specified in the Port box of the same page. The message will be incremented at the interval shown in the splitter's Probe Interval box.

Reporting and Splitting

On source RealServers, the access log does not show any records pertaining to the splitter connections. However, if the same event is encoded to multiple RealServers, (described in "Using Backup Sources"), records will be created in the source RealServer's access log.

On splitters, the access log contains records for each clip delivered, and shows the splitting mount point.

If you use push splitting, and have a lot of live events being split, the access log will fill up quickly. With pull splitting, the access log records will be fewer, as pull split streams are only delivered when requested by splitters. (Push splitting continually sends out all available live presentations.)

Any errors in setting up a source or splitter will appear in the error log file.

Setting Up Both Types of Splitting

In both push splitting and pull splitting, there are four main steps. The person who administers the source and the person who runs the splitter may be the same person, but they are treated as separate people for purposes of clarity.

1. Configure the source RealServer.

2. Configure the splitter RealServer.

3. Create the links.

4. Start encoding the live event. This is described briefly in Chapter 4, "Sources of Content".

Administrators for the source and the splitter in push splitting need to discuss the settings each of them is using. The source RealServer needs information about the splitter, and the splitter needs information about the source. Those shared values are shown at the end of each set of instructions.

In pull splitting, the source administrator needs to supply some information to the splitter administrator so she can create the links properly. The splitter administrator does not need to give information to the source administrator.

Setting Up Push Splitting

If you are administering the source RealServer where the broadcasts originate, use the steps in "Setting Up the Source for Push Splitting". If you are setting up the splitter, follow the steps in "Setting Up the Splitter for Push Splitting"to configure the splitter and create the links to the split broadcasts.

	Note
	If you are using Access Control to limit the splitters, encoders, or clients that can contact your RealServer, be sure that your Access Control rules permit splitters to contact the HTTP Port. Otherwise, splitters will not receive content from this source even though splitting is configured correctly. See "Controlling Splitter Access to the Source RealServer" for more information.

Setting Up the Source for Push Splitting

Before you can set up the source RealServer for push splitting, you will need to contact the splitter administrator and find out what value she is using for Host Name. You will use this in setting up the Splitter Control List.

In the example used in this chapter, the source RealServer is in Japan.

	Note
	These instructions describe only the steps required to set up this feature. For more options, see "Optional Push Splitting Features".

To configure the source RealServer for push splitting:

1. In RealSystem Administrator, click Splitting. Click Push Source.

   

2. The Mount Point box refers to the mount point the splitter administrator will use in the links to split content. If you change this from its default value of /farm/, be certain to inform the splitter administrator.

3. Type the name or IP address of the machine on which this RealServer is running in the Host Name or IP Address box. RealServer uses this value to identify itself when it sends a live broadcast to a splitter.

4. From the Protocol list, select the protocol to use in sending live data to splitters. The default is UDP. Choose TCP if you are splitting through a firewall (this will produce a connection that can be broken, disturbing the broadcast; it also takes more overhead).

5. In the Resend Buffer box, type the size of the buffer (in seconds). It can range from 0 to 32767; a recommended value is 30.

   The source maintains a buffer of data packets to use if the splitter makes resend requests. If you set this too high for your system, the source may try to use more memory than is available. Set it too low, and the source cannot recover lost packets. If your live stream is a high bit-rate stream, choose a smaller number for the buffer.

6. Limit how many seconds RealServer will wait before it stops sending data to a splitter that is not responding, by typing a value in the Timeout box. A recommended value is 30.

7. Select Yes in the Split All Streams list to indicate that all live broadcasts from this RealServer will be delivered to splitters.

   	Additional Information
   	To restrict which broadcasts can be split, refer to "Splitting Only Certain Broadcasts".

8. In the Splitter Control List area, click Add New. You will list the names of the splitters that are authorized to receive this live broadcast.

   A generic splitter name appears in the Splitter Control List and the Edit Splitter Description box.

   1. In the Edit Splitter Description box, type a description or the name of a splitter.

   2. Click Edit.

   3. In the Splitter IP Address or Hostname box, type the name or IP address of the splitter (as shown in the splitter's Host Name or IP Address box, on the splitter RealSystem Administrator's Push Splitter page). You will need to contact the administrator of the splitter to get this value.

      	Warning
      	You must exactly match the value in the splitter's Host Name or IP Address box. If the administrator of the splitter typed an IP address for Host Name, type the IP address here. If the administrator typed a DNS name, type that here.

   4. Repeat Step a through Step c for each splitter to which you will be sending your live broadcasts.

9. Click Apply.

10. The person who will be setting up the splitter will need to know the values you chose in these steps. The table below shows the information about the source RealServer that you will need to share with the splitter administrator.

    Source Information Needed by Splitter Administrator

    Information	Reason
    Splitter Host Name value (called SplitterHostName in the configuration file)	Used in the URL to the split broadcast. In the example in this chapter, this value is Japan. The administrator of the Japan RealServer must give the splitting information to the Australia splitter administrator and the North America administrator.
    HTTP Port value (from the Ports page)	Used in the Splitter Source list. In the example in this chapter, this value is 8080.
    Source Mount Point	Used in the link to the split broadcast, usually /farm/. In the example in this chapter, the value is /farm/.
    Encoder Mount Point value (from Broadcasting section)	Used in the link to the split broadcast, usually /encoder/. In this chapter, the default is used.
    Source Path value (if any) (FarmSplitSources list in the configuration file)	Used in the link to the split broadcast. In this chapter, this option is not used.
    Live broadcast file name	Used in the link to the split broadcast. In the example in this chapter, the value is concert.rm.

Setting Up the Splitter for Push Splitting

Using the information you received from the administrator of the source RealServer (see "Source Information Needed by Splitter Administrator" table), use the steps below to set up the splitter.

Use these instructions to create the settings for RealServer to use when it is acting as a splitter.

	Note
	These instructions describe only the steps required to set up this feature. For more options, see "Optional Push Splitting Features".

To configure the splitter for push splitting:

1. In RealSystem Administrator, click Splitting. Click Push Splitter.

   

2. In the Mount Point box, type the mount point you want to use in the links to split content. This value is usually /farm/, the same as on the source.

3. Type the name of the machine on which this RealServer is running in the Host Name or IP Address box. The administrator of the source RealServer will need to know this value.

4. In the Port box, type a port number on this splitter to which the source will send broadcasts. A recommended value is 11001.

5. Define how many seconds of data to store in the buffer by typing a number in the Buffer Delay box. This helps reduce packet losses (dropouts) over a splitter connection. The recommended value is 30 seconds; a minimum of at least 10 seconds should be used.

   This setting establishes the delay between the time the live broadcast starts and when a client can connect to it.

6. Define how long the splitter will wait before considering a source's stream inactive. Type the number of seconds, from 0 to 32767 in the Timeout box. A recommended value is 30.

7. Set how often the splitter will request a stream. Type this number in the Probe Interval box. This value is given in seconds, and can range from 0 to 32767. A recommended value is 30.

8. List the RealServer or RealServers that the splitter should contact for live material to split.

   1. In the Server Sources area, click Add New. A generic source name appears in the Server Sources list and in the edit Server Description box.

   2. In the Edit Server Description box, type a description for the source.

   3. Click Edit.

   4. In the Server Host Name or IP Address box, type the host name of the source RealServer.

      	Warning
      	You must exactly match the value in the source's Host Name or IP Address box. If the administrator of the source typed an IP address for Host Name, type the IP address here. If the administrator typed a DNS name, type that here.

   5. In the Server Port box, type the HTTP Port number of the source RealServer to which this splitter will send its requests (usually 8080).

   6. In the Server Mount Point box, type the name of the mount point used on the source for push splitting. (If you also set up the source, use the value from Step 2.) The default value is /farm/.

   7. Repeat Step a through Step f for each source that this splitter will be receiving live broadcasts from.

9. Click Apply.

10. The administrator of the source RealServer needs to know some of the settings you used in the steps above.

    Splitter Information Needed by Source Administrator

    Information	Reason
    Splitter Host Name value	Appears in the source's Splitter Control List to identify which splitters are authorized to receive push splitting broadcasts. In the example used in this chapter, the administrator of the Australia splitter and the North America splitter must each tell the Japan administrator what values they are using for their splitters.

Linking to Push Split Content

This section describes the format of links to push splitted content.

To create the Web page URL for push splitting:

The link to the split content looks like this:

http://SplitterHostName:HTTPPort/ramgen/farm/SourceHostName/encoder/path/file

Notice that the first part of the link refers to settings on the splitter, and the second part refers to settings on the source.

To create the direct link URL for push splitting:

The link that you would type directly in the Open Location dialog box of RealPlayer has the following format. (This is also what the Server will send back to the RealPlayer when it receives the request shown in "Linking to Push Split Content". 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.

rtsp://SplitterHostName:RTSPPort/farm/SourceHostName/encoder/path/file

Example Push Splitting Links

Consider the example shown at the beginning of this chapter, in which a source RealServer in Japan sends its broadcasts to splitters in Australia and North America.

Note that the direct link to the Japan RealServer uses a regular live broadcast link, rather than the special push splitting format. It does not include the /ramgen/ mount point.

This example shows the text you would place in a Web page.

...we hope you enjoy the concert! Choose the link nearest you:

<a href="http://Japan.company.com.jp:8080/ramgen/encoder/concert.rm">Japan</a>

<a href="http://Australia.company.com.au:8080/ramgen/farm/
Japan.company.com.jp/encoder/concert.rm">Australia</a>

<a href="http://NorthAmerica.company.com:8080/ramgen/farm/
Japan.company.com.jp/encoder/concert.rm">North America</a>

The same links, when typed directly in the Open Location dialog box of RealPlayer, would have the following formats:

rtsp://Australia.company.com.au:554/farm/Japan.company.com.jp/encoder
/concert.rm

rtsp://NorthAmerica.company.com:554/ramgen/farm/Japan.company.com.jp
/encoder/concert.rm

Optional Push Splitting Features

This section describes some ways in which you can use splitting to create more sophisticated delivery of live broadcasts. The additional features are:

• Splitting only certain broadcasts

• Using backup sources

• Daisy-chaining splitters

Splitting Only Certain Broadcasts

You can choose to split a limited number of broadcasts, or to split all but a few broadcasts. Set up this feature on the source RealServer.

To split only a few streams:

1. In the Split All Streams list, select No.

2. In the Source Path section, click Add New.

   A generic name appears in the Source Path box.

3. Type the path or mount point of the live broadcast path you want to split in the Edit Source Path box.

4. Click Edit.

5. From the Split From This Path list, select Yes.

6. Repeat Step 1 through Step 7 for each live source you want to split.

7. Click Apply.

To split most streams, but make certain streams unavailable:

1. In the Split All Streams list, select Yes.

2. In the Source Path section, click Add New.

   A generic name appears in the Source Path box.

3. Type the path or mount point of the live broadcast path you do not want to split in the Edit Source Path box.

4. Click Edit.

5. From the Split From This Path list, select No.

6. Repeat Step 1 through Step 7 for each live source that should not be split.

7. Click Apply.

Using Backup Sources

If you are broadcasting a live event that is being served from several source RealServers, you can create a single URL that uses a wildcard so that if one source becomes unavailable, clients will still be able to connect the event using the single link. This feature is configured on both the source and the splitters.

Backup Sources

Clients can receive the broadcast from any of the sources. Should the source become unavailable, the splitter will automatically choose the next available source for new connections.

For example, a client connects to Splitter, which feeds the live.rm from Source B. If Source B goes down, the client receives an error message. Meanwhile, Splitter switches to Source C. The user can re-click the link in the Web page or click the Play button in RealPlayer, and will receive live.rm again.

This feature works when the URL for the split stream on all sources is identical except for the Host Name, and the sources and splitter are all configured to communicate with each other.

To set up backup sources:

1. Configure each source to recognize the splitter, by adding the splitter information to each source's Splitter Control List.

2. Configure the splitter to get broadcasts from each source, by adding each source to the Splitter Source list.

3. Create the special URL for this broadcast: instead of typing the Host Name in the URL, type an asterisk.

Linking to Backup Sources

To create the link that will allow the stream to come from multiple RealServers, use the same format as for push splitting (refer to "Linking to Push Split Content"), but substitute an asterisk (*) for the HostName value.

The following uses the example in the illustration above:

<a href="http://splitter.company.com:8080/ramgen/farm/*/encoder/live.rm">

Within RealPlayer, this link appears as the following:

rtsp://splitter.company.com:554/farm/*/encoder/live.rm

Chaining Splitters

A splitter can act as a source for another splitter. Clients connecting to the second splitter receive the broadcasts originating at the source.

In the illustration below, a stream that originates at the source RealServer is passed to Splitter A, then to Splitter B, and finally to Splitter C. A client can receive the live stream from any splitter.

This feature is configured on both the source and the splitters.

Daisy-Chain Push Splitting

The links for the live stream served by the source and each splitter are shown in the table below. Notice that each link starts with the name of the RealServer that appears to be hosting the content.

The following table shows how the links would look if typed directly in RealPlayer, used in a Ram or SMIL file, or created by Ramgen:

The links appear to pull directly from the source, but in configuring each splitter, you configure it to contact the previous splitter in the chain.

For example links, see the samples in "Example Push Splitting Links".

The following shows how the RealServers in "Daisy-Chain Push Splitting" are configured:

• Source RealServer is configured as a source; Splitter A is added to Source's Splitter Control List.

• Splitter A is configured as a splitter that contacts Source. It is also configured as a source; Splitter B is added to Splitter A's Splitter Control List.

• Splitter B is configured as a splitter that contacts Splitter A. It is also configured as a source; Splitter C is added to Splitter B's Splitter Control List.

• Splitter C is configured as a splitter only, that contacts Splitter B.

In addition to being configured as a splitter, each splitter in the chain (except the last one) must also be configured as a source. To set up a splitter as a source, first configure it as a splitter, as described in "Setting Up the Splitter for Push Splitting". Then configure it as a source, using the instructions in "Setting Up the Source for Push Splitting"Although the links appear to point directly to the source RealServer, the configuration on each splitter in fact points to the previous splitter in the chain. Each RealServer only knows about the RealServer on either side in the chain; it doesn't know about all the other RealServers in the chain.

To set up chained push splitting:

1. Configure the first RealServer as a source, and add Splitter A to Source's Splitter Control List. (See "Setting Up the Source for Push Splitting".)

2. Configure Splitter A as a splitter, and add Source to the Sources list.

3. Configure Splitter A as a source, and add Splitter B to the Splitter Control List.

4. Configure Splitter B as a splitter, and add Splitter A to the Sources list.

5. Configure Splitter B as a source, and add Splitter C to the Splitter Control List.

6. Configure Splitter C as a splitter, and add Splitter B to the Sources list.

Repeat Step 2 through Step 6 for each splitter in the chain.

To create the links for chained push splitting:

Use the standard format for linking to push splitting content, as described in "Linking to Push Split Content". The link for each splitter should reference the splitter and the source. Even though each splitter is configured to get the stream from the previous splitter in the chain, this information is not included in the link.

Setting Up Pull Splitting

If you are administering the source RealServer where the broadcasts originate, use the steps in "Setting Up the Source for Pull Splitting". If you are setting up the splitter, follow the steps in "Setting Up the Splitter for Pull Splitting"to configure the splitter and create the links to the split broadcasts.

Setting Up the Source for Pull Splitting

The source RealServer uses only the following setting for pull splitting (you can view it in RealSystem Administrator by clicking Splitting>Pull Source), and it is pre-configured:

• Port-the port to which the source RealServer will listen for splitter requests. A recommended value is 3030.

The person who creates the links to pull split content will need to know some of the values you chose in these steps. The table below shows the information needed. (Unlike in push splitting, the administrator of the pull splitter doesn't need to know the settings you used.)

Setting Up the Splitter for Pull Splitting

With the information you received from the administrator of the source RealServer, use the steps below to set up the splitter.

RealServer uses the following settings to perform pull splitting (you can view them by clicking Splitting > Pull Splitter in RealSystem Administrator), and they are pre-configured:

• Mount Point-the mount point you will use in the URL for split content. A recommended value is /split/.

• Port-the port number on the source RealServer to which the splitter will direct its requests.

• Protocol-indicates the protocol to use in sending live data to splitters. The default is UDP. Choose TCP if you are splitting through a firewall (this will produce a slower connection and more overhead).

The person who creates the links to pull split content will need to know some of the values you chose in these steps. Refer to the table in "Linking to Pull Split Content" for the complete list of information used in the link.

Linking to Pull Split Content

This section describes the format of the link to pull split broadcasts.

To link to pull split content from a Web page:

The link to the split content looks like this:

http://address:HTTPPort/ramgen/split/source:Port/encoder/path/file

Notice that the first part of the link refers to settings on the splitter, and the second part refers to settings on the source.

To create the direct link URL for pull splitting:

The link to the split content, as created by the source RealServer or as typed directly in the Open Location dialog box of RealPlayer, has the following format. 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.

rtsp://address:RTSPPort/split/source:Port/encoder/path/file

Example Pull Splitting Link

Consider the example shown at the beginning of this chapter, in which a source RealServer in Japan sends its broadcasts to splitters in Australia and North America.

Note that the direct link to the Japan RealServer uses a regular live broadcast link, rather than the special pull splitting format).

The links used in the Web page have the following format:

...we hope you enjoy the concert! Choose the link nearest you:

<a href="http://Japan.company.com.jp:8080/ramgen/encoder/concert.rm">
Japan</a>

<a href="http://Australia.company.com.au:8080/ramgen/split
/Japan.company.com.jp:3030/encoder/concert.rm">Australia</a>

<a href="http://NorthAmerica.company.com:8080/ramgen/split
/Japan.company.com.jp:3030/encoder/concert.rm">North America</a>

When the source RealServer receives these requests, it generates the following links, which can also be typed directly in the Open Location dialog box of RealServer:

rtsp://Japan.company.com.jp:554/encoder/concert.rm

rtsp://Australia.company.com.au:554/split/Japan.company.com.jp:3030/encoder
/concert.rm">Australia</a>

rtsp://NorthAmerica.company.com:554/split/Japan.company.com.jp:3030/encoder
/concert.rm">North America</a>

Copyright © 1998, 1999 RealNetworks
For information on RealNetworks' technical support, click here.
Comments on this document? Click here.
This file last updated on 12/02/99 at 10:53:30.