JP4777999B2 - セッションコントローラ及びその動作方法 - Google Patents

Description

１． 従来技術の説明
１．１ セッションコントローラ
セキュリティ、ＱｏＳ制御、ＮＡＰＴ（ネットワークアドレス及び／又はポート番号）トラバーサル等の理由により、多くのＶｏＩＰ及びＩＰマルチメディアサービスプロバイダが、ＶｏＩＰ／ＩＰマルチメディアコアネットワークと１）家庭及び企業顧客用のアクセスネットワークとの境界のみならず、２）他のサービスプロバイダのＶｏＩＰ／マルチメディアネットワークへ向かう境界にも、セッションコントローラノードの設置を要求し始めている。

セッションコントローラ、セッション境界コントローラ、境界コントローラ、境界横断装置、等は、ＶｏＩＰ及びマルチメディアに関連したＩＰ−ＩＰゲートウェイの新しいカテゴリに属する製品について、ベンダが付けた別名である。このタイプの装置は、業界が統一した名称に合意するより前に商品化されるほど急速にはやってきている。しかし、業界はこの種の装置に対して「セッションコントローラ」という用語を使用する方向でまとまりつつあるようであり（文献１）、本明細書においては、上述の装置全てをカバーする用語として、「セッションコントローラ」を用いる。

セッションコントローラはＩＰネットワークの交差点に存在し、そこでセッションコントローラはＨ．３２３，ＳＩＰ（セッション開始プロトコル），ＭＧＣＰ又はＭｅｇａｃｏ／Ｈ．２４８といったＩＰシグナリングプロトコルを用いて、ＩＰネットワーク間の境界を横断するリアルタイムＩＰ音声、映像及び他のデータのセッション（シグナリング及び関連するメディアストリーム）を流している。セッションコントローラの目的は、セキュリティ、サービス品質、サービスレベル契約、法定の傍受(legal intercept)、ＮＡＰＴ／ＦＷ（ファイヤウォール）トランスバーサル、及びＩＰストリームに関する他の重要な機能を確保するために、ＩＰセッション（シグナリング及びメディアストリーム）を管理することである。

ここで、ネットワーク境界とは、任意のＩＰ通信可能なインフラストラクチャにおけるハンドオフ点、すなわちセッションがあるネットワーク（又はネットワークの一部）から別のネットワークへ渡る場所を意味する。境界はキャリアのネットワーク辺縁又は企業とそのキャリアとの間の区分点として規定することが可能である。１つのキャリアネットワーク内の異なる部分の間に境界が発生しうるので、同一ネットワーク内に複数の境界が生じることもありうる。全てのセッションコントローラは、境界を横断するＩＰトラフィックを処理する。

ＳＩＰネットワーク内のセッションコントローラは、２つのエンティティ、シグナリングプロキシ（ＳＰ）、例えばＳＩＰ ＢＳＢＵＡ（バックツーバックユーザエージェント）と、ＭＰ（メディアプロキシ）とによって、論理的及び／又は物理的に形成されていると考えることができる。Ｂ２ＢＵＡ又はＭＰによって提供される機能の一部は、完全なセッションコントローラが存在していなくても、マルチメディアネットワークにおいて必要とされうる。

１．２ ホスト型ＮＡＰＴ／ＦＷトラバーサル
家庭及び企業ネットワーク内のＳＩＰクライアントは、顧客の敷地内ＦＷの背後にあることが多い。これは、（クライアントへ）到着するＳＩＰ／ＲＴＰトラフィックにとって問題をもたらす。ＦＷは、そこから出て行くトラフィックによってのみ”開放”されうるので、（クライアントへ）到着するセッションは通常ブロックされることになるだろうからである。

任意の外部ホストから内部ホストへ向かうトラフィックを許可するため、ファイアウォールにおいて広範囲のクライアントポートを静的に開けておくこともできるかもかもしれない。あるいは、正しいプロトコルに対するポートを、ＳＩＰ及び付随するメディアセッションが要求した際にだけ開き、セッション終了時に再度閉じるようにしてもよい。

