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