JP5522985B2 - 通信装置、通信システム及びセッション制御方法 - Google Patents

通信装置、通信システム及びセッション制御方法 Download PDF

Info

Publication number
JP5522985B2
JP5522985B2 JP2009155291A JP2009155291A JP5522985B2 JP 5522985 B2 JP5522985 B2 JP 5522985B2 JP 2009155291 A JP2009155291 A JP 2009155291A JP 2009155291 A JP2009155291 A JP 2009155291A JP 5522985 B2 JP5522985 B2 JP 5522985B2
Authority
JP
Japan
Prior art keywords
message
conference
communication device
session
unit
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2009155291A
Other languages
English (en)
Other versions
JP2011015004A (ja
Inventor
竜太郎 小野
尚之 持田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Corp
Panasonic Holdings Corp
Original Assignee
Panasonic Corp
Matsushita Electric Industrial Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Panasonic Corp, Matsushita Electric Industrial Co Ltd filed Critical Panasonic Corp
Priority to JP2009155291A priority Critical patent/JP5522985B2/ja
Priority to CN201080026727.7A priority patent/CN102804746B/zh
Priority to US13/378,138 priority patent/US20120089680A1/en
Priority to PCT/JP2010/004298 priority patent/WO2011001670A1/ja
Publication of JP2011015004A publication Critical patent/JP2011015004A/ja
Application granted granted Critical
Publication of JP5522985B2 publication Critical patent/JP5522985B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/56—Arrangements for connecting several subscribers to a common circuit, i.e. affording conference facilities
    • H04M3/563—User guidance or feature selection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1813—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast for computer conferences, e.g. chat rooms
    • H04L12/1822—Conducting the conference, e.g. admission, detection, selection or grouping of participants, correlating users to one or more conference sessions, prioritising transmission
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • H04L65/403—Arrangements for multi-party communication, e.g. for conferences
    • H04L65/4046—Arrangements for multi-party communication, e.g. for conferences with distributed floor control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • H04L65/403—Arrangements for multi-party communication, e.g. for conferences
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2203/00—Aspects of automatic or semi-automatic exchanges
    • H04M2203/20—Aspects of automatic or semi-automatic exchanges related to features of supplementary services
    • H04M2203/2088—Call or conference reconnect, e.g. resulting from isdn terminal portability

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Telephonic Communication Services (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Description

本発明は、転送サービス、接続地点数の変更サービス又は会議サーバ移行サービスを容易に実現する、複数者通話を行うための通信装置、通信システム及びセッション制御方法に関する。
近年、電話又はテレビ電話に代表される二地点通信に加えて、三者以上が参加可能な音声会議や多地点テレビ会議を実現する多地点通信が実用化されている。多地点通信を利用したサービスには、音声又は映像の通信サービスの他、次のような付加サービスが含まれる。例えば、二者通話を第三者に転送するサービス、二者通話から三者通話への切り替えや三者通話から二者通話への切り替え等の地点数変更サービス、又は使用する会議サーバを変更する会議サーバ移行サービス等である。このようなサービスを提供するための一つの方法としては、ＳＩＰ（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」リクエストに従って着信待ちの状態となるため、当該移行サービスは実現可能である。
第２〜第４の実施形態では、会議端末２０１〜２０４の各々が会議サーバ２１１を内蔵した構成を例に説明した。しかし、会議サーバ２１１は、会議端末とは別体に構成されていても良い。
本発明に係る通信装置及び通信システムは、音声会議端末及びそのシステム、並びに、テレビ会議端末及びそのシステム等として有用である。
１００ ネットワーク
１０１〜１０４，２０１〜２０４ 会議端末
１１１ 通信部
１１３ セッション確立部
１１５ セッション保留部
１１７ 切断メッセージ作成部
１１９ 切断メッセージ送受信部
１２１ メディアデータ送受信部
１２３ 制御部
１２５ 映像・音声入出力部
１２７ 入力インターフェイス部
２１１ 会議サーバ
２２１ セッション確立部
２２３ 切断メッセージ作成部
２２５ 切断メッセージ送受信部
２２７ 制御部

Claims (15)

  1. 呼制御プロトコルの基本メソッド又は応答を用いて少なくとも１つの他の通信装置との間のセッションを制御する通信装置であって、
    他の通信装置から送られた、セッション終了後の動作に係る再接続制御情報が前記基本メソッド又は応答に記述されたメッセージを受信するメッセージ受信部と、
    前記メッセージに含まれる再接続制御情報に基づいて再接続制御を行う第１の制御部と、
    ３つ以上の通信装置間の相互セッションを制御する会議サーバ部と、を備え、
    前記会議サーバ部は、
    セッション終了後の動作に係る再接続制御情報が前記基本メソッドに記述されたメッセージを作成する第２のメッセージ作成部と、
    他の通信装置から送られたメッセージに含まれる再接続制御情報に基づいて再接続制御を行う第２の制御部と、
    前記第２のメッセージ作成部が作成したメッセージを他の複数の通信装置に送信し、かつ、他の通信装置から送られたメッセージを受信する送受信部と、を有することを特徴とする通信装置。
  2. 請求項１に記載の通信装置であって、
    前記再接続制御情報は、指定した通信装置からのセッション開始要求があるまでアイドル状態を維持するよう指示する情報であることを特徴とする通信装置。
  3. 請求項１に記載の通信装置であって、
    前記再接続制御情報は、指定した通信装置にセッション開始要求を行うよう指示する情報であることを特徴とする通信装置。
  4. 呼制御プロトコルの基本メソッド又は応答を用いて少なくとも１つの他の通信装置との間のセッションを制御する通信装置であって、
    セッション終了後の動作に係る再接続制御情報が前記基本メソッド又は応答に記述されたメッセージを作成する第１のメッセージ作成部と、
    前記第１のメッセージ作成部が作成したメッセージを他の通信装置に送信するメッセージ送信部と、
    ３つ以上の通信装置間の相互セッションを制御する会議サーバ部と、を備え、
    前記会議サーバ部は、
    セッション終了後の動作に係る再接続制御情報が前記基本メソッドに記述されたメッセージを作成する第２のメッセージ作成部と、
    他の通信装置から送られたメッセージに含まれる再接続制御情報に基づいて再接続制御を行う第２の制御部と、
    前記第２のメッセージ作成部が作成したメッセージを他の複数の通信装置に送信し、かつ、他の通信装置から送られたメッセージを受信する送受信部と、を有することを特徴とする通信装置。
  5. 請求項４に記載の通信装置であって、
    前記再接続制御情報は、指定した通信装置からのセッション開始要求があるまでアイドル状態を維持するよう指示する情報であることを特徴とする通信装置。
  6. 請求項４に記載の通信装置であって、
    前記再接続制御情報は、指定した通信装置にセッション開始要求を行うよう指示する情報であることを特徴とする通信装置。
  7. 呼制御プロトコルの基本メソッド又は応答を用いて少なくとも１つの他の通信装置との間のセッションを制御する通信装置であって、
    セッション終了後の動作に係る再接続制御情報が前記基本メソッド又は応答に記述されたメッセージを作成する第１のメッセージ作成部と、
    前記第１のメッセージ作成部が作成したメッセージを他の通信装置に送信し、かつ、他の通信装置から送られたメッセージを受信するメッセージ送受信部と、
    他の通信装置から送られたメッセージに含まれる再接続制御情報に基づいて再接続制御を行う第１の制御部と、
    ３つ以上の通信装置間の相互セッションを制御する会議サーバ部と、を備え、
    前記会議サーバ部は、
    セッション終了後の動作に係る再接続制御情報が前記基本メソッドに記述されたメッセージを作成する第２のメッセージ作成部と、
    他の通信装置から送られたメッセージに含まれる再接続制御情報に基づいて再接続制御を行う第２の制御部と、
    前記第２のメッセージ作成部が作成したメッセージを他の複数の通信装置に送信し、かつ、他の通信装置から送られたメッセージを受信する送受信部と、を有することを特徴とする通信装置。
  8. 請求項７に記載の通信装置であって、
    前記再接続制御情報は、指定した通信装置からのセッション開始要求があるまでアイドル状態を維持するよう指示する情報、又は、指定した通信装置にセッション開始要求を行うよう指示する情報であることを特徴とする通信装置。
  9. 請求項１〜８のいずれか一項に記載の通信装置であって、
    前記基本メソッドには、セッション開始要求又はセッション終了要求が含まれることを特徴とする通信装置。
  10. 請求項１〜８のいずれか一項に記載の通信装置であって、
    前記呼制御プロトコルは、ＳＩＰ（Session Initiation Protocol）であることを特徴
    とする通信装置。
  11. 請求項１０に記載の通信装置であって、
    前記セッション開始要求は、ＳＩＰで定義された「INVITE」であることを特徴とする通信装置。
  12. 請求項１０に記載の通信装置であって、
    前記セッション終了要求は、ＳＩＰで定義された「BYE」であることを特徴とする通信装置。
  13. 呼制御プロトコルの基本メソッド又は応答を用いて複数の通信装置間のセッションを制御する通信システムであって、
    前記複数の通信装置の各々は、
    セッション終了後の動作に係る再接続制御情報が前記基本メソッド又は応答に記述されたメッセージを作成する第１のメッセージ作成部と、
    前記第１のメッセージ作成部が作成したメッセージを他の通信装置に送信し、かつ、他の通信装置から送られたメッセージを受信するメッセージ送受信部と、
    他の通信装置から送られたメッセージに含まれる再接続制御情報に基づいて再接続制御を行う第１の制御部と、
    ３つ以上の通信装置間の相互セッションを制御する会議サーバ部と、を備え、
    前記会議サーバ部は、
    セッション終了後の動作に係る再接続制御情報が前記基本メソッドに記述されたメッセージを作成する第２のメッセージ作成部と、
    他の通信装置から送られたメッセージに含まれる再接続制御情報に基づいて再接続制御を行う第２の制御部と、
    前記第２のメッセージ作成部が作成したメッセージを他の複数の通信装置に送信し、かつ、他の通信装置から送られたメッセージを受信する送受信部と、を有することを特徴とする通信システム。
  14. 請求項１３に記載の通信システムであって、
    前記再接続制御情報は、指定した通信装置からのセッション開始要求があるまでアイドル状態を維持するよう指示する情報、又は、指定した通信装置にセッション開始要求を行うよう指示する情報であることを特徴とする通信システム。
  15. 呼制御プロトコルの基本メソッド又は応答を用いて複数の通信装置間のセッションを制御するセッション制御方法であって、
    セッション終了後の動作に係る再接続制御情報が前記基本メソッド又は応答に記述されたメッセージを作成する第１のメッセージ作成部と、
    前記第１のメッセージ作成部が作成したメッセージを他の通信装置に送信し、かつ、他の通信装置から送られたメッセージを受信する第１のメッセージ送受信部と、
    ３つ以上の通信装置間の相互セッションを制御する会議サーバ部と、を備えるとともに、
    前記会議サーバ部は、
    指定した通信装置からのセッション開始要求があるまでアイドル状態を維持するよう指示する第１の再接続制御情報、又は、指定した通信装置にセッション開始要求を行うよう指示する第２の再接続制御情報が、前記基本メソッド又は応答に記述されたメッセージを作成する第２のメッセージ作成部と、
    前記第２のメッセージ作成部が作成したメッセージを他の通信装置に送信し、かつ、他の通信装置から送られたメッセージを受信する第２のメッセージ送受信部と、を有する前記複数の通信装置の各々は、
    他の通信装置から送られたメッセージに含まれる再接続制御情報に基づいて再接続制御を行うことを特徴とするセッション制御方法。
JP2009155291A 2009-06-30 2009-06-30 通信装置、通信システム及びセッション制御方法 Active JP5522985B2 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
JP2009155291A JP5522985B2 (ja) 2009-06-30 2009-06-30 通信装置、通信システム及びセッション制御方法
CN201080026727.7A CN102804746B (zh) 2009-06-30 2010-06-29 通信装置、通信系统和会话控制方法
US13/378,138 US20120089680A1 (en) 2009-06-30 2010-06-29 Communication apparatus, communication system and session control method
PCT/JP2010/004298 WO2011001670A1 (ja) 2009-06-30 2010-06-29 通信装置、通信システム及びセッション制御方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2009155291A JP5522985B2 (ja) 2009-06-30 2009-06-30 通信装置、通信システム及びセッション制御方法

Publications (2)

Publication Number Publication Date
JP2011015004A JP2011015004A (ja) 2011-01-20
JP5522985B2 true JP5522985B2 (ja) 2014-06-18

Family

ID=43410757

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2009155291A Active JP5522985B2 (ja) 2009-06-30 2009-06-30 通信装置、通信システム及びセッション制御方法

Country Status (4)

Country Link
US (1) US20120089680A1 (ja)
JP (1) JP5522985B2 (ja)
CN (1) CN102804746B (ja)
WO (1) WO2011001670A1 (ja)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8898235B2 (en) * 2012-07-18 2014-11-25 Infinite Convergence Solutions, Inc. Method and devices for message disposition notification after session termination
US10742692B2 (en) * 2012-08-09 2020-08-11 Avaya Inc. Snap-in invocation for call reconstruction
US10601880B2 (en) 2015-07-17 2020-03-24 Avaya Inc. Conference reconstruction in SIP networks
US9992643B2 (en) * 2016-07-06 2018-06-05 Verizon Patent And Licensing Inc. Session establishment, maintenance, and termination by end device based on SMS messaging
US10581936B2 (en) * 2016-09-15 2020-03-03 Ricoh Company, Ltd. Information processing terminal, management system, communication system, information processing method, and recording medium

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3471558B2 (ja) * 1997-04-11 2003-12-02 日本電気株式会社 計算機を利用した会議システム
KR100277104B1 (ko) * 1998-12-03 2001-01-15 윤종용 이동통신시스템에서의호장애시호재접속방법
US6512818B1 (en) * 1999-11-17 2003-01-28 Mci Worldcom, Inc. Method and system for releasing a voice response unit from a protocol session
JP3654157B2 (ja) * 2000-07-31 2005-06-02 サクサ株式会社 ボタン電話装置
US7768909B1 (en) * 2003-10-28 2010-08-03 At&T Intellectual Property Ii, L.P. Congestion control in an IP network
JP4348270B2 (ja) * 2004-10-05 2009-10-21 パナソニック株式会社 Ｓｉｐサーバ
US7594020B2 (en) * 2005-05-31 2009-09-22 Microsoft Corporation Re-establishing a connection for an application layer via a service layer
US8374166B1 (en) * 2005-09-22 2013-02-12 Verizon Patent And Licensing Inc. Method and system for providing call waiting features in a SIP-based network
US9258259B2 (en) * 2005-09-30 2016-02-09 Nokia Technologies Oy Retrieval of offline instant messages
JP4869774B2 (ja) * 2006-04-24 2012-02-08 Ｎｅｃアクセステクニカ株式会社 通信端末および通信端末の通話サービス制御プログラム
US9025587B2 (en) * 2006-08-16 2015-05-05 Microsoft Technology Licensing Auto answer in voice over internet protocol
US8442517B2 (en) * 2006-11-10 2013-05-14 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for controlling communications
US8572255B2 (en) * 2007-01-31 2013-10-29 Broadsoft M6, Llc System and method for reestablishing, with a client device, a signaling session associated with a call in progress
JP2008199324A (ja) * 2007-02-13 2008-08-28 Nec Corp 通信制御課金システム、通信制御課金方法、および通信制御課金プログラム
CN101442421A (zh) * 2007-11-19 2009-05-27 华为技术有限公司 创建会议的方法、装置及系统
JP4540720B2 (ja) * 2008-04-02 2010-09-08 株式会社エヌ・ティ・ティ・ドコモ データ通信端末、プロキシ装置、データ通信システム、及びデータ通信方法
CA2736471A1 (en) * 2008-09-08 2010-03-11 Research In Motion Limited Apparatus and method for reducing responses when executing a session initiation protocol operation
US20100174785A1 (en) * 2009-01-07 2010-07-08 Yigang Cai Dynamic sender blocking based on accumulated content violations
US8112480B2 (en) * 2009-01-16 2012-02-07 Microsoft Corporation Signaling support for sharer switching in application sharing
US20100217873A1 (en) * 2009-02-23 2010-08-26 Xcast Labs, Inc. Method and system for sip access to media and conferences

Also Published As

Publication number Publication date
WO2011001670A1 (ja) 2011-01-06
US20120089680A1 (en) 2012-04-12
CN102804746B (zh) 2015-10-14
CN102804746A (zh) 2012-11-28
JP2011015004A (ja) 2011-01-20

Similar Documents

Publication Publication Date Title
JP4819923B2 (ja) セッション設定プロトコル基盤のアーリーメディアサービス提供方法、及びセッション設定プロトコル基盤のアーリーメディアサービス提供応用サーバ
JP5522985B2 (ja) 通信装置、通信システム及びセッション制御方法
JP2010213027A (ja) 通信システム及びサーバ
US7496089B2 (en) Network, private branch exchange, and PBX additional service starting method
JP2008011366A (ja) Ｓｉｐを用いたボタン電話装置およびそのグループ代表着信および着信応答方法
JP2007013726A (ja) サーバ装置
CN102165752B (zh) 在IPv4与IPv6数据终端设备之间在SIP控制的数据流中双向地址转换的方法和设备
WO2006100751A1 (ja) 電話装置
JP2008085838A (ja) 通信メディア自動変換システム
CN102984186A (zh) 会话建立方法及装置
CN101184129A (zh) 实现转移呼叫的方法、装置及系统
CN101072261A (zh) 实现转移呼叫的方法、装置及系统
JP2005311670A (ja) テレビ会議端末、テレビ会議システム、テレビ会議方法並びにそのプログラム
EP2106114B1 (en) IP telephone device
JP2009135590A (ja) 会議装置及び接続制御方法
JP2008067083A (ja) グループ通話制御システム、グループ通話制御方法および移動通信端末
JP4371874B2 (ja) 通話保留音出力方法及びｓｉｐサーバ
JP5579660B2 (ja) 多地点接続テレビ会議装置
JP4772739B2 (ja) ビジュアルコミュニケーションサーバおよび通信システム
JP4028407B2 (ja) Ｉｐ電話システムの代理応答制御方法
CN110891058B (zh) 基于sip协议实现通话的方法、智能终端及储存介质
JP5421940B2 (ja) 呼処理制御装置および呼処理制御方法
JP2014207709A (ja) 端末
JP5153720B2 (ja) 通信システムとその制御装置および通信制御方法
JP2008252815A (ja) ボタン電話装置

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20120319

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20130730

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20130925

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20131225

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20140311

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20140408

R151 Written notification of patent or utility model registration

Ref document number: 5522985

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250