ネットワークの内部ＩＰアドレスが、そのネットワークの外部では無効である（例えばプライベートアドレスの場合）場合や、例えばセキュリティの観点から内部アドレッシングを外部ネットワークに隠す必要がある場合など、そのネットワークの外部では使用できない場合に用いられるＮＡＰＴについてもファイアウォールが実行する場合、事態はより複雑になる。ＮＡＰＴはまた、プライベートネットワーク内部の広いアドレス空間を、外部の、より小さなアドレスのセットにマッピングする際にも用いられる。さらに、ＮＡＰＴは外部（ＩＳＰ）ネットワークトポロジの変化を隠すためにも便利である。ＮＡＰＴにより、プライベートネットワーク内のホストは、外部ネットワーク内の宛先とトランスペアレントに通信することが可能となり、外部ネットワークからもプライベートネットワーク内へのホストとトランスペアレントに通信することが可能となる。つまり、ＮＡＰＴ装置は、ＩＰヘッダ内のアドレス内容を、ＩＰパケットのルーティング先のアドレス体系において有効となるように変更することにより、異種のアドレス体系間でのＩＰパケットの透過的なルーティングを提供又はサポートしている。

動的ＦＷ／ＮＡＰＴに関する１つの問題は、ユーザ（ＳＩＰクライアント）がＩＰパケットをパブリックＩＰアドレスへ宛てて送信を開始した際にアドレス変換バインディングの設定を行うが、そのユーザから／へのＩＰパケットの習慣的な流れ(regular flow)がある期間しかバインディングを保持しないことである。そのユーザがしばらくの間（１分以内であることも多い）インアクティブであった場合、ＮＡＰＴはバインディングを削除し、そのユーザがＩＰパケットの送信を開始した次の時点で新しいバインディングを実行するであろう。一旦バインディングが削除されてしまうと、パブリックネットワークからはそのクライアントへ到達できなくなるであろう。そして、外部から見たクライアントアドレスは経時的に変化することになる。

ＦＷ／ＮＡＰＴトラバーサルに関する問題はよく知られており、特殊なプロトコル及びＮＡＰＴトラバーサルサーバを用いるＳＴＵＮ及びＴＵＲＮのような多種多様の解決方法が存在する。しかし、ＦＷ／ＮＡＰＴのパブリックネットワーク側をセッションコントローラにインタフェースさせると、ＳＴＲＮやＴＵＲＮのような特殊なプロトコル及び、顧客のドメイン内部のＳＴＵＮ及びＴＵＲＮサーバ又はトンネルクライアントのような付加装置なしに、ＦＷ／ＮＡＰＴトラバーサルを解決できる。セッションパス内でＦＷ／ＮＡＰＴを処理するため、以下の点がサポートされる。

１ ＳＩＰクライアントからのＲＥＧＩＳＴＥＲメッセージの受信に関連して、シグナリングプロキシが、到着したＲＥＧＩＳＴＥＲメッセージを含んだＩＰパケットのソースアドレス／ポートを調べる。もしこのアドレスがＲＥＧＩＳＴＥＲメッセージのＳＩＰコンテンツヘッダ内のアドレスと異なっていれば、ＳＩＰクライアントへのパスにＮＡＰＴが存在しており、そのクライアント宛の全てのＳＩＰメッセージについては、コンテンツヘッダ内のアドレスの代わりにＩＰパケットのソースアドレスが用いられる。

２ そのクライアント宛のＩＮＶＩＴＥＳがそのＦＷ／ＮＡＰＴを通過し、正しい場所へ到達できるよう、ＮＡＰＴ内のファイアウォール及びアドレスバインディングは、最初の登録の後は恒久的に開けつづけられる必要がある。あるクライアントについてのＦＷ／ＮＡＰＴバインディングを開け続けるための方法はいくつか存在する。ＳＩＰクライアント及び最新のホームＦＷ／ＮＡＰＴ製品は、ＵＰＮＰ（ユニバーサルプラグアンドプレイ）をサポートしているものが多い。これは、そのクライアントがセッションコントローラを用いずにＦＷ／ＮＡＰＴバインディングを維持できることを意味するが、下流のセッションパス内にさらなるＮＡＰＴが存在する場合には、それだけでは不十分である。

代わりに、ＵＰＮＰがサポートされていない場合、ＦＷ／ＮＡＰＴバインディングを開け続けることは、一般に、顧客の敷地内における様々なクライアントがセッションコントローラのＳＩＰポートへ、ＦＷ／ＮＡＰＴ内のバインディングがタイムアウトしないために十分な頻度で（たいてい３０秒ごと）周期的にＩＰパケットを送信することによって達成される これを実行する一般的な方法は、ＦＷ／ＮＡＰＴバインディングを開け続けるための周期的な再登録に十分な程度に小さい値を、クライアントの再登録インターバルに設定することである。これはセッションコントローラに重い負荷を与えるであろう。そのため、（ＨｏｔＳＩＰアクティブコンタクトクライアントのような）最新のＳＩＰクライアントは、空のＵＤＰパケット（ＳＩＰオーバＵＤＰの場合）や、ＳＩＰラインフィード”ＣＲＬＦ”キャラクタ（ＳＩＰオーバＴＣＰの場合）を代わりに送信できるようになっている。

