JP2004064734A

JP2004064734A - 電気通信システム、ゲートウェイ及びストリーミングビデオコンテンツの送信方法

Info

Publication number: JP2004064734A
Application number: JP2003128940A
Authority: JP
Inventors: Michel Alexander Bais; マイケル　アレキサンダー　ベイス; Rudi Schramp; ルディ　シュランプ; Franklin Selgert; フランクリン　セルガート; Frederik Harm Klok; フレデリック　ハーム　クロック
Original assignee: Koninklijke KPN NV
Current assignee: Koninklijke KPN NV
Priority date: 2002-05-07
Filing date: 2003-05-07
Publication date: 2004-02-26
Anticipated expiration: 2023-05-07
Also published as: US20030210683A1; JP3909303B2

Abstract

【課題】ともにテレビ会議がイネーブルされた（例えば、Ｈ．３２４Ｍ）移動端局と接続される回線交換網及びパケット交換網を有する電気通信システムを提供する。
【解決手段】前記移動端局からインターネット５内のストリーミングビデオサーバ９へのストリーミングビデオコンテンツの送信のために、ゲートウェイ７は、一方の側で回線交換網に接続され、他方の側でインターネットに接続される。前記移動端局およびゲートウェイが、移動端局間でのテレビ会議用のプロトコルに準拠してビデオビットストリームを変換するために適していることを特徴とする電気通信システム。
【選択図】　　　図１

Description

