JP5384431B2 - 配信サーバ及び方法 - Google Patents

Description

本発明は、ネットワーク制御方式に関し、より詳細には、ネットワークを介したデータ伝送処理におけるストリーム制御セッションの識別情報と通信管理セッションの識別情報との対応付けを行う配信サーバ及び方法に関する。

現在、ＴＩＳＰＡＮ（Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ ａｎｄ Ｉｎｔｅｒｎｅｔ ｃｏｎｖｅｒｇｅｄ Ｓｅｒｖｉｃｅｓ ａｎｄ Ｐｒｏｔｏｃｏｌｓ ｆｏｒ Ａｄｖａｎｃｅｄ Ｎｅｔｗｏｒｋｉｎｇ）等の国際標準化団体では、ネットワークを介した映像配信サービスの実現方式が議論されている（非特許文献１）。一般に、ＮＧＮ（Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｎｅｔｗｏｒｋ）のような管理型ネットワークでは、映像配信サービスを行う場合、ストリーム制御用通信路とストリーム配信用通信路の２つの通信路を確立する必要がある。

ストリーム制御用通信路は、再生、一時停止、早送り、巻き戻しなどのストリームを制御するための通信路である。ストリーム制御用通信路で使用される具体的なプロトコルとして、ＲＴＳＰ（Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）があげられる。

他方、ストリーム配信用通信路は、実際に端末にストリームを流すための通信路である。ストリーム配信用通信路で使用される具体的なプロトコルとして、ＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）があげられる。

なお、ここで使用される「通信路」とは、複数の端末の間で通信を行う際の経路を表す。

これら２つの通信路を確立するため、端末とストリームを提供する配信サーバは、ＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）／ＳＤＰ（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ）等の通信管理用プロトコルを用いて、ＩＰアドレス、ポート番号、プロトコル等の通信路情報を互いに送受信し、通信路を確立する。

ここで、上述した管理型ネットワークでは、ストリーム制御状況に基づく通信路の管理と、ストリーム制御情報に関するプレゼンスサービスの提供との２つの処理のため、通信管理セッションＩＤとストリーム制御セッションＩＤとの対応付けを配信サーバが保持する必要がある。

なお、ここで使用される「セッション」とは、特定のプロトコルを用いて複数の端末の間で通信を開始してから終了するまでの処理を表す。

前者のストリーム制御状況に基づく通信路の管理の具体例として、以下の処理があげられる。例えば、ストリームの停止要求を受信した場合、配信サーバは自動的に通信路を切断する。この処理を実現するため、ストリーム制御信号に記述されたストリーム制御セッションＩＤに基づき、配信サーバは、該当する通信管理セッションＩＤを決定し、通信路管理用プロトコルを用いて通信路を切断する必要がある。また、他の例として、ストリーム制御における障害発生時には、配信サーバは自動的に通信路を切断する。この処理を実現するため、障害が発生したストリーム制御セッションＩＤに基づき、配信サーバは、該当する通信管理セッションＩＤを決定し、通信路管理用プロトコルを用いて通信路を切断する必要がある。さらなる他の例として、配信サーバは、ストリーム制御用通信路とストリーム配信用通信路とを確立したにもかかわらず、実際にストリーム配信が実行されていない通信路を検出すると、当該通信路を自動的に切断し、帯域を効率的に管理する。この処理を実現するため、該当するストリーム制御セッションＩＤに基づき、配信サーバは、対応する通信管理セッションＩＤを決定し、通信路管理用プロトコルを用いて通信路を切断する必要がある。