対称的応答ルーティングに関しては、ＲＦＣ３５８１も参照されたい。

注： クライアントからの頻繁な再登録による負荷を軽減するため、企業顧客は顧客敷地内ＡＬＧをクライアントと企業ＦＷ／ＮＡＰＴの間にも設けることが多い。ＡＬＧはＦＷ／ＮＡＰＴを通じた全てのＳＩＰシグナリングを１つのＩＰアドレスにまとめる。これにより、ＳＩＰシグナリングのために１つのＦＷ／ＮＡＰＴバインディングを開け続けるだけでよい。

３ セッションコントローラは再登録メッセージを、ＣＳＣＦが最初の登録メッセージに対する応答において指定した再登録インターバルでのみ、ＣＳＣＦ宛の再登録メッセージを転送しなければならない。

４ セッションコントローラは、ＳＤＰパラメータをＳＩＰ ＩＮＶＩＴＥから受信すると、メディアストリーム単位で入方向のメディアに対するアドレス／ポートを割り当てる。ＳＤＰ応答はセッションコントローラが割り当てたアドレス／ポート番号を含むことになる。しかし、そのメディアストリームのパスにＦＷ／ＮＡＰＴがある場合、出方向で使用するアドレス／ポートが不明である。そのため、メディアプロキシは、割り当てた入方向アドレス／ポート上の入来ＲＴＰメディアパケットの監視を開始しなければならない。入方向ポートに最初に入来メディアパケットが到着すると、メディアプロキシはそのパケットのソースアドレス／ポートフィールドを読み、メディアプロキシ出方向アドレス／ポートバインディングをそのアドレス／ポートに設定しなければならない。これは「ＲＴＰポートラッチング」又は「メディアプレーンアドレス及びポートへのラッチング」と呼ばれることが多い。

セッションコントローラのＢ２ＢＵＡ部は、セッションコントローラのＭＰ部を制御する方法を必要とし、Ｈ．２４８がこの目的で使われている。ＥＴＳＩ ＴＩＳＰＡＮ／ＭＳＦ寄稿[2]において、「ＮＡＰＴ処理」と呼ばれる特定のＨ．２４８プロパティを含むＮＡＰＴトラバーサルパッケージが提案された。このプロパティが切断(termination)に適用される場合、このプロパティは切断のためのリモートデスクリプタにおいて受け渡されるであろう任意のアドレスをオーバライドする。その代わりに、ＭＧは入来メディアストリームから得られるソースアドレス及びソースポートを、出発メディアストリームのデスティネーションアドレス及びデスティネーションポートとして用いることができる。この場合の入来メディアストリームはデスティネーションアドレス及びデスティネーションポートによってのみ分類可能である（ソースアドレス及びポートはストリームの到着前においては不明であるため）。

１．３ 問題及び制限事項
発明者は、ＮＡＰＴトラバーサルパッケージ寄稿が、ＳＩＰクライアントが呼の間に自身のＩＰアドレス又はポートを変更する場合には対応していないことを認識してきた。クライアントからのこの振る舞いはＳＩＰネットワークで許されている。

ＳＩＰクライアントがアドレス及び／又はポートを変更する場合に、Ｂ２ＢＵＡがＭＰに対して何のアクションも取らないとすると、メディアフローの好ましからざる停止を招きうる。これは、クライアントのアドレス／ポート変更は、ＭＰによって認識されないＮＡＰＴの外部ＩＰアドレス及びポートの変更を招き、それによりＮＡＰＴからのトラフィックが遮断され、ＮＡＰＴへのトラフィックは誤ったアドレス／ポートへ送信されるであろうからである。

発明者はまた、ＳＩＰクライアントがアドレス及び／又はポートを変更する場合にＢ２ＢＵＡが再度ＭＰにラッチを行うよう指示するものとした場合に問題が生じうることも認識してきた。なぜなら、以前に使われたソースからのヒステリシスメディアフローティングが依然として存在するような状況においてその指示が起こりうるため、ＭＰが再度「古い」ソースをラッチしうるからである。本発明の１つ又は複数の見地は、独立請求項に提示されている。ここで開示される方法の態様に対応する装置態様もまた提供され、その逆もしかりである。