【０００１】
【発明の属する技術分野】
本発明は、移動端局からインターネット内のストリーミングビデオサーバにストリーミングビデオコンテンツを送信するシステム及び方法に関わる。本発明は、ストリーミングビデオコンテンツの移動端局への送信に使用されるゲートウェイも指す。
【０００２】
【従来の技術】
デジタルカメラとハンディカムの売り上げは急速に拡大している。休日、出張等の間のイベントをニアリアルタイムで記録するためにこれらのカメラを使用することは、ピクチャまたはショートビデオクリップを電子メールで送信するレベルにある。自国（ｈｏｍｅ）の状況では、人はすでに、例えば自分自身をインターネット上で見てもらうためにいわゆるウェブ（ＷＥＢ）カメラを使用している。ケーブルとＡＤＳＬを介したワイドバンドインターネットアクセスにより、これらのサービスはなおさらに普及している。
【０００３】
【発明が解決しようとする課題】
本発明の目的は、移動端局によりインターネットに発信されるストリーミングビデオコンテンツのアップロードを可能にするために、別の技術分野用に、つまり電話間のテレビ会議用に標準化されたプロトコルを使用する電気通信システムを提供することにある。
【０００４】
【課題を解決するための手段】
本発明は、一方の側で回線交換網に接続され、他方の側でインターネットに接続されるゲートウェイを利用する、移動端局からインターネットストリーミングサーバへのストリーミングビデオ信号の送信に適した電気通信システムを提示し、前記ゲートウェイは、インターネットで互換性のあるストリーミングビデオフォーマットのファイルへの、回線交換網を介して移動端局から受信されるのに適したフォーマットのストリーミングビデオビットストリームの変換に格好である。移動端局間のテレビ会議用に標準化されたプロトコルが好ましくはオプションで利用できるため、現在、このような変換ゲートウェイが移動端局と通信するための標準プロトコルはない。このようなテレビ会議が、テレビ会議がイネーブルされた移動電話を備えた二人またはそれ以上のユーザが互いとテレビ会議を行うことができるアーキテクチャで使用するために開発されたことが注記される。
【０００５】
インターネットサーバまたはクライアントにストリーミングビデオコンテンツをアップロードするためにこのような「テレビ会議プロトコル」を使用できるために、移動端局と前記一方の側にあるゲートウェイは、好ましくは、電話間のテレビ会議用のプロトコルに準拠して、ビデオビットストリームを交換するために適している。ＩＴＵ　Ｈ．３２４Ｍテレビ会議プロトコルは意図されている目的に非常に適している。したがって、本発明の１つの態様は、移動端局によりインターネットに発信されるストリーミングビデオコンテンツのアップロードを可能にするために、別の技術分野用に、つまり電話間のテレビ会議用に標準化されたプロトコルを使用することである。
【０００６】
本発明の第２の態様は、ビデオコンテンツ記憶の管理に対処する。変換されたストリーミングファイルの記憶ターゲットを管理できるために、システムは、好ましくは、例えば前記パケット交換網を介して前記移動端局と接続され、関連する移動端局ごとに端局識別子を登録し、関連する移動端局によって発信されるインターネットで互換性のあるストリーミングビデオが記憶される、あるいは記憶されることになるインターネット記憶場所のアドレスとその識別子をリンクするのに適した登録サーバを有してよい。このような登録サーバの使用を可能とするために、システムは、好ましくは、登録サーバで、その検出される端局識別子により誘導され、関連する移動端局により発信されるインターネットで互換性のあるストリーミングビデオが記憶されることになるインターネット記憶場所のアドレスを検索し、そのインターネット記憶場所アドレスに前記インターネットで互換性のあるストリーミングビデオを転送する手段だけではなく、回線交換網を介して関連する端局の識別子（例えば、その発呼回線識別子、ＣＬＩ）を検出する手段も有する。
【０００７】
好ましくは、関連する端局識別子を検出する前記手段及びインターネット記憶場所のアドレスを登録サーバで検索し、そのインターネット記憶場所アドレスに前記インターネットで互換性のあるストリーミングビデオを転送する前記手段は、変換ゲートウェイ内に位置する。代替策として、前記検出手段、検索手段及び転送手段は登録サーバ内に位置することがある。その場合、ゲートウェイの出力――端局識別子を含む――は以後、関連する記憶領域アドレスを指す端局識別子によって誘導され、関連する記憶場所に変換済みのコンテンツを分散する登録サーバに送信されるだろう。別のオプションは、前記検出手段、検索手段、及び転送手段を任意の他のサーバに位置させる、あるいはそれらの手段をさまざまなサーバ上で分散させることである。
【０００８】
Ｈ．３２４Ｍテレビ会議プロトコルがイネーブルされた電話と組み合わせて提案されているアーキテクチャを用いる場合――変換ゲートウェイと好適登録サーバを除き――標準構成要素を使用して、このような移動電話のそれぞれからインターネットサーバ及びクライアント（例えばＰＣまたは他の移動電話）へ、パーティ、自動車事故などの計画されていたイベント及び計画されていないイベントの「ライブ」放送を実行することが可能である。
【０００９】
電気通信システムは、ストリーミングビデオコンテンツを発信する、あるいは発信した、前記コンテントの記憶場所へのリンクを有する端局にメッセージを送信する手段を有してよい。
【００１０】
それらの手段は、発信側ユーザ端末とは異なる１つまたは複数の他のユーザ端末に同様のメッセージを送信するためにイネーブルされ、前記コンテンツの記憶場所及び／または前記ストリーミングビデオコンテンツ自体の少なくとも一部に対するリンクを有してよい。発信側端末及び／または他の（発信側ではない）端末に対する関連するメッセージは、例えば電子メールメッセージ、「ＳＭＳ」メッセージ、あるいは（例えばＭＳＮまたはＩＣＱをベースにした）「インスタントメッセージ通信」メッセージとして送信されてよい。
【００１１】
【発明の実施の形態】
図１では、端局１は、基地局及び「無線網コントローラ」（ＲＮＣ）２を介して回線交換網（ＣＳＮ）３とパケット交換網（ＰＳＮ）４と接続可能である。ＰＳＮ４を介して、つまりインターネットゲートウェイ（ＩＧ）６（ａ）を介して、該端局１はインターネット（ＩＰ）５をブラウズできる。端局ユーザは、ＰＳＮ４を介して、認証ウェブ（ＷＥＢ）サーバ８（ＡＷＳ）で、「移動ウェブ（ＷＥＢ）カムストリーミング及びメーリングサービス」（ｂ）に加入し、許可されたユーザがＩＰストリーミングサーバ（ＳＳ）９（ｆ）にビデオコンテンツをストリーミングできるようにする。認証ウェブ（ＷＥＢ）サーバ８での加入プロセスの一部はユーザの電話番号とメールアドレスであってよい。
【００１２】
加入中、ユーザは、ｅメールによってあるいはＳＭＳによってユーザに通信されることがある、ストリーミングサーバ９にある（明示的に示されていない）データベース内の場所アドレスを割り当てられる。ユーザが「移動ウェブカミング（ｃａｍｍｉｎｇ）」をしている場合には、該記憶場所がユーザのストリームファイルを格納する。この場所のアドレスはＡＷＳ８にある（明示的に示されていない）データベースに保存される。該場所アドレスはユーザの電話番号にリンクされる。
【００１３】
興味のあるイベントが発生すると、ユーザは端局１を介してＨ．３２４ゲートウェイ７の番号をダイヤルし（ｃ）、その後ユーザはインターネットに「ライブ」でイベントをストリーミングし、それを例えばストリーミングサーバ９（ｅ）に記憶することができる。ストリーミングがストリーミングサーバ９を介して開始する前に、Ｈ．３２４ゲートウェイ７は、認証サーバ８にあるユーザの発呼回線識別子（ＣＬＩ）――ユーザの電話番号――をチェックし、ユーザの該ＣＬＩによって誘導され、アップストリーミングされたコンテンツ（ｄ）のユーザの記憶場所を検索する。インターネット５を介して、ＰＣユーザ１０は、ＰＣストリーミングクライアント（ｇ）を介して、ライブで、あるいは関連する記憶場所にしばらく記憶された後に、ストリーミングサーバ９からアップストリーミングされたコンテンツを表示することができる。
【００１４】
まず最初に、ビデオ録画セッション中、またはビデオ録画セッション後に、ユーザはメッセージサーバ（ＭＳ）１１によって、ユーザの電話１で電子メールまたはＳＭＳメッセージを、あるいは「インスタントメッセージ通信（ＩＭ）を介してユーザのＰＣ１０上で――ＩＰゲートウェイ６とＰＳＮ４を経由して――あるいは記憶されているコンテンツ（ｈ，ｉ）の場所へのリンクを有するユーザのＰＣ１０でメッセージを受信してよい。ユーザの電話にメッセージを送信することに加え、ユーザに関連する記憶領域アドレスを知らせるために，ユーザ自身の他に、他の電話及び／またはＰＣユーザにいつストリーミングビデオの録画が開始するのか、あるいはそれがいつ終了したのかを知らせるオプションをイネーブルすることが好ましい。例えば，ユーザは自分の友人の関心をユーザの移動端末を介して録画されたユーザの最近のビデオに引き付けることができる。通知は、ストリーミングビデオセッションの始まりに、セッション中に、あるいはセッション後に、メッセージサーバ１１を使用してそれらの友人に送信されてよい。特別のオプションとして、ストリーミングビデオファイルまたは（紹介ビデオ「トレーラー」のような）？？の一部がメッセージの中に組み込まれる、あるいは添付されてよい。
【００１５】
移動端末１からＨ．３２４ゲートウェイ７への呼は、交換６４Ｋｂｉｔチャネルを介して送られてよい。Ｈ．３２４Ｍゲートウェイ７は、既製のＩＳＤＮ接続を介して回線交換網３と接続されてよい。この簡略な接続モデルのため、他のＵＭＴＳ網からＨ．３２４ゲートウェイに接続することが可能である場合がある。
【００１６】
最終的に、Ｈ．３２４Ｍゲートウェイの例示的なソフトウェアインプリメンテーションは図２に説明され，図示される。図２は以下のラベルを含む。