後者のストリーム制御情報に関するプレゼンスサービスの提供の具体例として、以下の処理があげられる。ＳＩＰなどの通信管理用プロトコルは、上述された通信路の確立だけでなく、確立された通信路に接続している端末の現在状態に関する情報（プレゼンス情報）をプレゼンスサーバに通知する処理にも利用される。そこで、非特許文献１及び２では、映像配信サーバが通信管理用プロトコルを用いて、ユーザの現在のストリーム制御状況（例えば、視聴しているコンテンツ、再生や一時停止などのコンテンツに対する操作、視聴時間など）をプレゼンスサーバに登録するサービスを規定している。このサービスを実現するため、映像配信サーバは、通信管理セッションＩＤとストリーム制御セッションＩＤとの対応関係を保持する必要がある。すなわち、配信サーバは、通信管理セッションＩＤとストリーム制御セッションＩＤとの対応付けを行い、ストリーム制御の状況をプレゼンスサーバに通知する。例えば、図１に示されるように、端末からストリーム制御セッションＩＤ：１１１１１１１１により「コンテンツ○○○を早送りする」との要求を受信すると、配信サーバは、通信管理セッションＩＤ：ＹＹＹＹＹＹＹＹを用いて、プレゼンスサーバに「通信管理セッションＩＤ：ＹＹＹＹＹＹＹＹのセッションでは、現在コンテンツ○○○の早送りを行っている」と通知する。

ETSI TS 182 027 V2.4.1(2009-07) Telecommunications and Internet converged Services and Protocols for Advanced Networking(TISPAN); IPTV Architecture; IPTV functions supported by the IMS subsystem ETSI TS 183 063 V2.4.2(2009-06) Telecommunications and Internet converged Services and Protocols for Advanced Networking(TISPAN); IMS-based IPTV stage 3 specification ETSI TS 183 048 V2.2.1(2009-08) Telecommunications and Internet converged Services and Protocols for Advanced Networking(TISPAN); Resource and Admission Control System(RACS); Protocol Signaling flows specification; RACS Stage 3

通信管理プロトコルとしてＳＩＰを、ストリーム制御用プロトコルとしてＲＴＳＰを、ストリーム配信用プロトコルとしてＲＴＰが使用される場合について説明する。非特許文献１及び２では、映像配信サーバにおいて、ＳＩＰセッションのＩＤとＲＴＳＰセッションのＩＤとの対応関係を保持するため、図２では、端末がＳＩＰ信号にＲＴＳＰセッションＩＤを記述する方式が記載されている。

この従来方式によると、以下のような問題が生じる可能性がある。まず、従来方式では、ＳＩＰに関するＳＩＰ信号にこれと異なるプロトコルであるＲＴＳＰに関する情報（ＲＴＳＰセッションＩＤ）が記述される。このため、端末、配信サーバ等のＳＩＰを処理する機器、端末と配信サーバとの間のＳＩＰ関連のインタフェース等が、ＲＴＳＰに固有の情報を処理できるよう拡張される必要が生じてくる。この場合、一方のプロトコルの拡張が他のプロトコルに影響を及ぼす可能性がある。そのため、一方のプロトコルを拡張した場合、他方のプロトコルにも機能拡張を行う必要が生じる。図２に示される例について、ＳＩＰにＲＴＳＰ信号の拡張を行った場合、ＳＩＰ信号処理部にも影響が生じる可能性があるため、ＶｏＩＰ（Ｖｏｉｃｅ ｏｖｅｒ ＩＰ）等のＲＴＳＰとは無関係なサービスに用いるＳＩＰ機器（例えば、ＶｏＩＰ端末など）に関しても機能検証を行う必要が生じてくる。

また、従来方式では、ＳＩＰ信号内には１つのＲＴＳＰセッションＩＤしか記述することができない。そのため、単一のＳＩＰセッションＩＤで確立された１つの通信路において複数のＲＴＳＰセッションが確立される場合、従来方式は適切に対応することができない。

上記問題点に鑑み、本発明の課題は、ＳＩＰへの追加的拡張を行うことなく、ＲＴＳＰセッションＩＤとＳＩＰセッションＩＤとの対応付けを可能にすることである。

上記課題を解決するため、本発明の一態様は、制御用通信路とデータ用通信路とを確立するための通信管理セッションにおいて、サーバが端末から制御用通信路情報を受信するステップと、前記通信管理セッションを特定する第１セッション識別子と前記受信した制御用通信路情報とを関連付けて前記サーバに格納するステップと、前記第１セッション識別子により特定される通信管理セッションにおいて確立された制御用通信路を介し、前記サーバが前記端末から前記制御用通信路情報を含むストリーム制御セッション確立要求を受信するステップと、前記サーバが前記ストリーム制御セッション確立要求に係るストリーム制御セッションの第２セッション識別子を決定し、前記受信した制御用通信路情報と関連付けされた前記第１セッション識別子と関連付けて前記決定された第２セッション識別子を格納するステップとを有する方法に関する。