２． 好ましい実施形態の説明
２．１ 概要
本発明の実施形態を単純化して示す添付図面を参照して、本発明のいくつかの好適な実施形態について例示のみを目的として説明する。ＮＡＰＴ３０の背後にあるＳＩＰクライアント４０が、継続中のメディアセッションに対する自分のＩＰアドレス及び／又はポートを変更していることをＢ２ＢＵＡ１０が検出すると、Ｂ２ＢＵＡ１０は、本明細書において「再ラッチ(RE-LATCH)」と呼ぶ動作の実行をＭＰ２０に指示する。再ラッチとは、ＭＰ２０が、ＮＡＰＴ３０で現在使われている外部ポートとの送受信を継続する一方で、開いたポートに新たなアドレス／ポートソースを用いて到来するメディアの探索を開始することを意味する。ＭＰ２０が現在ラッチされているのとは別のソースアドレス／ポートを有する最初のＩＰパケットが到着すると、ＭＰ２０はその新しいソースを再ラッチし、そのメディアの新しいソースへの送信を開始するとともに、この新しいソースからのメディアのみを受け付ける。

２．２ 再ラッチのＨ．２４８制御
ＭＰにこのような振る舞いをするように指示するＢ２ＢＵＡは、Ｂ２ＢＵＡとＭＰとの間でＨ．２４８が用いられている場合、以下の特性を有する「ＮＡＰＴ処理(NAPT Processing)」プロパティを用いることができるであろう。

名称： NAPT Processing
プロパティＩＤ： nap
説明： ＭＰにＮＡＰＴ処理を入来フローに適用するように指示する。
型： 列挙型(Enumeration)
値： OFF（デフォルト）, LATCH, RELATCH
定義の場所： LocalControl記述子
手順： ...

ＮＡＰＴ処理プロパティは、不明な数のＣＰＥ又はネットワークベースのＮＡＰＴ装置を通じて受け渡されるメディアフローをサポートするようにＭＰを設定することを可能にする。なお、アーリーメディア(Early Media)（１８ｘ）であることが示された場合、アドレス及びポートを検出するための転送メディアが存在しないだろうから、ラッチを実行することが出来ないであろう。このような状況下で受信されたパケットがあれば、それらはラッチに用いられた後廃棄されるであろう。

ＮＡＰＴ処理プロパティがOFFに設定された場合、ＭＰは受信したリモートＳＤＰに規定されたＩＰアドレス及びポートに対するピンホールを開くであろう。

ＮＡＰＴ処理プロパティガLATCHに設定された場合、ＭＰはリモートＳＤＰで受信されるアドレスを無視する。その代わりに、ＭＰは入来メディアストリームから得られるソースアドレス及びソースポートを、出発メディアストリームのデスティネーションアドレス及びデスティネーションポートとして用いることができる。この場合の入来メディアストリームはデスティネーションアドレス及びデスティネーションポートによってのみ分類可能である（ソースアドレス及びポートはストリームの到着前においては不明であるため）。

ＮＡＰＴ処理プロパティがRELATCHに設定された場合、ＭＰは上述したラッチ処理と似た処理を実行する。相異点は、ＭＰが受信ストリーム上のリモートＩＰアドレス／ポートの変化をチェックすることである。新しいリモートＩＰアドレス及び／又はポートが検出されたならば、それらは将来の出方向パケットに対して用いられるであろう。再ラッチ後に古いアドレス及びポートの組み合わせで受信されたパケットは、不正なものと見なされ、そのように取り扱われる（廃棄及び計数される）。

ＮＡＰＴ処理プロパティはLocalControl記述子によって受け渡される。ラッチ／再ラッチが実行されない場合、このプロパティは、値ＯＦＦでLocalControl記述子に含めることもできるし、記述子から省いても良い。ラッチを実行すべき際には、値LATCHを有するプロパティが含められる。値へのラッチを維持するため、その値はその後の全てのLocalControl記述子に存在するであろう。再ラッチを実行すべき際には、プロパティは値RELATCHを含むであろう。その後のLocalControl記述子は、再ラッチされた値を維持するため、値LATCHを含むであろう。

