スプリッティングとはクライアントではなく他のRealServerにライブブロードキャストを送る方式です。スプリッタとして設定された、これら他の RealServerはストリームをクライアントに再ブロードキャストします。 ストリームがユーザ近くで複製されるため、クライアントが高品質のコンテンツを受け取り、帯域幅の利用が最小限に抑えられる一方、オーディエンスサイズは最大となります。
ライブマテリアルを発信するRealServerはソース RealServerと呼ばれ、そこから送られるライブブロードキャストはスプリッタという別の RealServerを通じてユーザに届けられます。スプリッタとは、簡単に言うと、別のRealServer から発信されたストリームを再ブロードキャストする目的で設定された RealServerのことです。Webページのリンクは、ソースではなくスプリッタを指しています。ユーザがリンクをクリックすると、スプリッタは専用URLを認識して、ストリームをソース RealServer からクライアントへ転送します。
たとえば、日本で発信されたコンサートをインターネットを通じてオーストラリアや北米の RealServerへブロードキャストすることができます。これらの都市のユーザは最寄りの RealServerへ接続することによって、品質の高いメディアを得ることができるとともに、使用するネットワーク帯域幅も少なくてすみます。
別のコンピュータを発信源とするコンテンツをサービスする一方、RealServerは、その役割がソースであるかスプリッタであるかにかかわらず、自前のコンテンツをこれまで通りストリーミング配信することができます 。また、すべてのクライアントにサービスする必要がないので、自前コンテンツのストリーミング配信により多くの接続を充てることができます。
サービスおよびスプリットされるライブマテリアルは、RealProducer Plusなどのエンコーダでエンコードしたライブイベントでもいいし、 G2SLTAユーティリティでブロードキャストする収録済みのライブイベントでもいいでしょう。ライブソースの設定に関する情報については、第11章「ライブプレゼンテーションのユニキャスト」を参照してください。
イベントを示すWebページには、所在地ごとに別のリンクが示されています。
以下はこの機能を使用するかどうか決める時に考慮すべき要因です。これは必要条件ではありませんが、重要な決定要素と言えます。
スプリッティングには プッシュスプリッティングと プルスプリッティングの2つのタイプの方法があります。
プッシュスプリッティングではソースと各スプリッタ間が常に接続されているため、スプリットストリームを要求する最初のクライアントはより早く接続できることになります。ソースはすべてのライブブロードキャストを接続されたスプリッタに送ります。
プルスプリッティングでは、ソース RealServerは最初のクライアントから要求があるまで、スプリッタにストリームを送りません。
どちらのスプリッティング方法も SureStream 帯域幅ネゴシエーションしたファイルをサポートしています。
プッシュスプリッティングでは、 ソース RealServerとスプリッタは常に交信中です。 ソース RealServerはエンコーダからのライブフィードをストリーミング配信し始めるとただちに、そのブロードキャストをすべてのスプリッタに送ります。
クライアントがスプリッタからのブロードキャストをリクエストした時点で、スプリッタとRealServerはすでに接続ずみなので、ブロードキャストはただちにクライアントへ配信されます。
プッシュスプリッティングを使うと、ライブブロードキャストのスプリットを部分的に選ぶことができます。すべてのブロードキャストをスプリットするか、ごく一部をスプリットするか選ぶことができます。もちろん、ユーザが再生できるブロードキャストは、リンクが作成されているものに限られます。
プッシュスプリッティングの場合は常にソースとスプリッタ間が交信中ですが、プルスプリッティングの場合はクライアントからの要求があるまでソースとスプリッタ間の接続が確立されていない状態にあるので、使用する帯域幅が少なくてすみます。 ライブブロードキャストのリクエストを受けると、スプリッタはソースへの接続を開きます。RealServerはスプリッタへブロードキャストを送り、今度はスプリッタがそれをクライアントへブロードキャストします。
プッシュスプリッティングと違って、この形のスプリッティングでは、ソース RealServer 上のどのブロードキャストをスプリットできるか特定することはできません。プルスプリッティングを有効にすると、お使いの RealServerのすべてのライブイベントに対してプルスプリッティングが有効になります。しかし、実際には、ユーザはリンクの存在するブロードキャストだけを再生することができます。
プルスプリッティングの設定は、プッシュスプリッティングほど複雑ではありません。
プッシュとプルのどちらのスプリッティング方法を選ぶかは、ユーザの使用予測頻度とタイプによって決まります。
これらの方法を組み合わせて、帯域幅を最大限に活用することができます。
たとえば、タイムゾーンに合わせてプッシュスプリッティングとプルスプリッティングを分けて使用することができます。同一あるいは近いタイムゾーンのスプリッタにイベントを送る場合はプッシュスプリッティングを使い、潜在的ユーザが眠っていると思われる、世界の反対側のタイムゾーンにいるユーザはプルスプリッティングを使用できるようにします。
プッシュスプリッティングは、すべてのスプリッタのアクセスが予想される、人気のあるイベントに最適です。
プルスプリッティングは、小規模なイベントや、地元あるいは少人数のオーディエンスに適しています。
プッシュスプリッティングとプルスプリッティングのどちらの場合でも、RealServer Acess Controlリストにスプリッタのアドレスとポートアドレスを加えることによって、ソースにアクセスできるスプリッタを制限することができます。アクセス制御リストに関する詳細は 「IPアドレスでのアクセス制限」を参照してください。
また、ソース RealServerではブロードキャストのリクエストを認められているプッシュスプリッタのリストも保持しています。詳細は 手順8を参照してください。Access Controlリスト（もしあれば）でもアクセスを制限しています。Access ControlはSplitter Control Listより優先されます。アクセス制御を使用している場合は、プッシュスプリッタはHTTPポートを使用してリクエストするので、このポートにスプリッタアクセスを認める規則を必ず作ってください。
ソース RealServerを発信源とするマテリアルに対してスプリッタとしてサービスしながら、スプリッタは標準的ブロードキャスティングおよびオンデマンドストリーミング法を使用して、同時に自前のコンテンツをサービスすることもできます。スプリッタをソースとしても使用できるようにセットアップするには、 「プッシュスプリッティングのためのスプリッタセットアップ」に書かれた手順を用いて、まずスプリッタ部分をセットアップしてください。それから 「プッシュスプリッティング用のセットアップ」に述べられた指示に従ってソースとしてセットアップしてください。
デイジーチェーン連結機能を使用すると、各スプリッタは同じマテリアルに対してスプリッタとソースの両方の働きをします。詳細は 「スプリッタの連結」 を参照してください。
本セクションではスプリッティングを他の機能といっしょに使用する方法を説明します。
どちらのスプリッティング方法もオンデマンドストリーミングとともに使用することはできません。スプリッティングはライブブロードキャストのみを配信するからです。 G2SLTA を使ってオンデマンドクリップをライブブロードキャストに変換できます。本セクションの後の部分に出てくる 「G2SLTAとスプリッティング」 を参照してください。
ユニキャスティングはソースやスプリッタから自動的に起こることがあります。ソース上のストリームを直接指すリンクを作るとき、ユニキャスティングを使用していることになります。 「スプリッティングの図」と題した図では、右上に示した3人のクライアントは日本のソース RealServeriからのユニキャストを受けています。
スプリッティングとマルチキャスティングを組み合わせて、帯域幅を最大限に活用することができます。詳細とイラストについては 第13章「ライブプレゼンテーションの マルチキャスティング」の「スプリッティングとマルチキャスティング」 を参照してください。
スプリッタは RealServerから受け取るブロードキャストをアーカイブすることはできません。ブロードキャストをアーカイブしたい場合は、ソース RealServer上のライブブロードキャストをアーカイブしなければなりません。
スプリットブロードキャスト用ソースとしてライブイベントを使用することもできれば、 G2SLTAを使って、収録済みのクリップからライブイベントをシミュレートすることもできます。 G2SLTAは、実際のイベントをブロードキャストする前にスプリッタの設定をテストするよい方法です。
RealProxyは、ライブブロードキャストをキャッシュできません。キャッシュする実際のファイルがないからです。しかし、RealProxyにはライブストリームをクライアント間で「共有」する機能があり、ソースRealServerから要求される帯域幅を減らすことができます。通信はプルスプリッティングで行い、RealServerはソースとして働くように事前設定され、RealProxyはプルスプリッタとして働くように自動的にセットアップされます。
ソースとスプリッタは速く効率的な通信のためにUDPを使いますが、こうしたタイプのトラフィックを許可しないファイアウォールもあります。ソース RealServer とスプリッタがファイアウォールの反対側にある場合、ProtocolオプションをTCPに変えてください。
 |