また、本発明の他の態様は、制御用通信路とデータ用通信路とを確立するための通信管理セッションにおいて端末から制御用通信路情報を受信する通信制御部と、前記通信管理セッションを特定する第１セッション識別子と前記受信した制御用通信路情報とを関連付けて格納する格納部とを有する配信サーバであって、前記第１セッション識別子により特定される通信管理セッションにおいて確立された制御用通信路を介し前記端末から前記制御用通信路情報を含むストリーム制御セッション確立要求をさらに受信すると、前記通信制御部は、前記ストリーム制御セッション確立要求に係るストリーム制御セッションの第２セッション識別子を決定し、前記受信した制御用通信路情報と関連付けされた前記第１セッション識別子と関連付けて前記決定された第２セッション識別子を前記格納部に格納する配信サーバに関する。

本発明の上記態様によると、ＳＩＰへの追加的拡張を行うことなく、ＲＴＳＰセッションＩＤとＳＩＰセッションＩＤとの対応付けが可能になる。

図１は、従来技術によるデータ伝送処理を示す。 図２は、従来技術によるデータ伝送処理を示す。 図３は、本発明の一実施例による端末の構成を示す。 図４は、本発明の一実施例による配信サーバの構成を示す。 図５は、本発明の一実施例によるデータ伝送処理を示す。 図６は、本発明の一実施例によるストリーム制御情報管理テーブルを示す。 図７は、本発明の一実施例によるデータ伝送処理を示す。 図８は、本発明の一実施例によるストリーム制御情報管理テーブルを示す。 図９は、本発明の一実施例によるデータ伝送処理を示す。

以下、図面に基づいて本発明の実施の形態を説明する。

図３を参照して、本発明の一実施例による端末を説明する。本実施例の端末は、ネットワークを介しサーバ等の外部装置と通信するための通信機能を有する。端末は、典型的には、補助記憶装置、メモリ装置、ＣＰＵ、通信装置、表示装置、入力装置などの各種ハードウェアリソースの１以上から構成される。補助記憶装置は、ハードディスクやフラッシュメモリなどから構成され、後述される各種処理を実現するプログラムやデータを格納する。メモリ装置は、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）などから構成され、プログラムの起動指示があった場合に、補助記憶装置からプログラムを読み出して格納する。ＣＰＵは、情報を処理するプロセッサとして機能し、メモリ装置に格納されたプログラムに従って後述される各種機能を実現する。通信装置は、ネットワークを介し他の装置と有線及び／又は無線接続するための各種通信回路から構成される。通信装置はさらに、ネットワーク上のサーバなどの他の装置と接続するための通信インタフェースなどを有する。表示装置は、ディスプレイなどから構成され、配信サーバから受信したコンテンツやプログラムによるＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）等を表示する。入力装置は、典型的には、操作ボタン、キーボード、マウス等で構成され、端末のユーザが様々な操作命令を入力するのに用いられる。なお、本発明の以下の実施例で使用される端末は、上述したハードウェア構成に限定されるものでなく、ネットワークを介しサーバと双方向通信するための機能を有する他の何れか適切な装置であってもよい。

図３は、本発明の一実施例による端末の構成を示す。本実施例では、端末１００は、配信サーバ２００との間の通信路を確立するための通信管理プロトコルとしてＳＩＰを使用する。また、端末１００は、ＳＩＰにより確立される制御用通信路におけるストリーム制御用プロトコルとしてＲＴＳＰを、ＳＩＰにより確立されるデータ用通信路におけるストリーム配信用プロトコルとしてＲＴＰを使用して、配信サーバ２００と通信し、映像コンテンツなどのデータを取得する。しかしながら、本発明は、これら特定のプロトコルに限定されるものでなく、サーバ等の外部装置からデータを取得するため、制御用通信路とデータ用通信路とを使用する他の何れか適切な通信プロトコルであってもよい。