上述の再ラッチ手法の過程において、ＭＰ２０が新しいリモートＩＰアドレス及び／又はポートを（別個の）通知で受信することなく、受信したストリームから新しいリモートＩＰアドレス及び／又はポートを抽出することが理解されよう。従って、（ＭＰに新しいリモートＩＰアドレス及び／又はポートを知らせることのみを目的とした）通知は起こらない。しかし、本発明の好ましい実施形態において、ＭＰがリモートＩＰアドレス／ポートの変化について入力ストリームを監視できるよう、ＭＰは、クライアント４０がそのＩＰアドレス及び／又はポートを変更しているもしくは変更したという事実の通知を受ける。

上述の実施形態の改良として、ＳＰがアドレス及び／又はポート変更の後、クライアントがどのタイプのメディアを送信しようとしているのかを、ＳＩＰシグナリングから検出する。これはアドレス及び／ポート変更の前と同じタイプかも知れないし、違うタイプかも知れない。そして、ＳＰは予期されるメディアのタイプをＭＰに通知し、ＭＰは、ＳＰから通知されたメディアタイプが、RELATCH命令を受信した後でＭＰが受信したメディアのメディアタイプと合致すれば、新しいソースへRELATCHするだけでよい。

再ラッチ動作を実行するためにＮＡＰＴ処理プロパティを用いる実施形態を説明してきたが、再ラッチ動作を実行するために「信号(signal)」を用いることもできる。Ｈ．２４８が用いられる場合、信号は以下の特性を有しうる。

信号名： Latching
信号ＩＤ： latch
説明： この信号はＮＡＰＴトラバース処理を命令する。
信号形式： Brief
存続期間： 適用負荷
定義の場所： Signal記述子
追加パラメータ：
パラメータ名： NAPT Traversal Processing
パラメータＩＤ： napt
説明： ＮＡＰＴ処理を入来フローに適用するようＭＰに指示する。
型： 列挙型(Enumeration)
選択可否： 不可
取りうる値： OFF, LATCH, RELATCH
デフォルト： OFF

信号形式及び継続期間はパッケージ（この場合は「ipnapt」）で指定されるデフォルト値であるが、これらはＨ．２４８標準信号手順に従って変更されうる。好ましくは、パッケージはＨ．２４８．３７（ＩＰ ＮＡＰＴトラバーサルパッケージ）である。

上述の手法に基づく好ましい実施形態において、ラッチ／再ラッチについてのタイムアウト機構が導入される。このため、信号形式は「Brief」の代わりに「TimeOut」として定義もしくは変更され、「継続期間」は選択された値に設定される。これにより、タイムアウト（即ち、「継続期間」値の設定に対応する時間）後のラッチ／再ラッチの可能性が無くなる。これは、例えばクライアントがそのアドレス及び／又はポートを変更しようと決め、それを「SIP Re-INVITE」メッセージで通知するが、ＮＡＰＴが出方向のソースアドレス及び／又はポートを変更しない場合に特に便利である。この好適な実施形態による手法を用いることで、ＭＰは（「継続期間」で指定される）短時間だけ再ラッチの可能性を開けておくだけでよいであろう。これは、信号形式が「Brief」に設定されている場合、（例えばＮＡＰＴがそのアドレスもポートも変更しないとすると）再ラッチウィンドウが呼の継続期間に渡って開き続け、「悪意ある再ラッチ」（すなわち、悪意あるソースが、「クライアントとＭＰとの間のセッションを乗っ取る」ために、自身のストリームをＭＰ宛に送信する）に対してこの手法が攻撃されやすくなるのとは対照的である。

特に好ましい実施形態においては、再ラッチの可能性は指定された期間のみ開かれるが、再ラッチが実行されたならば直ちにその可能性を閉じる（即ち、指定された期間が終わる前における更なる再ラッチの可能性はない）。あるいは、又はさらに、他の負荷パラメータを定義することができる。

オフセットタイマ：
オフセットタイマパラメータは、（予め）規定された時間（例えば１，２，５又は１０秒）の経過後にのみラッチ／再ラッチの可能性が開かれることを確実にするために用いられ得る。これは、例えば「ＳＩＰフォーキング」の場合であって、複数のクライアントが「アーリーメディア」(SIP 180 呼びだし)を送信する場合に便利であろう。１つのクライアントが電話を取った場合、他のクライアントが「アーリーメディア」の送信を停止するまでには少し時間がかかるであろう。正しい／望まれるメディアソースへラッチされることを確実にするため、ＭＰはラッチ／再ラッチの可能性をこのオフセットタイマが切れた後に開く。もちろん、オフセットタイマパラメータは他の用途に用いても良い。