【００１７】
Ｈ．３２４Ｍソフトウェアの説明
コード化の原則
（あらゆるところではないが、多くの場所で）私たちが使用したいくつかの原則は以下の通りである。
−１つのクラスは、クラスと同じファイル名が付けられた、１つの．ｃｐｐファイルが（あらゆるところではないが、多くの場所で）私たちが使用したいくつかの原則は以下の通りである。
【００１８】
−１つのクラスは、クラスと同じファイル名が付けられた、１つの．ｃｐｐファイルが加えられた１つの．ｈファイルに内にある。
【００１９】
−パラメータはｆで始まり、グローバル変数はｇで始まり、実数定数はｃで始まる。局所的な変数はＩで始まることがある。属性（クラスデータメンバ）はａで始まる。
【００２０】
−クラス名は大文字で始まる。関数、パラメータ、及び変数の名前は小文字で始まる。
【００２１】
−ブールの場合、私たちはブール（ＢＯＯＬ）、真（ＴＲＵＥ）、及び偽（ＦＡＬＳＥ）を使用する。そして、同じことを意味するだろう他の綴りは（それらがわずかに異なるインプリメンテーションとなるため）使用しない。
【００２２】
−（「ダーティ（ｄｉｒｔｙ）」あるいは「レイジー（ｌａｚｙ）」なプログラミングのため）注意を要するいくつかのコードは２つの＠符号（＠＠）で記されている。
【００２３】
一般的な構造
「ＭＭＭＥＸＥ」ソースコードは、以下の３つの主要なセクションから成り立っており、それぞれがＭＳ　Ｖｉｓｕａｌ　Ｃ＋＋の中で「プロジェクト」として定義されている。
−Ｈ２４５
−Ｈ２４５ｃｏｄｅｃ
―ＭＭＭ
Ｈ２４５とＨ２４５ｃｏｄｅｃは、ＭＭＭとともにリンクされるライブラリである。これは実際的な理由のためである。つまり、Ｈ２４５メッセージ構文（Ｈ２４５ｃｏｄｅｃ）とメッセージ論理（Ｈ２４５）は別々に開発された。履歴上の理由から、いくつかのソースコードが、ＭＭＭアプリケーションの古い名前である「アリーナ（Ａｒｅｎａ）」を指している。
【００２４】
グローバル（ヘルパー）クラス
一般的な目的のため、次に示すいくつかの便利なクラスがある。
ＥＳｔｒｉｎｇ――Ｃｓｔｒｉｎｇの「さらにすぐれた」バージョン
ＩｎＦｉｌｅ――ＭＭＭ構成ファイル読み取り、解析するためのクラス
ＳｅｓｓｉｏｎＬｏｇ．Ｌｏｇ――マルチスレッドプログラムでコンテキスト情報を含んだロギングを可能にするクラス
ＳａｆｅＦｉｌｅ――スレッドセーフ（ｔｈｒｅａｄ−ｓａｆｅ）ｉ／ｏファイルクラス
ＴｉｍｅＨａｎｄｌｅｒ、ＴｉｍｅＯｂｊｅｃｔ――タイマ用のクラス（おもにＨ２４５タイマ）
【００２５】
スレッド（Ｔｈｒｅａｄｓ）
Ｍｉｃｒｏｓｏｆｔのマルチスレッドプログラムの方法をカプセル化するため、私たちは独自のスレッドライブラリを作成した。基本的に、スレッドとは、メッセージを送信するためにＴｈｒｅａｄＰｒｏｘｙを使用することによってのみ他のスレッドと通信できるコードの別個の一部である。各スレッドは専用のメッセージ待ち行列を備え、合間にタイマイベントを処理しながらも、待ち行列の中からメッセージを読み取る（ＦＩＦＯ）。メッセージがあるスレッドから別のスレッドに送信されると、このメッセージはパラメータとしてデータを含むことができる。ＴｈｒｅａｄＰｒｏｘｙはパラメータのパックとアンパックを処理する。発呼者−スレッドが被呼者−スレッドから戻り値を必要とする場合、データはＯｕｔｐｕｔＰａｒａｍｅｔｅｒにカプセル化される。ＴｈｒｅａｄＰｒｏｘｙはこのＯｕｔｐｕｔＰａｒａｍｅｔｅｒが充填されるまで、つまりメッセージが被呼者−スレッドによって処理されるまで待機する。このようにして、スレッド間で同期呼を実現することができる。異なるデータ型には、異なるＯｕｔｐｕｔＰａｒａｍｅｔｅｒクラスを必要とする。現在、以下が定義されている。つまり、ＳｔｒｉｎｇＡｒｒａｙＯｕｔｐｕｔＰａｒａｍｅｔｅｒ、ＩｎｔｅｇｅｒＯｕｔｐｕｔＰａｒａｍｅｔｅｒ、ＰｏｉｎｔｅｒＯｕｔｐｕｔＰａｒａｍｅｔｅｒである。プログラム「ＴｅｓｔＴｈｒｅａｄ」は、スレッドがどのように使用されるのかの例である。
【００２６】
Ｈ２４５ＣＯＤＥＣ
コード化されたＨ２４５は、完全にＣ＋＋でプログラミングされている。つまり、ＡＳＮ．１パーサや関与しているものはない。Ｈ２４５コーデックソフトウェアの全体的なインタフェースはｈ２４５ａｓｎ１．ｈの中にあるが、インプリメンテーションは多様なｃｐｐファイルの中にある。この場合、あらゆるクラスには専用の．ｃｐｐファイルと専用の．ｈファイルがなければならないという規則が破られたことになる。
【００２７】
ビットの低レベルのパッキングとアンパッキングは、クラスＢｉｔＢｕｆｆｅｒＭａｎａｇｅｒで実行される。その１番上では、Ｈ２４５構文は、複数のフィールドを含む１つのフィールドとして見なされている。フィールドとは、符号化または復号できる何かである。これらの２つの機能性は１つの方法、「ｅｎｄｅｃｏｄｅ」にある。この理由は、符号化と復号の大部分のインプリメンテーションが同一である（サブフィールドの「ｅｎｄｅｃｏｄｅ」に対する呼び出しから成り立っている）という点である。
【００２８】
いくつかの基本的なＨ２４５ビルディングブロックは、以下のクラスとして実現される。
【００２９】
つまり、ＬｅｎｇｔｈＤｅｔｅｒｍｉｎａｎｔ、Ｅｘｔｅｎｓｉｏｎ、ＳｅｑｕｅｎｃｅＥｘｔｅｎｓｉｏｎ、ＣｈｏｉｃｅＥｘｔｅｎｓｉｏｎ，ＢｏｏｌｅａｎＦｉｅｌｄ、ＮｕｍｂｅｒＦｉｅｌｄ、ＣｏｎｓｔｒａｉｎｅｄＩｎｔｅｇｅｒ，ＮｏｒｍａｌｌｙＳｍａｌｌＩｎｇｅｇｅｒ、ＯｃｔｅｔＳｔｒｉｎｇ、ＧｅｎｅｒａｌＳｔｒｉｎｇ，ＩＡ５Ｓｔｒｉｎｇ、ＯｐｅｎＦｉｅｌｄである。
これらのビルディングブロックを用いて、以下の頻繁に発生する構造を作成した。
つまり、ＣｈｏｉｃｅＦｉｅｌｄ、ＣｈｏｉｃｅＦｉｅｌｄＷｉｔｈｏｕｔＥｘｔｅｎｓｉｏｎ、ＣｈｏｉｃｅＦｉｅｌｄＷｉｔｈＥｘｔｅｎｓｉｏｎ、ＣｈｏｉｃｅＩｎｄｅｘＦｉｅｌｄ、ＣｈｏｉｃｅＩｎｄｅｘＦｉｅｌｄＷｉｔｈＥｘｔｅｎｓｉｏｎ、ＳｅｑｉｅｍｃｅＦｉｅｌｄＷｉｔｈＥｘｔｅｎｓｉｏｎ、ＡｒｒａＦｉｅｌｄである。
【００３０】
他のすべてのｈ２４５クラスは、前記クラスから継承することにより定義される。主要なＨ２４５メッセージはＭｕｌｔｉｍｅｄｉａＳｙｓｔｅｍＣｏｎｔｒｏｌＭｅｓｓａｇｅである。これは、選択肢が、ＲｅｑｕｅｓｔＭｅｓｓａｇｅ、ＲｅｓｐｏｎｓｅＭｅｓｓａｇｅ、ＣｏｍｍａｎｄＭｅｓｓａｇｅ，ＩｎｄｉｃａｔｉｏｎＭｅｓｓａｇｅの内の１つであるＣｈｏｉｃｅＦｉｅｌｄＷｉｔｈＥｘｔｅｎｓｉｏｎである。これらのメッセージは、同様に、文字通りＨ２４５規格（及び私たちが必要とする移動拡張部）に従っているサブフィールドから構成される。すべてのこれらのＨ２４５メッセージのインプリメンテーションはかなりの入力作業であった。ソースコードを可能な限り小さく、簡略に保つために、いくつかのＣマクロが定義された。
フィールドを別のフィールドにコピーできることが必要な場合がある。それらを必要としたそれらのクラスの場合「だけ」、演算子＝（）メソッドを定義した。
【００３１】
Ｈ２４５
Ｈ２４５プロトコルの論理はオブジェクトＨ２４５、Ｈ２４５Ｕｓｅｒ、及びＳｅ^＊＊＊（ＳｅＢｉＣｉ、ＳｅＢｉｃＯ、ＳｅＣｅＩ、ＳｅＣｅＯ、ＳｅＣＩｃＯ、ＳｅＬｃＩ、ＳｅＬｃＯ、ＳｅＭＩＩ、ＳｅＭＩＯ、ＳｅＭｒｌ、ＳｅＭｒＯ、ＳｅＭｓｄ、ＳｅＭｔｌ、ＳｅＭｔＯ、ＳｅＲｍｅｌ、ＳｅＲｍｅＯ，ＳｅＲｔｄ）を使用してシミュレーションされる。これらのオブジェクトは互いにメッセージを送信するが、これらは実際には同期関数呼び出しにすぎない。Ｈ２４５Ｕｓｅｒクラスはインタフェースクラスである。つまり、その関数のインプリメンテーションは「Ｓｅｓｓｉｏｎ」クラスの中にある。
【００３２】
Ｓｅ^＊＊＊クラスは総称クラスＳｅから継承する。このクラスは、トレーシングと符号化のためのヘルパー関数を有する。
【００３３】
ＣＡＰＩ
ＣＡＰＩはＩＳＤＮカード（ｈｔｔｐ：／／ｗｗｗ．ｃａｐｉ．ｏｒｇ）をアドレス指定するための標準ライブラリである。ａｎｓｉ　Ｃライブラリは、ＩＳＤＮのすべての態様に対して非常に詳細な制御を行う幅広い範囲のプラットホームでの単一スレッドアプリケーション向けである。Ｈ３２４ｍサーバ内のＣＡＰＩクラスは、ａｎｓｉ　Ｃライブラリを、Ｈ３２４サーバの待ち行列に基づいたマルチスレッドアーキテクチャと一致するマルチスレッドサポートを備えたオブジェクト指向型ＣＰＰ環境に適応させるためのＣＡＰＩライブラリのカプセル化である。ライブラリはＩＳＤＮ／ＣＡＰＩを（ＴＣＰ、モデム、指定パイプ、共用メモリのような）他の考えられる形のトランスポートから分離するように設計されている。
【００３４】
セッション通信
ＢｙｔｅＳｔｒｅａｍとＢｙｔｅＳｔｒｅａｍＬｉｓｔｅｎｅｒという２つの基本クラスが単一のＩＳＤＮセッションのコアである。ＢｙｔｅＳｔｒｅａｍは、ＩＳＤＮリンクを経由したデータの送信を実現するインタフェースである。ＢｙｔｅＳｔｒｅａｍＬｉｓｔｅｎｅｒは、データの受信者により実現されなければならず、新しいデータの受信を示し、データ送信のためのバッファリングのステータスを示すために使用される。ＩＳＤＮは同期通信媒体である（それは、ＣＡＰＩライブラリの中でＬＡＰＢ層を使用するときは非同期となる場合がある）ため、ＩＳＤＮセッションの送信バッファはつねに充填されていなければならない。送信バッファの充填が不十分な場合、ＩＳＤＮ層はトランスポートの中にランダムバイトを詰め込む。送信バッファが一杯になると、ＩＳＤＮ層はデータをドロップするだろう。セッションは、ＢｙｔｅＳｔｒｅａｍオブジェクトでｓｅｎｄＤａｔａに対する正確に１つの呼を使用して応答することによって、そのＢｙｔｅＳｔｒｅａｍＬｉｓｔｅｎｅｒインタフェース上でｄａｔａＲｅｑｕｅｓｔｅｄ（）メソッドに応答する必要がある。
【００３５】
ＢｙｔｅＳｔｒｅａｍクラスとは、拡張可能な基本クラスであり、Ｃａｐｉバージョンは考えられるインプリメンテーションの１つにすぎない。現在は以下のインプリメンテーションが存在する。
１）ＣａｐＬｏｇｉｃａｌＣｏｎｎｅｃｔｉｏｎＰｒｏｘｙ
２）ＩｎｔｅｒｎａｌＢｙｔｅＳｔｒｅａｍＴｒｅａｄ
３）ＴｒａｃｉｎｇＣｏｎｎｅｃｔｉｏｎ
４）ＲｅｐｌａｙＣｏｎｎｅｃｔｉｏｎ
追記１　ＣａｐｉＬｏｇｉｃａｌＣｏｎｎｅｃｔｉｏｎＰｒｏｘｙは、ＩＳＤＮを使用するシステムでの通常のインプリメンテーションである。
【００３６】
追記２　ＩｎｔｅｒｎａｌＢｙｔｅＳｔｒｅａｍＴｈｒｅａｄ。ＩＳＤＮを使用しないシステムでは、内部でサーバに自身と通信させることにより、なんらかの簡略な試験が可能である。動作はそれ自体を呼び出しているサーバに同一でなければならない。
【００３７】
追記３　ＴｒａｃｉｎｇＣｏｎｎｅｃｔｉｏｎ。デバッグの目的のため、このクラスは、データを別のＢｙｔｅＳｔｒｅａｍと受け渡す一方で、すべての送信済み及び受信済みのデータをファイルに記憶する。これは、データのロギングを可能にするユニックス（ｕｎｉｘ）の「ｔｅｅ」コマンドと比較できるだろう。
【００３８】
追記４　ＲｅｐｌａｙＣｏｎｎｅｃｔｉｏｎ。デバッグの目的のため、このクラスはｒａｃｉｎｇＣｏｎｎｅｃｔｉｏｎによって作成されるファイルを読み取り、記憶されているセッションの動作を真似るだろう。
【００３９】
セッションの作成
過去のセッションは、あるセッションに相当するなんらかの種類のセッションオブジェクトが存在し、ＢｙｔｅＳｔｒｅａｍＬｉｓｔｅｎｅｒインタフェースを実現し、ｒｅｓｇｉｓｔｅｒＬｉｓｔｅｎｅｒ（）メソッドを使用してＢｙｔｅＳｔｒｅａｍに登録されると仮定した。このタスクは、ＢｙｔｅＳｔｒｅａｍＣｏｎｔｒｏｌｌｅｒとＢｙｔｅＳｔｒｅａｍＣｏｎｎｅｃｔｉｏｎＬｉｓｔｅｎｅｒによって実現される。ＳｔｒｅａｍｉｎｇＴｒａｎｓｐｏｒｔからのそれぞれは、通常、別のセッションとの論理接続ごとにＢｙｔｅＳｔｒｅａｍｓを作成し、管理するＳｅｓｓｉｏｎＣｏｎｔｒｏｌｌｅｒを実現する（サーバ側セッションがクライアント側セッションと通信する）。
【００４０】
通常、以下の２つの形のセッションの作成が存在する。
【００４１】
１）一方が他方を呼び出す。
２）一方が他方から呼を受信する。
【００４２】
追記１．この機能は、ＢｙｔｅＳｔｒｅａｍＣｏｎｔｒｏｌｌｅｒでｍａｋｅＣｏｎｎｅｃｔｉｏｎメソッドを呼び出すことによって実行される。コントローラはＢｙｔｅＳｔｒｅａｍを作成し、それを（物理的な）接続にリンクし、登録されているＢｙｔｅＳｔｒｅａｍＣｏｎｎｅｃｔｉｏｎＬｉｓｔｅｎｅｒに新しい接続を通知する。
【００４３】
追記２．ＢｙｔｅＳｔｒｅａｍＣｏｎｔｒｏｌｌｅｒが、新規接続が要求されている（電話が鳴っている）というイベントを受信すると、それはＢｙｔｅＳｔｒｅａｍＣｏｎｎｅｃｔｉｏｎＬｉｓｔｅｎｅｒが登録されたことを検証し、新しい（物理）接続にリンクされる新規ＢｙｔｅＳｔｒｅａｍを作成し、そのＢｙｔｅＳｔｒｅａｍＣｏｎｎｅｃｔｉｏｎＬｉｓｔｅｎｅｒに新しい接続を通知する。
【００４４】
アプリケーションは、ＢｙｔｅＳｔｒｅａｍＣｏｎｎｅｃｔｉｏｎＬｉｓｔｅｎｅｒを拡張するオブジェクトを実現しなければならない。Ｈ３２４サーバでは、これはＳｅｓｓｉｏｎＣｏｎｔｒｏｌｌｅｒによって実現される。その（Ｉｔ）ｐｒｏｘｙＳｅｓｓｉｏｎＣｏｎｔｒｏｌｌｅｒＰｒｏｘｙはベースＢｙｔｅＳｔｒｅａｍＣｏｎｔｒｏｌｌｅｒに登録される。現在、以下の２種類のＢｙｔｅＳｔｒｅａｍＣｏｎｔｒｏｌｌｅｒが存在する。
【００４５】
１）ＣａｐｉＣｏｎｔｒｏｌｌｅｒ
２）ＩｎｔｅｒｎａｌＢｙｔｅＳｔｒｅａｍＣｏｎｔｒｏｌｌｅｒ
追記１．これがＢｙｔｅＳｔｒｅａｍＣｏｎｔｒｏｌｅｒｎｏ標準的なＩＳＤＮバージョンである。それは、呼を作成し、受信することができる。ＬｏｗｅｒＬａｙｅｒＢｅａｒｅｒＣａｐａｂｉｌｉｔｉｅｓに対する基本的なサポートが含まれる。つまり、対応する文字に電話番号を追加することによって、４つの事前に定義されたＢｅａｒｅｒＣａｐａｂｉｌｉｔｉｅｓ（音声（Ｃ）、バイナリデータ、ＨＤＬＣフレーミング（Ｈ）、Ｈ３２４ｍキャップ（Ｄ）付きのバイナリデータ）の中から選ぶことができる。Ｈ３２４の場合、すべての電話番号はＤで始まらなければならない。
【００４６】
追記２．デバッグの目的のため、一方がサーバ側であり、他方がクライアント側であるとしてリンクされる２つのＢｙｔｅＳｔｒｅａｍが作成される。このライブラリの使用例は、ＣａｐｉＴｅｓｔ．ｃｐｐ及びＣａｐｉＴｅｓｔ．ｈに記載される。
【００４７】
セッション他
最初に、私たちは、１つの接続に複数のスレッドが必要であると考えた。後に、以下のスレッドだけを持つだけで十分であることを発見した。
【００４８】
−ＣＡＰＩ
−マルチプレクサ
−１から３のＡＶＲｅｃｏｒｄｅｒｓ
さらに多くの別々のスレッドを持つということは、オーバヘッドがさらに増加することを意味する。ファイルからデータを読み取ることは他の機能性にとってのボトルネックではないため、ＡＶＰｌａｙｅｒがＭｕｌｔｉｐｌｅｘｅｒと同じスレッドで実行できることが分かった。セッションクラスと付随するクラスの論理は、ファイルＳＥＳＳＩＯＮ．ＧＩＦ（＠＠ｔｏｂｅｄｏｎｅ）の中で描写される。
【００４９】
クラスはおおまかに以下に分類できる。
−マルチプレクサ（最低レベルプロトコル）
−適応層（より高いレベルのプロトコル）
−セッション（制御の最高レベルのプロトコル、Ｈ２４５）
−ＡＶＲｅｃｏｒｄｅｒ（入信音声／ビデオの最高レベルのプロトコル）
−ＡＶＰｌａｙｅｒ（発信音声／ビデオの最高レベルのプロトコル）
【００５０】
マルチプレクサ（Ｍｕｌｔｉｐｌｅｘｅｒ）
／ＳｅｓｓｉｏｎＭａｎａｇｅｒ／Ｍｕｌｔｉｐｌｅｘｅｒ．ｈ（４４）：ｃｌａｓｓ　ＲｅｃｅｉｖｉｎｇＰｄｕ
／ＳｅｓｓｉｏｎＭａｎａｇｅｒ／Ｍｕｌｔｉｐｌｅｘｅｒ．ｈ（１１２）：ｃｌａｓｓ　Ｍｕｌｔｉｐｌｅｘｅｒ；ｐｕｂｌｉｃ：ＢｙｔｅＳｒｅａｍＬｉｓｔｅｎｅｒＴｈｒｅａｄ
【００５１】
適応層（ＡｄａｐｔａｔｉｏｎＬａｙｅｒ）
接続ごとに、発信ＡｄａｐｔａｔｉｏｎＬａｙｅｒＯｕｔオブジェクトのアレイ、及び入信ＡｄａｐｔａｔｉｏｎＬａｙｅｒｉｎオブジェクトのアレイがある。つまり、使用中のあらゆるチャネルに対して１つ（最高６チャネル）である。ＡｄａｐｔａｔｉｏｎＬａｙｅｒｉｎとＡｄａｐｔａｔｉｏｎＬａｙｅｒＯｕｔは、総称ＡｄａｐｔａｔｉｏｎＬａｙｅｒクラスから継承する。
【００５２】
発信プロトコルの場合、つねにチャネル０を制御チャネルとして、２を音声用に、３をビデオ用に定義する。ＡｄａｐｔａｔｉｏｎＬａｙｅｒｉｎオブジェクトの使用は端局側までである。コードの概略を保つために、ＡｄａｐｔａｔｉｏｎＬａｙｅｒｉｎクラスに、以下のいくつかのサブクラスを定義した。
【００５３】
ＡｄａｐｔａｔｉｏｎＬａｙｅｒＩｎ１Ａｄｍｉｎｉｓｔｒａｔｉｏｎ，ＡｄａｐｔａｔｉｏｎＬａｙｅｒＩｎ２Ａｄｍｉｎｉｓｔｒａｔｉｏｎ，ＡｄａｐｔａｔｉｏｎＬａｙｅｒＩｎ３Ａｄｍｉｎｉｓｔｒａｔｉｏｎ。チャネルはその特性を動的に変更できる（理論上は、接続中、ビデオチャネルが音声チャネルになることができる）ため、あらゆるＡｄａｐｔａｔｉｏｎＬａｙｅｒＯｕｔは、つねにすべての３つのサブクラスを含む。これらの管理クラスは、使用中の適応層にとって特定的である属性を備える。あらゆるＡｄａｐｔａｔｉｏｎＬａｙｅｒはＣｙｃｌｉｃＰａｃｋｅｔＢｕｆｆｅｒを含む。これは、スレッドセーフ（ｔｈｒｅａｄ−ｓａｆｅ）循環バッファである。スレッドセーフ機能は現在使用されていない（すべてのバッファ操作は同じスレッド内で起こる）。また、ＣｙｃｌｉｃＰａｃｋｅｔＢｕｆｆｅｒは、入信音声／ビデオチャネルに使用されない（データは、バッファに入れられず、ＡＶＲｅｃｏｒｄｅｒｓに直接的に送られる）。オブジェクトは、ＣｙｃｌｉｃＰａｃｋｅｔＢｕｆｆｅｒＬｉｓｔｅｎｅｒから継承し、ＩｎｉｔＣＰＢｕｆｆｅｒＬｉｓｔｎｅｒ（）を呼び出すことによって、ＣｙｃｌｉｃＰａｃｋｅｔＢｕｆｆｅｒに署名できる。その場合、ＣｙｃｌｉｃＰａｃｋｅｔＢｕｆｆｅｒの中に何かが書き込まれるときには、コールバック関数ｂｕｆｆｅｒＮｏｔＥｍｐｔｙ（）が呼び出される。
【００５４】
当方のＭＭＭ応用例では、受信側だけでこれを使用する。
【００５５】
セッションは入信制御ＡｄａｐｔａｔｉｏｎＬａｙｅｒ（０番）のバッファに署名した。発信側では、マルチプレクサが、バッファを充填しなければならないＡＶＰｌａｙｅｒ：：ｐｌａｙ（）を呼び出した後に直接的にバッファを空にする。
【００５６】
セッション（Ｓｅｓｓｉｏｎ）
以下のいくつかの目的で、セッションオブジェクトが作成された。
−Ｈ２４５メッセージを処理する。
−呼を中断する（例えば、エラー発生時）。
−他のすべてのオブジェクトを制御（作成／削除、起動／停止）する。
【００５７】
ソフトウェア作成の後期の段階で、Ｓｅｓｓｉｏｎをマルチプレクサスレッドの一部とした。つまり、制御のいくらかがマルチプレクサスレッドに移動された。特に、クリーンアップ（オブジェクトの削除等）のためのコードはいま少々厄介になった。そのＨ２４５タスクを実行するために、セッションオブジェクトは、以下の管理オブジェクトを含む。つまり、ＭｓｄＡｄｍｉｎｉｓｔｒａｔｉｏｎ、ＭｔＡｄｍｉｎｉｓｔｒａｔｉｏｎ、ＣｅＡｄｍｉｎｉｓｔｒａｔｉｏｎ、ＬｃＡｄｍｉｎｉｓｔｒａｔｉｏｎ、ＢｉｃＡｄｍｉｎｉｓｔｒａｔｉｏｎ（後者２つはＣａｐａｂｉｌｉｔｉｅｓＡｄｍｉｎｉｓｔｒａｔｉｏｎから派生する）である。これらのオブジェクトの名称は、明らかにＨ２４５プロトコル（ＭＳＤ、ＭＴ等）を参照している。それらはすべて１つのソースファイルの組で定義されている。
【００５８】
ＳｅｓｓｉｏｎＡｄｍｉｎｉｓｔｒａｉｏｎｓ．ｈ／ＳｅｓｓｉｏｎＡｄｍｉｎｉｓｔｒａｔｉｏｎｓ．ｃｐｐ
【００５９】
ＡＶＲｅｃｏｒｄｅｒ及びＡＶＰｌａｙｅｒ
ＡＶＲｅｃｏｒｄｅｒとＡＶＰｌａｙｅｒのクラスから、特定的な音声プロトコルとビデオプロトコルを処理できるクラスを引き出す。現在、以下のＡＶＰｌａｙｅｒｓがある。
−ＳｉｍｐｌｅＡＶＰｌａｙｅｒ：ファイルから単にバイトを読み取る。
【００６０】
現在以下のＡＶＲｅｃｏｒｄｅｒｓがある。
−ＤｅｂｕｇＡＶＲｅｃｏｒｄｅｒ：バイトを文字通りファイルの中にダンプする。
−ＡＶＲｅｃｏｒｄｅｒＦｏｒＡＶ：ＡＶＩプレーヤーがファイルを使用できるようにファイルの中にバイトをダンプする。
【００６１】
−ＮａｍｅｄＰｉｐｅＡＶＲｅｃｏｒｄｅｒ：指定されるパイプの中にバイトをダンプするため、リアルタイムのプレーヤーは（デモ）画面にビデオ／音声を表示できる。Ｈ２４５プロトコルでは、相手側にこちら側のプレーヤーの機能を教える必要がある。このデータはクラスＡＶＰｌａｙｅｒＣａｐａｂｉｌｉｔｉｅｓに記憶される。特定的なプレーヤーに対して、引き出されたクラスを定義した。つまり、ＰｌａｙｅｒＣａｐａｂｉｌｉｔｉｅｓとＡｍｒＡｎｄＭｐｅｇ４ＡＶＰｌａｙｅｒＣａｐａｂｉｌｉｔｉｅｓである。
【００６２】
Ｍａｉｎ
主要なＭＭＭプログラムはファイルＡｒｅｎａＭａｉｎ．ｃｐｐ内にある。このファイルもいくつかの小さなクラス定義を含み、ソースをさらに明確にしている。ＩｎｃｏｍｉｎｇＳｅｓｓｉｏｎ，ＯｕｔｇｏｉｎｇＳｅｓｓｉｏｎ，ＳｅｓｓｉｏｎＣｏｎｔｒｏｌｌｅｒ
【００６３】
【発明の効果】
本発明は、上述のように構成したので、移動端局によりインターネットに発信されるストリーミングビデオコンテンツのアップロードを可能にするために、別の技術分野用に、つまり電話間のテレビ会議用に標準化されたプロトコルを使用する電気通信システムの実現を可能にした。
【図面の簡単な説明】
【図１】図１は本発明の好適実施形態のアーキテクチャを示す。
【図２】図２はＨ．３２４Ｍゲートウェイの例示的なインプリメンテーションを示す。
【符号の説明】
１　移動端局
２　無線網コントローラ（ＲＮＣ）
３　回線交換網（ＣＳＮ）
４　パケット交換網（ＰＳＮ）
５　インターネット
７　ゲートウェイ
８　登録サーバ
９　ストリーミングビデオサーバ