図３に示されるように、端末１００は、ユーザインタフェース部１１０と、通信制御部１２０と、送受信部１３０とを有する。

ユーザインタフェース部１１０は、ユーザから各種命令を受信し、受信した命令に対応する処理結果を提供する。具体的には、ユーザインタフェース部１１０が、配信サーバ２００から映像コンテンツなどのデータを取得するようユーザから指示されると、通信制御部１２０に当該データ取得リクエストを送信する。通信制御部１２０が、後述される処理を介し要求されたデータを取得し、これをユーザインタフェース部１１０に提供すると、ユーザインタフェース部１１０は、ユーザからのリクエストに応じて取得したデータを表示、再生等することによって、ユーザに提供する。

通信制御部１２０は、配信サーバ２００から映像コンテンツなどのデータを取得するリクエストをユーザインタフェース部１１０から受信すると、配信サーバ２００との間で、ＳＩＰセッションによりストリーム制御用のＲＴＳＰ用通信路とストリーム配信用のＲＴＰ用通信路とを確立する。具体的には、通信制御部１２０は、送受信部１３０を介し配信サーバ２００に対して、当該ＳＩＰセッションに係るＳＩＰセッションＩＤと、ＲＴＳＰ用通信路情報として端末１００側のストリーム制御用のＩＰアドレス、ポート番号、プロトコルなどを送信し、ＲＴＰ用通信路情報として端末１００側のストリーム配信用のＩＰアドレス、ポート番号などを送信する。その後、配信サーバ２００から応答メッセージとして、ＳＩＰセッションＩＤと、配信サーバ２００側のストリーム制御用及びストリーム配信用のＩＰアドレス、ポート番号及びプロトコルなどを受信すると、通信制御部１２０は、配信サーバ２００との間でＲＴＳＰ用通信路とＲＴＰ用通信路とが確立されたことを確認する。

このようにしてＲＴＳＰ用通信路とＲＴＰ用通信路が確立されると、通信制御部１２０は、配信サーバ２００との間でＲＴＳＰセッションを確立するため、端末１００側のストリーム制御用のＩＰアドレスとポート番号とをヘッダ情報（ＩＰヘッダ）として含むＲＴＳＰ信号を生成し、生成したＲＴＳＰ信号を送受信部１３０を介し配信サーバ２００に送信する。ＲＴＳＰ信号の応答として配信サーバ２００からストリーム制御のためのＲＴＳＰセッションＩＤを受信すると、通信制御部１２０は、このＲＴＳＰセッションＩＤを用いて、ユーザからリクエストされたストリーム制御、例えば、配信サーバ２００から送信される映像コンテンツの再生、停止、早送りなどのストリーム制御を送受信部１３０を介し配信サーバ２００にリクエストする。その後、通信制御部１２０は、リクエストしたストリーム制御に従って、映像コンテンツなどのデータを送受信部１３０を介し配信サーバ２００から取得し、取得したデータをユーザインタフェース部１１０に提供する。

次に、図４を参照して、本発明の一実施例による配信サーバを説明する。本実施例のサーバは、典型的には、補助記憶装置、メモリ装置、ＣＰＵ、通信装置などの各種ハードウェアリソースの１以上から構成される。補助記憶装置は、ハードディスクやフラッシュメモリなどから構成され、後述される各種処理を実現するプログラムやデータを格納する。メモリ装置は、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）などから構成され、プログラムの起動指示があった場合に、補助記憶装置からプログラムを読み出して格納する。ＣＰＵは、情報を処理するプロセッサとして機能し、メモリ装置に格納されたプログラムに従って後述される各種機能を実現する。通信装置は、ネットワークを介し他の装置と接続するための各種通信回路から構成される。通信装置は、典型的には、各種ネットワークと接続するための通信インタフェースなどを有する。後述される配信サーバ２００とプレゼンスサーバ３００とは、典型的には、上述したようなハードウェア構成を有するが、本発明はこれに限定されるものでなく、後述される各機能を実現可能な他の何れか適切なハードウェア構成を有してもよい。