追加情報 |
|---|
| ファイアウォールと、ソースやスプリッタの最適な配置は 「ファイアウォールの後ろのスプリッタとの通信」で説明してい ます。 |
他の機能の場合と同じく、 RealServer はAccess Controlリスト の規則を用いてどのシステムがブロードキャストを受け取るか決めます。さらに、プッシュスプリッティングには独自のSplitter ControlListがあり、そこにソース RealServerからのブロードキャスト受信を許可されたスプリッタが入っています。
スプリッタとして機能するRealServerにストリームを送信する場合、認証情報を保存するすべてのデータベースのコピーをスプリッタに置く必要があります。こうすることにより、認証負荷が分散されます。
あなたのRealServerがソースの場合、Java モニタは、ソースへのスプリッタの接続だけを表示します。スプリッタへの個々のクライアント接続は、スプリッタのJava モニタに表示されます。
ソース RealServerがプッシュスプリッティング用に正しく設定されると、 Java モニタのファイルタブに以下のメッセージが表示されます。
“farm/givemeallyourstreams.IP.port”、この場合 IP とは、Push SplitterページのHost Name or IP AddressボックスにタイプされたスプリッタのIPアドレスや名前のことで、 portとは同ページのPortボックスに指定されたスプリッタのポートのことです。メッセージはスプリッタのProbe Intervalボックスに表示された間隔で増えていきます。
ソース RealServer上では、アクセスログにはスプリッタ接続に関係する記録は表示されていません。しかし、同じイベントが複数のRealServerにエンコードされている場合（「バックアップソースの使用」で説明）、ソースRealServerのアクセスログに記録が作られます。
スプリッタ上では、アクセスログには配信された各クリップが記録され、スプリッティングマウントポイントが表示されます。
プッシュスプリッティングを使っていて、スプリットするライブイベントがたくさんある場合は、アクセスログはすぐにいっぱいになります。プルスプリッティングの場合、プルスプリットストリームはスプリッタからリクエストがあるときしか配信されないので、アクセスログの記録は少なくなります。（プッシュスプリッティングは使用できるすべてのライブプレゼンテーションを継続的に送ります。 ）
ソースやスプリッタのセットアップでエラーがあれば、エラーログファイルにそれが記録されます。
プッシュスプリッティングとプルスプリッティングのどちらにおいても、4つの主なステップがあります。ソースの管理者とスプリッタの運営者は同一人物かもしれませんが、わかりやすくするために便宜上区別します。
プッシュスプリッティングのソースとスプリッタの管理者は、それぞれが使用しているセッティングについて話し合う必要があります。ソースRealServerはスプリッタについての情報を必要とし、スプリッタはソースについての情報を必要とします。各々の指示の最後にこれらの共通情報を表示しています。
プルスプリッティングでは、ソース管理者はスプリッタ管理者に情報を提供して、正しくリンクを作れるようにする必要があります。スプリッタ管理者はソース管理者に情報を提供する必要はありません。
ブロードキャストの発信源であるソースRealServerを管理している場合は、 「プッシュスプリッティング用のセットアップ」の手順を用いてください。スプリッタをセットアップする場合は、「プッシュスプリッティングのためのスプリッタセットアップ」の手順に従って、スプリッタを設定しスプリットブロードキャストへのリンクを作ってください。
 |
