(57)【特許請求の範囲】
【請求項１】
呼制御プロトコルの基本メソッド又は応答を用いて少なくとも１つの他の通信装置との間のセッションを制御する通信装置であって、
他の通信装置から送られた、セッション終了後の動作に係る再接続制御情報が前記基本メソッド又は応答に記述されたメッセージを受信するメッセージ受信部と、
前記メッセージに含まれる再接続制御情報に基づいて再接続制御を行う第１の制御部と、
３つ以上の通信装置間の相互セッションを制御する会議サーバ部と、を備え、
前記会議サーバ部は、
セッション終了後の動作に係る再接続制御情報が前記基本メソッドに記述されたメッセージを作成する第２のメッセージ作成部と、
他の通信装置から送られたメッセージに含まれる再接続制御情報に基づいて再接続制御を行う第２の制御部と、
前記第２のメッセージ作成部が作成したメッセージを他の複数の通信装置に送信し、かつ、他の通信装置から送られたメッセージを受信する送受信部と、を有することを特徴とする通信装置。
【請求項２】
請求項１に記載の通信装置であって、
前記再接続制御情報は、指定した通信装置からのセッション開始要求があるまでアイドル状態を維持するよう指示する情報であることを特徴とする通信装置。
【請求項３】
請求項１に記載の通信装置であって、
前記再接続制御情報は、指定した通信装置にセッション開始要求を行うよう指示する情報であることを特徴とする通信装置。
【請求項４】
呼制御プロトコルの基本メソッド又は応答を用いて少なくとも１つの他の通信装置との間のセッションを制御する通信装置であって、
セッション終了後の動作に係る再接続制御情報が前記基本メソッド又は応答に記述されたメッセージを作成する第１のメッセージ作成部と、
前記第１のメッセージ作成部が作成したメッセージを他の通信装置に送信するメッセージ送信部と、
３つ以上の通信装置間の相互セッションを制御する会議サーバ部と、を備え、
前記会議サーバ部は、
セッション終了後の動作に係る再接続制御情報が前記基本メソッドに記述されたメッセージを作成する第２のメッセージ作成部と、
他の通信装置から送られたメッセージに含まれる再接続制御情報に基づいて再接続制御を行う第２の制御部と、
前記第２のメッセージ作成部が作成したメッセージを他の複数の通信装置に送信し、かつ、他の通信装置から送られたメッセージを受信する送受信部と、を有することを特徴とする通信装置。
【請求項５】
請求項４に記載の通信装置であって、
前記再接続制御情報は、指定した通信装置からのセッション開始要求があるまでアイドル状態を維持するよう指示する情報であることを特徴とする通信装置。
【請求項６】
請求項４に記載の通信装置であって、
前記再接続制御情報は、指定した通信装置にセッション開始要求を行うよう指示する情報であることを特徴とする通信装置。
【請求項７】
呼制御プロトコルの基本メソッド又は応答を用いて少なくとも１つの他の通信装置との間のセッションを制御する通信装置であって、
セッション終了後の動作に係る再接続制御情報が前記基本メソッド又は応答に記述されたメッセージを作成する第１のメッセージ作成部と、
前記第１のメッセージ作成部が作成したメッセージを他の通信装置に送信し、かつ、他の通信装置から送られたメッセージを受信するメッセージ送受信部と、
他の通信装置から送られたメッセージに含まれる再接続制御情報に基づいて再接続制御を行う第１の制御部と、
３つ以上の通信装置間の相互セッションを制御する会議サーバ部と、を備え、
前記会議サーバ部は、
セッション終了後の動作に係る再接続制御情報が前記基本メソッドに記述されたメッセージを作成する第２のメッセージ作成部と、
他の通信装置から送られたメッセージに含まれる再接続制御情報に基づいて再接続制御を行う第２の制御部と、
前記第２のメッセージ作成部が作成したメッセージを他の複数の通信装置に送信し、かつ、他の通信装置から送られたメッセージを受信する送受信部と、を有することを特徴とする通信装置。
【請求項８】
請求項７に記載の通信装置であって、
前記再接続制御情報は、指定した通信装置からのセッション開始要求があるまでアイドル状態を維持するよう指示する情報、又は、指定した通信装置にセッション開始要求を行うよう指示する情報であることを特徴とする通信装置。
【請求項９】
請求項１〜８のいずれか一項に記載の通信装置であって、
前記基本メソッドには、セッション開始要求又はセッション終了要求が含まれることを特徴とする通信装置。
【請求項１０】
請求項１〜８のいずれか一項に記載の通信装置であって、
前記呼制御プロトコルは、ＳＩＰ（Session Initiation Protocol）であることを特徴
とする通信装置。
【請求項１１】
請求項１０に記載の通信装置であって、
前記セッション開始要求は、ＳＩＰで定義された「INVITE」であることを特徴とする通信装置。
【請求項１２】
請求項１０に記載の通信装置であって、
前記セッション終了要求は、ＳＩＰで定義された「BYE」であることを特徴とする通信装置。
【請求項１３】
呼制御プロトコルの基本メソッド又は応答を用いて複数の通信装置間のセッションを制御する通信システムであって、
前記複数の通信装置の各々は、
セッション終了後の動作に係る再接続制御情報が前記基本メソッド又は応答に記述されたメッセージを作成する第１のメッセージ作成部と、
前記第１のメッセージ作成部が作成したメッセージを他の通信装置に送信し、かつ、他の通信装置から送られたメッセージを受信するメッセージ送受信部と、
他の通信装置から送られたメッセージに含まれる再接続制御情報に基づいて再接続制御を行う第１の制御部と、
３つ以上の通信装置間の相互セッションを制御する会議サーバ部と、を備え、
前記会議サーバ部は、
セッション終了後の動作に係る再接続制御情報が前記基本メソッドに記述されたメッセージを作成する第２のメッセージ作成部と、
他の通信装置から送られたメッセージに含まれる再接続制御情報に基づいて再接続制御を行う第２の制御部と、
前記第２のメッセージ作成部が作成したメッセージを他の複数の通信装置に送信し、かつ、他の通信装置から送られたメッセージを受信する送受信部と、を有することを特徴とする通信システム。
【請求項１４】
請求項１３に記載の通信システムであって、
前記再接続制御情報は、指定した通信装置からのセッション開始要求があるまでアイドル状態を維持するよう指示する情報、又は、指定した通信装置にセッション開始要求を行うよう指示する情報であることを特徴とする通信システム。
【請求項１５】
呼制御プロトコルの基本メソッド又は応答を用いて複数の通信装置間のセッションを制御するセッション制御方法であって、
セッション終了後の動作に係る再接続制御情報が前記基本メソッド又は応答に記述されたメッセージを作成する第１のメッセージ作成部と、
前記第１のメッセージ作成部が作成したメッセージを他の通信装置に送信し、かつ、他の通信装置から送られたメッセージを受信する第１のメッセージ送受信部と、
３つ以上の通信装置間の相互セッションを制御する会議サーバ部と、を備えるとともに、
前記会議サーバ部は、
指定した通信装置からのセッション開始要求があるまでアイドル状態を維持するよう指示する第１の再接続制御情報、又は、指定した通信装置にセッション開始要求を行うよう指示する第２の再接続制御情報が、前記基本メソッド又は応答に記述されたメッセージを作成する第２のメッセージ作成部と、
前記第２のメッセージ作成部が作成したメッセージを他の通信装置に送信し、かつ、他の通信装置から送られたメッセージを受信する第２のメッセージ送受信部と、を有する前記複数の通信装置の各々は、
他の通信装置から送られたメッセージに含まれる再接続制御情報に基づいて再接続制御を行うことを特徴とするセッション制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、転送サービス、接続地点数の変更サービス又は会議サーバ移行サービスを容易に実現する、複数者通話を行うための通信装置、通信システム及びセッション制御方法に関する。
【背景技術】
【０００２】
近年、電話又はテレビ電話に代表される二地点通信に加えて、三者以上が参加可能な音声会議や多地点テレビ会議を実現する多地点通信が実用化されている。多地点通信を利用したサービスには、音声又は映像の通信サービスの他、次のような付加サービスが含まれる。例えば、二者通話を第三者に転送するサービス、二者通話から三者通話への切り替えや三者通話から二者通話への切り替え等の地点数変更サービス、又は使用する会議サーバを変更する会議サーバ移行サービス等である。このようなサービスを提供するための一つの方法としては、ＳＩＰ（Session Initiation Protocol）に準拠した転送方法、地点数変更方法又は会議サーバ移行方法がある。
【０００３】
図１７は、ＳＩＰに準拠した電話サービスシステムにおけるネットワーク構成の一例を示す図である。図１７に示すシステムでは、ＳＩＰで定義された「REFER」及び「NOTIFY」等の拡張メソッドを、サポートするＩＰ電話８０１〜８０４及び会議サーバ８１０が、ネットワーク８００を介して接続されている。このようなシステムにおいて、ＩＰ電話８０１〜８０４が二者通話を行う場合、ＩＰ電話は会議サーバ８１０を介さずに通信を行うことができる。また、ＩＰ電話８０１〜８０４が三者以上の通話を行う場合、ＩＰ電話は会議サーバ８１０を介して通信を行うことができる。
【０００４】
図１７に示すシステムにおいて、二者通話中の第三者への転送は、以下の手順で行われる。まず、ＩＰ電話８０１とＩＰ電話８０２が通話中に、ＩＰ電話８０１が通話を保留する。その後、ＩＰ電話８０１は、ＩＰ電話８０３に発信して、ＩＰ電話８０３と通話状態になる。その後、ＩＰ電話８０１がＩＰ電話８０３への転送を実行すると、ＩＰ電話８０２とＩＰ電話８０３の間で新規通話が確立する。さらに、ＩＰ電話８０１とＩＰ電話８０２の間の通話及びＩＰ電話８０１とＩＰ電話８０３の間の通話が切断されると、転送が完了する。
【０００５】
上記転送を行う際のＳＩＰシーケンスについて、図１８を用いて説明する。図１８は、ＳＩＰに準拠した電話サービスにおける転送シーケンスの一例を示す図である。まず、ＩＰ電話８０１は、ＩＰ電話８０２に「INVITE」リクエストを送る。ＩＰ電話８０２は、当該「INVITE」リクエストに対して「200 OK」応答をＩＰ電話８０１に送る。その結果、ＩＰ電話８０１とＩＰ電話８０２の間に「通話Ａ」が確立する。
【０００６】
通話Ａが確立している状態でＩＰ電話８０１に対して保留操作が行われると、ＩＰ電話８０１は、ＩＰ電話８０２に「UPDATE」リクエストを送る。ＩＰ電話８０２は、当該「UPDATE」リクエストに対して「200 OK」応答をＩＰ電話８０１に送る。その結果、ＩＰ電話８０１とＩＰ電話８０２の間の通話Ａが保留になる。
【０００７】
次に、ＩＰ電話８０１に対してＩＰ電話８０３への通話操作が行われると、ＩＰ電話８０１は、ＩＰ電話８０３に「INVITE」リクエストを送る。ＩＰ電話８０３は、当該「INVITE」リクエストに対して「200 OK」応答をＩＰ電話８０１に送る。その結果、ＩＰ電話８０１とＩＰ電話８０３の間に「通話Ｂ」が確立する。
【０００８】
通話Ｂが確立している状態でＩＰ電話８０１に対して転送操作が行われると、ＩＰ電話８０１は、次の動作を行う。ＩＰ電話８０１は、ＩＰ電話８０３のＵＲＩ（192.168.1.3）と、通話Ｂのセッション情報を記述したRefer-Toヘッダを含む「REFER」をＩＰ電話８０２に送る。次に、ＩＰ電話８０２は、当該「REFER」に対して「202 Accepted」応答をＩＰ電話８０１に送った後、「NOTIFY」をＩＰ電話８０１に送る。ＩＰ電話８０１は、当該「NOTIFY」に対して「200 OK」応答をＩＰ電話８０２に送る。
【０００９】
その後、ＩＰ電話８０２は、通話Ｂのセッション情報をReplacesヘッダに記述した「INVITE」リクエストをＩＰ電話８０３に送る。ＩＰ電話８０３は、当該「INVITE」リクエストに対して「200 OK」応答をＩＰ電話８０２に送る。その結果、ＩＰ電話８０２とＩＰ電話８０３の間に「通話Ｃ」が確立する。ＩＰ電話８０３は、Replacesヘッダに記述された通話Ｂを切断するために、ＩＰ電話８０１に「BYE」リクエストを送る。ＩＰ電話８０２は、ＩＰ電話８０３から「INVITE」リクエストに対する「200 OK」応答を受け取った後、転送完了を示す「200 OK」を含む「NOTIFY」をＩＰ電話８０１に送る。ＩＰ電話８０１は、当該「NOTIFY」に対して「200 OK」応答を送り、通話Ａを切断するためにＩＰ電話８０２に「BYE」リクエストを送る。ＩＰ電話８０２は、当該「BYE」リクエストに対して「200 OK」応答をＩＰ電話８０１に送る。以上説明した手順によりＩＰ電話８０２とＩＰ電話８０３が通話することが可能となり、転送が完了する。
【００１０】
次に、二者通話から三者通話に切り替える際のＳＩＰシーケンスについて、図１９を用いて説明する。図１９は、ＳＩＰに準拠した電話サービスにおける二者通話から三者通話への移行シーケンスの一例を示す図である。まず、ＩＰ電話８０１は、ＩＰ電話８０２に「INVITE」リクエストを送る。ＩＰ電話８０２は、当該「INVITE」リクエストに対して「200 OK」応答をＩＰ電話８０１に送る。その結果、ＩＰ電話８０１とＩＰ電話８０２の間に「通話Ａ」が確立する。
【００１１】
通話Ａが確立している状態で、ＩＰ電話８０３がＩＰ電話８０１に「INVITE」リクエストを送ると、ＩＰ電話８０１は、呼出中を表す「180 Ringing」応答をＩＰ電話８０３に送る。ＩＰ電話８０１に対して通話切替操作が行われると、ＩＰ電話８０１は、ＩＰ電話８０２に「UPDATE」リクエストを送る。ＩＰ電話８０２は、当該「UPDATE」リクエストに対して「200 OK」応答をＩＰ電話８０１に送る。その結果、ＩＰ電話８０１とＩＰ電話８０２の間の通信Ａが保留になる。
【００１２】
次に、ＩＰ電話８０１は、ＩＰ電話８０３に対して「200 OK」応答を送る。その結果、ＩＰ電話８０１とＩＰ電話８０３の間に「通話Ｂ」が確立する。その後、ＩＰ電話８０１に対して三者通話への切替操作が行われると、ＩＰ電話８０１は、会議サーバ８１０に「INVITE」リクエストを送る。会議サーバ８１０は、当該「INVITE」リクエストに対して「200 OK」応答をＩＰ電話８０１に送り、ＩＰ電話８０１が参加する「会議Ｃ」を確立する。
【００１３】
その後、ＩＰ電話８０１は、ＩＰ電話８０２のＵＲＩ（192.168.1.2）と、通話Ａのセッション情報を記述したRefer-Toヘッダを含む「REFER」を会議サーバ８１０に送る。次に、会議サーバ８１０は、当該「REFER」に対して「202 Accepted」応答をＩＰ電話８０１に送った後、「NOTIFY」をＩＰ電話８０１に送る。ＩＰ電話８０１は、当該「NOTIFY」に対して「200 OK」応答を会議サーバ８１０に送る。その後、会議サーバ８１０は、通話Ｂのセッション情報をReplacesヘッダに記述した「INVITE」リクエストをＩＰ電話８０２に送る。ＩＰ電話８０２は、当該「INVITE」リクエストに対して「200 OK」応答を送って会議Ｄを確立する。その後、ＩＰ電話８０２は、Replacesヘッダに記述された通話Ｂを切断するために、ＩＰ電話８０１に「BYE」リクエストを送る。
【００１４】
ＩＰ電話８０１は、ＩＰ電話８０２を会議に参加させた手順と同じ手順でＩＰ電話８０３も会議に参加させる。これによって、ＩＰ電話８０１，８０２，８０３は、それぞれ会議サーバ８１０との間に会議用セッションとして会議Ｃ，会議Ｄ，会議Ｅを確立するため、会議サーバ８１０を介した三者通話が確立する。
【００１５】
次に、テレビ会議の例を示す。図２０は、ＳＩＰに準拠したテレビ会議システムにおけるネットワーク構成の一例を示す図である。図２０に示すシステムでは、テレビ会議端末９０１〜９０４が、ネットワーク９００を介して接続されている。なお、テレビ会議端末９０１〜９０４は、それぞれ会議サーバを内蔵しており、三者以上の通話を行う場合は内蔵会議サーバを介して通信を行う。
【００１６】
図２０に示すシステムにおいて、四者通話中の三者通話への切替は、以下の手順で行われる。テレビ会議端末９０１の内蔵会議サーバを使用してテレビ会議端末９０１〜９０４が通話中にテレビ会議端末９０４が切断すると、テレビ会議端末９０４との通話が切断され、テレビ会議端末９０１〜９０３の三者通話となる。
【００１７】
テレビ会議において、四者通話から三者通話に切り替える際のＳＩＰシーケンスを図２１に示す。図２１は、四者通話から三者通話に切り替える際のＳＩＰシーケンスの一例を示す図である。テレビ会議端末９０１〜９０４は、テレビ会議端末９０１の内蔵会議サーバ９１０を介して通話を確立している。このとき、テレビ会議端末９０４が、会議から離脱するために会議サーバ９１０に「BYE」リクエストを送る。会議サーバ９１０は、当該「BYE」に対して「200 OK」をテレビ会議端末９０４に送る。その結果、テレビ会議端末９０１〜９０３による三者通話に切り替わり、三者通話が可能となる。
【００１８】
なお、図２０に示したシステムにおいて、四者通話中に、内蔵会議サーバを使用しているテレビ会議端末が切断した場合、通常は三者通話に移行せずに、全てのテレビ会議端末が当該内蔵会議サーバと通話を切断して会議を終了する。これは、三者通話を継続する場合、会議サーバを移行する必要があるためである。
【００１９】
内蔵会議サーバを使用しているテレビ会議端末が切断した場合のＳＩＰシーケンスを図２２に示す。図２２は、内蔵会議サーバを使用しているテレビ会議端末が切断した場合のＳＩＰシーケンスの一例を示す図である。テレビ会議端末９０１〜９０４は、テレビ会議端末９０１の内蔵会議サーバ９１０を介して通話を確立している。このとき、テレビ会議端末９０１が、会議から離脱するために内蔵会議サーバ９１０に「BYE」リクエストを送る。会議サーバ９１０は、当該「BYE」リクエストに対して「200 OK」応答をテレビ会議端末９０１に送る。
【００２０】
その後、会議サーバ９１０は、テレビ会議端末９０２〜９０４の各々に「BYE」リクエストを送信する。次に、テレビ会議端末９０２〜９０４は、当該「BYE」リクエストに対する「200 OK」応答を会議サーバ９１０に送って通話を切断する。これによって会議が終了する。
【００２１】
このように、上記の方法では、ＳＩＰに準拠した地点数切替方法を利用することによって、会議サーバを内蔵するテレビ会議端末を用いた場合でも地点数切り替えを実現できる。但し、内蔵会議サーバを使用しているテレビ会議端末が会議から離脱する場合には、会議サーバの移行ができないため、会議を終了しなければならなかった。
【００２２】
会議サーバ移行方法の一例については、特許文献１で示されている。特許文献１の方法では、会議から離脱したテレビ会議端末に内蔵された会議サーバが、別のテレビ会議端末に内蔵された会議サーバにサーバ移動要求を送る。サーバ移動要求を受信した会議サーバは、現在の会議情報を取得するため、会議から離脱したテレビ会議端末に内蔵された会議サーバに取得メッセージを送信する。次に、サーバ移動要求を受信した会議サーバは、取得メッセージに対する応答メッセージから現在の会議情報を取得し、現在の会議情報に応じて会議を開始する。このようにして、会議サーバが移行する。
【先行技術文献】
【特許文献】
【００２３】
【特許文献１】特開平１０−２８９１８５号公報
【発明の概要】
【発明が解決しようとする課題】
【００２４】
上記説明したＳＩＰに準拠した転送方法及び地点数変更方法では、「REFER」メソッド及び「NOTIFY」メソッドを使いた複雑なシーケンスが実行される。したがって、システムを構築するＩＰ電話及び会議サーバは、ＳＩＰで定義されたこれらの拡張メソッドをサポートしている端末である必要がある。言い替えれば、これらの拡張メソッドをサポートしていない端末との間では、上記説明した転送方法及び地点数変更方法を実行できない。
【００２５】
また、「REFER」や「NOTIFY」等のメソッドは、「BYE」メソッド等の基本メソッドではなく、システムの機能拡張を実現する拡張メソッドである。したがって、転送又は地点数の変更を実現するためのシーケンスが複雑となるため、開発工数が多い。また、会議サーバ移行方法に関して、上記説明した特許文献１の方法では、標準規格で定義されていない独自のメッセージを会議サーバが送受信する。
【００２６】
したがって、当該方法に対応していない会議サーバとの間では、会議サーバを移行することができないという課題を有している。また、独自のメッセージを利用するため、当該方法の開発工数が多い。
【００２７】
本発明の目的は、呼制御プロトコルの基本メソッドを利用して転送、地点数切替又は会議サーバ移行が可能な通信装置、通信システム及びセッション制御方法を提供することである。
【課題を解決するための手段】
【００２８】
本発明は、呼制御プロトコルの基本メソッド又は応答を用いて少なくとも１つの他の通信装置との間のセッションを制御する通信装置であって、他の通信装置から送られた、セッション終了後の動作に係る再接続制御情報が前記基本メソッド又は応答に記述されたメッセージを受信するメッセージ受信部と、前記メッセージに含まれる再接続制御情報に基づいて再接続制御を行う第１の制御部と、３つ以上の通信装置間の相互セッションを制御する会議サーバ部と、を備え、前記会議サーバ部は、セッション終了後の動作に係る再接続制御情報が前記基本メソッドに記述されたメッセージを作成する第２のメッセージ作成部と、他の通信装置から送られたメッセージに含まれる再接続制御情報に基づいて再接続制御を行う第２の制御部と、前記第２のメッセージ作成部が作成したメッセージを他の複数の通信装置に送信し、かつ、他の通信装置から送られたメッセージを受信する送受信部と、を有する通信装置を提供する。
【００２９】
本発明は、呼制御プロトコルの基本メソッド又は応答を用いて少なくとも１つの他の通信装置との間のセッションを制御する通信装置であって、セッション終了後の動作に係る再接続制御情報が前記基本メソッド又は応答に記述されたメッセージを作成する第１のメッセージ作成部と、前記第１のメッセージ作成部が作成したメッセージを他の通信装置に送信するメッセージ送信部と、３つ以上の通信装置間の相互セッションを制御する会議サーバ部と、を備え、前記会議サーバ部は、セッション終了後の動作に係る再接続制御情報が前記基本メソッドに記述されたメッセージを作成する第２のメッセージ作成部と、他の通信装置から送られたメッセージに含まれる再接続制御情報に基づいて再接続制御を行う第２の制御部と、前記第２のメッセージ作成部が作成したメッセージを他の複数の通信装置に送信し、かつ、他の通信装置から送られたメッセージを受信する送受信部と、を有する通信装置を提供する。
【００３０】
本発明は、呼制御プロトコルの基本メソッド又は応答を用いて少なくとも１つの他の通信装置との間のセッションを制御する通信装置であって、セッション終了後の動作に係る再接続制御情報が前記基本メソッド又は応答に記述されたメッセージを作成する第１のメッセージ作成部と、前記第１のメッセージ作成部が作成したメッセージを他の通信装置に送信し、かつ、他の通信装置から送られたメッセージを受信するメッセージ送受信部と、他の通信装置から送られたメッセージに含まれる再接続制御情報に基づいて再接続制御を行う第１の制御部と、３つ以上の通信装置間の相互セッションを制御する会議サーバ部と、を備え、前記会議サーバ部は、セッション終了後の動作に係る再接続制御情報が前記基本メソッドに記述されたメッセージを作成する第２のメッセージ作成部と、他の通信装置から送られたメッセージに含まれる再接続制御情報に基づいて再接続制御を行う第２の制御部と、前記第２のメッセージ作成部が作成したメッセージを他の複数の通信装置に送信し、かつ、他の通信装置から送られたメッセージを受信する送受信部と、を有する通信装置を提供する。
【００３２】
本発明は、呼制御プロトコルの基本メソッド又は応答を用いて複数の通信装置間のセッションを制御する通信システムであって、前記複数の通信装置の各々は、セッション終了後の動作に係る再接続制御情報が前記基本メソッド又は応答に記述されたメッセージを作成する第１のメッセージ作成部と、前記第１のメッセージ作成部が作成したメッセージを他の通信装置に送信し、かつ、他の通信装置から送られたメッセージを受信するメッセージ送受信部と、他の通信装置から送られたメッセージに含まれる再接続制御情報に基づいて再接続制御を行う第１の制御部と、３つ以上の通信装置間の相互セッションを制御する会議サーバ部と、を備え、前記会議サーバ部は、セッション終了後の動作に係る再接続制御情報が前記基本メソッドに記述されたメッセージを作成する第２のメッセージ作成部と、他の通信装置から送られたメッセージに含まれる再接続制御情報に基づいて再接続制御を行う第２の制御部と、前記第２のメッセージ作成部が作成したメッセージを他の複数の通信装置に送信し、かつ、他の通信装置から送られたメッセージを受信する送受信部と、を有する通信システムを提供する。
【００３３】
本発明は、呼制御プロトコルの基本メソッド又は応答を用いて複数の通信装置間のセッションを制御するセッション制御方法であって、セッション終了後の動作に係る再接続制御情報が前記基本メソッド又は応答に記述されたメッセージを作成する第１のメッセージ作成部と、前記第１のメッセージ作成部が作成したメッセージを他の通信装置に送信し、かつ、他の通信装置から送られたメッセージを受信する第１のメッセージ送受信部と、３つ以上の通信装置間の相互セッションを制御する会議サーバ部と、を備えるとともに、前記会議サーバ部は、指定した通信装置からのセッション開始要求があるまでアイドル状態を維持するよう指示する第１の再接続制御情報、又は、指定した通信装置にセッション開始要求を行うよう指示する第２の再接続制御情報が、前記基本メソッド又は応答に記述されたメッセージを作成する第２のメッセージ作成部と、前記第２のメッセージ作成部が作成したメッセージを他の通信装置に送信し、かつ、他の通信装置から送られたメッセージを受信する第２のメッセージ送受信部と、を有する前記複数の通信装置の各々は、他の通信装置から送られたメッセージに含まれる再接続制御情報に基づいて再接続制御を行うセッション制御方法を提供する。
【発明の効果】
【００３４】
本発明に係る通信装置、通信システム及びセッション制御方法によれば、呼制御プロトコルの基本メソッドを利用して転送、地点数切替又は会議サーバ移行が可能である。
【図面の簡単な説明】
【００３５】
【図１】ＳＩＰに準拠したテレビ会議システムにおけるネットワーク構成の一例を示す図
【図２】第１の実施形態の会議端末の内部構成を示すブロック図
【図３】第１の実施形態のテレビ会議システムにおける転送シーケンスの一例を示す図
【図４】図３に示した転送シーケンスにおける会議端末１０１の動作を示すフローチャート
【図５】図３に示した転送シーケンスにおける会議端末１０３の動作を示すフローチャート
【図６】図３に示した転送シーケンスにおける会議端末１０２の動作に示すフローチャート
【図７】ＳＩＰに準拠したテレビ会議システムにおけるネットワーク構成の一例を示す図
【図８】第２の実施形態の会議端末の内部構成を示すブロック
【図９】第２の実施形態の会議端末に含まれる会議サーバの内部構成を示すブロック図
【図１０】第２の実施形態のテレビ会議システムにおける二者通話から三者通話への移行シーケンスの一例を示す図
【図１１】図１０に示した移行シーケンスにおける会議端末２０１の動作を示すフローチャート
【図１２】図１０に示した移行シーケンスにおける会議端末２０３の動作を示すフローチャート
【図１３】図１０に示した移行シーケンスにおける会議端末２０２の動作に示すフローチャート
【図１４】第３の実施形態のテレビ会議システムにおける三者通話から二者通話への移行シーケンスの一例を示す図
【図１５】第４の実施形態のテレビ会議システムにおける四者通話から三者通話への移行シーケンスの一例を示す図
【図１６】図１４に示した第３の実施形態の移行シーケンス及び図１５に示した第４の実施形態の移行シーケンスにおける会議端末２０２の動作を示すフローチャート
【図１７】ＳＩＰに準拠した電話サービスシステムにおけるネットワーク構成の一例を示す図
【図１８】ＳＩＰに準拠した電話サービスにおける転送シーケンスの一例を示す図
【図１９】ＳＩＰに準拠した電話サービスにおける二者通話から三者通話への移行シーケンスの一例を示す図
【図２０】ＳＩＰに準拠したテレビ会議システムにおけるネットワーク構成の一例を示す図
【図２１】四者通話から三者通話に切り替える際のＳＩＰシーケンスの一例を示す図
【図２２】内蔵会議サーバを使用しているテレビ会議端末が切断した場合のＳＩＰシーケンスの一例を示す図
【発明を実施するための形態】
【００３６】
以下、本発明の実施形態について、図面を参照して説明する。なお、以下説明する実施形態では、多地点テレビ会議の例を示すが、音声会議又はその他の会議通信であっても同様の手順で実現可能である。また、本実施形態では、当該会議で用いられる通信プロトコルとしてＳＩＰを用いて説明する。なお、通信プロトコルとしては、H.323又はHTTP等の他の通信プロトコルが用いても良い。
【００３７】
（第１の実施形態）
第１の実施形態では、再接続制御情報を含むＳＩＰ（Session Initiation Protocol）の基本メソッドを送受信することによって、実現される転送サービスの一例について説明する。
【００３８】
図１は、ＳＩＰに準拠したテレビ会議システムにおけるネットワーク構成の一例を示す図である。図１に示すシステムでは、ＲＦＣ３２６１等に規定されたＳＩＰの基本メソッドに準拠した会議端末１０１〜１０４が、ネットワーク１００を介して接続されている。ネットワーク１００は、インターネット、社内ＬＡＮ、宅内ネットワーク又はその他のネットワークである。なお、ＳＩＰの基本メソッドには、「INVITE」リクエスト、「UPDATE」リクエスト及び「BYE」リクエスト、並びに、これらのリクエストに対する「200 OK」等の応答が含まれる。これらのリクエスト及び応答は、「メッセージ」という。「INVITE」リクエストは、セッションを開始するよう要求するメッセージである。「UPDATE」リクエストは、確立されているセッションを保留するよう要求するメッセージである。「BYE」リクエストは、セッションを終了するよう要求するメッセージである。
【００３９】
図２は、第１の実施形態の会議端末の内部構成を示すブロック図である。図２に示すように、テレビ会議システムで用いられる会議端末１０１〜１０４の各々は、通信部１１１と、セッション確立部１１３と、セッション保留部１１５と、切断メッセージ作成部１１７と、切断メッセージ送受信部１１９と、メディアデータ送受信部１２１と、制御部１２３と、映像・音声入出力部１２５と、入力インターフェイス部１２７とを備える。
【００４０】
通信部１１１は、ネットワーク１００を介して他の会議端末と通信を行う。
【００４１】
セッション確立部１１３は、会議端末間で、「INVITE」リクエスト及びこのリクエストに対する「200 OK」応答を、通信部１１１を介して送受信する。セッション確立部１１３は、「INVITE」リクエスト及び「200 OK」応答の送受信が完了すると、会議端末間でのセッションを確立する。その結果、当該会議端末間は通話状態となる。
【００４２】
セッション保留部１１５は、セッションが確立している会議端末間で、「UPDATE」リクエスト及びこのリクエストに対する「200 OK」応答を通信部１１１を介して送受信する。セッション保留部１１５は、「UPDATE」リクエスト及び「200 OK」応答の送受信が完了すると、会議端末間の通話を保留する。
【００４３】
切断メッセージ作成部１１７は、Reasonヘッダに再接続制御情報が記述された「BYE」リクエストを作成する。「BYE」リクエストは、セッションを終了するためのメッセージである。再接続制御情報は、他の会議端末からの着信があるまで着信待ち状態（アイドル状態）を維持するよう指示する情報、及び特定の端末に発信するよう指示する情報の２種類である。１つ目の再接続制御情報は、例えば、「process=recv;from="sip:192.168.1.2"」と表される。この再接続制御情報は、識別情報であるSIP URIがsip:192.168.1.2の会議端末からの「INVITE」リクエストを受け取るまで、着信待ち状態（アイドル状態）を保持するよう指示している。２つ目の再接続制御情報は、例えば、「process=send;to="sip:192.168.1.3"」と表される。この再接続制御情報は、SIP URIがsip:192.168.1.3の会議端末に「INVITE」リクエストを送るよう指示している。
【００４４】
なお、会議端末の識別情報としては、SIP URIの他、ＩＰアドレス又はＭＡＣアドレス等が用いられても良い。また、セッションを終了するためのメッセージは、「BYE」リクエスト以外でも良い。さらに、再接続制御情報は、「BYE」リクエストのReasonヘッダに限らず、「BYE」リクエストの他のヘッダやボディに記述されていても良い。
【００４５】
切断メッセージ送受信部１１９は、切断メッセージ作成部１１７が作成した「BYE」リクエスト、及び他の会議端末から送られた「BYE」リクエストに対する「200 OK」応答を、通信部１１１を介して送信する。また、切断メッセージ送受信部１１９は、他の会議端末から送られた「BYE」リクエスト及び「200 OK」応答を、通信部１１１を介して受信する。切断メッセージ送受信部１１９は、「BYE」リクエスト及び「200 OK」応答の送受信が完了すると、会議端末間で確立していたセッションを終了する。このとき、通話中であった各会議端末は、アイドル状態となる。
【００４６】
映像・音声入出力部１２５は、カメラ、マイク、ディスプレイ及びスピーカ等である。メディアデータ送受信部１２１は、会議端末間で、映像・音声入出力部１２５を介して入出力された映像又は音声等のメディアデータを通信部１１１を介して送受信する。入力インターフェイス部１２７は、会議端末のユーザが設定情報等を会議端末に入力するためのインターフェイスである。
【００４７】
制御部１２３は、会議端末に含まれる各部を制御する。また、制御部１２３は、切断メッセージ送受信部１１９が「BYE」リクエストを受信すると、セッションを終了するよう処理する。制御部１２３がセッションを終了すると、会議端末はアイドル状態になる。さらに、制御部１２３は、切断メッセージ送受信部１１９が受信した「BYE」リクエストのReasonヘッダに記述された再接続制御情報を参照して、当該再接続制御情報が指示する動作を行う。
【００４８】
図１に示すテレビ会議システムにおいて、会議端末１０１と会議端末１０２の間の二者通話中の会議端末１０３への転送は、以下の手順で行われる。なお、会議端末１０１のSIP URI（Uniform Resource Identifier）は、「sip:192.168.1.1」である。会議端末１０２のSIP URIは、「sip:192.168.1.2」である。会議端末１０３のSIP URIは、「sip:192.168.1.3」である。なお、ＳＩＰは、アプリケーション・レイヤの共通のアドレスであるＵＲＩを指定してセッションの相手を指定します。
【００４９】
図３は、第１の実施形態のテレビ会議システムにおける転送シーケンスの一例を示す図である。なお、図３では、「ACK」の図示が省略されている。まず、会議端末１０１は、会議端末１０２に「INVITE」リクエストを送る（Ｐ１０１）。会議端末１０２は、当該「INVITE」リクエストに対して「200 OK」応答会議端末１０１に送る（Ｐ１０３）。その結果、会議端末１０１と会議端末１０２の間にセッション「通話Ａ」が確立する。
【００５０】
通話Ａが確立している状態で、会議端末１０１に対して保留動作が行われると、会議端末１０１は、会議端末１０２に「UPDATE」リクエストを送る（Ｐ１０５）。次に、会議端末１０２は、当該「UPDATE」リクエストに対して「200 OK」応答を会議端末１０１に送る（Ｐ１０７）。その結果、会議端末１０１と会議端末１０２の間のセッション「通話Ａ」が保留になる。
【００５１】
次に、会議端末１０１に対して会議端末１０３への通話操作が行われると、会議端末１０１は、会議端末１０３に「INVITE」リクエストを送る（Ｐ１０９）。会議端末１０３は、当該「INVITE」リクエストに対して「200 OK」応答を会議端末１０１に送る（Ｐ１１１）。その結果、会議端末１０１と会議端末１０３の間にセッション「通話Ｂ」が確立する。
【００５２】
その後、会議端末１０１は、通話Ｂを終了するための「BYE」リクエストを会議端末１０３に送る（Ｐ１１３）。「BYE」リクエストのReasonヘッダには、会議端末１０２（sip:192.168.1.2）からの着信待ちを指示する再接続制御情報を記述する。再接続制御情報は、例えば、「process=recv;from="sip:192.168.1.2"」と記述する。会議端末１０３は、当該「BYE」リクエストに対する「200 OK」応答を会議端末１０１に送る（Ｐ１１５）。この後、会議端末１０３は、アイドル状態に移行して、会議端末１０２からの着信待ちの状態となる。
【００５３】
次に、会議端末１０１は、通話Ａを終了するための「BYE」リクエストを会議端末１０２に送る（Ｐ１１７）。この「BYE」リクエストのReasonヘッダには、会議端末１０３（sip:192.168.1.3）への発信を指示する再接続制御情報を記述する。再接続制御情報は、例えば、「process=send;to="sip:192.168.1.3"」と記述する。会議端末１０２は、当該「BYE」リクエストに対する「200 OK」応答を会議端末１０１に送る（Ｐ１１９）。
【００５４】
会議端末１０２は、会議端末１０１から送られた「BYE」リクエストのReasonヘッダに記述された再接続制御情報に従い、会議端末１０３に「INVITE」リクエストを送る（Ｐ１２１）。会議端末１０３は、当該「INVITE」リクエストに対する「200 OK」応答を会議端末１０２に送る（Ｐ１２３）。その結果、会議端末１０２と会議端末１０３の間にセッション「通話Ｃ」が確立する。このようにして、会議端末１０１と会議端末１０２の通話を会議端末１０２と会議端末１０３の通話に切り替える転送サービスが実現される。
【００５５】
図４は、図３に示した転送シーケンスにおける会議端末１０１の動作を示すフローチャートである。まず、セッション確立部１１３は、会議端末１０２に「INVITE」リクエストを送り、通話Ａを確立する（Ｓ１０１）。その後、セッション保留部１１５は、会議端末１０２に「UPDATE」リクエストを送り、通話Ａを保留とする（Ｓ１０３）。その後、セッション確立部１１３は、会議端末１０３に「INVITE」リクエストを送り、通話Ｂを確立する（Ｓ１０５）。
【００５６】
制御部１２３は、会議端末１０１と会議端末１０２の間の通話が切断後に、発信側になる会議端末及び着信側になる会議端末をそれぞれ決定する（Ｓ１０７）。発信側及び着信側の決定方法は、識別情報の番号が小さい方を発信側にするなど、どのような方法でも良い。本実施形態では、発信側になる会議端末を会議端末１０２、着信側になる会議端末を会議端末１０３に決定した例を示す。
【００５７】
次に、切断メッセージ作成部１１７は、着信側になる会議端末（会議端末１０３）に送る「BYE」リクエストを作成する（Ｓ１０９）。なお、切断メッセージ作成部１１７は、この「BYE」リクエストのReasonヘッダに、会議端末１０２（sip:192.168.1.2）からの着信待ちを指示する再接続制御情報を記述する。再接続制御情報は、例えば、「process=recv;from="sip:192.168.1.2"」と記述される。次に、切断メッセージ送受信部１１９は、切断メッセージ作成部１１７が作成した当該「BYE」リクエストを会議端末１０３に送る（Ｓ１１１）。
【００５８】
次に、切断メッセージ作成部１１７は、発信側になる会議端末（会議端末１０２）に送る「BYE」リクエストを作成する（Ｓ１１３）。なお、切断メッセージ作成部１１７は、この「BYE」リクエストのReasonヘッダに、会議端末１０３（sip:192.168.1.3）への発信を指示する再接続制御情報を記述する。再接続制御情報は、例えば、「process=send;to="sip:192.168.1.3"」と記述される。次に、切断メッセージ送受信部１１９は、切断メッセージ作成部１１７が作成した当該「BYE」リクエストを会議端末１０２に送る（Ｓ１１５）。
【００５９】
図５は、図３に示した転送シーケンスにおける会議端末１０３の動作を示すフローチャートである。まず、セッション確立部１１３は、会議端末１０１からの「INVITE」リクエストを受け取って通話Ｂを確立する（Ｓ２０１）。次に、切断メッセージ送受信部１１９は、会議端末１０１からの「BYE」リクエストを受け取る（Ｓ２０３）。この「BYE」リクエストのReasonヘッダには、会議端末１０２（sip:192.168.1.2）からの着信待ちを指示する再接続制御情報が記述されている。再接続制御情報は、例えば、「process=recv;from="sip:192.168.1.2"」と記述される。
【００６０】
次に、制御部１２３は、受信した「BYE」リクエストに記述された再接続制御情報に従って、自端末（会議端末１０３）を会議端末１０２からの着信待ちの状態にする（Ｓ２０５）。その後、セッション確立部１１３は、会議端末１０２からの「INVITE」リクエストを受け取る（Ｓ２０７）。制御部１２３は、「INVITE」リクエストの発信元アドレスが、ステップＳ２０３で受け取った「BYE」リクエストの再接続制御情報に記述されたアドレスと一致するかを判断する（Ｓ２０９）。なお、制御部１２３は、「INVITE」リクエストのFromヘッダ等を参照して、当該「INVITE」リクエストの発信元アドレスを判別する。
【００６１】
これらのアドレスが一致する場合、セッション確立部１１３は、「200 OK」応答を会議端末１０２に送って通話Ｃを確立する（Ｓ２１１）。一方、これらのアドレスが一致しない場合、セッション確立部１１３は、次の処理を行う。セッション確立部１１３は、ステップＳ２０７で受け取った「INVITE」リクエストに対するエラー応答（03 Forbidden等）を、会議端末１０２に送って着信を拒否し（Ｓ２１３）、自端末を再び着信待ちの状態にする。なお、ステップＳ２１３において、セッション確立部１１３は、エラー応答を送らずに「INVITE」リクエストを無視しても良い。
【００６２】
上記説明では、ステップＳ２０９で、制御部１２３は、「INVITE」リクエストの発信元アドレスが、その前に受け取った「BYE」リクエストの再接続制御情報に記述されたアドレスと一致するかを判断すると説明した。しかし、会議端末１０３の制御部１２３は、当該判断を行わなくても良い。すなわち、会議端末１０３の制御部１２３は、「BYE」リクエストに記述された再接続制御情報を参照する機能を有していなくても良い。この場合、ステップＳ２１３は行われない。但し、会議端末１０３のセッション確立部１１３は、会議端末１０２以外の会議端末から「INVITE」リクエストを受け取る場合がある。この場合、会議端末１０３のセッション確立部１１３は、この「INVITE」リクエストに対する「200 OK」応答を当該会議端末に送ってセッションを確立してしまう。
【００６３】
図６は、図３に示した転送シーケンスにおける会議端末１０２の動作に示すフローチャートである。まず、セッション確立部１１３は、会議端末１０１からの「INVITE」リクエストを受け取って通話Ａを確立する（Ｓ３０１）。その後、セッション保留部１１５は、会議端末１０１からの「UPDATE」リクエストを受け取り、通話Ａを保留とする（Ｓ３０３）。
【００６４】
次に、切断メッセージ送受信部１１９は、会議端末１０１からの「BYE」リクエストを受け取る（Ｓ３０５）。この「BYE」リクエストのReasonヘッダには、会議端末１０３（sip:192.168.1.3）への発信を指示する再接続制御情報が記述されている。再接続制御情報は、例えば、「process=send;to="sip:192.168.1.3"」と記述される。セッション確立部１１３は、ステップＳ３０５で受け取った「BYE」リクエストに記述された再接続制御情報に従って、会議端末１０３に「INVITE」リクエストを送る（Ｓ３０７）。その後、セッション確立部１１３は、ステップＳ３０７で送った「INVITE」リクエストに対する「200 OK」応答を受け取って通話Ｃを確立する（Ｓ３０９）。
【００６５】
以上説明したように、第１の実施形態では、会議端末１０１の切断メッセージ作成部１１７が、「BYE」リクエストに、各会議端末が行う動作(発信又は着信)に関する指示、及び発信先又は着信先のアドレスを再接続制御情報として記述する。当該「BYE」リクエストを受け取った会議端末が再接続制御情報の指示する動作を行うことによって、転送サービスが実現される。
【００６６】
このように、本実施形態では、転送サービスを実現するために、ＲＦＣ３２６１等に規定されたＳＩＰの基本メソッドしか用いられていない。したがって、本実施形態では、ＳＩＰの基本メソッドに対応した会議端末であれば、煩雑な処理を行うことなく容易に転送サービスを実現可能である。すなわち、拡張メソッドに対応していない会議端末や独自のメッセージを利用した会議端末であっても、ＳＩＰの基本メソッドに対応してさえすれば、接続性を失うことなく転送サービスを実現することができる。また、本実施形態では、当該転送サービスを開発するための工数を削減できる。さらに、送受信するメッセージ数が減るため、サービスの実行に必要な時間が短縮される。
【００６７】
なお、ＳＩＰは、理解できないヘッダを無視するというプロトコルである。このため、会議端末１０３が、他の会議端末から受け取った「BYE」リクエストのReasonヘッダに記述された再接続制御情報を参照しない端末であった場合、Reasonヘッダを無視するだけである。但し、会議端末１０３は、「BYE」リクエストに従ってセッションを終了し着信待ちの状態となるため、転送サービスは実現可能である。
【００６８】
（第２の実施形態）
第２の実施形態では、再接続制御情報を含むＳＩＰの基本メソッドを送受信することによって、実現される二者通話から三者通話への移行サービスの一例について説明する。
【００６９】
図７は、ＳＩＰに準拠したテレビ会議システムにおけるネットワーク構成の一例を示す図である。図７に示すシステムでは、ＲＦＣ３２６１等に規定されたＳＩＰの基本メソッドに準拠した会議端末２０１〜２０４が、ネットワーク１００を介して接続されている。ネットワーク１００は、インターネット、社内ＬＡＮ、宅内ネットワーク又はその他のネットワークである。
【００７０】
図８は、第２の実施形態の会議端末の内部構成を示すブロック図である。図８に示すように、テレビ会議システムで用いられる会議端末２０１〜２０４の各々は、第１の実施形態の会議端末と同様に、通信部１１１と、セッション確立部１１３と、セッション保留部１１５と、切断メッセージ作成部１１７と、切断メッセージ送受信部１１９と、メディアデータ送受信部１２１と、制御部１２３と、映像・音声入出力部１２５と、入力インターフェイス部１２７とを備える。さらに、会議端末２０１〜２０４は、会議サーバ２１１を備えるものとする。なお、図８において、図２と共通する構成要素には、同じ参照符号が付されている。
【００７１】
会議サーバ２１１は、当該テレビ会議システムにおいて、三者以上の会議が行われる際に使用される。このとき、会議端末間の通信は、３つの会議端末のいずれかの会議サーバを介して行われる。当該会議サーバは、各会議端末とのセッション確立及び会議端末間の通信の中継を、通信部１１１を介して行う。
【００７２】
図９は、第２の実施形態の会議端末に含まれる会議サーバ２１１の内部構成を示すブロック図である。図９に示すように、会議サーバ２１１は、セッション確立部２２１と、切断メッセージ作成部２２３と、切断メッセージ送受信部２２５と、制御部２２７とを有する。
【００７３】
セッション確立部２２１は、会議端末との間で、「INVITE」リクエスト及びこのリクエストに対する「200 OK」応答を、会議端末の通信部１１１を介して送受信する。セッション確立部２２１は、「INVITE」リクエスト及び「200 OK」応答の送受信が完了すると、会議端末との間のセッションを確立する。なお、セッション確立部２２１は、会議端末から送られた「INVITE」リクエストに、セッションを確立する会議端末のアドレスが再接続制御情報として記述されているとき、各アドレスの会議端末に「INVITE」リクエストを送る。
【００７４】
切断メッセージ作成部２２３は、Reasonヘッダに再接続制御情報が記述された「BYE」リクエストを作成する。当該「BYE」リクエストに記述される再接続制御情報は、第１の実施形態で説明した再接続制御情報と同様である。切断メッセージ送受信部２２５は、切断メッセージ作成部２２３が作成した「BYE」リクエスト、及び会議端末から送られた「BYE」リクエストに対する「200 OK」応答を、会議端末の通信部１１１を介して送信する。また、切断メッセージ送受信部２２５は、会議端末から送られた「BYE」リクエスト及び「200 OK」応答を、会議端末の通信部１１１を介して受信する。切断メッセージ送受信部２２５は、「BYE」リクエスト及び「200 OK」応答の送受信が完了すると、会議端末との間で確立していたセッションを終了する。
【００７５】
制御部２２７は、会議サーバ２１１に含まれる各部を制御する。また、制御部２２７は、切断メッセージ送受信部２２５が「BYE」リクエストを受信すると、セッションを終了するよう処理する。
【００７６】
図８に示すテレビ会議システムにおいて、会議端末２０１，２０２の二者通話から会議端末２０１〜２０３間の三者通話への移行は、以下の手順で行われる。なお、三者通話時には会議端末２０１の会議サーバ２１１が用いられる。会議端末２０１のSIP URIは、「sip:192.168.1.1」である。会議端末２０２のSIP URIは、「sip:192.168.1.2」である。会議端末２０３のSIP URIは、「sip:192.168.1.3」である。会議端末２０１の会議サーバ２１１のSIP URIは、「sip:192.168.1.1:55060」である。
【００７７】
図１０は、第２の実施形態のテレビ会議システムにおける二者通話から三者通話への移行シーケンスの一例を示す図である。なお、図１０では「ACK」の図示が省略されている。まず、会議端末２０１は、会議端末２０２に「INVITE」リクエストを送る（Ｐ２０１）。会議端末２０２は、当該「INVITE」リクエストに対する「200 OK」応答を会議端末２０１に送る（Ｐ２０３）。その結果、会議端末２０１と会議端末２０２の間に通話Ａが確立する。
【００７８】
通話Ａが確立している状態で、会議端末２０３は、会議端末２０１に「INVITE」リクエストを送る（Ｐ２０５）。会議端末２０１は、会議端末２０３を含めた三者通話に移行するために、当該「INVITE」リクエストに対する「488」応答を会議端末２０３に送る（Ｐ２０７）。この「488」応答のWarningヘッダには、会議端末２０１の会議サーバ２１１（sip:192.168.1.1:55060）からの着信待ちを指示する再接続制御情報が、記述されている。再接続制御情報は、例えば、「process=recv;from="sip:192.168.1.1:55060"」と記述される。なお、当該「488」応答は、会議端末２０１の切断メッセージ作成部１１７が作成する。会議端末２０３は、会議端末２０１から送られた「488」応答のWarningヘッダに記述された再接続制御情報に従い、会議端末２０１の会議サーバ２１１からの着信待ちの状態となる。
【００７９】
次に、会議端末２０１は、通話Ａを終了するための「BYE」リクエストを会議端末２０２に送る（Ｐ２０９）。この「BYE」リクエストのReasonヘッダには、会議端末２０１の会議サーバ２１１（sip:192.168.1.1:55060）からの着信待ちを指示する再接続制御情報が、記述されている。再接続制御情報は、例えば、「process=recv;from="sip:192.168.1.1:55060"」と記述される。会議端末２０２は、当該「BYE」リクエストに対する「200 OK」応答を会議端末２０１に送る（Ｐ２１１）。さらに、会議端末２０２は、会議端末２０１から送られた「BYE」リクエストのReasonヘッダに記述された再接続制御情報に従い、会議端末２０１の会議サーバ２１１からの着信待ちの状態となる。
【００８０】
次に、会議端末２０１は、「INVITE」リクエストを内蔵の会議サーバ２１１(sip:192.168.1.1:55060)に送る（Ｐ２１３）。なお、当該「INVITE」リクエストのボディには、会議端末２０２，２０３の各アドレスが接続先リスト（URI-List）として記述されている。但し、これらのアドレスは、SIPの拡張ヘッダ等に記述されていても良い。会議端末２０１の会議サーバ２１１のセッション確立部２２１は、当該「INVITE」リクエストに対する「200 OK」応答を会議端末２０１に送る（Ｐ２１５）。その結果、会議サーバ２１１と会議端末２０１の間にセッション「会議Ｂ」が確立する。
【００８１】
次に、会議端末２０１の会議サーバ２１１のセッション確立部２２１は、会議端末２０２，２０３の各々に「INVITE」リクエストを送る（Ｐ２１７）。会議端末２０２，２０３は、当該「INVITE」リクエストに対する「200 OK」応答を会議端末２０１の会議サーバ２１１に送る（Ｐ２１９）。その結果、会議サーバ２１１と会議端末２０２の間にセッション「会議Ｃ」が確立し、会議サーバ２１１と会議端末２０３の間にセッション「会議Ｄ」が確立して、会議端末２０１〜２０３間の三者通話が確立する。このようにして、会議端末２０１と会議端末２０２が二者通話中に会議端末２０３を含めた三者通話に移行するサービスが実現される。
【００８２】
図１１は、図１０に示した移行シーケンスにおける会議端末２０１の動作を示すフローチャートである。まず、セッション確立部１１３は、会議端末２０２に「INVITE」リクエストを送って通話Ａを確立する（Ｓ４０１）。次に、セッション確立部１１３は、会議端末２０３からの「INVITE」リクエストを受け取る（Ｓ４０３）。
【００８３】
次に、切断メッセージ作成部１１７は、当該「INIVITE」リクエストに対する「488」応答を作成する（Ｓ４０５）。なお、切断メッセージ作成部１１７は、この「488」応答のWarningヘッダに、会議端末２０１の会議サーバ２１１（sip:192.168.1.1:55060）からの着信待ちを指示する再接続制御情報を、記述する。再接続制御情報は、例えば、「process=recv;from="sip:192.168.1.1:55060"」と記述される。次に、切断メッセージ送受信部１１９は、切断メッセージ作成部１１７が作成した当該「488」応答を会議端末２０３に送る（Ｓ４０７）。
【００８４】
次に、切断メッセージ作成部１１７は、通話中の会議端末２０２に送る「BYE」リクエストを作成する（Ｓ４０９）。なお、切断メッセージ作成部１１７は、この「BYE」リクエストのReasonヘッダに、会議端末２０１の会議サーバ２１１（sip:192.168.1.1:55060）からの着信待ちを指示する再接続制御情報を、記述する。再接続制御情報は、例えば、「process=recv;from="sip:192.168.1.1:55060"」と記述される。次に、切断メッセージ送受信部１１９は、切断メッセージ作成部１１７が作成した当該「BYE」リクエストを会議端末２０２に送る（Ｓ４１１）。
【００８５】
次に、セッション確立部１１３は、会議端末２０２，２０３の各アドレスが接続先リスト（URI-List）としてボディに記述された「INVITE」リクエストを、内蔵する会議サーバ２１１に送る（Ｓ４１３）。
【００８６】
図１２は、図１０に示した移行シーケンスにおける会議端末２０３の動作を示すフローチャートである。まず、セッション確立部１１３は、会議端末２０１に「INVITE」リクエストを送る（Ｓ５０１）。その後、切断メッセージ送受信部１１９は、当該「INVITE」リクエストに対して会議端末２０１が送信した「488」応答を受け取る（Ｓ５０３）。この「488」応答のWarningヘッダには、会議端末２０１の会議サーバ２１１（sip:192.168.1.1:55060）からの着信待ちを指示する再接続制御情報が、記述されている。再接続制御情報は、例えば、「process=recv;from="sip:192.168.1.1:55060"」と記述する。
【００８７】
次に、制御部１２３は、受信した「488」応答に記述された再接続制御情報に従って、自端末（会議端末２０３）を会議端末２０１の会議サーバ２１１からの着信待ちの状態にする（Ｓ５０５）。その後、セッション確立部１１３が、会議端末２０１の会議サーバ２１１からの「INVITE」リクエストを受け取る（Ｓ５０７）。制御部１２３は、「INVITE」リクエストの発信元アドレスが、ステップＳ５０３で受け取った「488」応答の再接続制御情報に記述されたアドレスと一致するかを判断する（Ｓ５０９）。なお、制御部１２３は、「INVITE」リクエストのFromヘッダ等を参照して、当該「INVITE」リクエストの発信元アドレスを判別する。
【００８８】
これらのアドレスが一致する場合、セッション確立部１１３は、「200 OK」応答を会議端末２０１の会議サーバ２１１に送って会議Ｄを確立する（Ｓ５１１）。一方、これらのアドレスが一致しない場合、セッション確立部１１３は、次の処理を行う。セッション確立部１１３は、ステップＳ５０７で受け取った「INVITE」リクエストに対するエラー応答（03 Forbidden等）を、会議端末２０１の会議サーバ２１１に送って着信を拒否する（Ｓ５１３）。なお、セッション確立部１１３は、自端末を再び着信待ちの状態にする。なお、ステップＳ５１３では、セッション確立部１１３は、エラー応答を送らずに「INVITE」リクエストを無視しても良い。
【００８９】
上記説明では、ステップＳ５０９で、制御部１２３は、「INVITE」リクエストの発信元アドレスが、その前に受け取った「488」応答の再接続制御情報に記述されたアドレスと一致するかを判断するように説明した。しかし、会議端末２０３の制御部１２３は、当該判断を行わなくても良い。すなわち、会議端末２０３の制御部１２３は、「488」リクエストに記述された再接続制御情報を参照する機能を有していなくても良い。この場合、ステップＳ５１３は、行われない。但し、会議端末２０３のセッション確立部１１３は、会議端末２０１の会議サーバ２１１以外の会議端末又は会議サーバから「INVITE」リクエストを受け取る場合がある。この場合は、会議端末２０３のセッション確立部１１３は、この「INVITE」リクエストに対する「200 OK」応答を当該会議端末又は会議サーバに送ってセッションを確立してしまう。
【００９０】
図１３は、図１０に示した移行シーケンスにおける会議端末２０２の動作に示すフローチャートである。まず、セッション確立部１１３は、会議端末２０１からの「INVITE」リクエストを受け取って通話Ａを確立する（Ｓ６０１）。次に、切断メッセージ送受信部１１９は、会議端末２０１からの「BYE」リクエストを受け取る（Ｓ６０３）。この「BYE」リクエストのReasonヘッダには、会議端末２０１の会議サーバ２１１（sip:192.168.1.1:55060）からの着信待ちを指示する再接続制御情報が、記述されている。再接続制御情報は、例えば、「process=recv;from="sip:192.168.1.1:55060"」と記述する。
【００９１】
次に、セッション確立部１１３は、ステップＳ６０３で受け取った「BYE」リクエストに記述された再接続制御情報に従って、自端末（会議端末２０２）を会議端末２０１の会議サーバ２１１からの着信待ちの状態にする（Ｓ６０５）。その後、セッション確立部１１３は、会議端末２０１の会議サーバ２１１からの「INVITE」リクエストを受け取る（Ｓ６０７）。制御部１２３は、「INVITE」リクエストの発信元アドレスが、ステップＳ６０３で受け取った「BYE」リクエストの再接続制御情報に記述されたアドレスと一致するかを判断する（Ｓ６０９）。なお、制御部１２３は、「INVITE」リクエストのFromヘッダ等を参照して、当該「INVITE」リクエストの発信元アドレスを判別する。
【００９２】
これらのアドレスが一致する場合、セッション確立部１１３は、「200 OK」応答を会議端末２０１の会議サーバ２１１に送って会議Ｃを確立する（Ｓ６１１）。一方、これらのアドレスが一致しない場合、セッション確立部１１３は、次の処理を行う。セッション確立部１１３は、ステップＳ６０７で受け取った「INVITE」リクエストに対するエラー応答（03 Forbidden等）を、会議端末２０１の会議サーバ２１１に送って着信を拒否する（Ｓ６１３）。なお、セッション確立部１１３は、自端末を再び着信待ちの状態にする。なお、ステップＳ６１３において、セッション確立部１１３は、エラー応答を送らずに「INVITE」リクエストを無視しても良い。
【００９３】
上記説明では、ステップＳ６０９で、制御部１２３は、「INVITE」リクエストの発信元アドレスが、その前に受け取った「BYE」リクエストの再接続制御情報に記述されたアドレスと一致するかを判断するように説明をした。しかし、会議端末２０２の制御部１２３は、当該判断を行わなくても良い。すなわち、会議端末２０２の制御部１２３は、「BYE」リクエストに記述された再接続制御情報を参照する機能を有していなくても良い。この場合、ステップＳ６１３は行われない。但し、会議端末２０２のセッション確立部１１３は、会議端末２０１の会議サーバ２１１以外の会議端末又は会議サーバから「INVITE」リクエストを受け取る場合がある。この場合、会議端末２０２のセッション確立部１１３は、この「INVITE」リクエストに対する「200 OK」応答を当該会議端末又は会議サーバに送ってセッションを確立してしまう。
【００９４】
以上説明したように、第２の実施形態では、会議端末２０１の切断メッセージ作成部１１７が、「488」応答及び「BYE」リクエストに、各会議端末が行う動作に関する指示、及び着信先のアドレスを再接続制御情報に記述するようにした。また、会議端末２０１のセッション確立部１１３が、内蔵の会議サーバ２１１に送る「INVITE」リクエストに、会議端末２０２，２０３の各アドレスを再接続制御情報として記述するようにした。これらのリクエスト又は応答を受け取った会議端末又は、会議サーバが再接続制御情報の指示する動作を行うことによって、二者通話から三者通話への移行サービスが実現される。
【００９５】
このように、本実施形態は、二者通話から三者通話への移行サービスを実現するために、ＲＦＣ３２６１等に規定されたＳＩＰの基本メソッドしか用いられていない。したがって、ＳＩＰの基本メソッドに対応した会議端末は、煩雑な処理を行うことなく容易にこの移行サービスを実現可能である。すなわち、拡張メソッドに対応していない会議端末や独自のメッセージを利用した会議端末であっても、ＳＩＰの基本メソッドに対応してさえすれば接続性を失うことなくこの移行サービスを実現することができる。また、本実施形態では、当該移行サービスを開発するための工数を削減できる。さらに、送受信するメッセージ数が減るため、サービスの実行に必要な時間が短縮される。
【００９６】
なお、ＳＩＰは、理解できないヘッダを無視するというプロトコルである。このため、他の会議端末又は会議サーバから受け取った「BYE」リクエストのReasonヘッダ、又は「488」応答のWarningヘッダに記述された再接続制御情報を参照しない端末は、これらのヘッダを無視するだけである。会議端末２０２，２０３が、これらの情報を無視する端末であった場合は、ヘッダを無視することになる。但し、会議端末２０２は、「BYE」リクエストに従ってセッションを終了し着信待ちの状態となるため、当該移行サービスは実現可能である。
【００９７】
（第３の実施形態）
第３の実施形態では、再接続制御情報を含むＳＩＰの基本メソッドに応じたリクエスト又は応答を送受信することによって、実現される三者通話から二者通話への移行サービスの一例について説明する。
【００９８】
本実施形態のシステムは、第２の実施形態の図７に示したテレビ会議システムと同様である。また、本実施形態のテレビ会議システムに含まれる会議端末は、第２の実施形態の図８に示した会議端末と同様である。図８に示したテレビ会議システムにおいて、会議端末２０１〜２０３間の三者通話から会議端末２０２，２０３の二者通話への移行は、以下の手順で行われる。なお、三者通話時には、第２の実施形態と同様、会議端末２０１の会議サーバ２１１が用いられる。
【００９９】
図１４は、第３の実施形態のテレビ会議システムにおける三者通話から二者通話への移行シーケンスの一例を示す図である。なお、図１４では、「ACK」の図示が省略されている。まず、会議端末２０１は、「INVITE」リクエストを内蔵の会議サーバ２１１（sip:192.168.1.1:55060）に送る（Ｐ３０１）。なお、当該「INVITE」リクエストのボディには、会議端末２０２，２０３の各アドレスが接続先リスト（URL-List）として記述されている。会議端末２０１の会議サーバ２１１のセッション確立部２２１は、当該「INVITE」リクエストに対する「200 OK」応答を会議端末２０１に送る（Ｐ３０３）。その結果、会議サーバ２１１と会議端末２０１の間にセッション「会議Ａ」が確立する。
【０１００】
次に、会議端末２０１の会議サーバ２１１のセッション確立部２２１は、会議端末２０２，２０３の各々に「INVITE」リクエストを送る（Ｐ３０５）。会議端末２０２，２０３は、当該「INVITE」リクエストに対する「200 OK」応答を会議端末２０１の会議サーバ２１１に送る（Ｐ３０７）。その結果、会議サーバ２１１と会議端末２０２の間にセッション「会議Ｂ」が確立し、会議サーバ２１１と会議端末２０３の間にセッション「会議Ｃ」が確立して、会議端末２０１〜２０３間の三者通話が確立する。
【０１０１】
その後、会議端末２０１は、内蔵の会議サーバ２１１に「BYE」リクエストを送り（Ｐ３０９）、会議から離脱する。会議サーバ２１１は、当該「BYE」リクエストに対する「200 OK」応答を会議端末２０１に送る（Ｐ３１１）。さらに、会議サーバ２１１は、会議端末２０３に「BYE」リクエストを送る（Ｐ３１３）。この「BYE」リクエストのReasonヘッダには、会議端末２０２（sip:192.168.1.2）からの着信待ちを指示する再接続制御情報が記述されている。再接続制御情報は、例えば、「process=recv;from="sip:192.168.1.2"」と記述する。会議端末２０３は、当該「BYE」リクエストに対する「200 OK」応答を会議端末２０１の会議サーバ２１１に送る（Ｐ３１５）。この後、会議端末２０３は、アイドル状態に移行して、会議端末２０２からの着信待ちの状態となる。
【０１０２】
次に、会議サーバ２１１は、会議端末２０２に「BYE」リクエストを送る（Ｐ３１７）。この「BYE」リクエストのReasonヘッダには、会議端末２０３（sip:192.168.1.3）への発信を指示する再接続制御情報が記述されている。再接続制御情報は、例えば、「process=send;to="sip:192.168.1.3"」と記述する。会議端末２０２は、当該「BYE」リクエストに対する「200 OK」応答を会議端末２０１の会議サーバ２１１に送る（Ｐ３１９）。
【０１０３】
会議端末２０２は、会議端末２０１の会議サーバ２１１から送られた「BYE」リクエストのReasonヘッダに記述された再接続制御情報に従い、会議端末２０３に「INVITE」リクエストを送る（Ｐ３２１）。会議端末２０３は、当該「INVITE」リクエストに対する「200 OK」応答を会議端末２０２に送る（Ｐ３２３）。その結果、会議端末２０２と会議端末２０３の間にセッション「通話Ｄ」が確立する。このようにして、会議端末２０１〜２０３間の三者通話中に会議端末２０１が離脱した場合に、会議端末２０２，２０３の二者通話に移行するサービスが実現される。
【０１０４】
以上説明したように、第３の実施形態では、会議端末２０１の切断メッセージ作成部２２３が、「BYE」リクエストに、各会議端末が行う動作(発信又は着信)の指示、及び発信先又は着信先のアドレスを再接続制御情報として記述する。当該「BYE」リクエストを受け取った会議端末が再接続制御情報の指示する動作を行うことによって、三者通話から二者通話への移行サービスが実現される。
【０１０５】
このように、本実施形態は、三者通話から二者通話への移行サービスを実現するために、ＲＦＣ３２６１等に規定されたＳＩＰの基本メソッドしか用いられていない。したがって、本実施形態は、ＳＩＰの基本メソッドに対応した会議端末であれば、煩雑な処理を行うことなく容易にこの移行サービスを実現可能である。すなわち、拡張メソッドに対応していない会議端末や独自のメッセージを利用した会議端末であっても、ＳＩＰの基本メソッドに対応してさえすれば接続性を失うことなくこの移行サービスを実現することができる。また、本実施形態では、当該移行サービスを開発するための工数を削減できる。さらに、本実施形態では、送受信するメッセージ数が減るため、サービスの実行に必要な時間が短縮される。
【０１０６】
なお、ＳＩＰは、理解できないヘッダを無視するというプロトコルである。このため、会議端末２０３が、会議サーバから受け取った「BYE」リクエストのReasonヘッダに記述された再接続制御情報を参照しない端末であったとしても、会議端末２０３は、これらのヘッダを無視するだけである。但し、会議端末２０３は、「BYE」リクエストに従って着信待ちの状態となるため、当該移行サービスは実現可能である。
【０１０７】
（第４の実施形態）
第４の実施形態では、再接続制御情報を含むＳＩＰの基本メソッドに応じたリクエスト又は応答を送受信することによって、実現される四者通話から三者通話への移行サービスについて説明する。なお、本実施形態では、四者通話から三者通話への移行の際に会議サーバを移行する。
【０１０８】
本実施形態のシステムは、第２の実施形態の図７に示したテレビ会議システムと同様である。また、本実施形態のテレビ会議システムに含まれる会議端末は、第２の実施形態の図８に示した会議端末と同様である。図８に示したテレビ会議システムにおいて、会議端末２０１〜２０３間の三者通話から会議端末２０２，２０３の二者通話への移行は、以下の手順で行われる。なお、四者通話時には、第２の実施形態と同様、会議端末２０１の会議サーバ２１１が用いられ、三者通話時には、会議端末２０２の会議サーバ２１１が用いられる。
【０１０９】
図１５は、第４の実施形態のテレビ会議システムにおける四者通話から三者通話への移行シーケンスの一例を示す図である。なお、図１５では、「ACK」の図示が省略されている。まず、会議端末２０１は、「INVITE」リクエストを内蔵の会議サーバ２１１(sip:192.168.1.1:55060)に送る（Ｐ４０１）。なお、当該「INVITE」リクエストのボディには、会議端末２０２〜２０４の各アドレスが接続先リスト（URL-List）として記述されている。会議端末２０１の会議サーバ２１１のセッション確立部２２１は、当該「INVITE」リクエストに対する「200 OK」応答を会議端末２０１に送る（Ｐ４０３）。その結果、会議サーバ２１１と会議端末２０１の間にセッション「会議Ａ」が確立する。
【０１１０】
次に、会議端末２０１の会議サーバ２１１のセッション確立部２２１は、会議端末２０２〜２０４の各々に「INVITE」リクエストを送る（Ｐ４０５）。会議端末２０２〜２０４は、当該「INVITE」リクエストに対する「200 OK」応答を会議端末２０１の会議サーバ２１１に送る（Ｐ４０７）。その結果、会議サーバ２１１と会議端末２０２の間にセッション「会議Ｂ」が確立し、会議サーバ２１１と会議端末２０３の間にセッション「会議Ｃ」が確立する。また、会議サーバ２１１と会議端末２０４の間にセッション「会議Ｄ」が確立して、会議端末２０１〜２０４間の四者通話が確立する。
【０１１１】
その後、会議端末２０１は、内蔵の会議サーバ２１１に「BYE」リクエストを送り（Ｐ４０９）、会議から離脱する。ここで、四者通話から三者通話に移行するが、会議端末２０１が会議から離脱したため、使用する会議サーバを会議端末２０２〜２０４のいずれかの会議サーバに移行しなければならない。本実施形態では、会議端末２０２の会議サーバを使用した三者通話に移行する例を示す。
【０１１２】
会議端末２０１の会議サーバ２１１は、当該「BYE」リクエストに対する「200 OK」応答を会議端末２０１に送る（Ｐ４１１）。さらに、会議端末２０１の会議サーバ２１１は、会議端末２０３，２０４に「BYE」リクエストを送る（Ｐ４１３）。この「BYE」リクエストのReasonヘッダには、会議端末２０２の会議サーバ２１１（sip:192.168.1.2:55060）からの着信待ちを指示する再接続制御情報が、記述されている。再接続制御情報は、例えば、「process=recv;from="sip:192.168.1.2:55060"」と記述する。会議端末２０３，２０４は、当該「BYE」リクエストに対する「200 OK」応答を会議端末２０１の会議サーバ２１１に送る（Ｐ４１５）。この後、会議端末２０３，２０４は、アイドル状態に移行して、会議端末２０２の会議サーバ２１１からの着信待ちの状態となる。
【０１１３】
次に、会議端末２０１の会議サーバ２１１は、会議端末２０２に「BYE」リクエストを送る（Ｐ４１７）。この「BYE」リクエストのReasonヘッダには、会議端末２０３（sip:192.168.1.3）、及び会議端末２０４（sip:192.168.1.4）への発信を指示する再接続制御情報を示すが記述されている。再接続制御情報は、例えば、「process=send;to="sip:192.168.1.3";to=”sip:192.168.1.4”」と記述する。会議端末２０２は、当該「BYE」リクエストに対する「200 OK」応答を会議端末２０１の会議サーバ２１１に送る（Ｐ４１９）。
【０１１４】
会議端末２０２は、会議端末２０１の会議サーバ２１１から送られた「BYE」リクエストのReasonヘッダに記述された再接続制御情報に従い、「INVITE」リクエストを内蔵の会議サーバ２１１（sip:192.168.1.2:55060）に送る（Ｐ４２１）。なお、当該「INVITE」リクエストのボディには、会議端末２０３，２０４の各アドレスが接続先リスト（URL-List）として記述されている。会議端末２０２の会議サーバ２１１のセッション確立部２２１は、当該「INVITE」リクエストに対する「200 OK」応答を会議端末２０２に送る（Ｐ４２３）。その結果、会議端末２０２の会議サーバ２１１と会議端末２０２の間にセッション「会議Ａ」が確立する。
【０１１５】
次に、会議端末２０２の会議サーバ２１１のセッション確立部２２１は、会議端末２０３，２０４に「INVITE」リクエストを送る（Ｐ４２５）。会議端末２０３，２０４は、当該「INVITE」リクエストに対する「200 OK」応答を会議端末２０２の会議サーバ２１１に送る（Ｐ４２７）。これにより、会議端末２０２の会議サーバ２１１と会議端末２０３の間にセッション「会議Ｂ」が確立し、会議端末２０２の会議サーバ２１１と会議端末２０４の間にセッション「会議Ｃ」が確立する。その結果、会議端末２０２〜２０４間の三者通話が確立する。このようにして、会議端末２０１〜２０４間の四者通話中に会議端末２０１が離脱した場合に、会議端末２０２の会議サーバ２１１を用いた会議端末２０２〜２０４間の三者通話に移行するサービスが実現される。
【０１１６】
図１６は、図１４に示した第３の実施形態の移行シーケンス及び図１５に示した第４の実施形態の移行シーケンスにおける、会議端末２０２の動作を示すフローチャートである。まず、セッション確立部１１３は、会議端末２０１の会議サーバ２１１からの「INVITE」リクエストを受け取って会議Ｂを確立する（Ｓ７０１）。その後、切断メッセージ送受信部１１９は、会議端末２０１の会議サーバ２１１からの「BYE」リクエストを受け取る（Ｓ７０３）。制御部１２３は、当該「BYE」リクエストの再接続制御情報に記述されたアドレス数が単数か複数かを判断する（Ｓ７０５）。
【０１１７】
アドレス数が単数の場合、第３の実施形態で説明した図１４の手順Ｐ３２１に示したように、セッション確立部１１３は、「BYE」リクエストの再接続制御情報が示す会議端末に「INVITE」リクエストを送る（Ｓ７０７）。この後、セッション確立部１１３は、当該「INVITE」リクエストに対する「200 OK」応答を受け取ってセッションを確立する（Ｓ７０９）。
【０１１８】
一方、アドレス数が複数の場合、第４の実施形態で説明した図１５の手順Ｐ４２１に示したように、セッション確立部１１３は、「INVITE」リクエストを内蔵の会議サーバ２１１に送る（Ｓ７１１）。なお、当該（INVITE）リクエストのボディには、「BYE」リクエストの再接続制御情報が示す会議端末のアドレスが接続先リスト（URI-List）として記述されている。次に、セッション確立部１１３は、当該（INVITE）リクエストに対する「200 OK」応答を内蔵の会議サーバ２１１から受け取って、当該会議サーバ２１１とのセッションを確立する（Ｓ７１３）。
【０１１９】
以上説明したように、第４の実施形態では、会議端末２０１の切断メッセージ作成部２２３が、「BYE」リクエストに、各会議端末が行う動作(発信又は着信)の指示、及び発信先又は着信先のアドレスを再接続制御情報として記述する。当該「BYE」リクエストを受け取った会議端末が再接続制御情報の指示する動作を行うことによって、四者通話から三者通話への移行サービスが実現される。
【０１２０】
このように、本実施形態は、四者通話から三者通話への移行サービスを実現するために、ＲＦＣ３２６１等に規定されたＳＩＰの基本メソッドしか用いられていない。したがって、ＳＩＰの基本メソッドに対応した会議端末であれば、煩雑な処理を行うことなく容易にこの移行サービスを実現可能である。すなわち、拡張メソッドに対応していない会議端末や独自のメッセージを利用した会議端末であっても、ＳＩＰの基本メソッドに対応してさえすれば接続性を失うことなくこの移行サービスを実現することができる。また、本実施形態は、当該移行サービスを開発するための工数を削減できる。さらに、送受信するメッセージ数が減るため、サービスの実行に必要な時間が短縮される。
【０１２１】
また、従来のテレビ会議システムでは、テレビ会議端末９０１の内蔵会議サーバ９１０を使用した通話中に、テレビ会議端末９０１が会議から離脱する場合、会議サーバを移行するために会議を一度終了する必要があった。しかし、本実施形態の移行サービスによれば、四者通話中に内蔵会議サーバが利用されている会議端末が離脱する際にも、会議を一度終了する必要がない。なお、第４の実施形態では、四者通話から三者通話への移行サービスを例に説明したが、例えば、五者通話から四者通話への移行サービス等にも同様に適用される。
【０１２２】
なお、ＳＩＰは、理解できないヘッダを無視するというプロトコルである。このため、会議端末２０３，２０４が、会議サーバから受け取った「BYE」リクエストのReasonヘッダに記述された再接続制御情報を参照しない端末であったとしても、会議端末２０３，２０４は、これらのヘッダを無視するだけである。但し、会議端末２０３，２０４は、「BYE」リクエストに従って着信待ちの状態となるため、当該移行サービスは実現可能である。
【０１２３】
第２〜第４の実施形態では、会議端末２０１〜２０４の各々が会議サーバ２１１を内蔵した構成を例に説明した。しかし、会議サーバ２１１は、会議端末とは別体に構成されていても良い。
【産業上の利用可能性】
【０１２４】
本発明に係る通信装置及び通信システムは、音声会議端末及びそのシステム、並びに、テレビ会議端末及びそのシステム等として有用である。
【符号の説明】
【０１２５】
１００  ネットワーク
１０１〜１０４，２０１〜２０４  会議端末
１１１  通信部
１１３  セッション確立部
１１５  セッション保留部
１１７  切断メッセージ作成部
１１９  切断メッセージ送受信部
１２１  メディアデータ送受信部
１２３  制御部
１２５  映像・音声入出力部
１２７  入力インターフェイス部
２１１  会議サーバ
２２１  セッション確立部
２２３  切断メッセージ作成部
２２５  切断メッセージ送受信部
２２７  制御部
【図１】
0005522985.tif 000002
【図２】
0005522985.tif 000003
【図３】
0005522985.tif 000004
【図４】
0005522985.tif 000005
【図５】
0005522985.tif 000006
【図６】
0005522985.tif 000007
【図７】
0005522985.tif 000008
【図８】
0005522985.tif 000009
【図９】
0005522985.tif 000010
【図１０】
0005522985.tif 000011
【図１１】
0005522985.tif 000012
【図１２】
0005522985.tif 000013
【図１３】
0005522985.tif 000014
【図１４】
0005522985.tif 000015
【図１５】
0005522985.tif 000016
【図１６】
0005522985.tif 000017
【図１７】
0005522985.tif 000018
【図１８】
0005522985.tif 000019
【図１９】
0005522985.tif 000020
【図２０】
0005522985.tif 000021
【図２１】
0005522985.tif 000022
【図２２】
0005522985.tif 000023