図４は、本発明の一実施例による配信サーバの構成を示す。本実施例では、配信サーバ２００は、端末１００に通信接続され、通信管理プロトコルとしてＳＩＰを、ストリーム制御用プロトコルとしてＲＴＳＰを、ストリーム配信用プロトコルとしてＲＴＰを使用して、端末１００と通信し、映像コンテンツなどのデータを提供する。さらに、配信サーバ２００は、プレゼンスサーバ３００と通信接続され、端末１００の現在のストリーム制御状況を通知する。しかしながら、本発明は、これら特定のプロトコルに限定されるものでなく、端末等の外部装置にデータを提供するため制御用通信路とデータ用通信路とを使用する他の何れか適切な通信プロトコルであってもよい。

図４に示されるように、配信サーバ２００は、送受信部２１０と、通信制御部２２０と、ストリーム制御情報管理テーブル格納部２３０とを有する。

送受信部２１０は、通信制御部２２０の制御の下で端末１００やプレゼンスサーバ３００と信号をやりとりする。送受信部２１０は、受信した信号からデータを抽出し、通信制御部２２０に提供する。また、送受信部２１０は、通信制御部２２０から提供されたデータに基づき信号を生成し、端末１００やプレゼンスサーバ３００に送信する。

通信制御部２２０は、端末１００がＳＩＰセッションにより配信サーバ２００との間でストリーム制御用のＲＴＳＰ用通信路とストリーム配信用のＲＴＰ用通信路とを確立するため、ＳＩＰセッションＩＤと端末１００側のＩＰアドレス、ポート番号、プロトコルなどのＲＴＳＰ用通信路情報とＲＴＰ用通信路情報とを配信サーバ２００に送信すると、送受信部２１０を介しこれらの情報を受信する。通信制御部２２０は、受信したＳＩＰセッションＩＤと、ＲＴＳＰ用通信路情報のＩＰアドレスとポート番号とをストリーム制御情報管理テーブル格納部２３０に送信する。通信制御部２２０は、ＲＴＳＰ用通信路とＲＴＰ用通信路とが確立されたことを示すための応答メッセージとして、ＳＩＰセッションＩＤと、配信サーバ２００側のストリーム制御用及びストリーム配信用のＩＰアドレス及びポート番号を送受信部２１０を介し端末１００に送信する。

ＲＴＳＰ用通信路とＲＴＰ用通信路との確立後、端末１００からＲＴＳＰセッションの確立をリクエストするＲＴＳＰ信号を受信すると、通信制御部２２０は、要求されたＲＴＳＰセッションのＲＴＳＰセッションＩＤを決定する。さらに、通信制御部２２０は、送受信部２１０によりＲＴＳＰ信号のヘッダ情報から抽出された端末１００側のＩＰアドレスとポート番号とを検索キーとして、ストリーム制御情報管理テーブル格納部２３０にアクセスして、ストリーム制御情報管理テーブルの該当するレコードを検索する。該当するレコードが検出されると、通信制御部２２０は、決定したＲＴＳＰセッションＩＤを検出したレコードに追加する。これにより、ＳＩＰセッションＩＤとＲＴＳＰセッションＩＤとの対応付けが可能となる。通信制御部２２０は、応答メッセージとして端末１００にＲＴＳＰセッションＩＤを通知する。

なお、該当するレコードがすでに他のＲＴＳＰセッションＩＤと関連付けされていた場合、通信制御部２２０は、新たなレコードを作成し、当該レコードにおいてＳＩＰセッションＩＤとＲＴＳＰセッションＩＤとを関連付けて記録するようにしてもよい。これにより、１つのＳＩＰセッションに対して複数のＲＴＳＰセッションを対応付けすることが可能となる。

その後、端末１００から通知したＲＴＳＰセッションＩＤと共にストリーム制御（映像コンテンツの再生、一時停止、早送り、巻き戻しなど）のリクエストを受信すると、通信制御部２２０は、リクエストされたストリーム制御を実行すると共に、ストリーム制御情報管理テーブル格納部２３０にアクセスして、受信したＲＴＳＰセッションＩＤに対応するＳＩＰセッションＩＤを検索する。対応するＳＩＰセッションＩＤを検出すると、通信制御部２２０は、検出したＳＩＰセッションＩＤを用いて、当該ＳＩＰセッションにより確立された通信路を管理し、プレゼンスサーバ３００にストリーム制御の状況を通知する。