メモ |
|---|
| Access ControlでRealServerへアクセスできるスプリッタ、エ ンコーダ、あるいはクライアントを制限している場合、必ず Access Control規則でHTTP Portへのアクセスを許可してくだ さい。そうでないと、スプリッティングを正しく設定しても、 スプリッタはこのソースからコンテンツを受け取れなくなりま す。詳細は「ソースRealServerへのスプリッタのアクセス制御」 を参照してください。 |
プッシュスプリッティングのためにソースRealServerをセットアップする前に、スプリッタ管理者にHost Name用に用いている値を問い合わせる必要があります。 Splitter Control Listのセットアップにこれを使用します。
本章で用いた例ではソースRealServerは日本にあるものとします。
|
|
メモ |
|---|
| ここではこの機能のセットアップに必要な手順だけを説明して います。詳細は次を参照してください。 「プッシュスプリッティ ング機能のオプション」 |
/farm/ を変える場合は、必ずスプリッタ管理者に知らせてください。
UDPです。ファイアウォールを通じてスプリットしている場合は TCPを選んでください（このような接続は、切れたり、ブロードキャストを妨害することがあります。また、オーバーヘッドもさらにかかります）。
0から32767までの間から選びますが、推奨設定値は30です。
スプリッタが再送をリクエストする場合、ソースはデータパケットのバッファをそのまま使用します。設定した値がシステムにとって高すぎると、ソースは使用できる以上のメモリを使おうとすることがあります。設定した値が低すぎれば、ソースは失われたパケットを回復することができません。ライブストリームが高ビットレートシステムの場合は、バッファを小さくしてください。
30です。
Yesを選択して、このRealServerからのすべてのライブブロードキャストがスプリッタに配信されるよう設定してください。
|
|
追加情報 |
|---|
| どのブロードキャストをスプリットするか制限するには、「特定 のブロードキャストのみのスプリット」を参照してください。 |
Splitter Control ListとEdit Splitter Descriptionボックスに一般的な名前が表示されます。
 |
