セッション間端末接続方法、セッション間端末接続装置、及びセッション間端末接続プログラム
【課題】プロトコル定義に違反することなく、２つのセッション間の通信端末の移動を行う。
【解決手段】既存セッション識別情報保存・修正機能部１２１は、全てのセッションに属する各通信端末が持つセッション情報のセッション識別情報を全て保存する。既存セッション識別情報保存・修正機能部１２１は、新しいセッション識別情報を、保存しておいたセッション識別情報に修正する。メディア情報行数比較機能部１２２は、それぞれのセッション情報のメディア情報の行数を比較する。セッション間端末接続機能部１２０は、比較結果に基づき、行数の多い側のセッション情報を新しいオファーとして採用する。全メディア情報削除機能部１２３は、行数の少ない側のメディア情報を全て削除し、多い側のメディア情報で置き換える。
【解決手段】既存セッション識別情報保存・修正機能部１２１は、全てのセッションに属する各通信端末が持つセッション情報のセッション識別情報を全て保存する。既存セッション識別情報保存・修正機能部１２１は、新しいセッション識別情報を、保存しておいたセッション識別情報に修正する。メディア情報行数比較機能部１２２は、それぞれのセッション情報のメディア情報の行数を比較する。セッション間端末接続機能部１２０は、比較結果に基づき、行数の多い側のセッション情報を新しいオファーとして採用する。全メディア情報削除機能部１２３は、行数の少ない側のメディア情報を全て削除し、多い側のメディア情報で置き換える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＳＤＰに基づく既存の２つのセッションのそれぞれに属する通信端末のうち、一方のセッションに属する通信端末を他方のセッションに移動させるセッション間端末接続方法、セッション間端末接続装置、及びセッション間端末接続プログラムに関する。
【背景技術】
【０００２】
電話等のサービスを提供する通信事業者の通信ネットワークに対し、通信ネットワークにおけるセッション制御をアプリケーション等のコントローラから制御する３ＰＣＣ（Third Party Call Control）と呼ばれる技術が存在する。３ＰＣＣにおいては、これまでは、２つの通信端末間でセッション接続を行う方式を中心に検討が進められてきた。このような流れの中にあって、近年、３ＰＣＣ制御用のＡＰＩ（Application Program Interface）の中に、２通信端末間のセッション接続に加えて、ある２つのセッションの一方のセッションから他方のセッションへと通信端末を移動する命令が定義されるようになった。このような命令を実現する際の方式として、コントローラ側でメディアストリームを終端する方式と、メディアストリームを終端しない３ＰＣＣの拡張方式とが考えられる。
【０００３】
通信ネットワークにおけるセッション制御をアプリケーション等のコントローラから制御する３ＰＣＣの実現方法については、ＲＦＣ３７２５に詳しく記載されている（例えば、非特許文献１参照）。ＲＦＣ３７２５には、通信プロトコルとして、ＳＩＰ（Session Initiation Protocol）を用いた場合の３ＰＣＣを実現するシーケンスについて、４つのパターンと、それぞれのメリット・デメリットとについて記述されている。
【０００４】
図４は、従来技術によるネットワークの構成を示すブロック図である。図において、コントローラ１００は、セッション制御用ネットワーク２００を介して各通信端末３００〜３０３を制御する。ここで、セッション制御用ネットワーク２００は、ＮＧＮ（Next Generation Network）や、ＩＭＳ（IP Multimedia Subsystems）に代表されるようなＳＩＰによるセッション制御を行う通信ネットワークを想定している。通信端末３００〜３０３は、一般のＩＰ電話機や、ＩＰテレビ電話機、またＳＩＰによるセッション制御を受け付ける、その他いかなるＳＩＰ Ｕｓｅｒ Ａｇｅｎｔをも含む。
【０００５】
図５は、ＲＦＣ３７２５に記載の４つのシーケンスのうち、最も単純とされる第１のシーケンスを示すシーケンス図である。図において、コントローラ１００が通信端末３００に対してＳＩＰのＩＮＶＩＴＥメッセージにＳＤＰに基づくセッション情報を載せずに送る（ステップＳ００１）。これに対して、通信端末３００は、自身の望むセッション情報を載せた応答を返す（ステップＳ００２）。
【０００６】
コントローラ１００は、このセッション情報を載せたＩＮＶＩＴＥメッセージを通信端末３０１に送り（ステップＳ００３）、通信端末３０１から両通信端末で合意に達したセッション情報を受け取ると（ステップＳ００４）、ＡＣＫを通信端末３０１に返し（ステップＳ００５）、このセッション情報を、最後に通信端末３００に送る（ステップＳ００６）。これにより、セッションの開始に必要な情報が出揃い、両通信端未間でメディアストリームを載せたＲＴＰメッセージのやり取りが開始される（ステップＳ００７）。
【０００７】
このような２つの通信端末を新たに呼び出してセッション接続する方法については、ＲＦＣ３７２５を始めとして、実現方法が各方面で論じられてきた。一方、ネットワーク機能を制御するＷｅｂサービス形式のＡＰＩとして標準化されているＰａｒｌａｙ Ｘでは、このような２つの通信端末間での新規セッション接続の他に、より複雑なセッション制御方法が挙げられている。Ｐａｒｌａｙ Ｘには、その制御する機能種別に応じて幾つかのパートに分かれており、３ＰＣＣを含むセッション制御については、Ｐａｒｔ ２：Ｔｈｉｒｄ Ｐａｒｔｙ Ｃａｌｌに記述されている（例えば、非特許文献２参照）。ここでは、２つの通信端末を新たに呼び出してセッション接続するＡＰＩ（makeCallSession）の他に、既存の２つのセッションに属する通信端末を１つずつ選び、一方のセッションの通信端末を他方のセッションの通信端末と再接続するというＡＰＩ（transferCallParticipant）が定義されている。
【０００８】
これらのセッション制御方法について、図６と図７を参照して説明する。図６は、ｍａｋｅＣａｌｌＳｅｓｓｉｏｎのような２つの通信端末間でセッション接続を行う３ＰＣＣ制御を、通信端未３００と通信端未３０１間、通信端末３０２と通信端末３０３間で実行した後のセッションと通信端末との関係を示すブロック図である。前者の組み合わせでは、コントローラ１００が通信端末３００と通信端末３０１との間のダイアログ（呼）を関連付けて、セッション４００（♯１）としてまとめている。後者の組み合わせでは、同様に、コントローラ１００が通信端末３０２と通信端末３０３との間のダイアログを関連付けて、セッション４０１（♯２）としてまとめている。
【０００９】
こうして生成された２つのセッション４００（＃１）とセッション４０１（＃２）との間で、通信端末の移動を行うのがｔｒａｎｓｆｅｒＣａｌｌＳｅｓｓｉｏｎの機能である。図７は、一例として、セッション４０１（＃２）に属する通信端末３０２を、セッション４００（＃１）に属する通信端末３００と接続した場合を示すブロック図である。通信端末３０２は、コントローラによって通信端末３００の属するセッション４００（＃１）に移動され、一度も切断されることなく、通信端末３００と通信端末３０２との間で通話が継続する。この過程において、セッション４０１（＃２）から通信端未３０２が離脱したため、セッション４０１（♯２）は無くなり、通信端末３０３は、切断されるか、外部のガイダンスサーバ等の別の通信端末へと接続し直される等の処理がコントローラ１００によって行われたものとする。同様に、セッション４００（＃１）に属していた通信端末３０１も、コントローラによって切断されるか、外部のガイダンスサーバ等の別の通信端末へと接続し直されたものとする。
【非特許文献１】J. Rosenberg, J. Peterson, H. Schulzrinne, and Camarillo, “Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP),” IETF RFC 3725, Apr. 2004.
【非特許文献２】Parlay Group. “Open Service Access (OSA); Parlay X Web Services; Part 2: Third Party Call (Parlay X 3), “ETSI ES 202 504-2 v0.0.5, Jun. 2007.
【発明の開示】
【発明が解決しようとする課題】
【００１０】
このような既存セッション間の通信端末を接続する方法を考える際に課題となるのが、セッションのセッション情報を記述するプロトコルであるＳＤＰ（Session Description Protocol）に対する違反である。ＳＤＰは、ＲＦＣ４５６６（M. Handley, V. Jacobson, and C. Perkins, “SDP: Session Description Protocol,” IETF RFC 4566, Jul. 2006）で定義されたプロトコルであり、ＳＩＰにおける要求元からのオファーと要求先からのアンサーによって合意を取る方法については、ＲＦＣ３２６４（J. Rosenberg and H. Schulzrinne, “An Offer/Answer Model with the Session Description Protocol (SDP),” IETF REC 3264, Jun. 2002）において定義されている。ＳＤＰは、オファーとアンサーのやり取りにより、２つの通信端末間で共通のコーデックを選んで通信できるようにする等、最適なセッション情報を決定するためのプロトコルである。ある通信端末が別の通信端末にＳＩＰのＩＮＶＩＴＥメッセージを送る場合には、ＳＤＰの定義に従った実装を行えば何の問題もないが、３ＰＣＣや、セッション間端末接続等のコントローラによってセッション制御を行う場合には、ＳＤＰの定義で制限・禁止されている事項に抵触しないよう実現方法を考える必要がある。３ＰＣＣにおけるＳＤＰによる制限については、ＲＦＣ３７２５に４つのシーケンスごとに記載されている。
【００１１】
上述したように、ＳＩＰ（Session Initiation Protocol）を用いた３ＰＣＣによるセッション間端末接続は、ＲＦＣ３７２５に記載のシーケンスにより行われる。図８は、図５に示すＲＦＣ３７２５のシーケンスの通信端末３０１を、通信端末３０２に置き換えたときのセッション状態を示すシーケンス図である。図５と図８との違いは、図８では、既に通信端未３００と通信端未３０２とがそれぞれ異なるセッションに属しているという点である。そのため、図８の各ｌＮＶＩＴＥメッセージ（ステップＳ１０１、Ｓ１０３）は、セッション確立済み状態におけるＩＮＶＩＴＥ（一般に、ｒｅ−ＩＮＶＩＴＥと呼ばれる）である。
【００１２】
図８に示すシーケンス図について、順を追って説明する。確立済みセッションに属する通信端末３００に対し、コントローラ１００からセッション情報を載せないＩＮＶＩＴＥメッセージを送り（ステップＳ１０１）、これに対して通信端末３００からセッション情報（ＳＤＰ）のオファーを受け取る（ステップＳ１０２）。このオファーを載せたＩＮＶＩＴＥメッセージを、別の確立済みセッションに属する通信端末３０２に対して送り（ステップＳ１０３）、これに対する応答としてＳＤＰのアンサーを得る（ステップＳ１０４）。コントローラ１００は、通信端末３００に対し、このアンサーを載せたＡＣＫを送り（ステップＳ１０６）、通信端末３００と通信端末３０２との間でメディアストリームが流れ始める（ステップＳ１０７）。
【００１３】
このシーケンスによってセッション間端末接続を実現するためには、いくつかの課題が存在している。第１の課題に関して、ＳＤＰにおいてセッション識別情報を記述する行（“ｏ＝”行）は、ＲＦＣ３２６４において、次のように定義されている。即ち、同一のセッションにおいて、セッション識別情報に記述されたセッション情報の発信者の識別子は、不変でなければならず、セッション情報のバージョンを表すシーケンス番号は、インクリメントされなければならない。この条件に対し、図８に示す従来技術によるシーケンスでは、正常に機能しないという問題がある。
【００１４】
ステップＳ１０２〜Ｓ１０３において、コントローラ１００を経由して送られたオファーは、通信端末３００から見れば、発信者の識別子が以前のものと変わっていないため問題ない。しかしながら、通信端未３０２からは、それまでの識別子（この場合、このシーケンスが実行される前に、通信端末３０２が接続していた相手の通信端末の識別子）とは、別の識別子が送られてきたように見える。このため、ＲＦＣ３２６４の規定に違反したことになり、正常に機能しないことが予想される。
【００１５】
第２と第３の課題は、ＲＦＣ３２６４では、メディア情報を認証する行（“ｍ＝”行）について、セッション情報を更新する際に、以前のセッション情報のメディア情報の行数と新しいメディア情報の行数が一致、もしくは増加している必要があり（第２の課題）、行数の一致している分については、以前のメディア情報の記述の順序を変えてはならない（第３の課題）としている点が挙げられる。ここで、メディア情報は、通信端末間で送受信される音声情報や映像情報などのメディアを識別する情報である。ＳＤＰに基づく１つのセッションでは複数のメディアを管理することが可能であり、例えば、テレビ会議を行う場合には、音声情報と映像情報とを１つのセッションで管理することが可能である。
【００１６】
ここで、メディア行数が増加している場合というのは、以前のメディア情報とメディア情報の記述の順序が一致している場合のみ、最後に新しいメディア情報の行を追加することが許されていることを示す。これらをまとめると、メディア情報の行数は、前回のメディア情報の行数と等しいか、前回よりも増えていなければならず、また、その行の並びについても、同じメディアについては、同じ行番号の行で記述しなければならない。
【００１７】
図８に示す例では、この条件下で正常に機能する場合とそうでない場合とがある。正常に機能するのは、通信端末３００のセッション情報と通信端末３０２のセッション情報とで、偶然にもメディア情報の行数が等しいか、あるいは、通信端未３００のセッション情報のメディア情報の行数が多く、かつ同じ順序で同一のメディアについて言及していた場合である。これ以外の場合については、通信端末３０２が新しいオファーを受け取った時点（ステップＳ１０３）でＲＦＣ３２６４に違反したこととなり、正常に機能しないという問題がある。
【００１８】
本発明は、このような事情を考慮してなされたものであり、その目的は、メディアストリームを終端しない３ＰＣＣ拡張方式において、プロトコル定義に違反することなく、２つのセッション間の通信端末の移動を行うことができるセッション間端末接続方法、セッション間端末接続装置、及びセッション間端末接続プログラを提供することにある。
【課題を解決するための手段】
【００１９】
上述した課題を解決するために、本発明は、ＳＤＰに基づく既存の２つのセッションのそれぞれに属する通信端末のうち、一方のセッションに属する通信端末のセッション情報を、他方のセッションに属する通信端末のセッション情報に置き換えて通信端末のセッションを移動させるセッション間端末接続装置の、メディア情報行数比較手段が、既存の２つのそれぞれのセッションのセッション情報中のメディア情報に関する記述の行数を比較するステップと、セッション間端末接続手段が、メディア情報行数比較手段による比較結果に基づいて、メディア情報の行数が少ないセッションのセッション情報を、メディア情報の行数が多い他方のセッション情報に置き換えるセッション情報として決定するステップと、を備えることを特徴とする。
【００２０】
また、本発明は、セッション間端末接続装置の、メディア情報削除手段が、メディア情報行数比較手段による比較結果に基づいて、メディア情報の行数が少ない側のセッション情報のメディア情報の行を全て削除するステップを備えることを特徴とする。
【００２１】
また、本発明は、セッション間端末接続装置の、既存セッション識別情報保存手段が、既存の２つのセッションのそれぞれのセッション情報中のセッション識別情報を記憶して保存するステップと、既存セッション識別情報修正手段が、２つのセッションのうち一方のセッションに属する通信端末から送信されるセッション情報に含まれるセッション識別情報を、既存セッション識別情報保存手段に記憶された他方のセッションのセッション識別情報に置き換えるステップと、を備えることを特徴とする。
【００２２】
また、本発明は、ＳＤＰに基づく既存の２つのセッションのそれぞれに属する通信端末のうち、一方のセッションに属する通信端末のセッション情報を、他方のセッションに属する通信端末のセッション情報に置き換えて通信端末のセッションを移動させるセッション間端末接続装置であって、既存の２つのそれぞれのセッションのセッション情報中のメディア情報に関する記述の行数を比較するメディア情報行数比較手段と、メディア情報行数比較手段による比較結果に基づいて、メディア情報の行数が少ないセッションのセッション情報を、メディア情報の行数が多い他方のセッション情報に置き換えるセッション情報として決定するセッション間端末接続手段と、を備えることを特徴とする。
【００２３】
また、本発明は、メディア情報行数比較手段による比較結果に基づいて、メディア情報の行数が少ない側のセッション情報のメディア情報の行を全て削除するメディア情報削除手段を備えることを特徴とする。
【００２４】
また、本発明は、既存の２つのセッションのそれぞれのセッション情報中のセッション識別情報を記憶して保存する既存セッション識別情報保存手段と、２つのセッションのうち一方のセッションに属する通信端末から送信されるセッション情報に含まれるセッション識別情報を、既存セッション識別情報保存手段に記憶された他方のセッションのセッション識別情報に置き換える既存セッション識別情報修正手段と、を備えることを特徴とする。
【００２５】
また、本発明は、ＳＤＰに基づく既存の２つのセッションのそれぞれに属する通信端末のうち、一方のセッションに属する通信端末を他方のセッションに移動させるセッション間端末接続装置のコンピュータに、既存の２つのそれぞれのセッションのセッション情報中のメディア情報に関する記述の行数を比較するステップと、メディア情報に関する記述の行数の比較結果に基づいて、メディア情報の行数が少ないセッションのセッション情報を、メディア情報の行数が多い他方のセッション情報に置き換えるセッション情報として決定するステップと、を実行させることを特徴とするセッション間端末接続プログラムである。
【発明の効果】
【００２６】
この発明によれば、２つのセッション情報中のメディア情報の行数を比較し、該比較結果に基づいて、メディア情報の行数が少ないセッションに属する通信端末を、メディア情報の行数が多い他方のセッションに移動させるようにしたので、メディア情報の行数が、以前と同じか、より増えていなければならないという条件を満たすことができ、プロトコル定義に違反することなく、２つのセッション間の通信端末の移動を行うことができるという利点が得られる。
【発明を実施するための最良の形態】
【００２７】
以下、本発明の一実施形態を、図面を参照して説明する。
図１は、本発明の実施形態によるネットワークの構成を示すブロック図である。図において、コントローラ１００ａは、セッション制御用ネットワーク２００を介して各通信端末３００〜３０３のセッションを制御する。ここで、セッション制御用ネットワーク２００は、ＮＧＮ（Next Generation Network）や、ＩＭＳ（IP Multimedia Subsystems）に代表されるようなＳＩＰによるセッション制御を行う通信ネットワークを想定している。通信端末３００〜３０３は、一般のＩＰ電話機や、ＩＰテレビ電話機、またＳＩＰによるセッション制御を受け付ける、その他いかなるＳＩＰ Ｕｓｅｒ Ａｇｅｎｔをも含む。ここで、本発明のセッション間端末接続方法におけるメディア種別については、ＳＤＰで許容されているメディア種別全てについて利用可能であり、特に、本発明固有の制限は設けない。
【００２８】
図２は、本実施形態によるコントローラ１００ａの構成を示すブロック図である。図において、コントローラ１００ａは、ＳＩＰの制御を行うため、一般にＳＩＰのアプリケーションサーバとして実現される。コントローラ１００ａは、セッション制御機能部１１０と、セッション間端末機能部１２０とを備える。セッション制御機能部１１０は、前述した図７に示した従来の３ＰＣＣを実現するコントローラ１００が有する機能と同等であり、図８に示したシーケンスに代表されるＲＦＣ３７２５における各種３ＰＣＣシーケンスを実行する。セッション間端末接続機能部１２０は、セッション間端末接続を実現する機能であり、前述した第１から第３の課題に対し、既存セッション識別情報保存・修正機能部１２１、メディア情報行数比較機能部１２２、全メディア情報削除機能部１２３を含む。
【００２９】
既存セッション識別情報保存・修正機能部１２１は、コントローラ１００ａを経由する全てのセッションのセッション情報に含まれるセッション識別情報を保存する。即ち、既存セッション識別情報保存・修正機能部１２１は、前述した図６で示すようなコントローラ１００を介したセッション４００（＃１）とセッション４０１（♯２）が存在したとき、それぞれのセッションに属する各通信端末３００〜３０３が持つセッション情報のセッション識別情報を全て保存する。
【００３０】
その後、図８に示したようなセッション間端末接続の実行時における通信端末間でのセッション情報のやり取りの際に、既存セッション識別情報保存・修正機能部１２１は、以前のセッション諭別情報と新しいセッション識別情報との間で不一致が発生しないよう、対象のセッション情報の新しいセッション識別情報を、保存しておいたセッション識別情報に修正する。これにより、第１の課題として述べたセッション識別情報の一致という条件を満たすことができる。なお、既存セッション識別情報保存・修正機能部１２１によって保存されたセッション識別情報は、セッション識別情報の属するセッション情報のセッションが切断・破棄された場合に削除される。
【００３１】
メディア情報行数比較機能部１２２は、セッション間端未接続機能部１２０による接続シーケンスの初期において得られた、それぞれのセッション情報のメディア情報の行数を比較する。セッション間端末接続機能部１２０は、該比較結果に基づき、その行数の多い側のセッション情報を新しいオファーとして採用する。これにより、第２の課題として述べたメディア情報の行数の一致については、ＲＦＣ３２６４に記載の「メディア情報の行数は前回のメディア情報の行数と等しいか、前回よりも増えていなければならなない」という条件を常に満たすことができる。
【００３２】
但し、上記第２の課題に対する解決手段だけでは、ＲＦＣ３２６４の「メディア情報の行の並びについても、同じメディアについては同じ行番号の行で記述しなければならない」という条件を満たすことができない（第３の課題）。例えば、行数の多いメディア情報が、前回の行数の少ないメディア情報に行を足した形ではなく、全ての行の内容がまるで変わってしまっている場合が考えられる。
【００３３】
上記第３の課題における条件を満たすため、一度削除した（無効であると印をつけた）メディア情報の行については、全く別のメディア情報の行によって置き換えることで再利用が可能であるというＲＦＣ３２６４記載の別の条件を利用する。即ち、全メディア情報削除機能部１２３は、行数の少ないメディア情報を持つセッション情報のメディア情報の行を予め全て削除し、行数の多いメディア情報を持つセッション情報を新しいオファーとした場合、少ない側のメディア情報の行を多い側のメディア情報の行で置き換える。この方法により、第３の課題として述べたメディア情報の行の順序の一致についても解決する。
【００３４】
次に、本実施形態の動作について説明する。
図３は、本実施形態によるコントローラ１００ａの動作例として、セッション間端末接続動作を説明するためのシーケンス図である。これは、前述した図６に示すように、通信端未３００と通信端末３０１間のセッション４００（＃１）と、通信端末３０２と通信端末３０３間のセッション４０１（＃２）とを、前述した図７に示すように、通信端末３００と通信端未３０２間のセッションに変更するよう、セッション間での端未接続を行う例である。
【００３５】
まず、コントローラ１００ａは、それぞれが既に確立済みのセッションに属する通信端末３００と通信端末３０２に対して、セッション情報のオファーを載せないＩＮＶＩＴＥメッセージを送信する（ステップＳ２０１、Ｓ２０２）。それぞれのメッセージに対して、新しいセッション情報のオファーを載せた応答が各通信端未３００、３０２から返ってくる（ステップＳ２０３、Ｓ２０４）。なお、このステップＳ２０３、Ｓ２０４における応答については特に順序性は必要としないため、図示の例では、ステップＳ２０３、Ｓ２０４の順に応答があったように記述しているが、ステップＳ２０４、Ｓ２０３の順に応答があってもよい。
【００３６】
次に、ステップＳ２０３に載せられた新しいオファー（ｏｆｆｅｒ１）と、ステップＳ２０４に載せられた新しいオファー（ｏｆｆｅｒ２）とを、コントローラ１００ａのメディア情報行数比較機能部１２２において比較する。ここで、もし、ｏｆｆｅｒ２のメディア情報の行数がｏｆｆｅｒ１のそれと同じか、あるいは、多かった場合には（ステップＳ２０５）、ステップＳ２０６以降のシーケンスを実行する。
【００３７】
一方、ｏｆｆｅｒ１のメディア情報の行数のほうが、ｏｆｆｅｒ２のそれよりも多かった場合には（ステップＳ２１２）、ステップＳ２１３以降のシーケンスを実行し、ステップＳ２０６〜Ｓ２１０については実行しない。ステップＳ２０５以降とステップＳ２１２以降は、左右が反転しただけで、基本的には同じシーケンスである。即ち、メディア情報の行数の多い側のセッション情報を新たなオファーとして採用し、このオファーをメディア情報の行数の少なかった側へと送信するようになっている。このため、ここでは、ステップＳ２０５〜Ｓ２１１までを説明し、ステップＳ２１２以降については説明を省略する。
【００３８】
ステップＳ２０６以降では、ｏｆｆｅｒ２が新しいオファーとして採用されているため、採用されなかったｏｆｆｅｒ１については、全メディア情報削除機能部１２３においてメディア情報の全ての行を削除した（無効にした）セッション情報を、アンサー（ａｎｓｗｅｒ１）としてＡＣＫメッセージに載せて通信端末３００に送信する（ステップＳ２０６）。なお、ここで送信したセッション情報のセッション識別情報については、通信端末３０２のセッション識別情報が載っていたところを、既存セッション識別情報保存・修正機能部１２１で保存されていた通信端未３０１のセッション識別情報に置き換えている。これにより、通信端末３００からは、以前と変わらず、通信端未３０１のセッション識別情報を載せたセッション情報を受け取っていることになり、第１の課題における、セッション識別情報の一致という条件は満たされていることになる。
【００３９】
次に、採用されたオファーであるｏｆｆｅｒ２’を載せたＩＮＶＩＴＥメッセージをコントローラ１００ａから通信端末３００へと送信する（ステップＳ２０７）。ここでも、ｏｆｆｅｒ２のセッション識別情報については、通信端末３０２のものから通信端末３０１のものへと既存セッション識別情報保存・修正機能部１２１によって置き換えている（置き換え前をｏｆｆｅｒ２、置き換え後をｏｆｆｅｒ２’と記述する）。このｏｆｆｅｒ２’は、通信端未３００のセッション情報（この段階では、ａｎｓｗｅｒ１）と同じか、それ以上のメディア情報の行を持っており、また、ステップＳ２０６において、ａｎｓｗｅｒ１のメディア情報は全て削除されているため、通信端末３００のセッション情報のメディア情報は、ａｎｓｗｅｒ１からｏｆｆｅｒ２’へと問題なく置き換えることができる。
【００４０】
次に、このｏｆｆｅｒ２’に対するアンサーをａｎｓｗｅｒ２’とし、このａｎｓｗｅｒ２’を載せた２００ ＯＫメッセージを、通信端末３００からコントローラ１００ａへ返送する（ステップＳ２０８）。ここで、ａｎｓｗｅｒ２’のセッション識別情報を、既存セッション識別情報保存・修正機能部１２１が通信端末３００のものから、通信端末３０３のものへと置き換える。この置き換えた後のアンサーをａｎｓｗｅｒ２と記述する。
【００４１】
コントローラ１００ａは、ａｎｓｗｅｒ２を載せたＡＣＫメッセージを通信端末３０２へと送信し（ステップＳ２０９）、最後に通信端未３００に対してＡＣＫメッセージを送信する（ステップＳ２１０）。これにより、通信端末３００と通信端末３０２との間で新たにメディアストリームの送受信が行われるようになり（ステップＳ２１１）、セッション間の端末接続が完了する。
【００４２】
上述した実施形態によれば、ＳＩＰや、ＳＤＰ等のプロトコルで定義されている条件を満たしつつ、セッション間端末接続という複雑なセッション制御を実現することが可能となる。これにより、セッション間端末接続ＡＰＩを提供するゲートウェイ装置のＳＩＰのセッション制御による実現が可能となり、セッション制御アプリケーションの高度化と多様化が促進される。
【００４３】
なお、上述した実施形態において、コントローラ１００ａにおける、セッション制御機能部１１０、セッション間端末接続機能部１２０、既存セッション識別情報保存・修正機能部１２１、メディア情報行数比較機能部１２２、全メディア情報削除機能部１２３による機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより、セッション間端末接続処理を行ってもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものであってもよい。また、「コンピュータシステム」は、ＷＷＷシステムを利用している場合であれば、ホームページ提供環境（あるいは表示環境）も含むものとする。また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、フラッシュメモリ等の書き込み可能な不揮発性メモリ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。
【００４４】
さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ（例えばＤＲＡＭ（Dynamic Random Access Memory））のように、一定時間プログラムを保持しているものも含むものとする。また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク（通信網）や電話回線等の通信回線（通信線）のように情報を伝送する機能を有する媒体のことをいう。また、上記プログラムは、前述した機能の一部を実現するためのものであっても良い。さらに、前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であってもよい。
【図面の簡単な説明】
【００４５】
【図１】本発明の実施形態によるネットワークの構成を示すブロック図である。
【図２】本実施形態によるコントローラ１００ａの構成を示すブロック図である。
【図３】本実施形態によるコントローラ１００ａの動作例として、セッション間端末接続動作を説明するためのシーケンス図である。
【図４】従来技術によるネットワークの構成を示すブロック図である。
【図５】ＲＦＣ３７２５に記載の４つのシーケンスのうち、最も単純とされる第１のシーケンスを示すシーケンス図である。
【図６】ｍａｋｅＣａｌｌＳｅｓｓｉｏｎのような２つの通信端末間でセッション接続を行う３ＰＣＣ制御を、通信端未３００と通信端未３０１間、通信端末３０２と通信端末３０３間で実行した後のセッションと通信端末との関係を示すブロック図ある。
【図７】セッション４０１（＃２）に属する通信端末３０２を、セッション４００（＃１）に属する通信端末３００と接続した場合を示すブロック図である。
【図８】ＲＦＣ３７２５のシーケンスの通信端末３０１を、通信端末３０２に置き換えたときのセッション状態を示すシーケンス図である。
【符号の説明】
【００４６】
１００ａ コントローラ
１１０ セッション制御機能部
１２０ セッション間端末接続機能部
１２１ 既存セッション識別情報保存・修正機能部
１２２ メディア情報行数比較機能部
１２３ 全メディア情報削除機能部
２００ セッション制御用ネットワーク
３００〜３０３ 通信端末
【技術分野】
【０００１】
本発明は、ＳＤＰに基づく既存の２つのセッションのそれぞれに属する通信端末のうち、一方のセッションに属する通信端末を他方のセッションに移動させるセッション間端末接続方法、セッション間端末接続装置、及びセッション間端末接続プログラムに関する。
【背景技術】
【０００２】
電話等のサービスを提供する通信事業者の通信ネットワークに対し、通信ネットワークにおけるセッション制御をアプリケーション等のコントローラから制御する３ＰＣＣ（Third Party Call Control）と呼ばれる技術が存在する。３ＰＣＣにおいては、これまでは、２つの通信端末間でセッション接続を行う方式を中心に検討が進められてきた。このような流れの中にあって、近年、３ＰＣＣ制御用のＡＰＩ（Application Program Interface）の中に、２通信端末間のセッション接続に加えて、ある２つのセッションの一方のセッションから他方のセッションへと通信端末を移動する命令が定義されるようになった。このような命令を実現する際の方式として、コントローラ側でメディアストリームを終端する方式と、メディアストリームを終端しない３ＰＣＣの拡張方式とが考えられる。
【０００３】
通信ネットワークにおけるセッション制御をアプリケーション等のコントローラから制御する３ＰＣＣの実現方法については、ＲＦＣ３７２５に詳しく記載されている（例えば、非特許文献１参照）。ＲＦＣ３７２５には、通信プロトコルとして、ＳＩＰ（Session Initiation Protocol）を用いた場合の３ＰＣＣを実現するシーケンスについて、４つのパターンと、それぞれのメリット・デメリットとについて記述されている。
【０００４】
図４は、従来技術によるネットワークの構成を示すブロック図である。図において、コントローラ１００は、セッション制御用ネットワーク２００を介して各通信端末３００〜３０３を制御する。ここで、セッション制御用ネットワーク２００は、ＮＧＮ（Next Generation Network）や、ＩＭＳ（IP Multimedia Subsystems）に代表されるようなＳＩＰによるセッション制御を行う通信ネットワークを想定している。通信端末３００〜３０３は、一般のＩＰ電話機や、ＩＰテレビ電話機、またＳＩＰによるセッション制御を受け付ける、その他いかなるＳＩＰ Ｕｓｅｒ Ａｇｅｎｔをも含む。
【０００５】
図５は、ＲＦＣ３７２５に記載の４つのシーケンスのうち、最も単純とされる第１のシーケンスを示すシーケンス図である。図において、コントローラ１００が通信端末３００に対してＳＩＰのＩＮＶＩＴＥメッセージにＳＤＰに基づくセッション情報を載せずに送る（ステップＳ００１）。これに対して、通信端末３００は、自身の望むセッション情報を載せた応答を返す（ステップＳ００２）。
【０００６】
コントローラ１００は、このセッション情報を載せたＩＮＶＩＴＥメッセージを通信端末３０１に送り（ステップＳ００３）、通信端末３０１から両通信端末で合意に達したセッション情報を受け取ると（ステップＳ００４）、ＡＣＫを通信端末３０１に返し（ステップＳ００５）、このセッション情報を、最後に通信端末３００に送る（ステップＳ００６）。これにより、セッションの開始に必要な情報が出揃い、両通信端未間でメディアストリームを載せたＲＴＰメッセージのやり取りが開始される（ステップＳ００７）。
【０００７】
このような２つの通信端末を新たに呼び出してセッション接続する方法については、ＲＦＣ３７２５を始めとして、実現方法が各方面で論じられてきた。一方、ネットワーク機能を制御するＷｅｂサービス形式のＡＰＩとして標準化されているＰａｒｌａｙ Ｘでは、このような２つの通信端末間での新規セッション接続の他に、より複雑なセッション制御方法が挙げられている。Ｐａｒｌａｙ Ｘには、その制御する機能種別に応じて幾つかのパートに分かれており、３ＰＣＣを含むセッション制御については、Ｐａｒｔ ２：Ｔｈｉｒｄ Ｐａｒｔｙ Ｃａｌｌに記述されている（例えば、非特許文献２参照）。ここでは、２つの通信端末を新たに呼び出してセッション接続するＡＰＩ（makeCallSession）の他に、既存の２つのセッションに属する通信端末を１つずつ選び、一方のセッションの通信端末を他方のセッションの通信端末と再接続するというＡＰＩ（transferCallParticipant）が定義されている。
【０００８】
これらのセッション制御方法について、図６と図７を参照して説明する。図６は、ｍａｋｅＣａｌｌＳｅｓｓｉｏｎのような２つの通信端末間でセッション接続を行う３ＰＣＣ制御を、通信端未３００と通信端未３０１間、通信端末３０２と通信端末３０３間で実行した後のセッションと通信端末との関係を示すブロック図である。前者の組み合わせでは、コントローラ１００が通信端末３００と通信端末３０１との間のダイアログ（呼）を関連付けて、セッション４００（♯１）としてまとめている。後者の組み合わせでは、同様に、コントローラ１００が通信端末３０２と通信端末３０３との間のダイアログを関連付けて、セッション４０１（♯２）としてまとめている。
【０００９】
こうして生成された２つのセッション４００（＃１）とセッション４０１（＃２）との間で、通信端末の移動を行うのがｔｒａｎｓｆｅｒＣａｌｌＳｅｓｓｉｏｎの機能である。図７は、一例として、セッション４０１（＃２）に属する通信端末３０２を、セッション４００（＃１）に属する通信端末３００と接続した場合を示すブロック図である。通信端末３０２は、コントローラによって通信端末３００の属するセッション４００（＃１）に移動され、一度も切断されることなく、通信端末３００と通信端末３０２との間で通話が継続する。この過程において、セッション４０１（＃２）から通信端未３０２が離脱したため、セッション４０１（♯２）は無くなり、通信端末３０３は、切断されるか、外部のガイダンスサーバ等の別の通信端末へと接続し直される等の処理がコントローラ１００によって行われたものとする。同様に、セッション４００（＃１）に属していた通信端末３０１も、コントローラによって切断されるか、外部のガイダンスサーバ等の別の通信端末へと接続し直されたものとする。
【非特許文献１】J. Rosenberg, J. Peterson, H. Schulzrinne, and Camarillo, “Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP),” IETF RFC 3725, Apr. 2004.
【非特許文献２】Parlay Group. “Open Service Access (OSA); Parlay X Web Services; Part 2: Third Party Call (Parlay X 3), “ETSI ES 202 504-2 v0.0.5, Jun. 2007.
【発明の開示】
【発明が解決しようとする課題】
【００１０】
このような既存セッション間の通信端末を接続する方法を考える際に課題となるのが、セッションのセッション情報を記述するプロトコルであるＳＤＰ（Session Description Protocol）に対する違反である。ＳＤＰは、ＲＦＣ４５６６（M. Handley, V. Jacobson, and C. Perkins, “SDP: Session Description Protocol,” IETF RFC 4566, Jul. 2006）で定義されたプロトコルであり、ＳＩＰにおける要求元からのオファーと要求先からのアンサーによって合意を取る方法については、ＲＦＣ３２６４（J. Rosenberg and H. Schulzrinne, “An Offer/Answer Model with the Session Description Protocol (SDP),” IETF REC 3264, Jun. 2002）において定義されている。ＳＤＰは、オファーとアンサーのやり取りにより、２つの通信端末間で共通のコーデックを選んで通信できるようにする等、最適なセッション情報を決定するためのプロトコルである。ある通信端末が別の通信端末にＳＩＰのＩＮＶＩＴＥメッセージを送る場合には、ＳＤＰの定義に従った実装を行えば何の問題もないが、３ＰＣＣや、セッション間端末接続等のコントローラによってセッション制御を行う場合には、ＳＤＰの定義で制限・禁止されている事項に抵触しないよう実現方法を考える必要がある。３ＰＣＣにおけるＳＤＰによる制限については、ＲＦＣ３７２５に４つのシーケンスごとに記載されている。
【００１１】
上述したように、ＳＩＰ（Session Initiation Protocol）を用いた３ＰＣＣによるセッション間端末接続は、ＲＦＣ３７２５に記載のシーケンスにより行われる。図８は、図５に示すＲＦＣ３７２５のシーケンスの通信端末３０１を、通信端末３０２に置き換えたときのセッション状態を示すシーケンス図である。図５と図８との違いは、図８では、既に通信端未３００と通信端未３０２とがそれぞれ異なるセッションに属しているという点である。そのため、図８の各ｌＮＶＩＴＥメッセージ（ステップＳ１０１、Ｓ１０３）は、セッション確立済み状態におけるＩＮＶＩＴＥ（一般に、ｒｅ−ＩＮＶＩＴＥと呼ばれる）である。
【００１２】
図８に示すシーケンス図について、順を追って説明する。確立済みセッションに属する通信端末３００に対し、コントローラ１００からセッション情報を載せないＩＮＶＩＴＥメッセージを送り（ステップＳ１０１）、これに対して通信端末３００からセッション情報（ＳＤＰ）のオファーを受け取る（ステップＳ１０２）。このオファーを載せたＩＮＶＩＴＥメッセージを、別の確立済みセッションに属する通信端末３０２に対して送り（ステップＳ１０３）、これに対する応答としてＳＤＰのアンサーを得る（ステップＳ１０４）。コントローラ１００は、通信端末３００に対し、このアンサーを載せたＡＣＫを送り（ステップＳ１０６）、通信端末３００と通信端末３０２との間でメディアストリームが流れ始める（ステップＳ１０７）。
【００１３】
このシーケンスによってセッション間端末接続を実現するためには、いくつかの課題が存在している。第１の課題に関して、ＳＤＰにおいてセッション識別情報を記述する行（“ｏ＝”行）は、ＲＦＣ３２６４において、次のように定義されている。即ち、同一のセッションにおいて、セッション識別情報に記述されたセッション情報の発信者の識別子は、不変でなければならず、セッション情報のバージョンを表すシーケンス番号は、インクリメントされなければならない。この条件に対し、図８に示す従来技術によるシーケンスでは、正常に機能しないという問題がある。
【００１４】
ステップＳ１０２〜Ｓ１０３において、コントローラ１００を経由して送られたオファーは、通信端末３００から見れば、発信者の識別子が以前のものと変わっていないため問題ない。しかしながら、通信端未３０２からは、それまでの識別子（この場合、このシーケンスが実行される前に、通信端末３０２が接続していた相手の通信端末の識別子）とは、別の識別子が送られてきたように見える。このため、ＲＦＣ３２６４の規定に違反したことになり、正常に機能しないことが予想される。
【００１５】
第２と第３の課題は、ＲＦＣ３２６４では、メディア情報を認証する行（“ｍ＝”行）について、セッション情報を更新する際に、以前のセッション情報のメディア情報の行数と新しいメディア情報の行数が一致、もしくは増加している必要があり（第２の課題）、行数の一致している分については、以前のメディア情報の記述の順序を変えてはならない（第３の課題）としている点が挙げられる。ここで、メディア情報は、通信端末間で送受信される音声情報や映像情報などのメディアを識別する情報である。ＳＤＰに基づく１つのセッションでは複数のメディアを管理することが可能であり、例えば、テレビ会議を行う場合には、音声情報と映像情報とを１つのセッションで管理することが可能である。
【００１６】
ここで、メディア行数が増加している場合というのは、以前のメディア情報とメディア情報の記述の順序が一致している場合のみ、最後に新しいメディア情報の行を追加することが許されていることを示す。これらをまとめると、メディア情報の行数は、前回のメディア情報の行数と等しいか、前回よりも増えていなければならず、また、その行の並びについても、同じメディアについては、同じ行番号の行で記述しなければならない。
【００１７】
図８に示す例では、この条件下で正常に機能する場合とそうでない場合とがある。正常に機能するのは、通信端末３００のセッション情報と通信端末３０２のセッション情報とで、偶然にもメディア情報の行数が等しいか、あるいは、通信端未３００のセッション情報のメディア情報の行数が多く、かつ同じ順序で同一のメディアについて言及していた場合である。これ以外の場合については、通信端末３０２が新しいオファーを受け取った時点（ステップＳ１０３）でＲＦＣ３２６４に違反したこととなり、正常に機能しないという問題がある。
【００１８】
本発明は、このような事情を考慮してなされたものであり、その目的は、メディアストリームを終端しない３ＰＣＣ拡張方式において、プロトコル定義に違反することなく、２つのセッション間の通信端末の移動を行うことができるセッション間端末接続方法、セッション間端末接続装置、及びセッション間端末接続プログラを提供することにある。
【課題を解決するための手段】
【００１９】
上述した課題を解決するために、本発明は、ＳＤＰに基づく既存の２つのセッションのそれぞれに属する通信端末のうち、一方のセッションに属する通信端末のセッション情報を、他方のセッションに属する通信端末のセッション情報に置き換えて通信端末のセッションを移動させるセッション間端末接続装置の、メディア情報行数比較手段が、既存の２つのそれぞれのセッションのセッション情報中のメディア情報に関する記述の行数を比較するステップと、セッション間端末接続手段が、メディア情報行数比較手段による比較結果に基づいて、メディア情報の行数が少ないセッションのセッション情報を、メディア情報の行数が多い他方のセッション情報に置き換えるセッション情報として決定するステップと、を備えることを特徴とする。
【００２０】
また、本発明は、セッション間端末接続装置の、メディア情報削除手段が、メディア情報行数比較手段による比較結果に基づいて、メディア情報の行数が少ない側のセッション情報のメディア情報の行を全て削除するステップを備えることを特徴とする。
【００２１】
また、本発明は、セッション間端末接続装置の、既存セッション識別情報保存手段が、既存の２つのセッションのそれぞれのセッション情報中のセッション識別情報を記憶して保存するステップと、既存セッション識別情報修正手段が、２つのセッションのうち一方のセッションに属する通信端末から送信されるセッション情報に含まれるセッション識別情報を、既存セッション識別情報保存手段に記憶された他方のセッションのセッション識別情報に置き換えるステップと、を備えることを特徴とする。
【００２２】
また、本発明は、ＳＤＰに基づく既存の２つのセッションのそれぞれに属する通信端末のうち、一方のセッションに属する通信端末のセッション情報を、他方のセッションに属する通信端末のセッション情報に置き換えて通信端末のセッションを移動させるセッション間端末接続装置であって、既存の２つのそれぞれのセッションのセッション情報中のメディア情報に関する記述の行数を比較するメディア情報行数比較手段と、メディア情報行数比較手段による比較結果に基づいて、メディア情報の行数が少ないセッションのセッション情報を、メディア情報の行数が多い他方のセッション情報に置き換えるセッション情報として決定するセッション間端末接続手段と、を備えることを特徴とする。
【００２３】
また、本発明は、メディア情報行数比較手段による比較結果に基づいて、メディア情報の行数が少ない側のセッション情報のメディア情報の行を全て削除するメディア情報削除手段を備えることを特徴とする。
【００２４】
また、本発明は、既存の２つのセッションのそれぞれのセッション情報中のセッション識別情報を記憶して保存する既存セッション識別情報保存手段と、２つのセッションのうち一方のセッションに属する通信端末から送信されるセッション情報に含まれるセッション識別情報を、既存セッション識別情報保存手段に記憶された他方のセッションのセッション識別情報に置き換える既存セッション識別情報修正手段と、を備えることを特徴とする。
【００２５】
また、本発明は、ＳＤＰに基づく既存の２つのセッションのそれぞれに属する通信端末のうち、一方のセッションに属する通信端末を他方のセッションに移動させるセッション間端末接続装置のコンピュータに、既存の２つのそれぞれのセッションのセッション情報中のメディア情報に関する記述の行数を比較するステップと、メディア情報に関する記述の行数の比較結果に基づいて、メディア情報の行数が少ないセッションのセッション情報を、メディア情報の行数が多い他方のセッション情報に置き換えるセッション情報として決定するステップと、を実行させることを特徴とするセッション間端末接続プログラムである。
【発明の効果】
【００２６】
この発明によれば、２つのセッション情報中のメディア情報の行数を比較し、該比較結果に基づいて、メディア情報の行数が少ないセッションに属する通信端末を、メディア情報の行数が多い他方のセッションに移動させるようにしたので、メディア情報の行数が、以前と同じか、より増えていなければならないという条件を満たすことができ、プロトコル定義に違反することなく、２つのセッション間の通信端末の移動を行うことができるという利点が得られる。
【発明を実施するための最良の形態】
【００２７】
以下、本発明の一実施形態を、図面を参照して説明する。
図１は、本発明の実施形態によるネットワークの構成を示すブロック図である。図において、コントローラ１００ａは、セッション制御用ネットワーク２００を介して各通信端末３００〜３０３のセッションを制御する。ここで、セッション制御用ネットワーク２００は、ＮＧＮ（Next Generation Network）や、ＩＭＳ（IP Multimedia Subsystems）に代表されるようなＳＩＰによるセッション制御を行う通信ネットワークを想定している。通信端末３００〜３０３は、一般のＩＰ電話機や、ＩＰテレビ電話機、またＳＩＰによるセッション制御を受け付ける、その他いかなるＳＩＰ Ｕｓｅｒ Ａｇｅｎｔをも含む。ここで、本発明のセッション間端末接続方法におけるメディア種別については、ＳＤＰで許容されているメディア種別全てについて利用可能であり、特に、本発明固有の制限は設けない。
【００２８】
図２は、本実施形態によるコントローラ１００ａの構成を示すブロック図である。図において、コントローラ１００ａは、ＳＩＰの制御を行うため、一般にＳＩＰのアプリケーションサーバとして実現される。コントローラ１００ａは、セッション制御機能部１１０と、セッション間端末機能部１２０とを備える。セッション制御機能部１１０は、前述した図７に示した従来の３ＰＣＣを実現するコントローラ１００が有する機能と同等であり、図８に示したシーケンスに代表されるＲＦＣ３７２５における各種３ＰＣＣシーケンスを実行する。セッション間端末接続機能部１２０は、セッション間端末接続を実現する機能であり、前述した第１から第３の課題に対し、既存セッション識別情報保存・修正機能部１２１、メディア情報行数比較機能部１２２、全メディア情報削除機能部１２３を含む。
【００２９】
既存セッション識別情報保存・修正機能部１２１は、コントローラ１００ａを経由する全てのセッションのセッション情報に含まれるセッション識別情報を保存する。即ち、既存セッション識別情報保存・修正機能部１２１は、前述した図６で示すようなコントローラ１００を介したセッション４００（＃１）とセッション４０１（♯２）が存在したとき、それぞれのセッションに属する各通信端末３００〜３０３が持つセッション情報のセッション識別情報を全て保存する。
【００３０】
その後、図８に示したようなセッション間端末接続の実行時における通信端末間でのセッション情報のやり取りの際に、既存セッション識別情報保存・修正機能部１２１は、以前のセッション諭別情報と新しいセッション識別情報との間で不一致が発生しないよう、対象のセッション情報の新しいセッション識別情報を、保存しておいたセッション識別情報に修正する。これにより、第１の課題として述べたセッション識別情報の一致という条件を満たすことができる。なお、既存セッション識別情報保存・修正機能部１２１によって保存されたセッション識別情報は、セッション識別情報の属するセッション情報のセッションが切断・破棄された場合に削除される。
【００３１】
メディア情報行数比較機能部１２２は、セッション間端未接続機能部１２０による接続シーケンスの初期において得られた、それぞれのセッション情報のメディア情報の行数を比較する。セッション間端末接続機能部１２０は、該比較結果に基づき、その行数の多い側のセッション情報を新しいオファーとして採用する。これにより、第２の課題として述べたメディア情報の行数の一致については、ＲＦＣ３２６４に記載の「メディア情報の行数は前回のメディア情報の行数と等しいか、前回よりも増えていなければならなない」という条件を常に満たすことができる。
【００３２】
但し、上記第２の課題に対する解決手段だけでは、ＲＦＣ３２６４の「メディア情報の行の並びについても、同じメディアについては同じ行番号の行で記述しなければならない」という条件を満たすことができない（第３の課題）。例えば、行数の多いメディア情報が、前回の行数の少ないメディア情報に行を足した形ではなく、全ての行の内容がまるで変わってしまっている場合が考えられる。
【００３３】
上記第３の課題における条件を満たすため、一度削除した（無効であると印をつけた）メディア情報の行については、全く別のメディア情報の行によって置き換えることで再利用が可能であるというＲＦＣ３２６４記載の別の条件を利用する。即ち、全メディア情報削除機能部１２３は、行数の少ないメディア情報を持つセッション情報のメディア情報の行を予め全て削除し、行数の多いメディア情報を持つセッション情報を新しいオファーとした場合、少ない側のメディア情報の行を多い側のメディア情報の行で置き換える。この方法により、第３の課題として述べたメディア情報の行の順序の一致についても解決する。
【００３４】
次に、本実施形態の動作について説明する。
図３は、本実施形態によるコントローラ１００ａの動作例として、セッション間端末接続動作を説明するためのシーケンス図である。これは、前述した図６に示すように、通信端未３００と通信端末３０１間のセッション４００（＃１）と、通信端末３０２と通信端末３０３間のセッション４０１（＃２）とを、前述した図７に示すように、通信端末３００と通信端未３０２間のセッションに変更するよう、セッション間での端未接続を行う例である。
【００３５】
まず、コントローラ１００ａは、それぞれが既に確立済みのセッションに属する通信端末３００と通信端末３０２に対して、セッション情報のオファーを載せないＩＮＶＩＴＥメッセージを送信する（ステップＳ２０１、Ｓ２０２）。それぞれのメッセージに対して、新しいセッション情報のオファーを載せた応答が各通信端未３００、３０２から返ってくる（ステップＳ２０３、Ｓ２０４）。なお、このステップＳ２０３、Ｓ２０４における応答については特に順序性は必要としないため、図示の例では、ステップＳ２０３、Ｓ２０４の順に応答があったように記述しているが、ステップＳ２０４、Ｓ２０３の順に応答があってもよい。
【００３６】
次に、ステップＳ２０３に載せられた新しいオファー（ｏｆｆｅｒ１）と、ステップＳ２０４に載せられた新しいオファー（ｏｆｆｅｒ２）とを、コントローラ１００ａのメディア情報行数比較機能部１２２において比較する。ここで、もし、ｏｆｆｅｒ２のメディア情報の行数がｏｆｆｅｒ１のそれと同じか、あるいは、多かった場合には（ステップＳ２０５）、ステップＳ２０６以降のシーケンスを実行する。
【００３７】
一方、ｏｆｆｅｒ１のメディア情報の行数のほうが、ｏｆｆｅｒ２のそれよりも多かった場合には（ステップＳ２１２）、ステップＳ２１３以降のシーケンスを実行し、ステップＳ２０６〜Ｓ２１０については実行しない。ステップＳ２０５以降とステップＳ２１２以降は、左右が反転しただけで、基本的には同じシーケンスである。即ち、メディア情報の行数の多い側のセッション情報を新たなオファーとして採用し、このオファーをメディア情報の行数の少なかった側へと送信するようになっている。このため、ここでは、ステップＳ２０５〜Ｓ２１１までを説明し、ステップＳ２１２以降については説明を省略する。
【００３８】
ステップＳ２０６以降では、ｏｆｆｅｒ２が新しいオファーとして採用されているため、採用されなかったｏｆｆｅｒ１については、全メディア情報削除機能部１２３においてメディア情報の全ての行を削除した（無効にした）セッション情報を、アンサー（ａｎｓｗｅｒ１）としてＡＣＫメッセージに載せて通信端末３００に送信する（ステップＳ２０６）。なお、ここで送信したセッション情報のセッション識別情報については、通信端末３０２のセッション識別情報が載っていたところを、既存セッション識別情報保存・修正機能部１２１で保存されていた通信端未３０１のセッション識別情報に置き換えている。これにより、通信端末３００からは、以前と変わらず、通信端未３０１のセッション識別情報を載せたセッション情報を受け取っていることになり、第１の課題における、セッション識別情報の一致という条件は満たされていることになる。
【００３９】
次に、採用されたオファーであるｏｆｆｅｒ２’を載せたＩＮＶＩＴＥメッセージをコントローラ１００ａから通信端末３００へと送信する（ステップＳ２０７）。ここでも、ｏｆｆｅｒ２のセッション識別情報については、通信端末３０２のものから通信端末３０１のものへと既存セッション識別情報保存・修正機能部１２１によって置き換えている（置き換え前をｏｆｆｅｒ２、置き換え後をｏｆｆｅｒ２’と記述する）。このｏｆｆｅｒ２’は、通信端未３００のセッション情報（この段階では、ａｎｓｗｅｒ１）と同じか、それ以上のメディア情報の行を持っており、また、ステップＳ２０６において、ａｎｓｗｅｒ１のメディア情報は全て削除されているため、通信端末３００のセッション情報のメディア情報は、ａｎｓｗｅｒ１からｏｆｆｅｒ２’へと問題なく置き換えることができる。
【００４０】
次に、このｏｆｆｅｒ２’に対するアンサーをａｎｓｗｅｒ２’とし、このａｎｓｗｅｒ２’を載せた２００ ＯＫメッセージを、通信端末３００からコントローラ１００ａへ返送する（ステップＳ２０８）。ここで、ａｎｓｗｅｒ２’のセッション識別情報を、既存セッション識別情報保存・修正機能部１２１が通信端末３００のものから、通信端末３０３のものへと置き換える。この置き換えた後のアンサーをａｎｓｗｅｒ２と記述する。
【００４１】
コントローラ１００ａは、ａｎｓｗｅｒ２を載せたＡＣＫメッセージを通信端末３０２へと送信し（ステップＳ２０９）、最後に通信端未３００に対してＡＣＫメッセージを送信する（ステップＳ２１０）。これにより、通信端末３００と通信端末３０２との間で新たにメディアストリームの送受信が行われるようになり（ステップＳ２１１）、セッション間の端末接続が完了する。
【００４２】
上述した実施形態によれば、ＳＩＰや、ＳＤＰ等のプロトコルで定義されている条件を満たしつつ、セッション間端末接続という複雑なセッション制御を実現することが可能となる。これにより、セッション間端末接続ＡＰＩを提供するゲートウェイ装置のＳＩＰのセッション制御による実現が可能となり、セッション制御アプリケーションの高度化と多様化が促進される。
【００４３】
なお、上述した実施形態において、コントローラ１００ａにおける、セッション制御機能部１１０、セッション間端末接続機能部１２０、既存セッション識別情報保存・修正機能部１２１、メディア情報行数比較機能部１２２、全メディア情報削除機能部１２３による機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより、セッション間端末接続処理を行ってもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものであってもよい。また、「コンピュータシステム」は、ＷＷＷシステムを利用している場合であれば、ホームページ提供環境（あるいは表示環境）も含むものとする。また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、フラッシュメモリ等の書き込み可能な不揮発性メモリ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。
【００４４】
さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ（例えばＤＲＡＭ（Dynamic Random Access Memory））のように、一定時間プログラムを保持しているものも含むものとする。また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク（通信網）や電話回線等の通信回線（通信線）のように情報を伝送する機能を有する媒体のことをいう。また、上記プログラムは、前述した機能の一部を実現するためのものであっても良い。さらに、前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であってもよい。
【図面の簡単な説明】
【００４５】
【図１】本発明の実施形態によるネットワークの構成を示すブロック図である。
【図２】本実施形態によるコントローラ１００ａの構成を示すブロック図である。
【図３】本実施形態によるコントローラ１００ａの動作例として、セッション間端末接続動作を説明するためのシーケンス図である。
【図４】従来技術によるネットワークの構成を示すブロック図である。
【図５】ＲＦＣ３７２５に記載の４つのシーケンスのうち、最も単純とされる第１のシーケンスを示すシーケンス図である。
【図６】ｍａｋｅＣａｌｌＳｅｓｓｉｏｎのような２つの通信端末間でセッション接続を行う３ＰＣＣ制御を、通信端未３００と通信端未３０１間、通信端末３０２と通信端末３０３間で実行した後のセッションと通信端末との関係を示すブロック図ある。
【図７】セッション４０１（＃２）に属する通信端末３０２を、セッション４００（＃１）に属する通信端末３００と接続した場合を示すブロック図である。
【図８】ＲＦＣ３７２５のシーケンスの通信端末３０１を、通信端末３０２に置き換えたときのセッション状態を示すシーケンス図である。
【符号の説明】
【００４６】
１００ａ コントローラ
１１０ セッション制御機能部
１２０ セッション間端末接続機能部
１２１ 既存セッション識別情報保存・修正機能部
１２２ メディア情報行数比較機能部
１２３ 全メディア情報削除機能部
２００ セッション制御用ネットワーク
３００〜３０３ 通信端末
【特許請求の範囲】
【請求項１】
ＳＤＰに基づく既存の２つのセッションのそれぞれに属する通信端末のうち、一方のセッションに属する通信端末のセッション情報を、他方のセッションに属する通信端末のセッション情報に置き換えて通信端末のセッションを移動させるセッション間端末接続装置の、
メディア情報行数比較手段が、前記既存の２つのそれぞれのセッションのセッション情報中のメディア情報に関する記述の行数を比較するステップと、
セッション間端末接続手段が、前記メディア情報行数比較手段による比較結果に基づいて、メディア情報の行数が少ないセッションのセッション情報を、メディア情報の行数が多い他方のセッション情報に置き換えるセッション情報として決定するステップと、
を備えることを特徴とするセッション間端末接続方法。
【請求項２】
前記セッション間端末接続装置の、
メディア情報削除手段が、前記メディア情報行数比較手段による比較結果に基づいて、メディア情報の行数が少ない側のセッション情報のメディア情報の行を全て削除するステップ
を備えることを特徴とする請求項１記載のセッション間端末接続方法。
【請求項３】
前記セッション間端末接続装置の、
既存セッション識別情報保存手段が、前記既存の２つのセッションのそれぞれのセッション情報中のセッション識別情報を記憶して保存するステップと、
既存セッション識別情報修正手段が、前記２つのセッションのうち一方のセッションに属する通信端末から送信されるセッション情報に含まれるセッション識別情報を、前記既存セッション識別情報保存手段に記憶された他方のセッションのセッション識別情報に置き換えるステップと、
を備えることを特徴とする請求項１または２記載のセッション間端末接続方法。
【請求項４】
ＳＤＰに基づく既存の２つのセッションのそれぞれに属する通信端末のうち、一方のセッションに属する通信端末のセッション情報を、他方のセッションに属する通信端末のセッション情報に置き換えて通信端末のセッションを移動させるセッション間端末接続装置であって、
前記既存の２つのそれぞれのセッションのセッション情報中のメディア情報に関する記述の行数を比較するメディア情報行数比較手段と、
前記メディア情報行数比較手段による比較結果に基づいて、メディア情報の行数が少ないセッションのセッション情報を、メディア情報の行数が多い他方のセッション情報に置き換えるセッション情報として決定するセッション間端末接続手段と、
を備えることを特徴とするセッション間端末接続装置。
【請求項５】
前記メディア情報行数比較手段による比較結果に基づいて、メディア情報の行数が少ない側のセッション情報のメディア情報の行を全て削除するメディア情報削除手段
を備えることを特徴とする請求項４記載のセッション間端末接続装置。
【請求項６】
前記既存の２つのセッションのそれぞれのセッション情報中のセッション識別情報を記憶して保存する既存セッション識別情報保存手段と、
前記２つのセッションのうち一方のセッションに属する通信端末から送信されるセッション情報に含まれるセッション識別情報を、前記既存セッション識別情報保存手段に記憶された他方のセッションのセッション識別情報に置き換える既存セッション識別情報修正手段と、
を備えることを特徴とする請求項４または５記載のセッション間端末接続装置。
【請求項７】
ＳＤＰに基づく既存の２つのセッションのそれぞれに属する通信端末のうち、一方のセッションに属する通信端末を他方のセッションに移動させるセッション間端末接続装置のコンピュータに、
前記既存の２つのそれぞれのセッションのセッション情報中のメディア情報に関する記述の行数を比較するステップと、
前記メディア情報に関する記述の行数の比較結果に基づいて、メディア情報の行数が少ないセッションのセッション情報を、メディア情報の行数が多い他方のセッション情報に置き換えるセッション情報として決定するステップと、
を実行させることを特徴とするセッション間端末接続プログラム。
【請求項１】
ＳＤＰに基づく既存の２つのセッションのそれぞれに属する通信端末のうち、一方のセッションに属する通信端末のセッション情報を、他方のセッションに属する通信端末のセッション情報に置き換えて通信端末のセッションを移動させるセッション間端末接続装置の、
メディア情報行数比較手段が、前記既存の２つのそれぞれのセッションのセッション情報中のメディア情報に関する記述の行数を比較するステップと、
セッション間端末接続手段が、前記メディア情報行数比較手段による比較結果に基づいて、メディア情報の行数が少ないセッションのセッション情報を、メディア情報の行数が多い他方のセッション情報に置き換えるセッション情報として決定するステップと、
を備えることを特徴とするセッション間端末接続方法。
【請求項２】
前記セッション間端末接続装置の、
メディア情報削除手段が、前記メディア情報行数比較手段による比較結果に基づいて、メディア情報の行数が少ない側のセッション情報のメディア情報の行を全て削除するステップ
を備えることを特徴とする請求項１記載のセッション間端末接続方法。
【請求項３】
前記セッション間端末接続装置の、
既存セッション識別情報保存手段が、前記既存の２つのセッションのそれぞれのセッション情報中のセッション識別情報を記憶して保存するステップと、
既存セッション識別情報修正手段が、前記２つのセッションのうち一方のセッションに属する通信端末から送信されるセッション情報に含まれるセッション識別情報を、前記既存セッション識別情報保存手段に記憶された他方のセッションのセッション識別情報に置き換えるステップと、
を備えることを特徴とする請求項１または２記載のセッション間端末接続方法。
【請求項４】
ＳＤＰに基づく既存の２つのセッションのそれぞれに属する通信端末のうち、一方のセッションに属する通信端末のセッション情報を、他方のセッションに属する通信端末のセッション情報に置き換えて通信端末のセッションを移動させるセッション間端末接続装置であって、
前記既存の２つのそれぞれのセッションのセッション情報中のメディア情報に関する記述の行数を比較するメディア情報行数比較手段と、
前記メディア情報行数比較手段による比較結果に基づいて、メディア情報の行数が少ないセッションのセッション情報を、メディア情報の行数が多い他方のセッション情報に置き換えるセッション情報として決定するセッション間端末接続手段と、
を備えることを特徴とするセッション間端末接続装置。
【請求項５】
前記メディア情報行数比較手段による比較結果に基づいて、メディア情報の行数が少ない側のセッション情報のメディア情報の行を全て削除するメディア情報削除手段
を備えることを特徴とする請求項４記載のセッション間端末接続装置。
【請求項６】
前記既存の２つのセッションのそれぞれのセッション情報中のセッション識別情報を記憶して保存する既存セッション識別情報保存手段と、
前記２つのセッションのうち一方のセッションに属する通信端末から送信されるセッション情報に含まれるセッション識別情報を、前記既存セッション識別情報保存手段に記憶された他方のセッションのセッション識別情報に置き換える既存セッション識別情報修正手段と、
を備えることを特徴とする請求項４または５記載のセッション間端末接続装置。
【請求項７】
ＳＤＰに基づく既存の２つのセッションのそれぞれに属する通信端末のうち、一方のセッションに属する通信端末を他方のセッションに移動させるセッション間端末接続装置のコンピュータに、
前記既存の２つのそれぞれのセッションのセッション情報中のメディア情報に関する記述の行数を比較するステップと、
前記メディア情報に関する記述の行数の比較結果に基づいて、メディア情報の行数が少ないセッションのセッション情報を、メディア情報の行数が多い他方のセッション情報に置き換えるセッション情報として決定するステップと、
を実行させることを特徴とするセッション間端末接続プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【公開番号】特開２０１０−９８４４３（Ｐ２０１０−９８４４３Ａ）
【公開日】平成２２年４月３０日（２０１０．４．３０）
【国際特許分類】
【出願番号】特願２００８−２６６４７８（Ｐ２００８−２６６４７８）
【出願日】平成２０年１０月１５日（２００８．１０．１５）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
【公開日】平成２２年４月３０日（２０１０．４．３０）
【国際特許分類】
【出願日】平成２０年１０月１５日（２００８．１０．１５）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
[ Back to top ]