ストリーム制御情報管理テーブル格納部２３０は、通信制御部２２０から受信したＳＩＰセッションＩＤと、端末１００側のＩＰアドレス及びポート番号と、ＲＴＳＰセッションＩＤとを、後述されるようなストリーム制御情報管理テーブルに関連付けて格納する。

なお、端末１００が１つのＳＩＰセッションにおいて複数のストリーム制御をリクエストした場合、通信制御部２２０は、上述したＲＴＳＰ用通信路とＲＴＰ用通信路との確立後の処理を同様に実行してもよい。この場合、１つのＳＩＰセッションＩＤに対して複数のＲＴＳＰセッションＩＤが対応付けされることになる。

次に、図５〜９を参照して、本発明の一実施例によるデータ伝送処理を説明する。本実施例では、通信管理プロトコルとしてＳＩＰを、ストリーム制御用プロトコルとしてＲＴＳＰを、ストリーム配信用プロトコルとしてＲＴＰが使用される。しかしながら、本発明は、これら特定のプロトコルに限定されるものでなく、サーバが端末等の外部装置にデータを提供するため制御用通信路とデータ用通信路とを使用する他の何れか適切な通信プロトコルであってもよい。

まず、ステップ１０１〜１０３により、端末１００と配信サーバ２００との間で、ＳＩＰセッションによりストリーム制御用のＲＴＳＰ用通信路とストリーム配信用のＲＴＰ用通信路とが確立される。

ステップ１０１において、端末１００は、配信サーバ２００に対してＳＩＰセッションＩＤとＲＴＳＰ用通信路及びＲＴＰ用通信路の情報を通知する。より詳細には、端末１００は、これらの通信路を確立するためのＳＩＰセッションのＳＩＰセッションＩＤと共に、配信サーバ２００に対してＲＴＳＰ用通信路情報として端末１００側のストリーム制御用のＩＰアドレス、ポート番号、プロトコルなどを通知し、ＲＴＰ用通信路情報として端末１００側のストリーム配信用のＩＰアドレス、ポート番号などを通知する。

なお、この通知を行うための通信路上において、ＩＰアドレス及びポート番号を変換するＮＡＴ／ＮＡＰＴ（Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｉｏｎ／Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｐｏｒｔ Ｔｒａｎｓｌａｔｉｏｎ）が実行される場合、ネットワーク上に存在するサーバ（例えば、ＩＭＳ（ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ）におけるＰ−ＣＳＣＦ（Ｐｒｏｘｙ−Ｃａｌｌ Ｓｅｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ）など）が適宜、通信路の情報を書き換えるようにしてもよい（非特許文献３）。

ステップ１０２において、配信サーバ２００は、受信したＳＩＰセッションＩＤと、ストリーム制御用通信路であるＲＴＳＰ用通信路情報とを関連付けて、図６に示されるようなストリーム制御情報管理テーブルに格納する。

図示される実施例では、ストリーム制御情報管理テーブルは、「ＳＩＰセッションＩＤ」、「ストリーム制御用通信路のＩＰアドレス」、「ストリーム制御用通信路のポート番号」及び「ストリーム制御セッションＩＤ」の各データ項目を有し、受信した各データ項目に対応するレコードをテーブル形式により格納する。例えば、配信サーバ２００が端末１００から「ＳＩＰセッションＩＤ：ＹＹＹＹＹＹＹＹ」と、ＲＴＳＰ用通信路情報（ストリーム制御用通信路情報）として「ＩＰアドレス：ＩＰａ１」と「ポート番号Ｐａ１」とを受信すると、配信サーバ２００は、図６に示されるようなストリーム制御情報管理テーブルに受信した「ＳＩＰセッションＩＤ：ＹＹＹＹＹＹＹＹ」、「ＩＰアドレス：ＩＰａ１」及び「ポート番号Ｐａ１」を関連付けて１つのレコードとして記録する。この時点では、配信サーバ２００は、「ストリーム制御セッションＩＤ」を受信していないため、ストリーム制御情報管理テーブルの「ストリーム制御セッションＩＤ」のデータ項目は、「Ｎｕｌｌ」が入力される。