Claims

移動端局（１）に接続される回線交換網（３）を有し、さらにはインターネット（５）内での前記移動端局からストリーミングビデオサーバ（９）へのストリーミングビデオコンテンツの送信のために、一方の側で回線交換網に、他方の側でインターネットに接続されるゲートウェイ（７）を有し、前記ゲートウェイが、インターネットで互換性のあるストリーミングビデオフォーマットを有するファイルへの回線交換網を介して移動端局から受信されるストリーミングビデオビットストリームの変換に適していることを特徴とする電気通信システム。
前記一方の側にある移動端局（１）及びゲートウェイ（７）が、移動端局間でのテレビ会議用のプロトコルに準拠して、ビデオビットストリームを交換するために適していることを特徴とする請求項１に記載の電気通信システム。
前記テレビ会議関連プロトコルがＩＴＵ　Ｈ．３２４Ｍプロトコルであることを特徴とする請求項２に記載の電気通信システム。
前記移動端局（１）に接続され、関連する移動端局ごとに、該関連する移動端局により発信されるインターネットで互換性のあるストリーミングビデオが記憶される、または記憶されることになるインターネット記憶場所にリンクされた端局識別子を登録するために適した登録サーバ（８）を有することを特徴とする請求項１に記載の電気通信システム。
関連する移動端局の識別子を検出する手段と、該検索された識別子に誘導され、登録サーバ（８）で、端局により発信されるインターネットで互換性のあるストリーミングビデオが記憶されることになるインターネット記憶場所のアドレスを検索する手段と、そのインターネット記憶場所アドレスに前記インターネットで互換性のあるストリーミングビデオを転送する手段を有することを特徴とする請求項４に記載の電気通信システム。
関連する端局識別子を検出する前記手段、インターネット記憶場所のアドレスを登録サーバで検索する前記手段、及びそのインターネット記憶場所アドレスに前記インターネットで互換性のあるストリーミングビデオを転送する前記手段が、前記ゲートウェイ（７）の中に位置することを特徴とする請求項５に記載の電気通信システム。
関連する端局識別子を検出する前記手段、インターネット記憶場所のアドレスを登録サーバで検索する前記手段、及びそのインターネット記憶場所アドレスに前記インターネットで互換性のあるストリーミングビデオを転送する前記手段が、前記登録サーバ内に位置することを特徴とする請求項５に記載の電気通信システム。
関連する端局識別子を検出する前記手段、インターネット記憶場所のアドレスを登録サーバで検索する前記手段、及びそのインターネット記憶場所アドレスに前記インターネットで互換性のあるストリーミングビデオを転送する前記手段が、さまざまなサーバ上で分散されていることを特徴とする請求項５に記載の電気通信システム。
端局にメッセージを送信し、ストリーミングビデオコンテンツを発信する、あるいは発信した、前記コンテンツの記憶場所へのリンクを有する手段（１１）を有することを特徴とする請求項５に記載の電気通信システム。
該端局とは異なる１つまたは複数の端局にメッセージを送信し、ストリーミングビデオコンテンツを発信する、あるいは発信した、前記コンテンツの記憶場所へのリンクを有する手段（１１）を有することを特徴とする電気通信システム。
コンテンツを発信する端局とは異なる１つまたは複数の端局への前記メッセージとともに、前記ストリーミングビデオコンテンツの少なくとも一部を送信する手段（１１）を有することを特徴とする請求項１０に記載の電気通信システム。
前記メッセージが電子メールメッセージであることを特徴とする請求項９または１０に記載の電気通信システム。
前記メッセージがＳＭＳメッセージであることを特徴とする請求項９または１０に記載の電気通信システム。
前記メッセージがインスタントメッセージ通信メッセージであることを特徴とする請求項９または１０に記載の電気通信システム。
電気通信システム内で、移動端局（１）と接続される回線交換網（３）を有し、インターネット（５）内で前記移動端局からストリーミングビデオサーバ（９）にストリーミングビデオコンテンツを送信する方法であって、回線交換網を介して移動端局から受信されるのに適したフォーマットのストリーミングビデオビットストリームを、インターネットで互換性のあるストリーミングビデオフォーマットを有するファイルに変換するステップを有することを特徴とする方法。
移動端局から受信される前記ストリーミングビデオビットストリームのフォーマットが、移動端局間のテレビ会議用のプロトコルに準拠してビデオビットストリームを交換するのに適していることを特徴とする請求項１５に記載の方法。
前記テレビ会議関連プロトコルがＩＴＵ　Ｈ．３２４Ｍプロトコルであることを特徴とする請求項１６に記載の方法。
関連する移動端局ごとに、関連する移動端局により発信されるインターネットで互換性のあるストリーミングビデオが記憶されるあるいは記憶されることになるインターネット記憶場所のアドレスにリンクされる端局識別子を登録するステップを有することを特徴とする請求項１５に記載の方法。
関連する移動端局の識別子を検出するステップと、該検出された識別子によって誘導され、端局によって発信されるインターネットで互換性のあるストリーミングビデオが記憶されることになるインターネット記憶場所のアドレスを検索するステップと、その記憶場所アドレスに前記インターネットで互換性のあるストリーミングビデオを転送するステップとを有することを特徴とする請求項１７に記載の方法。
一方の側で回線交換電気通信網に接続され、他方の側でインターネットに接続されるのに適したゲートウェイ（７）であって、前記回線交換伝記通信網（３）が移動端局（１）と接続され、インターネット（５）内での前記移動端局からストリーミングビデオサーバ（９）へのストリーミングビデオコンテンツの送信用であり、回線交換網を介して移動端局から受信されるストリーミングビデオビットストリームをインターネットで互換性のあるストリーミングビデオフォーマットのファイルに変換するのに適していることを特徴とする前記ゲートウェイ。
移動端局間のテレビ会議用のプロトコルに準拠してビットストリームを交換するのに適していることを特徴とする請求項２０に記載のゲートウェイ。
前記テレビ会議関連プロトコルがＩＴＵ　Ｈ．３２４プロトコルであることを特徴とする請求項２１に記載のゲートウェイ。
回線交換電気通信網（３）を介して、他方の側でインターネットに接続されるゲートウェイ（７）の一方の側と接続されるのに適した端局であって、インターネット（５）内での前記移動端局からストリーミングビデオサーバ（９）へのストリーミングビデオコンテンツの送信用であり、回線交換網を介して移動端局から受信されるストリーミングビットストリームをインターネットで互換性のあるビデオフォーマットのファイルに変換するのに適していることを特徴とする端局。
移動端局間のテレビ会議用のプロトコルに準拠してビデオビットストリームを交換するのに適していることを特徴とする請求項２３に記載の端局。
前記テレビ会議関連プロトコルがＩＴＵ　Ｈ．３２４Ｍプロトコルであることを特徴とする請求項２４に記載の端局。