警告 |
|---|
| スプリッタのHost Name or IP Addressボックスにある値と完全に 同じでなければなりません。スプリッタ管理者がHost Nameに IPアドレスを入力した場合は、ここにIPアドレスを入力します。 管理者がDNS名を入力した場合は、ここにもそう入力します。 |
ソースRealServer管理者から受け取った情報を使用し（表「スプリッタ管理者に必要なソース情報」参照）、以下の手順を用いてスプリッタをセットアップします。
これらの指示を利用して、RealServerをスプリッタとして使用するときのセッティングを作ります。
|
|
メモ |
|---|
| ここではこの機能のセットアップに必要な手順だけを説明して います。詳細は次を参照してください。「プッシュスプリッティ ング機能のオプション」 |
/farm/で、ソース上の値と同じです。
11001です。
0から32767までの秒数を入力してください。推奨設定値は30です。
0から32767までの範囲から選択します。推奨設定値は30です。
|
|
警告 |
|---|
| ソースのHost Name or IP Addressボックスにある値と完全に同 じでなければなりません。ソース管理者がHost NameにIPア ドレスを入力した場合は、ここにIPアドレスを入力します。管 理者がDNS名を入力した場合は、ここにもそう入力します。 |
/farm/です。
本章ではプッシュスプリットしたコンテンツへのリンク形式を説明します。
スプリットWebページコンテンツへのリンクはこのようになります。
http://SplitterHostName:HTTPPort/ramgen/farm/SourceHostName/encoder/path/file
リンクの初めの部分はスプリッタ上のセッティングを、二番目はソース上のセッティングを表していることに注意してください。
| 構成要素 | 意味 |
|---|---|
| スプリッタ情報 | |
http |
ストリーミング配信に使うプロトコル (http). |
SplitterHostName |
スプリッタのHost Name値（コンフィグレーションファイルではSplitterHostNameと呼ばれます） |
HTTPPort |
スプリッタのHTTPポート設定（デフォルト値は8080）。 |
ramgen |
Webページへのリンクに必要。 |
farm |
ソースRealServerに使うプッシュスプリッティングマウントポイント、 通常は/farm/。 |
| ソース情報 | |
SourceHostName |
ソースのHost Name or IP Address値。（コンフィグレーションファイルではSplitterHostNameと呼ばれます）バックアップソースを使っている場合（「バックアップソースの使用」参照）、アステリスク( *)を使います。 |
encoder |
ソース上のライブコンテンツのためのエンコーダマウントポイント、通常は/encoder/です。 |
virtual_directory |
オプション。エンコーダによって定義される仮想ディレクトリ。 |
filename |
ライブストリームの名前。 |
RealPlayerのOpen Locationダイアログボックスに 直接入力するリンクは以下のような形式をとります。（これは「プッシュスプリットコンテンツのリンク」に示されたリクエストを受けるときにサーバがRealPlayerへ送り返すものでもあります。）形式はWebページで使われるリンクとほぼ同じです。プロトコルは異なり、ポートアドレス（あれば）はプロトコルと一致し、Ramgenは省略されます。
rtsp://SplitterHostName:RTSPPort/farm/SourceHostName/encoder/path/file
本章冒頭に挙げた例を考えてみましょう。この例では日本のソースRealServerはオーストラリアと北米のスプリッタにブロードキャストを送ります。
日本のRealServerは専用プッシュスプリッティング形式ではなく通常のライブブロードキャストリンクを使うことに注意してください。ここには/ramgen/マウントポイントは含まれません。
...コンサートをお楽しみください! 最寄りのリンクをお選びください:
<a href=”http://Japan.company.com.jp:8080/ramgen/encoder/concert.rm”>Japan</a>
<a href=”http://Australia.company.com.au:8080/ramgen/farm/”>Australia</a>
Japan.company.com.jp/encoder/concert.rm
<a href=”http://NorthAmerica.company.com:8080/ramgen/farm/”>North America</a>
Japan.company.com.jp/encoder/concert.rm
RealPlayerのOpen Locationダイアログボックスに直接入力する場合、同じリンクは以下のような形式をとります。
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
本セクションではスプリッティングを使ってライブブロードキャストのより高性能な配信方法を作る方法をいくつか説明しています。追加機能は:
限られたブロードキャストだけをスプリットしたり、または少数の一部を除くすべてのブロードキャストをスプリットするよう選択できます。ソースRealServerにこの機能をセットアップします。
Noを選択します。
Yesを選択します。
Yesを選択します。
Noを選択します。
いくつかのソースRealServerからサービスされているライブイベントをブロードキャストしている場合、ワイルドカードを使うURLを1つ作り、1つのソースを使用できなくなっても、クライアントが1つのリンクを使ってイベントへ接続できるようにすることができます。この機能はソースとスプリッタの両方に設定します。
クライアントはどのソースからもブロードキャストを受けられます。ソースが使用できなくなったら、スプリッタは新しい接続に使用できる次のソースを自動的に選びます。
たとえば、クライアントがソースBからlive.rmを供給するスプリッタに接続しているとします。ソースBがダウンした場合、クライアントはエラーメッセージを受け取ります。その間、スプリッタはソースCに切り換えます。ユーザはWebページのリンクを再クリックするか、RealPlayerのPlayボタンをクリックして、再びlive.rmを受信できます。
この機能が使用できるのは、すべてのソース上のスプリットストリームのURLがHost Nameをのぞいて同一であり、ソースとスプリッタはすべて互いに通信するように設定されている場合です。
複数のRealServerからストリームが来るのを許可するリンクを作るには、プッシュスプリッティングと同じ形式を使いますが（「プッシュスプリットコンテンツのリンク」参照）、アステリスク (*)をHostName値に変えてください。
<a href=”http://splitter.company.com:8080/ramgen/farm/*/encoder/live.rm”>
RealPlayer内ではこのリンクは以下のように表示されます。
rtsp://splitter.company.com:554/farm/*/encoder/live.rm
スプリッタは別のスプリッタのソースとして機能することができます。二次スプリッタに接続するクライアントはそのソースを発信源とするブロードキャストを受信します。
下の図では、ソースRealServerを発信源とするストリームはSplitter Aに転送され、それからSplitter Bに、最後にSplitter Cに転送されます。クライアントはどのスプリッタからでもライブストリームを受信できます。
ソースと各スプリッタがサービスするライブストリームのリンクを下の表に示しています。各リンクはコンテンツをホストするようなRealServerの名前で始まることに注意してください。
以下の表は、RamやSMILファイルで使ったりRamgenで作った場合、RealPlayerに直接入力するリンクがどう見えるかを示しています。
リンクはソースから直接引いているように見えますが、各スプリッタを設定する場合には、チェーンの前のスプリッタアクセスするように設定します。
リンク例については、「プッシュスプリッティングリンクの例」のサンプルを参照してください。
以下は「プッシュスプリッティングの連結」のRealServerがどのように設定されているか示しています。
スプリッタとしての設定に加えて、チェーン内の各スプリッタは（最後のものをのぞいて）ソースとしても設定しなければなりません。「プッシュスプリッティングのためのスプリッタセットアップ」で説明したように、スプリッタをソースとしてセットアップするには、まずスプリッタとして設定します。それから「プッシュスプリッティング用のセットアップ」 （162ページ）指示を利用して、ソースとして設定します
リンクはソースRealServerを直接指しているように見えますが、実際は各スプリッタの設定はチェーン内の前のスプリッタを指しています。各RealServerはチェーンの一方のRealServerのことしか知りません。チェーン内の他のすべての RealServerについてはわからないのです。
チェーン内の各スプリッタについて手順2から手順6をくりかえします。
「プッシュスプリットコンテンツのリンク」で説明したように、プッシュスプリッティングコンテンツへのリンクの標準形式を使います。各スプリッタのリンクはスプリッタとソースを参照しなければなりません。各スプリッタはチェーン内で前のスプリッタからストリームを受けるように設定されますが、この情報はリンクには含まれていません。
ブロードキャストの発信源であるソースRealServerを管理している場合は、「プルスプリッティングのためのソースの設定」の手順を用いてください。スプリッタをセットアップする場合は、「プルスプリッティングのためのスプリッタの設定」の手順に従って、スプリッタを設定しスプリットブロードキャストへのリンクを作ってください。
ソースRealServer はプルスプリッティングに以下の設定しか使わず（RealSystem AdministratorでSplitting>Pull Sourceをクリックすれば表示されます）、それは設定済みです。
プルスプリットコンテンツへのリンク作成者は、あなたがこれらの手順で選んだ値の一部を知る必要があります。下のテーブルは必要な情報を示しています。（プッシュスプリッティングと違って、プルスプリッティング管理者はあなたが用いた設定を知る必要はありません。）
| 情報 | 理由 |
|---|---|
| ソースマシンのドメイン名かIPアドレス | URLでスプリットブロードキャストに使用 |
| プルスプリッティングPort値 | |
| ライブブロードキャストファイル名 | |
ソースRealServer管理者から受け取った情報を使用し、以下の手順を用いてスプリッタを設定します。
RealServerは以下の設定を用いてプルスプリッティングを行い（RealSystem Administratorで Splitting > Pull Splitterをクリックすれば表示されます）、それらは設定済みです。
/split/です。
UDPです。ファイアウォールを通じてスプリットしている場合はTCPを選んでください（接続が遅くなり、オーバーヘッドが余計にかかります）。
プルスプリットコンテンツへのリンク作成者は、あなたがこれらの手順で選んだ値の一部を知っている必要があります。リンクで使われた情報の完全なリストについては「プルスプリットコンテンツへのリンク」の表を参照してください。
本セクションではプルスプリットブロードキャストへのリンク形式を説明します。
http://address:HTTPPort/ramgen/split/source:Port/encoder/path/file
リンクの初めの部分はスプリッタ上の設定を、二番目はソース上の設定を表していることに注意してください。
| 構成要素 | 意味 |
|---|---|
| スプリッタ情報 | |
address |
スプリッタのホストネームかIPアドレス |
HTTPPort |
オプション。ポート設定がデフォルト値の8080から変更された場合のみ入れます。 |
ramgen |
「プルスプリッティングのダイレクトリンクURLを作るには:」に示したリンクの作成に使用 |
split |
受け取るスプリッタのプルスプリッティングマウントポイント、通常は/split/です。 |
| ソース情報 | |
source |
ソースRealServerのホストネームかIPアドレス |
Port |
ソースのポート値（Pull Sourceページ）デフォルト値は3030です。 |
encoder |
/encoder/などライブマテリアルに適当なソースのマウントポイント |
virtual_directory |
オプション。エンコーダによって定義される仮想ディレクトリ。 |
filename |
スプリットするファイル名 |
ソースRealServerで作られたり、 RealPlayerのOpen Locationダイアログボックスに直接入力する場合、スプリットコンテンツへのリンクは以下のような形式をとります。形式はWebページで使われるリンクとほぼ同じです。プロトコルは異なり、ポートアドレス（あれば）はプロトコルと同じで、Ramgenは省略されます。
rtsp://address:RTSPPort/split/source:Port/encoder/path/file
本章冒頭に挙げた例を考えてみましょう。この例では日本のソースRealServerはオーストラリアと北米のスプリッタにブロードキャストを送ります。
日本のRealServerは専用プルスプリッティング形式ではなく通常のライブブロードキャストリンクを使うことに注意してください。
...コンサートをお楽しみください! 最寄りのリンクをお選びください:
<a href=”http://Japan.company.com.jp:8080/ramgen/encoder/concert.rm”>
Japan</a>
<a href=”http://Australia.company.com.au:8080/ramgen/split”>Australia</a>
/Japan.company.com.jp:3030/encoder/concert.rm
<a href=”http://NorthAmerica.company.com:8080/ramgen/split”>North America</a>
/Japan.company.com.jp:3030/encoder/concert.rm
ソースRealServerはこれらのリクエストを受けると、以下のようなリンクを生成しますが、それらはRealServerのOpen Locationダイアログボックスに直接入力することもできます。
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>