ステップ１０３において、配信サーバ２００は、端末１００に対してＳＩＰセッションＩＤとＲＴＳＰ用通信路及びＲＴＰ用通信路の情報を通知する。より詳細には、配信サーバ２００は、端末１００に対する応答メッセージとして、ＲＴＳＰ用通信路情報として、配信サーバ２００側のストリーム制御用のＩＰアドレス、ポート番号などを通知し、ＲＴＰ用通信路情報として、配信サーバ２００側のストリーム配信用のＩＰアドレス、ポート番号などを通知する。これにより、端末１００と配信サーバ２００との間で、ＲＴＳＰ用通信路とＲＴＰ用通信路とが確立される。

次に、端末１００は、例えば、映像コンテンツに対する再生、一時停止、早送りなど、ユーザからリクエストされたストリーム制御を配信サーバ２００に対して要求する。ステップ１０４において、端末１００は、ストリーム制御用プロトコルであるＲＴＳＰによるＲＴＳＰ信号を用いて、配信サーバ２００に対してＲＴＳＰセッションの確立を要求する。本実施例では、端末１００は、このＲＴＳＰ信号のヘッダ情報（ＩＰヘッダなど）に、端末１００側のストリーム制御用のＩＰアドレス及びポート番号を記述して、配信サーバ２００にストリーム制御要求のためのＲＴＳＰ信号を送信する。

ステップ１０５において、ストリーム制御要求のためのＲＴＳＰ信号を受信すると、配信サーバ２００は、まず当該ストリーム制御要求に係るＲＴＳＰセッションＩＤを決定する。さらに、配信サーバ２００は、受信したＲＴＳＰ信号のヘッダ情報から端末１００側のストリーム用のＩＰアドレス及びポート番号を抽出し、これを検索キーとしてストリーム制御情報管理テーブルの該当するレコードを検索する。この検索により該当するレコードが検出されると、配信サーバ２００は、図８に示されるように、当該レコードのデータ項目であるＲＴＳＰセッションＩＤに、決定したＲＴＳＰセッションＩＤを記録する。これにより、配信サーバ２００は、ＳＩＰセッションＩＤとＲＴＳＰセッションＩＤとの対応関係を取得できる。

ステップ１０６において、配信サーバ２００は、端末１００に対して決定したＲＴＳＰセッションＩＤを通知する。

ステップ１０７において、端末１００は、ステップ１０６で通知されたＲＴＳＰセッションＩＤを用いて、所望するストリーム制御（再生、一時停止、早送りなど）を要求する。

ステップ１０８において、端末１００からＲＴＳＰセッションＩＤによるストリーム制御要求を受信すると、配信サーバ２００は、要求されたストリーム制御を実行すると共に、ステップ１０５で更新されたストリーム制御情報管理テーブルにおいて、受信したＲＴＳＰセッションＩＤに対応するＳＩＰセッションＩＤを検索する。

ステップ１０９において、配信サーバ２００は、ステップ１０８において検出したＳＩＰセッションＩＤを用いて、所望されたストリーム制御に対応して通信路を管理し（ストリームの停止の場合には、通信路を切断するなど）、プレゼンスサーバ３００に対してストリーム制御の現状（プレゼンス情報）を通知する。

上述した本発明の実施例によると、既存のＳＩＰ信号に記述される情報、具体的には、ＩＰアドレスとポート番号とに基づきＳＩＰセッションＩＤとＲＴＳＰセッションＩＤとの対応付けが行われる。これにより、既存のＳＩＰ仕様を拡張することなく、ＳＩＰセッションとＲＴＳＰセッションとの対応付けが可能となる。このため、既存の端末、端末と配信サーバとの間のＳＩＰ関連のインタフェースに変更を加えることなく使用して、ＳＩＰセッションとＲＴＳＰセッションとの対応付けを行うことができる。また、あるプロトコルの拡張が他のプロトコルに及ぼす影響を回避することも可能であり、一方のプロトコルの拡張を行った場合に、そのプロトコルを処理する機能部のみを拡張するだけでよい。すなわち、他のプロトコルの処理機能部の拡張が不要となる。