再ラッチ動作をプロパティでなく信号として特定することにより、独特の利点を有しうる。ラッチ／再ラッチ動作を２つの連続したコマンドで実行しなければならない場合がある（例えば、ＳＩＰフォーキングの場合）。ＮＡＰＴ処理を「プロパティ」として指定したとすると、シグナリングに特別なMODIFYコマンドを追加し、連続するコマンドの間にプロパティをOFFに設定する必要があるだろう。ＮＡＰＴが信号として指定される場合、これは不要である。

さらに、再ラッチ機構を「信号」によって実施するということは、再ラッチ機構が「プロパティ」によって実施される場合と異なり、「信号」が引き続く全てのメッセージに含まれる必要がないことを意味する。

再ラッチ機構が「信号」、「プロパティ」のいずれによって実施されたとしても、好ましい実施形態において、セッションコントローラはラッチ／再ラッチの発生を通知され、好ましくはどのアドレス及び／又はポートへラッチ／再ラッチされたかも通知される。

さらに、ＳＰがＨ．２４８上のＭＰアプリケーションにより、ラッチ／再ラッチがいつ起こったのかを通知されることが好ましく、どのアドレス及び／又はポートへラッチ／再ラッチされたのかを通知されることが好ましい。

好ましい実施形態において、再ラッチは、アドレスは変わらずにポートが変わった場合のみ実行される。これにより、同じＮＡＰＴからのトラフィックだけが受け付けられることを確実にすることができる。これにより、異なるアドレスからのトラフィックは、不正な、あるいは悪意を持った振る舞いを示すものとして廃棄されることを確実とすることができる。

本発明の別の好ましい実施形態によれば、この考え方は、アドレス及び／又はポート範囲がラッチ／再ラッチ機能の一部として指定される場合、ラッチ／再ラッチが指定された範囲又は範囲群に含まれるメディアソースからのみ受け付けられるように適用することができる。範囲又は範囲群は、アクセスネットワークへ向かうネットワーク接続の設定／規定とともに、ノードプロバイダ／オペレータによって指定／構成される。範囲／範囲群は「なじみの(well known)」のＮＡＰＴのみがセッションコントローラへメディアへのメディア送信を許されるように選択されうる。

ＭＰ及びＳＰは物理的に別個のエンティティであっても、１つのエンティティに合体されても良いことが理解されよう。特にＭＰ及びＳＰがそのように合体される場合、ＳＰとＭＰとの間の通信にＨ．２４８を用いる必要はないであろう。いずれにせよ、発明者はＨ．２４８の使用を好むが、代わりに他のプロトコルを利用できることは理解されよう。

ＮＡＰＴ（即ち、ネットワークアドレス及び／又はポート番号を変換する変換器）に関して説明してきたが、本発明はＮＡＴ(Network Address Translator)に関しても利用可能であることが理解されよう。さらに、例示としてＳＩＰクライアントを用いて説明してきたが、例えばマルチメディアクライアントのような他のクライアントに対しても適用可能であることが理解されよう。

本発明を上述の好ましい実施形態について説明してきたが、これらの実施形態は例示のみを目的としたものであり、特許請求の範囲はそれらの実施形態に限定されない。本技術分野の当業者は、開示に基づいて、添付した特許請求の範囲に含まれるものと予期される変更物又は代替物を創造することが可能であろう。本明細書において開示又は説明された各特徴は、単独でも、他の開示又は説明された機能との適切な組み合わせにおいても本発明を構成するであろう。

３． 参考文献
［１］セッションコントローラフォーラムウェブサイト http://www.sessioncontrollerforum.org
［２］Msf2004.034.01 ゲート制御のためのＨ．２４８プロファイルに関する通信- Draft ETSI ES 2XX XXX vl.0.3 (2004-02)

本発明の実施形態を単純化して示す図である。

Claims (25)

1. クライアントと通信し、シグナリングプロキシ及びメディアプロキシを備え、メディアプレーンアドレス及びポートにラッチされているセッションコントローラを動作させる方法であって、
   前記シグナリングプロキシにおいて、前記クライアントがそのＩＰアドレス及び／又はポートを別のアドレス及び／又はポートに変更している、もしくは変更したことを検出するステップと、
   前記メディアプロキシに、前記メディアプロキシが前記クライアントの前記アドレス及び／又はポートとしてこれまで用いてきたものと異なるアドレス及び／又はポートの前記クライアントからの入来メディアを監視するように指示するステップと、
   前記メディアプロキシにおいてそのような異なるアドレス及び／又はポートのメディアが受信された場合、前記異なるアドレス及び／又はポートを、前記メディアプロキシから前記クライアントへのメディアについての宛先アドレスとして用いるステップとを有することを特徴とする方法。
2. 前記シグナリングプロキシが、前記クライアントが前記アドレス及び／又はポート変更の後にどのようなタイプのメディアを前記メディアプロキシに送信するかを前記メディアプロキシに通知し、前記メディアプロキシが、前記そのような異なるアドレス及び／又はポートのメディアの前記タイプが、前記シグナリングプロキシから通知された前記タイプと同じ場合のみ、前記異なるアドレス及び／又はポートを前記宛先アドレス及び／又はポートとして用いることを特徴とする請求項１記載の方法。
3. 前記異なるポートが、前記メディアが受信されていたアドレスと前記セッションコントローラがラッチされていたアドレスが同じである場合にのみ用いられることを特徴とする請求項１又は請求項２記載の方法。
4. 前記シグナリングプロキシと前記メディアプロキシとが、Ｈ．２４８を通じて通信することを特徴とする請求項１乃至請求項３のいずれか１項に記載の方法。
5. 前記メディアプロキシへ指示するステップが、前記シグナリングプロキシから前記メディアプロキシへパラメータを送信するステップを含み、前記パラメータが３通りの値を取りうることを特徴とする請求項４記載の方法。
6. 前記メディアプロキシへ指示するステップが、前記シグナリングプロキシから前記メディアプロキシへＨ．２４８信号を送信するステップを含むことを特徴とする請求項４記載の方法。
7. 前記シグナリングプロキシと前記メディアプロキシが、物理的に別個の装置であることを特徴とする請求項１乃至請求項６のいずれか１項に記載の方法。
8. 前記メディアプロキシが、前記そのような異なるアドレス及び／又はポートのメディアを受信した後に受信した、前記これまで用いていたアドレス及びポートのメディアを全て廃棄することを特徴とする請求項１乃至請求項７のいずれか１項に記載の方法。
9. 前記メディアプロキシが、前記そのような異なるアドレス及び／又はポートのメディアを受信した後、前記異なるアドレス及び／又はポートの組み合わせと異なるアドレスとポートの組み合わせのメディアを全て廃棄することを特徴とする請求項１乃至請求項８のいずれか１項に記載の方法。
10. 前記メディアプロキシが、前記指示された後、前記そのような異なるアドレス及び／又はポートのメディアを受信するまでは、前記これまで用いていたアドレス及びポートのメディアを廃棄することなくその受信を継続することを特徴とする請求項１乃至請求項９のいずれか１項に記載の方法。
11. 前記セッションコントローラが前記クライアントと１つ又はそれより多いネットワークアドレス及び／又はポート番号変換器を通じて通信することを特徴とする請求項１乃至請求項１０のいずれか１項に記載の方法。
12. シグナリングプロキシ及びメディアプロキシを備え、クライアントと通信するように構成されると共に、メディアプレーンアドレス及びポートへラッチするように構成されるセッションコントローラであって、
    前記シグナリングプロキシが、前記クライアントがそのＩＰアドレス及び／又はポートを別のアドレス及び／又はポートに変更している、もしくは変更したことを検出するように構成されるとともに、そのような変更の検出に応答して、前記メディアプロキシに、前記メディアプロキシが前記クライアントの前記アドレス及び／又はポートとしてこれまで用いてきたものと異なるアドレス及び／又はポートの前記クライアントからの入来メディアを監視するように指示するように構成され、
    前記メディアプロキシが、そのような異なるアドレス及び／又はポートのメディアが前記メディアプロキシで受信された場合、前記異なるアドレス及び／又はポートを、前記メディアプロキシから前記クライアントへのメディアについての宛先アドレスとして用いるように構成されることを特徴とするセッションコントローラ。