さらに、上述した本発明の実施例によると、グローバルにユニークなパラメータであるＩＰアドレスとポート番号の組をキーとして、ＳＩＰセッションＩＤとＲＴＳＰセッションＩＤとの対応関係が決定される。そのため、ＳＩＰセッションＩＤとＲＴＳＰセッションＩＤとが１対１の対応付けとなっていない場合にも、すなわち、１対ｎとなっている場合にも対応することが可能となる。

以上、本発明の実施例について詳述したが、本発明は上述した特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

１００ 端末
２００ 配信サーバ
３００ プレゼンスサーバ

Claims (8)

1. 制御用通信路とデータ用通信路とを確立するための通信管理セッションにおいて、サーバが端末から制御用通信路情報を受信するステップと、
   前記通信管理セッションを特定する第１セッション識別子と前記受信した制御用通信路情報とを関連付けて前記サーバに格納するステップと、
   前記第１セッション識別子により特定される通信管理セッションにおいて確立された制御用通信路を介し、前記サーバが前記端末から前記制御用通信路情報を含むストリーム制御セッション確立要求を受信するステップと、
   前記サーバが前記ストリーム制御セッション確立要求に係るストリーム制御セッションの第２セッション識別子を決定し、前記受信した制御用通信路情報と関連付けされた前記第１セッション識別子と関連付けて前記決定された第２セッション識別子を格納するステップと、
   を有する方法。
2. 前記サーバが前記端末に前記決定された第２セッション識別子を送信するステップと、
   前記サーバが前記端末から前記第２セッション識別子を含むストリーム制御要求を受信し、前記サーバに格納される前記受信した第２セッション識別子に対応する前記第１セッション識別子を検出するステップと、
   前記サーバが前記検出した第１セッションＩＤを用いて、前記受信したストリーム制御要求に係るストリーム制御を実行又は通知するステップと、
   をさらに有する、請求項１記載の方法。
3. 前記制御用通信路情報は、前記制御用通信路のアドレス情報とポート情報とを含む、請求項１又は２記載の方法。
4. 前記通信管理セッションは、ＳＩＰセッションであり、
   前記ストリーム制御セッションは、ＲＴＳＰセッションである、請求項１乃至３何れか一項記載の方法。
5. 制御用通信路とデータ用通信路とを確立するための通信管理セッションにおいて端末から制御用通信路情報を受信する通信制御部と、
   前記通信管理セッションを特定する第１セッション識別子と前記受信した制御用通信路情報とを関連付けて格納する格納部と、
   を有する配信サーバであって、
   前記第１セッション識別子により特定される通信管理セッションにおいて確立された制御用通信路を介し前記端末から前記制御用通信路情報を含むストリーム制御セッション確立要求を受信すると、前記通信制御部は、前記ストリーム制御セッション確立要求に係るストリーム制御セッションの第２セッション識別子を決定し、前記受信した制御用通信路情報に関連付けされた前記第１セッション識別子と関連付けて前記決定された第２セッション識別子を前記格納部に格納する配信サーバ。
6. 前記通信制御部は、前記端末に前記決定された第２セッション識別子を送信した後、前記端末から前記第２セッション識別子を含むストリーム制御要求を受信すると、前記格納部に格納される前記受信した第２セッション識別子に対応する前記第１セッション識別子を検出し、前記検出した第１セッションＩＤを用いて前記受信したストリーム制御要求に係るストリーム制御を実行又は通知する、請求項５記載の配信サーバ。
7. 前記制御用通信路情報は、前記制御用通信路のアドレス情報とポート情報とを含む、請求項５又は６記載の配信サーバ。
8. 前記通信管理セッションは、ＳＩＰセッションであり、
   前記ストリーム制御セッションは、ＲＴＳＰセッションである、請求項５乃至７何れか一項記載の配信サーバ。

Images