13. 前記シグナリングプロキシが、前記クライアントが前記アドレス及び／又はポート変更の後にどのようなタイプのメディアを前記メディアプロキシに送信するかを前記メディアプロキシに通知するように構成され、前記メディアプロキシが、前記そのような異なるアドレス及び／又はポートのメディアの前記タイプが、前記シグナリングプロキシから通知された前記タイプと同じ場合のみ、前記異なるアドレス及び／又はポートを前記宛先アドレス及び／又はポートとして用いるように構成されることを特徴とする請求項１２記載のセッションコントローラ。
14. 前記異なるポートを、前記メディアが受信されていたアドレスと前記セッションコントローラがラッチされていたアドレスが同じである場合にのみ用いるように構成されることを特徴とする請求項１２又は請求項１３記載のセッションコントローラ。
15. 前記シグナリングプロキシと前記メディアプロキシとが、Ｈ．２４８を通じて通信するように構成されることを特徴とする請求項１２乃至請求項１４のいずれか１項に記載のセッションコントローラ。
16. 前記シグナリングプロキシが前記メディアプロキシに命令するために前記メディアプロキシへパラメータを送信するように構成され、前記パラメータが３通りの値を取りうることを特徴とする請求項１５記載のセッションコントローラ。
17. 前記シグナリングプロキシが前記メディアプロキシに命令するために前記メディアプロキシへＨ．２４８信号を送信するように構成されることを特徴とする請求項１５記載のセッションコントローラ。
18. 前記シグナリングプロキシと前記メディアプロキシが、物理的に別個の装置であることを特徴とする請求項１２乃至請求項１７のいずれか１項に記載のセッションコントローラ。
19. 前記メディアプロキシが、前記そのような異なるアドレス及び／又はポートのメディアを受信した後に受信した、前記これまで用いていたアドレス及びポートのメディアを全て廃棄するように構成されることを特徴とする請求項１２乃至請求項１８のいずれか１項に記載のセッションコントローラ。
20. 前記メディアプロキシが、前記そのような異なるアドレス及び／又はポートのメディアを受信した後、前記異なるアドレス及び／又はポートの組み合わせと異なるアドレスとポートの組み合わせのメディアを全て廃棄するように構成されることを特徴とする請求項１２乃至請求項１９のいずれか１項に記載のセッションコントローラ。
21. 前記メディアプロキシが、前記指示された後、前記そのような異なるアドレス及び／又はポートのメディアを受信するまでは、前記これまで用いていたアドレス及びポートのメディアを廃棄することなくその受信を継続するように構成されることを特徴とする請求項１２乃至請求項２０のいずれか１項に記載のセッションコントローラ。
22. 前記セッションコントローラが前記クライアントと１つ又はそれより多いネットワークアドレス及び／又はポート番号変換器を通じて通信するように構成されることを特徴とする請求項１２乃至請求項２１のいずれか１項に記載のセッションコントローラ。
23. クライアントと通信するように構成されるとともにメディアプレーンアドレス及びポートにラッチするように構成され、シグナリングプロキシとメディアプロキシを備えるセッションコントローラにおいて使用するためのシグナリングプロキシであって、
    前記クライアントがそのＩＰアドレス及び／又はポートを別のアドレス及び／又はポートに変更している、もしくは変更したことを検出するように構成されるとともに、そのような変更の検出に応答して、前記メディアプロキシに、前記メディアプロキシが前記クライアントの前記アドレス及び／又はポートとしてこれまで用いてきたものと異なるアドレス及び／又はポートの前記クライアントからの入来メディアを監視するように指示するように構成されることを特徴とするシグナリングプロキシ。
24. クライアントと通信するように構成されるとともにメディアプレーンアドレス及びポートにラッチするように構成され、シグナリングプロキシとメディアプロキシを備えるセッションコントローラにおいて使用するためのメディアプロキシであって、
    前記クライアントがそのＩＰアドレス及び／又はポートを別のアドレス及び／又はポートに変更している、もしくは変更したことの前記シグナリングプロキシにおける検出に応答して、前記メディアプロキシが前記クライアントの前記アドレス及び／又はポートとしてこれまで用いてきたものと異なるアドレス及び／又はポートの前記クライアントからの入来メディアを監視するための指示を受信するように構成されるとともに、
    前記メディアプロキシが、そのような異なるアドレス及び／又はポートのメディアが前記メディアプロキシで受信された場合、前記異なるアドレス及び／又はポートを、前記メディアプロキシから前記クライアントへのメディアについての宛先アドレスとして用いるように構成されることを特徴とするメディアプロキシ。
25. クライアントと通信し、メディアプレーンアドレス及びポートにラッチされているセッションコントローラを動作させる方法であって、
    前記クライアントがそのＩＰアドレス及び／又はポートを別のアドレス及び／又はポートに変更している、もしくは変更したことを検出するステップと、
    その後前記異なるアドレス及び／又はポートに前記セッションコントローラをラッチするステップとを有することを特徴とする方法。

Images