JP5229299B2 - 通信装置、通信方法、および通信プログラム - Google Patents

Description

本発明は、複数の通信装置間でＰ２Ｐ通信を実行する通信システムで用いられる通信装置、通信方法、および通信プログラムに関する。

従来、複数の通信装置がＰ２Ｐ（ｐｅｅｒ ｔｏ ｐｅｅｒ）で通信を行うために、通信装置間でセッションを確立する技術が知られている。非特許文献１は、通信装置間でセッションを確立するための接続プロトコルであるＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）を開示している。ＳＩＰに従うことで容易にセッションを確立できるため、ＳＩＰは広く用いられている。

一般的に、ＳＩＰでは、ＳＩＰリクエストを処理するサーバを介して通信装置間のセッションが確立される。まず、発呼側の通信装置（以下、「発呼装置」という。）が、オファー情報を含むセッション開始メッセージ（呼出要求「ＩＮＶＩＴＥ」）をサーバに送信する。オファー情報には、メディアデータを受信するために使用するポートの情報、受信可能なメディア種別の情報（例えば、音声および映像のＣＯＤＥＣ）等が含まれる。サーバは、発呼装置から受信したセッション開始メッセージを、セッションを確立する相手方の通信装置（以下、「被呼装置」という。）に送信（転送）する。被呼装置は、サーバを介してセッション開始メッセージを受信すると、着信許可の指示がユーザによって入力されるまで、暫定応答メッセージ「１８０ Ｒｉｎｇｉｎｇ」をサーバを介して繰り返し発呼装置に送信する。着信許可の指示が被呼装置に入力されると、被呼装置は、セッション開始メッセージに含まれるオファー情報から、自身が採用するメディア種別を選択する。選択したメディア種別の情報を、アンサー情報として応答メッセージ「２００ ＯＫ」に含めてサーバに送信する。サーバは、被呼装置から受信した応答メッセージを発呼装置に送信（転送）する。その後、発呼装置は、受信した応答メッセージに含まれるアンサー情報に基づいて、サーバを介さずに直接被呼装置へデータを送信する。その結果、発呼装置と被呼装置との間のセッションが確立する。

ＩＥＴＦ ＲＦＣ３２６１「ＳＩＰ：Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ」＜ＵＲＬ＞ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ３２６１．ｔｘｔ（２０１０年９月２４日）

従来のセッションの確立方法では、サーバは、セッションの確立が完了するまでに多数のメッセージを送受信する必要があった。さらに、サーバは、セッションの確立が完了するまで、セッションの確立に必要な情報を保持しておかなければならなかった。従って、サーバにかかる負荷が大きいという問題点があった。

本発明は、通信装置間のセッションを確立する場合に、セッションの確立を仲介するサーバにかかる負荷を低下させることができる通信装置、通信方法、および通信プログラムを提供することを目的とする。

本発明の第一の態様に係る通信装置は、データの送受信を行うサーバを介して他の通信装置との間でセッションを確立することで、前記他の通信装置との間でＰ２Ｐ通信を行う通信装置であって、前記他の通信装置に対してセッションの確立を要求する発呼装置として動作する場合に、前記他の通信装置から制御セッション用のデータを直接受信するためのポートの情報を含むセッション開始メッセージを、前記サーバを介して前記他の通信装置に送信する第一送信手段と、前記他の通信装置からセッションの確立を要求される着呼装置として動作する場合に、前記他の通信装置の第一送信手段によって送信されたセッション開始メッセージを前記サーバを介して受信することを契機として、前記他の通信装置から制御セッション用のデータを直接受信するためのポートの情報を含む応答メッセージを、前記サーバを介して前記他の通信装置に送信する第二送信手段と、前記サーバを介して前記他の通信装置から受信したセッション開始メッセージまたは応答メッセージ内の情報によって特定される制御セッション用のポートへ制御メッセージを送信することで、前記他の通信装置との間でセッションを確立するセッション確立手段と、前記着呼装置として動作する場合に、前記他の通信装置からの着信を許可する旨のユーザの指示を受け付ける指示受付手段と、前記セッション確立手段によってセッションが確立された後に、前記指示受付手段によって前記指示が受け付けられることを契機として、前記他の通信装置との間のメディアデータの送受信を開始する開始手段とを備えている。

第一の態様に係る通信装置によると、発呼装置と着呼装置との間でサーバを介して送受信されるメッセージに、相手方の通信装置から直接制御セッション用のデータを受信するためのポートの情報が含まれる。発呼装置および着呼装置は、メッセージに含まれるポートの情報に基づいて、着呼装置に着信許可の指示が入力されるか否かに係らず、セッションを確立する。従って、サーバは、セッションの確立に必要な情報の保持時間を短縮することができる。また、通信装置は、セッションが確立するまでの間にサーバを介して送受信するメッセージ（例えば、接続確認のためのメッセージ）の数を減らすことができる。さらに、通信装置は、制御セッションを確立するために最低限必要な情報以外の情報については、セッションの確立後に相手方の通信装置との間で直接送受信することができる。その結果、サーバを中継するデータのデータ量が減少する。従って、通信装置は、サーバにかかる負荷を低下させることができる。

前記第二送信手段は、セッションを確立するための前記制御メッセージを前記他の通信装置から直接受信するための１つのポートの情報を、送信する前記応答メッセージに含めてもよい。この場合、応答メッセージに含まれるポートの情報が、１つのポートの情報のみとなる。よって、サーバを中継するデータのデータ量が減少し、サーバにかかる負荷をさらに低下させることができる。通信装置は、最低限必要なポートを１つだけ開放することになるため、情報が漏洩する可能性も低下させることができる。

前記第一送信手段は、セッションを確立するための前記制御メッセージを前記他の通信装置から直接受信するための１つのポートの情報を、送信する前記セッション開始メッセージに含めてもよい。この場合、セッション開始メッセージに含まれるポートの情報が、１つのポートの情報のみとなる。よって、サーバを中継するデータのデータ量が減少し、サーバにかかる負荷をさらに低下させることができる。通信装置は、最低限必要なポートを１つだけ開放することになるため、情報が漏洩する可能性も低下させることができる。

前記通信装置は、前記着呼装置として動作する場合に、前記他の通信装置の第一送信手段によって送信されたセッション開始メッセージを前記サーバから受信することを契機として、受信した前記セッション開始メッセージに対する暫定応答メッセージを、前記サーバを介して前記他の通信装置に送信する第三送信手段と、前記他の通信装置の第一送信手段によって送信されたセッション開始メッセージを前記サーバを介して受信した場合に、受信した前記セッション開始メッセージに含まれる情報に基づいて、前記第二送信手段による応答メッセージの送信、および前記第三送信手段による暫定応答メッセージの送信のいずれを実行するかを決定する決定手段とをさらに備えてもよい。前記第二送信手段および前記第三送信手段は、前記決定手段によって応答メッセージおよび暫定応答メッセージのいずれかを送信することが決定された場合にのみ、決定された応答メッセージまたは暫定応答メッセージを送信してもよい。この場合、通信装置は、従来の一般的なセッション確立方法に従い、第三送信手段によって暫定応答メッセージを送信することもできる。第二送信手段によってすぐに応答メッセージを送信し、即時にセッションを確立することもできる。従って、通信装置は、相手方の通信装置に応じた適切な方法でセッションを確立することができる。

前記決定手段は、前記制御メッセージを前記他の通信装置が直接受信するための１つのポートの情報が、前記サーバを介して受信した前記セッション開始メッセージに含まれていれば、前記第二送信手段によって応答メッセージを送信することを決定し、前記サーバを介して受信した前記セッション開始メッセージに前記１つのポートの情報が含まれていなければ、前記第三送信手段によって暫定応答メッセージを送信することを決定してもよい。従来の一般的な方法では、メディアを受信するためのポートの情報等がセッション開始メッセージに含まれているが、制御メッセージを受信するためのポート（以下、「制御セッション用ポート」という。）の情報は含まれていない。通信装置は、着信許可の入力前に即時にセッションを確立する方式（以下、「即時確立方式」という。）に相手方の通信装置が対応しているか否かを、制御セッション用ポートの情報が含まれているか否かに応じて的確に判断することができる。

前記第二送信手段は、前記サーバを介して受信した前記セッション開始メッセージに、前記他の通信装置がメディアデータを受信するポートであるメディア用ポートの情報が含まれている場合に、前記メディア用ポートにメディアデータを送信しないことを示す情報を前記応答メッセージに含めてもよい。この場合、発呼装置は、セッション開始メッセージによって着呼装置に通知したメディア用ポートを、セッションの確立後に再びメディア用ポートとして通知してもよい。一方、他のポートを用いてメディアデータを受信してもよい。よって、通信装置は、データがＮＡＴ装置を通過するか否か等の種々の条件に応じて、最適なポートを用いてメディアデータを送受信することができる。

本発明の第二の態様に係る通信方法は、データの送受信を行うサーバを介して他の通信装置との間でセッションを確立することで、前記他の通信装置との間でＰ２Ｐ通信を行う通信装置によって行われる通信方法であって、前記他の通信装置に対してセッションの確立を要求する発呼装置として前記通信装置が動作する場合に、前記他の通信装置から制御セッション用のデータを直接受信するためのポートの情報を含むセッション開始メッセージを、前記サーバを介して前記他の通信装置に送信する第一送信ステップと、前記他の通信装置からセッションの確立を要求される着呼装置として前記通信装置が動作する場合に、前記他の通信装置が実行した第一送信ステップにおいて送信されたセッション開始メッセージを前記サーバを介して受信することを契機として、前記他の通信装置から制御セッション用のデータを直接受信するためのポートの情報を含む応答メッセージを、前記サーバを介して前記他の通信装置に送信する第二送信ステップと、前記サーバを介して前記他の通信装置から受信したセッション開始メッセージまたは応答メッセージ内の情報によって特定される制御セッション用のポートへ制御メッセージを送信することで、前記他の通信装置との間でセッションを確立するセッション確立ステップと、前記通信装置が前記着呼装置として動作する場合に、前記他の通信装置からの着信を許可する旨のユーザの指示を受け付ける指示受付ステップと、前記セッション確立ステップにおいてセッションが確立された後に、前記指示受付ステップにおいて前記指示が受け付けられることを契機として、前記他の通信装置との間のメディアデータの送受信を開始する開始ステップとを備えている。

第二の態様に係る通信方法によると、発呼装置と着呼装置との間でサーバを介して送受信されるメッセージに、相手方の通信装置から直接制御セッション用のデータを受信するためのポートの情報が含まれる。発呼装置および着呼装置は、メッセージに含まれるポートの情報に基づいて、着呼装置に着信許可の指示が入力されるか否かに係らず、セッションを確立する。従って、サーバは、セッションの確立に必要な情報の保持時間を短縮することができる。また、通信装置は、セッションが確立するまでの間にサーバを介して送受信するメッセージ（例えば、接続確認のためのメッセージ）の数を減らすことができる。さらに、通信装置は、制御セッションを確立するために最低限必要な情報以外の情報については、セッションの確立後に相手方の通信装置との間で直接送受信することができる。その結果、サーバを中継するデータのデータ量が減少する。従って、通信装置は、サーバにかかる負荷を低下させることができる。

本発明の第三の態様に係る通信プログラムは、データの送受信を行うサーバを介して他の通信装置との間でセッションを確立することで、前記他の通信装置との間でＰ２Ｐ通信を行う通信装置によって実行される通信プログラムであって、前記他の通信装置に対してセッションの確立を要求する発呼装置として前記通信装置が動作する場合に、前記他の通信装置から制御セッション用のデータを直接受信するためのポートの情報を含むセッション開始メッセージを、前記サーバを介して前記他の通信装置に送信する第一送信ステップと、前記他の通信装置からセッションの確立を要求される着呼装置として前記通信装置が動作する場合に、前記他の通信装置が実行した第一送信ステップにおいて送信されたセッション開始メッセージを前記サーバを介して受信することを契機として、前記他の通信装置から制御セッション用のデータを直接受信するためのポートの情報を含む応答メッセージを、前記サーバを介して前記他の通信装置に送信する第二送信ステップと、前記サーバを介して前記他の通信装置から受信したセッション開始メッセージまたは応答メッセージ内の情報によって特定される制御セッション用のポートへ制御メッセージを送信することで、前記他の通信装置との間でセッションを確立するセッション確立ステップと、前記通信装置が前記着呼装置として動作する場合に、前記他の通信装置からの着信を許可する旨のユーザの指示を受け付ける指示受付ステップと、前記セッション確立ステップにおいてセッションが確立された後に、前記指示受付ステップにおいて前記指示が受け付けられることを契機として、前記他の通信装置との間のメディアデータの送受信を開始する開始ステップとを前記通信装置のコントローラに実行させるための指示を含む。

第三の態様に係る通信プログラムによると、発呼装置と着呼装置との間でサーバを介して送受信されるメッセージに、相手方の通信装置から直接制御セッション用のデータを受信するためのポートの情報が含まれる。発呼装置および着呼装置は、メッセージに含まれるポートの情報に基づいて、着呼装置に着信許可の指示が入力されるか否かに係らず、セッションを確立する。従って、サーバは、セッションの確立に必要な情報の保持時間を短縮することができる。また、通信装置は、セッションが確立するまでの間にサーバを介して送受信するメッセージ（例えば、接続確認のためのメッセージ）の数を減らすことができる。さらに、通信装置は、制御セッションを確立するために最低限必要な情報以外の情報については、セッションの確立後に相手方の通信装置との間で直接送受信することができる。その結果、サーバを中継するデータのデータ量が減少する。従って、通信装置は、サーバにかかる負荷を低下させることができる。

通信システム１００のシステム構成を示す図である。 ＰＣ１の電気的構成を示すブロック図である。 ＳＩＰサーバ２の電気的構成を示すブロック図である。 発呼装置が即時確立方式に従わずに動作する場合の処理の流れを示すシーケンス図である。 発呼装置が即時確立方式に従わずに動作する場合の「ＩＮＶＩＴＥ」メッセージの一例を示す図である。 発呼装置が即時確立方式に従って動作する場合の処理の流れを示すシーケンス図である。 発呼装置が即時確立方式に従って動作する場合の「ＩＮＶＩＴＥ」メッセージの一例を示す図である。 着呼装置が即時確立方式に従って動作する場合の「２００ ＯＫ」メッセージの一例を示す図である。 図８に示す「２００ ＯＫ」に対する応答「ＡＣＫ」の一例を示す図である。 ＰＣ１が実行するメイン処理のフローチャートである。 メイン処理中に行われる発呼処理のフローチャートである。 発呼処理中に行われる発呼側通話処理のフローチャートである。 メイン処理中に行われる着呼処理のフローチャートである。 着呼処理中に行われる着呼側通話処理のフローチャートである。 第二の実施形態に係る通信システムの処理の流れを示すシーケンス図である。 第二の実施形態における「ＩＮＶＩＴＥ」メッセージの一例を示す図である。 第二の実施形態における「２００ ＯＫ」メッセージの一例を示す図である。 第二の実施形態に係るＰＣ１が実行する発呼処理のフローチャートである。

以下、本発明の第一の実施形態について、図面を参照して説明する。参照する図面は、本発明が採用し得る技術的特徴を説明するために用いられるものである。図面に記載されている装置の構成、各種処理のフローチャート等は、それのみに限定する趣旨ではなく、単なる説明例である。

図１を参照して、通信システム１００のシステム構成について説明する。通信システム１００は、複数のパーソナルコンピュータ（以下、「ＰＣ」という。）１と、ＳＩＰサーバ２とを備える。各ＰＣ１は、インターネット等の外部ネットワーク８を介してＳＩＰサーバ２に接続することができる。ＳＩＰサーバ２は、複数のＰＣ１間におけるセッションを確立する。セッションとは、一般に、通信装置間の接続の開始から終了までを言う。特に、本実施形態では、少なくとも２つのＰＣ１が、制御データ、音声データ、および映像データ等の各種データをＰ２Ｐ（ｐｅｅｒ ｔｏ ｐｅｅｒ）で相互に送受信できる状態をいう。複数のＰＣ１は、セッションの確立後にメディアデータを相互に送受信することで、映像および音声を用いた遠隔会議を実現する。つまり、本実施形態の通信システム１００は、テレビ会議を行うために用いられるテレビ会議システムである。しかし、本発明は、テレビ会議システム以外の通信システムにも適用できる。例えば、所謂「チャット」を行うために文字データを送受信する通信システム、電話を行うために音声データを送受信する通信システム等にも、本発明は適用できる。ＰＣ１の代わりに、テレビ会議専用の端末等を通信装置として使用することも可能である。

通信システム１００では、複数のＰＣ１が外部ネットワーク８上で通信を開始するための双方向プロトコルとして、ＳＩＰ（ＲＦＣ３２６１）が用いられる。ＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）は、外部ネットワーク８上でエンド・トゥ・エンドのセッションを確立するためのプロトコルであり、リアルタイムコミュニケーションを容易に実現できる。ＳＩＰサーバ２は、ＳＩＰリクエストを処理し、複数のＰＣ１間のセッションを確立する。また、遠隔会議中には、ＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）に従って、音声データおよび映像データが複数のＰＣ１間で直接送受信される。

なお、図１に示すように、ＰＣ１は、ＮＡＴ（Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｉｏｎ）ルータ９を介して外部ネットワーク８に接続する場合があり、ＮＡＴルータ９を介さずに外部ネットワーク８に接続する場合もある。ＮＡＴルータ９は、ローカルなネットワーク（例えば、ＬＡＮ）内で使用されるプライベートＩＰアドレスと、外部ネットワーク８で使用されるグローバルＩＰアドレスとを相互変換する。複数のＰＣ１間における最適なセッションの確立方法は、通信状況に応じて異なる場合がある。例えば、最適なセッションの確立方法は、ＰＣ１と外部ネットワーク８との間にＮＡＴルータ９が存在するか否かによって異なる場合がある。接続しているＮＡＴルータ９の種別によって異なる場合もある。より具体的には、ＰＣ１がＮＡＴルータ９に接続している場合には、多くのポートをオープンするのは望ましくないため、１つのポートで複数種類のメディアデータをトンネリングさせるのがよい。一方、ＰＣ１がＮＡＴルータ９に接続していなければ、複数のポートを使用してもよい。詳細は後述するが、本実施形態のＰＣ１によると、通信状況に応じた最適な方法で柔軟にセッションを確立させることができる。

図２を参照して、ＰＣ１の電気的構成について説明する。ＰＣ１は、ＰＣ１の制御を司るＣＰＵ１０を備える。ＣＰＵ１０には、ＲＯＭ１１、ＲＡＭ１２、ハードディスクドライブ（以下、「ＨＤＤ」という。）１３、外部通信Ｉ／Ｆ１４、マイク１５、スピーカ１６、カメラ１７、表示装置１８、および操作部１９が接続されている。ＲＯＭ１１は、ＰＣ１を動作させるためのプログラムおよび初期値等を記憶している。ＲＡＭ１２は、制御プログラムで使用される各種の情報を一時的に記憶する。ＨＤＤ１３は、各種の情報を記憶する不揮発性の記憶装置であり、本発明に係る通信プログラム等を記憶している。外部通信Ｉ／Ｆ１４は、ＰＣ１を外部ネットワーク８に接続する。

マイク１５は、ＰＣ１が配置された拠点の音声を入力する。スピーカ１６は音声を出力する。カメラ１７は、ＰＣ１が配置された拠点の映像を撮像する。表示装置１８は映像を表示する。操作部１９は、ユーザがＰＣ１に各種指示を入力するために操作される。

図３を参照して、ＳＩＰサーバ２の電気的構成について説明する。ＳＩＰサーバ２は、ＳＩＰサーバ２の制御を司るＣＰＵ２０を備える。ＣＰＵ２０には、ＲＯＭ２１、ＲＡＭ２２、ＨＤＤ２３、外部通信Ｉ／Ｆ２４が接続されている。ＲＯＭ２１は、ＳＩＰサーバ２を動作させるためのプログラムおよび初期値等を記憶している。ＲＡＭ２２は、制御プログラムで使用される各種の情報を一時的に記憶する。ＨＤＤ２３は、各種の情報を記憶する不揮発性の記憶装置である。外部通信Ｉ／Ｆ２４は、ＳＩＰサーバ２を外部ネットワーク８に接続する。

図４から図９を参照して、通信システム１００で行われる処理の流れについて説明する。以下説明する処理は、ＰＣ１のＣＰＵ１０、およびＳＩＰサーバ２のＣＰＵ２０によって行われる。図４および図６に示す２つのＰＣ１のうち、他方のＰＣ１に対してセッションの確立を要求するＰＣ１を、「発呼装置」とする。他方のＰＣ１からセッションの確立を要求されるＰＣ１を、「着呼装置」とする。

まず、図４および図５を参照して、従来の一般的なセッションの確立方式に従ってセッションを確立する場合の処理の流れについて説明する。本実施形態のＰＣ１によると、着呼装置のユーザが着信許可を入力する前に即時にセッションを確立する方式（以下、「即時確立方式」という。）に従って、２つのＰＣ１の間でセッションを確立することができる。さらに、ＰＣ１は、着呼装置として動作する場合、発呼装置が即時確立方式に対応しているか否かを判断する。対応していなければ、ＰＣ１は、従来の一般的な方式に従ってセッションを確立することができる。図４に示すシーケンス図は、発呼装置が即時確立方式に従わずに動作する場合、または、発呼装置が即時確立方式に対応していない場合の処理の流れを示す。発呼装置および着呼装置は、以下の処理を行う前に、ＳＩＰサーバ２に登録要求「ＲＥＧＩＳＴＥＲ」のＳＩＰメッセージを送信し、通信システム１００内で通信を行う通信装置の１つとしてＳＩＰサーバ２に登録されている。

ユーザが発呼装置の操作部１９を操作し、着呼装置への発呼の指示を入力すると、発呼装置は、セッション開始メッセージである呼出要求「ＩＮＶＩＴＥ」を、ＳＩＰサーバ２へ送信する（Ｓ１）。ＳＩＰサーバ２は、発呼装置から受信したセッション開始メッセージを、着呼装置に転送する（Ｓ２）。

図５に、Ｓ１，Ｓ２で送信される「ＩＮＶＩＴＥ」メッセージの一例を示す。Ｓ１，Ｓ２で送信される「ＩＮＶＩＴＥ」は、従来の一般的なセッションの確立方式において送信される「ＩＮＶＩＴＥ」と同一である。例えば、文字列３１は、発呼装置が音声セッションで使用するポートのポート番号を示す。文字列３２は、発呼装置が対応できる音声のＣＯＤＥＣを示す。文字列３３は、発呼装置が映像セッションで使用するポートのポート番号を示す。文字列３４は、発呼装置が対応できる映像のＣＯＤＥＣを示す。図５に示す「ＩＮＶＩＴＥ」メッセージには、発呼装置が即時確立方式に対応していることを示す付加情報（詳細は後述する）は含まれていない。

着呼装置は、ＳＩＰサーバ２を介して受信した「ＩＮＶＩＴＥ」に付加情報が含まれていないことから、発呼装置が即時確立方式に対応していないと判断する。この場合、発呼装置は、「ＩＮＶＩＴＥ」に対する暫定応答メッセージ「１８０ Ｒｉｎｇｉｎｇ」を、ＳＩＰサーバ２を介して発呼装置に送信する（Ｓ３，Ｓ４）。発呼装置は、「１８０ Ｒｉｎｇｉｎｇ」に対する応答メッセージ「ＰＲＡＣＫ」を、ＳＩＰサーバ２を介して着呼装置に返信する（Ｓ５，Ｓ６）。着呼装置は、「ＰＲＡＣＫ」に対する応答メッセージ「２００ ＯＫ」を、ＳＩＰサーバ２を介して発呼装置に返信する（Ｓ７，Ｓ８）。以上のＳ３〜Ｓ８の処理によって、発呼装置および着呼装置の接続確認が行われる。着呼装置は、定期的に「１８０ Ｒｉｎｇｉｎｇ」を発呼装置に送信することで、接続確認を行う（Ｓ９〜Ｓ１４）。つまり、従来の一般的なセッションの確立方式では、接続確認を行うタイミングは着呼装置によって決定される。

ユーザが着呼装置の操作部１９を操作し、着信を許可する指示を入力すると、着呼装置は、「ＩＮＶＩＴＥ」に対する応答メッセージ「２００ ＯＫ」を、ＳＩＰサーバ２に送信する（Ｓ１５）。ＳＩＰサーバ２は、着呼装置から受信した応答メッセージ「２００ ＯＫ」を発呼装置に転送する（Ｓ１６）。Ｓ１５，Ｓ１６で送信される「２００ ＯＫ」には、着呼装置のＩＰアドレス、メディア用ポートのポート番号、および採用ＣＯＤＥＣ情報が含まれる。メディア用ポートとは、ＰＣ１がメディアデータのセッションで使用するポートである。採用ＣＯＤＥＣ情報とは、発呼装置が対応できるＣＯＤＥＣのうちのいずれを着呼装置が採用するかを示す情報である。発呼装置は、「２００ ＯＫ」に対する応答メッセージ「ＡＣＫ」を、ＳＩＰサーバ２を介して着呼装置に返信する（Ｓ１７，Ｓ１８）。

発呼装置は、Ｓ１６で受信した「２００ ＯＫ」によって通知されたメディア用ポートに、メディアデータを直接送信する（Ｓ１９）。着呼装置は、Ｓ２で受信した「ＩＮＶＩＴＥ」によって通知されたメディア用ポートに、メディアデータを直接送信する（Ｓ２０）。その結果、発呼装置と着呼装置との間のセッションが確立し、メディアデータの送受信が開始される。図４に示す例では、その後、発呼装置の操作部１９が操作されて、切断指示が入力される。発呼装置は、ＳＩＰサーバ２を介して「ＢＹＥ」を着呼装置に送信する（Ｓ２１，Ｓ２２）。着呼装置は、「ＢＹＥ」に対する応答メッセージ「２００ ＯＫ」を、ＳＩＰサーバ２を介して発呼装置に送信する（Ｓ２３，Ｓ２４）。その結果、発呼装置と着呼装置との間のＰ２Ｐ通信が終了する。なお、「ＢＹＥ」が着呼装置から発呼装置へ送信されてもよいことは言うまでもない。

以上のように、ＰＣ１は、従来の一般的な方式に従ってセッションを確立することもできるため、汎用性を有する。しかし、従来の方式では、セッションが確立されるまでに、ＳＩＰサーバ２は多数のメッセージを送受信しなければならない（Ｓ１〜１８）。さらに、ＳＩＰサーバ２は、セッションの確立が完了するまで、セッションの確立に必要な情報を保持しておかなければならない。よって、ＳＩＰサーバ２にかかる負荷は大きい。

図６から図９を参照して、即時確立方式に従ってセッションを確立する場合の処理の流れについて説明する。発呼の指示が発呼装置に入力されると、発呼装置は、セッション開始メッセージである呼出要求「ＩＮＶＩＴＥ」を、ＳＩＰサーバ２を介して着呼装置に送信する（Ｓ３１，Ｓ３２）。

図７に、Ｓ３１，Ｓ３２で送信される「ＩＮＶＩＴＥ」メッセージの一例を示す。Ｓ３１，Ｓ３２で送信される「ＩＮＶＩＴＥ」には、従来の確立方式において送信される「ＩＮＶＩＴＥ」（図５参照）と同様に、メディアデータを直接送受信するためのポートおよびＣＯＤＥＣの情報（以下、「メディア用情報」という。）を示す文字列３１〜３４が含まれる。さらに、Ｓ３１，Ｓ３２で送信される「ＩＮＶＩＴＥ」には、発呼装置が即時確立方式に対応していることを示す付加情報を含む文字列３７がある。

着呼装置は、受信した「ＩＮＶＩＴＥ」に付加情報が含まれていることから、発呼装置が即時確立方式に対応していると判断する。この場合、着呼装置は、着信を許可する指示がユーザによって行われたか否かに関わらず、「ＩＮＶＩＴＥ」に対する応答メッセージ「２００ ＯＫ」を、ＳＩＰサーバ２を介して即時に発呼装置に送信する（Ｓ３３，Ｓ３４）。

図８に、Ｓ３３，Ｓ３４で送信される応答メッセージ「２００ ＯＫ」のメッセージの一例を示す。Ｓ３３，Ｓ３４で送信される「２００ ＯＫ」には、「ＩＮＶＩＴＥ」によって発呼装置から提示されたメディア用情報（図７の文字列３１〜３４）を採用しないことを示す文字列４１が含まれる。つまり、文字列４１は、発呼装置が通知してきたメディア用ポートにメディアデータを送信しないことを示す。前述したように、複数のＰＣ１間における最適なセッションの確立方法は、ＮＡＴルータ９が存在するか否か等の通信の状況に応じて異なる場合がある。本実施形態のＰＣ１によれば、着呼装置は、発呼装置が通知してきたメディア用ポート以外のポートへメディアデータを送信することもできるため、通信の状況に応じた最適な方法でセッションを確立することができる。

また、Ｓ３３，Ｓ３４で送信される「２００ ＯＫ」では、セッションを確立するための制御メッセージを発呼装置から直接受信するための１つのポート（制御セッション用ポート）の番号が、文字列４２に含まれる。従って、着呼装置は、メディア用ポート等の複数のポートの情報を「２００ ＯＫ」に含める従来の方法に比べて、ＳＩＰサーバ２を経由するデータのデータ量を減少させることができる。着呼装置は、セッションを確立するために最低限必要なポートを１つだけ開放することになるため、情報が漏洩する可能性も低下させることができる。さらに、Ｓ３３，Ｓ３４で送信される「２００ ＯＫ」には、即時確立方式を用いてセッションを確立することを発呼装置に対して要求する情報を含む文字列４４がある。よって、発呼装置は、即時確立方式に従って処理を行うことを確実に認識することができる。

発呼装置は、ＳＩＰサーバ２を介して「２００ ＯＫ」を受信すると、「２００ ＯＫ」に対する応答メッセージ「ＡＣＫ」を、ＳＩＰサーバ２を介して着呼装置に返信する（Ｓ３５，Ｓ３６）。図９に、Ｓ３５，Ｓ３６で送信される応答メッセージ「ＡＣＫ」の一例を示す。Ｓ３５，Ｓ３６で送信される「ＡＣＫ」には、セッションを確立するための制御メッセージを着呼装置から直接受信するための１つの制御セッション用ポートの番号が、文字列４３に含まれる。制御セッション用ポートは、図７に示す「ＩＮＶＩＴＥ」でメディア用ポートとして通知したポートをそのまま用いてもよいし、メディア用ポートとは異なるポートをオープンして用いてもよい。なお、「ＡＣＫ」には、図８に示す「２００ ＯＫ」と同様に、即時確立方式を用いてセッションを確立することを相手方に要求する「Ｒｅｑｕｉｒｅ」の文字列が含まれる。

その後、発呼装置は、Ｓ３４で受信した応答メッセージによって特定された制御セッション用ポートに、セッションを確立するための制御メッセージである接続確認メッセージを、ＳＩＰサーバ２を介さずに直接送信する（Ｓ３７）。着呼装置は、Ｓ３６で受信した応答メッセージによって特定された制御セッション用ポートに、制御メッセージである接続確認の応答メッセージを直接送信する（Ｓ３８）。その結果、発呼装置と着呼装置との間の制御セッションが確立する。制御セッションとは、発呼装置と着呼装置とがＰ２Ｐ通信を行うために必要な制御情報を送受信するためのセッションである。なお、図６に示す例では、発呼装置が先に接続確認メッセージを送信している。しかし、着呼装置が先に接続確認メッセージを送信し、発呼装置が接続確認の応答メッセージを送信することで、セッションを確立してもよい。

発呼装置および着呼装置は、相手方のＰＣ１に最初に送信する制御メッセージ（図６に示す例では、Ｓ３７およびＳ３８で送信される接続確認のためのメッセージ）に、メディアデータを直接送受信するためのメディア用情報を含める。具体的には、相手方のＰＣ１からメディアデータを受信するためのメディア用ポートの番号と、ＣＯＤＥＣの情報とを含める。発呼装置および着呼装置は、最初に送信する制御メッセージにメディア用情報を含めることで、ＣＯＤＥＣの条件が合致しない場合の通信の中断等の対処を早急に行うことができる。しかし、メディア用情報を送信するタイミングを変更しても、本発明は実現できる。

発呼装置および着呼装置は、自らが決定した周期で相手方のＰＣ１に接続確認メッセージを送信する（例えば、Ｓ３７およびＳ３９）。発呼装置および着呼装置は、相手方のＰＣ１から接続確認メッセージを受信する毎に、接続確認の応答メッセージを返信する（例えば、Ｓ３８およびＳ４０）。前述したように、従来の一般的なセッションの確立方式では、接続確認を行うタイミング（「１８０ Ｒｉｎｇｉｎｇ」が送信されるタイミング）は着呼装置によって決定される。しかし、即時確立方式によれば、発呼装置からも自由に接続確認メッセージを送信できる。従って、所定時間通信を行わなければファイヤウォールがポートを閉じる環境にある場合等でも、問題が生じることはない。

ユーザが着呼装置の操作部１９を操作し、着信を許可する指示を入力すると、着呼装置は、着信許可メッセージを発呼装置に直接送信する（Ｓ４１）。発呼装置は、着信許可の応答メッセージを着呼装置に返信する（Ｓ４２）。その結果、発呼装置と着呼装置との間のメディアデータの送受信が開始される（Ｓ４３，Ｓ４４）。発呼装置または着呼装置の操作部１９が操作されて切断指示が入力されると、切断指示を受け付けたＰＣ１（図６に示す例では発呼装置）は、相手方のＰＣ１に切断要求メッセージを直接送信する（Ｓ４５）。切断要求メッセージを受信したＰＣ１は、切断要求の応答メッセージを返信し（Ｓ４６）、Ｐ２Ｐ通信が終了する。本実施形態では、従来とは異なり、切断要求メッセージもＳＩＰサーバ２を介さずにＰＣ１間で送受信されるため、ＳＩＰサーバ２に係る負荷をさらに低下させることができる。

図１０から図１４を参照して、上記の通信システム１００の処理を実行するために各ＰＣ１が実行する処理について説明する。ＰＣ１のＣＰＵ１０は、ＳＩＰサーバ２へ登録要求メッセージ「ＲＥＧＩＳＴＥＲ」を送信してＳＩＰサーバ２への登録が完了すると、図１０に示すメイン処理を実行する。メイン処理では、ＣＰＵ１０は、呼出要求発信（発呼）を指示する操作が操作部１９に対して行われたか否かを判断する（Ｓ５１）。操作部１９が操作されておらず、呼出要求発信の指示が入力されていなければ（Ｓ５１：ＮＯ）、ＣＰＵ１０は、他のＰＣ１から呼出要求「ＩＮＶＩＴＥ」を受信したか否かを判断する（Ｓ５２）。「ＩＮＶＩＴＥ」を受信していなければ（Ｓ５２：ＮＯ）、ＳＩＰサーバ２との間の接続の終了指示が操作部１９に入力されたか否かを判断する（Ｓ５３）。終了指示が入力されていなければ（Ｓ５３：ＮＯ）、Ｓ５１〜Ｓ５３の判断が繰り返される。終了指示が入力されると（Ｓ５３：ＹＥＳ）、メイン処理は終了する。

呼出要求発信を指示する操作が行われた場合には（Ｓ５１：ＹＥＳ）、ＣＰＵ１０は発呼処理を行う（Ｓ５５）。発呼処理は、ＰＣ１が発呼装置として動作する場合の処理である。他のＰＣ１から「ＩＮＶＩＴＥ」を受信した場合には（Ｓ５２：ＹＥＳ）、ＣＰＵ１０は着呼処理を行う（Ｓ５６）。着呼処理は、ＰＣ１が着呼装置として動作する場合の処理である。以下、発呼処理および着呼処理について詳細に説明する。

図１１および図１２を参照して、発呼処理について説明する。図１１に示すように、ＣＰＵ１０は、メディア用ポートをオープンする（Ｓ６１）。前述したように、メディア用ポートとは、ＰＣ１がメディアデータのセッションで使用するポートである。次いで、ＣＰＵ１０は、呼出要求「ＩＮＶＩＴＥ」をＳＩＰサーバ２へ送信する（Ｓ６２）。Ｓ６２で送信される「ＩＮＶＩＴＥ」には、Ｓ６１でオープンされたメディア用ポートの番号、ＣＯＤＥＣの情報等が含まれる（図７参照）。ＣＰＵ１０は、メッセージを暗号化するために必要な暗号鍵情報を「ＩＮＶＩＴＥ」に含めてもよい。なお、ＳＩＰサーバ２は、「ＩＮＶＩＴＥ」のメッセージによって特定されるＰＣ１（着呼装置）に「ＩＮＶＩＴＥ」を転送する。

次いで、ＣＰＵ１０は、着呼装置からメッセージを受信したか否かを判断する（Ｓ６３）。メッセージを受信していなければ（Ｓ６３：ＮＯ）、Ｓ６３の判断が繰り返される。メッセージを受信した場合（Ｓ６３：ＹＥＳ）、ＣＰＵ１０は、受信したメッセージが「１８０ Ｒｉｎｇｉｎｇ」であるか否かを判断する（Ｓ６４）。着呼装置が即時確立方式に対応しておらず、従来の方式に従って「１８０ Ｒｉｎｇｉｎｇ」を送信してきた場合には（Ｓ６４：ＹＥＳ）、ＣＰＵ１０は、ＳＩＰサーバ２を介して応答メッセージ「ＰＲＡＣＫ」を着呼装置に送信し、且つ「ＰＲＡＣＫ」に対する応答メッセージ「２００ＯＫ」をＳＩＰサーバ２から受信する（Ｓ６５）。処理はＳ６３の判断へ戻る。

受信したメッセージが「１８０ Ｒｉｎｇｉｎｇ」でなければ（Ｓ６４：ＮＯ）、ＣＰＵ１０は、受信したメッセージがメディア用情報を含む「２００ ＯＫ」であるか否かを判断する（Ｓ６７）。前述したように、従来の方式では、「ＩＮＶＩＴＥ」に対する応答メッセージ「２００ ＯＫ」にはメディア用情報が含まれる（図４のＳ１５，Ｓ１６参照）。従って、メディア用情報を含む「２００ ＯＫ」を受信した場合（Ｓ６７：ＹＥＳ）、ＣＰＵ１０は、従来の方式に従って、「２００ ＯＫ」に対する応答メッセージ「ＡＣＫ」をＳＩＰサーバ２を介して返信し（Ｓ６８）、通話処理を行う（Ｓ６９）。通話処理では、「２００ ＯＫ」で通知されたメディア用情報に従って、メディアデータが着呼装置に直接送信される。さらに、着呼装置からメディアデータが直接受信され、セッションが確立される。自装置または着呼装置に切断指示の入力が受け付けられると、通話処理（Ｓ６９）は終了し、処理はメイン処理へ戻る。

受信したメッセージが、メディア用情報を含む「２００ ＯＫ」でなければ（Ｓ６７：ＮＯ）、ＣＰＵ１０は、制御用情報を含む「２００ ＯＫ」（図８参照）を受信したか否かを判断する（Ｓ７１）。制御用情報とは、着呼装置が制御メッセージを直接受信するための制御セッション用ポートの番号の情報である。受信したメッセージが、制御用情報を含む「２００ ＯＫ」でもなければ（Ｓ７１：ＮＯ）、受信したメッセージは、着信拒絶通知メッセージ、またはエラーメッセージである。従って、ＣＰＵ１０は通信を終了し（Ｓ７２）、処理はメイン処理へ戻る。

受信したメッセージが、制御用情報を含む「２００ ＯＫ」であれば（Ｓ７１：ＹＥＳ）、着呼装置は即時確立方式に対応している。従って、ＣＰＵ１０は、Ｓ６１でオープンしたメディア用ポートを一旦閉じる（Ｓ７３）。制御セッション用ポートをオープンする（Ｓ７４）。ＣＰＵ１０は、オープンした制御セッション用ポートの番号を含む応答メッセージ「ＡＣＫ」（図９参照）を、ＳＩＰサーバ２を介して着呼装置に送信する（Ｓ７５）。次いで、ＣＰＵ１０は発呼側通話処理（Ｓ７６）を実行し、処理はメイン処理へ戻る。

図１２に示すように、ＣＰＵ１０は、発呼側通話処理を開始すると、「２００ ＯＫ」によって通知された制御セッション用ポートに、接続確認メッセージを送信する（Ｓ８１）。次いで、着呼装置からメッセージを受信したか否かを判断する（Ｓ８２）。メッセージを受信した場合（Ｓ８２：ＹＥＳ）、ＣＰＵ１０は、受信したメッセージが接続確認の応答メッセージであるか否かを判断する（Ｓ８３）。接続確認の応答メッセージであれば（Ｓ８３：ＹＥＳ）、接続が正常であることを確認し、処理はＳ８２の判断へ戻る。接続確認メッセージ、または接続確認の応答メッセージの送受信が完了した時点で、Ｐ２Ｐ通信に必要な各種情報を送受信するための制御セッションが確立する。

受信したメッセージが接続確認の応答メッセージでなければ（Ｓ８３：ＮＯ）、着呼装置から発せられた接続確認のメッセージであるか否かが判断される（Ｓ８４）。接続確認のメッセージであれば（Ｓ８４：ＹＥＳ）、ＣＰＵ１０は、接続確認の応答メッセージを着呼装置に直接返信し（Ｓ８５）、処理はＳ８２の判断へ戻る。なお、前述したように、ＣＰＵ１０は、着呼装置に最初に送信する接続確認メッセージまたは接続確認の応答メッセージに、メディア用情報を含める。

受信したメッセージが接続確認のメッセージでなければ（Ｓ８４：ＮＯ）、着信拒絶メッセージであるか否かが判断される（Ｓ８７）。詳細は図１３および図１４を参照して後述するが、着呼装置のユーザが着信を拒絶すると、着呼装置は発呼装置に着信拒絶メッセージを送信する。ＣＰＵ１０は、着信拒絶メッセージを受信すると（Ｓ８７：ＹＥＳ）、発呼の動作をキャンセルする処理を行い（Ｓ８８）、処理は発呼処理へ戻る。

受信したメッセージが着信拒絶メッセージでもなければ（Ｓ８７：ＮＯ）、受信したメッセージは着信許可メッセージである。ＣＰＵ１０は、着信許可メッセージを受信し（Ｓ８９）、着信許可の応答メッセージを着呼装置に直接返信する（Ｓ９０）。次いで、ＣＰＵ１０は通話処理を実行する（Ｓ９１）。通話処理（Ｓ９１）では、接続確認メッセージ、または接続確認の応答メッセージによって通知されたメディア用情報に従って、メディアデータのセッションが確立され、メディアデータが直接送受信される。また、切断指示の入力が受け付けられると、「ＢＹＥ」のメッセージ等が２つのＰＣ１の間で直接送受信されて、通話処理は終了する。処理は発呼処理へ戻る。

また、着呼装置からメッセージを受信していなければ（Ｓ８２：ＮＯ）、ＣＰＵ１０は、操作部１９に対して発信キャンセルの操作が行われたか否かを判断する（Ｓ９３）。発信キャンセルの操作が行われた場合（Ｓ９３：ＹＥＳ）、ＣＰＵ１０は、発信キャンセルメッセージを着呼装置に直接送信し（Ｓ９４）、発呼動作をキャンセルする処理を行う（Ｓ９５）。処理は発呼処理へ戻る。

発信キャンセルの操作が行われていなければ（Ｓ９３：ＮＯ）、ＣＰＵ１０は、接続確認の応答メッセージを受信しないままタイムアウトとなったか否かを判断する（Ｓ９７）。Ｓ８３で応答メッセージを受信しないまま、接続確認メッセージの送信（Ｓ８１）から所定時間が経過した場合には（Ｓ９７：ＹＥＳ）、接続が正常に行われていない。従って、ＣＰＵ１０は発呼動作をキャンセルし（Ｓ９５）、処理は発呼処理へ戻る。

タイムアウトとなっていなければ（Ｓ９７：ＮＯ）、ＣＰＵ１０は、接続確認メッセージの送信（Ｓ８１）から一定時間が経過したか否かを判断する（Ｓ９８）。この一定時間は、接続確認メッセージの送信間隔であり、ＣＰＵ１０は一定時間毎に接続確認メッセージを送信することになる。Ｓ９８で判断する時間は、Ｓ９７で判断する時間よりも長い。一定時間が経過していなければ（Ｓ９８：ＮＯ）、処理はＳ８２の判断へ戻る。一定時間が経過していれば（Ｓ９８：ＹＥＳ）、ＣＰＵ１０は、接続確認メッセージを再び送信する（Ｓ８１）。発呼動作のキャンセル、または通話の終了まで、接続確認メッセージは一定時間毎に繰り返し送信される。

図１３および図１４を参照して、着呼処理について説明する。前述したように、ＣＰＵ１０は、他のＰＣ１（発呼装置）から「ＩＮＶＩＴＥ」を受信すると、図１３に示す着呼処理を実行する。まず、ＣＰＵ１０は、受信した「ＩＮＶＩＴＥ」のメッセージによって、発呼装置が即時確立方式に対応しているか否かを判断する（Ｓ１０１）。第一の実施形態では、ＣＰＵ１０は、付加情報（図７の文字列３７）が「ＩＮＶＩＴＥ」に含まれるか否かによって、発呼装置が即時確立方式に対応しているか否かを判断する。

付加情報が含まれておらず、発呼装置が即時確立方式に対応していないと判断した場合には（Ｓ１０１：ＮＯ）、ＣＰＵ１０は、従来の方式に従ってセッションを確立する。詳細には、ＣＰＵ１０は、暫定応答メッセージ「１８０ Ｒｉｎｇｉｎｇ」をＳＩＰサーバ２に返信する（Ｓ１０２）。ＳＩＰサーバ２を介して「ＰＲＡＣＫ」を受信し、「ＰＲＡＣＫ」に対する応答メッセージを返信する（Ｓ１０３）。次いで、ＣＰＵ１０は、「１８０ Ｒｉｎｇｉｎｇ」の送信間隔として定められた一定時間が経過したか否かを判断する（Ｓ１０４）。一定時間が経過していなければ（Ｓ１０４：ＮＯ）、ＣＰＵ１０は、操作部１９に対して着信拒絶の指示の入力操作が行われたか否かを判断する（Ｓ１０５）。着信拒絶の操作が行われていなければ（Ｓ１０５：ＮＯ）、操作部１９に対して着信許可の指示の入力操作が行われたか否かを判断する（Ｓ１０６）。着信許可の操作が行われていなければ（Ｓ１０６：ＮＯ）、処理はＳ１０４の判断へ戻り、Ｓ１０４〜Ｓ１０６の判断が繰り返される。

一定時間が経過した場合には（Ｓ１０４：ＹＥＳ）、「１８０ Ｒｉｎｇｉｎｇ」がＳＩＰサーバ２へ再び送信されて、接続確認が行われる（Ｓ１０２、Ｓ１０３）。着信拒絶の操作が行われた場合には（Ｓ１０５：ＹＥＳ）、ＣＰＵ１０は、着信拒絶メッセージを、ＳＩＰサーバ２を介して発呼装置に送信し（Ｓ１０８）、通信を終了する（Ｓ１０９）。処理はメイン処理へ戻る。着信許可の操作が行われた場合には（Ｓ１０６：ＹＥＳ）、ＣＰＵ１０は、メディア用情報を含む応答メッセージ「２００ ＯＫ」を、ＳＩＰサーバ２を介して発呼装置に送信する（Ｓ１１１）。ＳＩＰサーバ２を介して、発呼装置からの応答メッセージ「ＡＣＫ」を受信する（Ｓ１１２）。図１１のＳ６９と同様に、セッションが確立されて通話処理が行われ（Ｓ１１３）、処理はメイン処理へ戻る。

また、発呼装置から受信した「ＩＮＶＩＴＥ」に付加情報が含まれており、発呼装置が即時確立方式に対応していると判断した場合（Ｓ１０１：ＹＥＳ）、ＣＰＵ１０は、即時確立方式に従ってセッションを確立する。詳細には、ＣＰＵ１０は、制御セッション用ポートを１つオープンする（Ｓ１１５）。着信許可の操作が行われたか否かに係らず、オープンした制御セッション用ポートの番号を含む応答メッセージ「２００ ＯＫ」を、サーバ２を介して発呼装置に送信する（Ｓ１１６）。ＣＰＵ１０は、ＳＩＰサーバ２から「ＡＣＫ」を受信するまで待機する（Ｓ１１７：ＮＯ）。「ＡＣＫ」を受信すると（Ｓ１１７：ＹＥＳ）、着呼側通話処理を実行し（Ｓ１１８）、処理はメイン処理へ戻る。

図１４に示すように、ＣＰＵ１０は、着呼側通話処理を開始すると、受信した「ＡＣＫ」のメッセージによって特定される制御セッション用ポートに、接続確認メッセージを直接送信する（Ｓ１２１）。次いで、発呼装置からメッセージを受信したか否かを判断する（Ｓ１２２）。メッセージを受信した場合（Ｓ１２２：ＹＥＳ）、ＣＰＵ１０は、受信したメッセージが接続確認の応答メッセージであるか否かを判断する（Ｓ１２４）。接続確認の応答メッセージであれば（Ｓ１２４：ＹＥＳ）、接続が正常であることを確認し、処理はＳ１２２の判断へ戻る。接続確認メッセージ、または接続確認の応答メッセージの送受信が完了した時点で、Ｐ２Ｐ通信に必要な各種情報を送受信するための制御セッションが確立する。

受信したメッセージが接続確認の応答メッセージでなければ（Ｓ１２４：ＮＯ）、発呼装置から発せられた接続確認のメッセージであるか否かが判断される（Ｓ１２５）。接続確認のメッセージであれば（Ｓ１２５：ＹＥＳ）、ＣＰＵ１０は、接続確認の応答メッセージを発呼装置に直接返信し（Ｓ１２６）、処理はＳ１２２の判断へ戻る。なお、前述したように、ＣＰＵ１０は、着呼装置に最初に送信する接続確認メッセージまたは接続確認の応答メッセージに、メディア用情報を含める。

受信したメッセージが接続確認のメッセージでなければ（Ｓ１２５：ＮＯ）、受信したメッセージは発信キャンセルメッセージである。ＣＰＵ１０は、発信キャンセルメッセージを受信し（Ｓ１２７）、応答メッセージを発呼装置に直接返信する（Ｓ１２８）。発呼装置との間の通信を終了し（Ｓ１２９）、処理は着呼処理へ戻る。

また、発呼装置からメッセージを受信していなければ（Ｓ１２２：ＮＯ）、ＣＰＵ１０は、操作部１９に対して着信拒絶の操作が行われたか否かを判断する（Ｓ１３１）。着信拒絶の操作が行われた場合（Ｓ１３１：ＹＥＳ）、ＣＰＵ１０は、着信拒絶メッセージを発呼装置に直接送信する（Ｓ１３６）。よって、着信拒絶時にＳＩＰサーバ２を介して「ＥＲＲＯＲ」を送信する従来の手法に比べて、ＳＩＰサーバ２にかかる負荷を低下させることができる。次いで、ＣＰＵ１０は発呼装置との間の通信を終了し（Ｓ１３７）、処理は着呼処理へ戻る。

着信拒絶の操作が行われていなければ（Ｓ１３１：ＮＯ）、ＣＰＵ１０は、着信許可の操作が行われたか否かを判断する（Ｓ１３２）。着信許可の操作が行われた場合（Ｓ１３２：ＹＥＳ）、ＣＰＵ１０は、着信許可メッセージを発呼装置に直接送信する（Ｓ１３９）。着信許可の応答メッセージを、発呼装置から直接受信する（Ｓ１４０）。次いで、ＣＰＵ１０は、図１２のＳ９１と同様に通話処理を実行する（Ｓ１４１）。通話処理（Ｓ１４１）では、接続確認メッセージ、または接続確認の応答メッセージによって通知されたメディア用情報に従って、メディアデータのセッションが確立され、メディアデータが直接送受信される。切断指示が入力されると、通話処理は終了し、処理は着呼処理へ戻る。

着信許可の操作が行われていなければ（Ｓ１３２：ＮＯ）、ＣＰＵ１０は、接続確認の応答メッセージを発呼装置から受信しないままタイムアウトとなったか否かを判断する（Ｓ１３３）。Ｓ１２４で応答メッセージを受信しないまま、接続確認メッセージの送信（Ｓ１２１）から所定時間が経過した場合には（Ｓ１３３：ＹＥＳ）、接続が正常に行われていない。従って、ＣＰＵ１０は通信を終了し（Ｓ１４２）、処理は着呼処理へ戻る。

タイムアウトとなっていなければ（Ｓ１３３：ＮＯ）、ＣＰＵ１０は、接続確認メッセージの送信（Ｓ１２１）から一定時間が経過したか否かを判断する（Ｓ１３４）。一定時間が経過していなければ（Ｓ１３４：ＮＯ）、処理はＳ１２２の判断へ戻る。一定時間が経過していれば（Ｓ１３４：ＹＥＳ）、ＣＰＵ１０は、接続確認メッセージを再び送信する（Ｓ１２１）。着信拒絶等の通信終了、または通話の終了まで、接続確認メッセージは一定時間毎に繰り返し送信される。

以上説明したように、第一の実施形態のＰＣ１によると、発呼装置と着呼装置との間でＳＩＰサーバ２を介して送受信されるメッセージに、相手方の通信装置から直接データを受信するためのポートの情報が含まれる。発呼装置および着呼装置は、メッセージに含まれるポートの情報に基づいて、着呼装置に着信許可の指示が入力されるか否かに係らず、制御セッションを確立する。従って、ＳＩＰサーバ２は、セッションの確立に必要な情報の保持時間を短縮することができる。また、ＰＣ１は、セッションが確立するまでの間にＳＩＰサーバ２を介して送受信するメッセージ（例えば、接続確認のためのメッセージ）の数を減らすことができる。さらに、ＰＣ１は、制御セッションを確立するために最低限必要な情報以外の情報については、制御セッションの確立後に相手方の通信装置との間で直接送受信することができる。その結果、ＳＩＰサーバ２を中継するデータのデータ量が減少する。従って、ＰＣ１は、ＳＩＰサーバ２にかかる負荷を低下させることができる。

ＰＣ１は、着呼装置として動作する場合、「ＩＮＶＩＴＥ」に対する応答メッセージ「２００ ＯＫ」に、制御メッセージを直接受信するための１つの制御セッション用ポートの情報を含める。その結果、「２００ ＯＫ」に含まれるポートの情報が、１つのポートの情報のみとなる。よって、メディア用ポートの情報等を含める場合に比べて、ＳＩＰサーバ２を中継するデータのデータ量が減少し、ＳＩＰサーバ２にかかる負荷をさらに低下させることができる。着呼装置は、「２００ ＯＫ」を送信する段階では、最低限必要なポートを１つだけ開放することになる。よって、情報が漏洩する可能性も低下させることができる。

ＰＣ１は、「ＩＮＶＩＴＥ」を受信した場合、発呼装置が即時確立方式に対応していなければ、従来の一般的な方法に従って暫定応答メッセージ「１８０ Ｒｉｎｇｉｎｇ」を返信することもできる。従って、ＰＣ１は、相手方の通信装置に応じた適切な方法でセッションを確立することができる。ＰＣ１は、「ＩＮＶＩＴＥ」に付加情報が含まれているか否かに応じて、発呼装置が即時確立方式に対応しているか否かを的確に判断することができる。

ＰＣ１は、「ＩＮＶＩＴＥ」メッセージにメディア用ポートの情報が含まれている場合に、通知されたメディア用ポートにデータを送信しないことを示す情報を「２００ ＯＫ」に含めることができる。よって、発呼装置は、一旦通知したメディア用ポートを、制御セッションの確立後に再びメディア用ポートとして着呼装置に通知してもよいし、他のポートをメディア用ポートとして通知してもよい。よって、ＰＣ１は、通信条件に応じて最適なポートを用いてメディアデータを送受信することができる。

上記第一の実施形態において、ＰＣ１が本発明の「通信装置」に相当する。ＳＩＰサーバ２が本発明の「サーバ」に相当する。図１１のＳ６２で「ＩＮＶＩＴＥ」を送信するＣＰＵ１０が「第一送信手段」として機能する。図１３のＳ１１１で「２００ ＯＫ」を送信するＣＰＵ１０が「第二送信手段」として機能する。図１４のＳ１２１およびＳ１２６で制御セッションを確立するＣＰＵ１０が「セッション確立手段」として機能する。図１４のＳ１３２で着信許可の指示を受け付けるＣＰＵ１０が「指示受付手段」として機能する。図１４のＳ１４１および図１２のＳ９１でメディアデータの送受信を開始するＣＰＵ１０が「開始手段」として機能する。

図１３のＳ１０２で「１８０ Ｒｉｎｇｉｎｇ」を送信するＣＰＵ１０が「第三送信手段」として機能する。図１３のＳ１０１で「２００ ＯＫ」および「１８０ Ｒｉｎｇｉｎｇ」のいずれを送信するかを決定するＣＰＵ１０が「決定手段」として機能する。

図１１のＳ６２で「ＩＮＶＩＴＥ」を送信する処理が「第一送信ステップ」に相当する。図１３のＳ１１１で「２００ ＯＫ」を送信する処理が「第二送信ステップ」に相当する。図１４のＳ１２１およびＳ１２６で制御セッションを確立する処理が「セッション確立ステップ」に相当する。図１４のＳ１３２で着信許可の指示を受け付ける処理が「指示受付ステップ」に相当する。図１４のＳ１４１および図１２のＳ９１でメディアデータの送受信を開始する処理が「開始ステップ」に相当する。

本発明の第二の実施形態について、図１５から図１８を参照して説明する。第二の実施形態に係るＰＣ１は、発呼装置として動作する場合に、「ＩＮＶＩＴＥ」メッセージに１つの制御セッション用ポートの番号を含める。メディア用ポートの番号等のメディア用情報は、「ＩＮＶＩＴＥ」には含めない。従って、着呼装置が即時確立方式に対応していることがあらかじめ判明している場合に有用である。第二の実施形態では、上記の「ＩＮＶＩＴＥ」を送信する処理等の一部の処理以外の処理、および装置の構成は、第一の実施形態における処理および構成と同じである。よって、第一の実施形態と同一の処理および構成については同一の番号を付し、説明を省略または簡略化する。

図１５から図１７を参照して、第二の実施形態に係る通信システムで行われる処理の流れについて説明する。以下説明する処理は、ＰＣ１のＣＰＵ１０、およびＳＩＰサーバ２のＣＰＵ２０によって行われる。図１５に示すように、発呼の指示が発呼装置に入力されると、発呼装置は、セッション開始メッセージである呼出要求「ＩＮＶＩＴＥ」を、ＳＩＰサーバ２を介して着呼装置に送信する（Ｓ１５１，Ｓ１５２）。

図１６に、Ｓ１５１，Ｓ１５２で送信される「ＩＮＶＩＴＥ」メッセージの一例を示すＳ１５１，Ｓ１５２で送信される「ＩＮＶＩＴＥ」メッセージには、第一の実施形態における「ＩＮＶＩＴＥ」メッセージ（図７参照）とは異なり、メディア用ポートの番号およびＣＯＤＥＣの情報（メディア用情報）は含まれない。一方で、制御セッション用ポートの番号を示す文字列５１のみが含まれる。従って、ＰＣ１は、ＳＩＰサーバ２を中継するメッセージのデータ量を減少させることができ、ＳＩＰサーバ２にかかる負荷をさらに低下させることができる。また、制御セッション用ポートの番号を示す文字列５１のみを「ＩＮＶＩＴＥ」に含めることで、着呼装置は、発呼装置が即時確立方式に対応していることを文字列５１から把握することができる。

図１５に示すように、着呼装置は、「ＩＮＶＩＴＥ」を受信すると、着信を許可する指示がユーザによって入力されたか否かに関わらず、「ＩＮＶＩＴＥ」に対する応答メッセージ「２００ ＯＫ」を即時に送信する（Ｓ１５３，Ｓ１５４）。「２００ ＯＫ」は、ＳＩＰサーバ２を介して発呼装置に送信される。図１７に、Ｓ１５３，Ｓ１５４で送信される「２００ ＯＫ」メッセージの一例を示す。Ｓ１５３，Ｓ１５４で送信される「２００ ＯＫ」メッセージでは、セッションを確立するための制御メッセージを発呼装置から直接受信するための１つの制御セッション用ポートの番号が、文字列５３に含まれる。なお、第一の実施形態における「２００ ＯＫ」メッセージ（図８参照）とは異なり、第二の実施形態では、メディア用情報を採用しないことを示す情報を含む必要はない。

発呼装置は、ＳＩＰサーバ２を介して「２００ ＯＫ」を受信すると、「２００ ＯＫ」に対する応答メッセージ「ＡＣＫ」を、ＳＩＰサーバ２を介して着呼装置に返信する（Ｓ１５５，Ｓ１５６）。発呼装置は、制御セッション用ポートの番号を「ＩＮＶＩＴＥ」メッセージによって既に着呼装置に通知しているため、「ＡＣＫ」メッセージにポートの番号を含める必要はない。以降のＳ３７〜Ｓ４６の処理は、図６を参照して説明した処理と同じであるため、説明を省略する。

図１８を参照して、第二の実施形態に係るＰＣ１が実行する処理について説明する。第二の実施形態では、前述した第一の実施形態に係る処理と異なるのは、図１８に示す発呼処理、および図１３のＳ１０１に示す判断の方法のみである。従って、第一の実施形態と共通する処理の説明については省略する。図１８に示すように、発呼処理を開始したＣＰＵ１０は、制御セッション用ポートをオープンする（Ｓ１７１）。次いでＣＰＵ１０は、制御セッション用ポートの番号を含む呼出要求メッセージ「ＩＮＶＩＴＥ」を、ＳＩＰサーバ２を介して着呼装置に送信する（Ｓ１７２）。

ＣＰＵ１０は、着呼装置からメッセージを受信したか否かを判断する（Ｓ１７３）。メッセージを受信していなければ（Ｓ１７３：ＮＯ）、Ｓ１７３の判断が繰り返される。メッセージを受信すると（Ｓ１７３：ＹＥＳ）、ＣＰＵ１０は、受信したメッセージが「２００ ＯＫ」であるか否かを判断する（Ｓ１７４）。「２００ ＯＫ」でなければ（Ｓ１７４：ＮＯ）、メッセージは着信拒絶通知メッセージ、またはエラーメッセージである。従って、ＣＰＵ１０は通信を終了し（Ｓ１７５）、処理はメイン処理へ戻る。受信したメッセージが「２００ ＯＫ」であれば（Ｓ１７４：ＹＥＳ）、ＣＰＵ１０は、「２００ ＯＫ」に対する応答メッセージ「ＡＣＫ」を、ＳＩＰサーバ２を介して返信する（Ｓ１７６）。ＣＰＵ１０は、発呼側通話処理を実行し（Ｓ１７７）、処理はメイン処理へ戻る。発呼側通話処理（Ｓ１７７）は、図１２に示した第一の実施形態に係る発呼側通話処理と同じである。

なお、第一の実施形態では、着呼処理（図１３参照）において、相手方のＰＣ１が即時確立方式に対応しているか否かが、付加情報の存否によって判断される（Ｓ１０１）。一方、第二の実施形態のＳ１０１では、ＣＰＵ１０は、ＳＩＰサーバ２を介して受信した「ＩＮＶＩＴＥ」メッセージに制御セッション用ポートの番号が含まれているか否かを判断する。制御セッション用ポートの番号が含まれていなければ、相手方のＰＣ１が即時確立方式に対応していないと判断し（Ｓ１０１：ＮＯ）、「１８０ Ｒｉｎｇｉｎｇ」を送信する（Ｓ１０２）。「ＩＮＶＩＴＥ」に制御セッション用ポートの番号が含まれていれば、即時確立方式に対応していると判断し（Ｓ１０１：ＹＥＳ）、「２００ ＯＫ」を即時に送信する（Ｓ１１５，Ｓ１１６）。

以上説明したように、第二の実施形態のＰＣ１は、１つの制御セッション用ポートの情報のみを、セッション開始メッセージである「ＩＮＶＩＴＥ」に含める。従って、メディア用情報を「ＩＮＶＩＴＥ」に含める場合に比べて、サーバを中継するデータのデータ量をさらに減少させることができる。ＰＣ１は、発呼装置として「ＩＮＶＩＴＥ」を送信する場合、最低限必要なポートを１つだけ開放することになるため、情報が漏洩する可能性も低下させることができる。また、従来のセッション確立方法では、「ＩＮＶＩＴＥ」メッセージにメディア用情報は含まれていたが、制御セッション用ポートの情報は含まれていない。第二の実施形態に係るＰＣ１は、受信した「ＩＮＶＩＴＥ」にメディア用情報が含まれているか否かに応じて、発呼装置が即時確立方式に対応しているか否かを容易且つ的確に判断することができる。なお、第二の実施形態では、図１８のＳ１７２で「ＩＮＶＩＴＥ」を送信するＣＰＵ１０が、本発明の「第一送信手段」として機能する。

本発明は上記実施形態に限定されることはなく、様々な変形が可能であることは言うまでもない。例えば、上記実施形態のＰＣ１は、一部の情報を送受信する際にＳＩＰメッセージを利用している。しかし、本発明は、ＳＩＰメッセージを利用せずに実現することも可能である。

上記実施形態では、着呼装置に着信許可の指示が入力されるか否かに関わらず、「２００ ＯＫ」が即時に発呼装置に送信され、制御セッションが確立される。従って、ＰＣ１は、メディアデータを直接送受信するために必要なメディア用情報を、ＳＩＰサーバ２を介さずに相手方のＰＣ１と直接送受信し、ＳＩＰサーバ２にかかる負荷を低下させることができる。しかし、本発明によると、ＰＣ１は、メディア用情報以外の情報も、ＳＩＰサーバ２を介さずにＰＣ１間で送受信することができる。例えば、ＰＣ１は、映像のフレームレート、解像度等の制御パラメータも、ＳＩＰサーバ２を介さずに送受信することができる。よって、ＳＩＰサーバ２にかかる負荷を大幅に減少させることができる。

上記第一の実施形態のＰＣ１は、着呼装置として動作する場合、「ＩＮＶＩＴＥ」によって通知されたメディア用情報を採用しない旨の情報を「２００ ＯＫ」メッセージに含める（図８の文字列４１、および図１３のＳ１１６参照）。従って、発呼装置は、使用する必要のないメディア用ポートを早急に閉じることができ、セキュリティ性が向上する。しかし、ＰＣ１は、メディア用情報を採用しない旨の情報を「２００ ＯＫ」に含めず、制御セッションの確立後に改めてメディア用ポートを設定してもよい。

上記実施形態のＰＣ１は、発呼装置が即時確立方式に対応しているか否かに応じて異なる処理を行うことができるため（図１３のＳ１０１等参照）、汎用性を有する。しかし、発呼装置が即時確立方式に対応していることが把握できていれば、図１３のＳ１０１〜１１３の処理を行わなくても本発明は実現可能である。

１ ＰＣ
２ ＳＩＰサーバ
１０ ＣＰＵ
１２ ＲＡＭ
１３ ＨＤＤ
１９ 操作部
１００ 通信システム

Claims (8)

1. データの送受信を行うサーバを介して他の通信装置との間でセッションを確立することで、前記他の通信装置との間でＰ２Ｐ通信を行う通信装置であって、
   前記他の通信装置に対してセッションの確立を要求する発呼装置として動作する場合に、前記他の通信装置から制御セッション用のデータを直接受信するためのポートの情報を含むセッション開始メッセージを、前記サーバを介して前記他の通信装置に送信する第一送信手段と、
   前記他の通信装置からセッションの確立を要求される着呼装置として動作する場合に、前記他の通信装置の第一送信手段によって送信されたセッション開始メッセージを前記サーバを介して受信することを契機として、前記他の通信装置から制御セッション用のデータを直接受信するためのポートの情報を含む応答メッセージを、前記サーバを介して前記他の通信装置に送信する第二送信手段と、
   前記サーバを介して前記他の通信装置から受信したセッション開始メッセージまたは応答メッセージ内の情報によって特定される制御セッション用のポートへ制御メッセージを送信することで、前記他の通信装置との間でセッションを確立するセッション確立手段と、
   前記着呼装置として動作する場合に、前記他の通信装置からの着信を許可する旨のユーザの指示を受け付ける指示受付手段と、
   前記セッション確立手段によってセッションが確立された後に、前記指示受付手段によって前記指示が受け付けられることを契機として、前記他の通信装置との間のメディアデータの送受信を開始する開始手段と
   を備えたことを特徴とする通信装置。
2. 前記第二送信手段は、セッションを確立するための前記制御メッセージを前記他の通信装置から直接受信するための１つのポートの情報を、送信する前記応答メッセージに含めることを特徴とする請求項１に記載の通信装置。
3. 前記第一送信手段は、セッションを確立するための前記制御メッセージを前記他の通信装置から直接受信するための１つのポートの情報を、送信する前記セッション開始メッセージに含めることを特徴とする請求項１または２に記載の通信装置。
4. 前記着呼装置として動作する場合に、前記他の通信装置の第一送信手段によって送信されたセッション開始メッセージを前記サーバから受信することを契機として、受信した前記セッション開始メッセージに対する暫定応答メッセージを、前記サーバを介して前記他の通信装置に送信する第三送信手段と、
   前記他の通信装置の第一送信手段によって送信されたセッション開始メッセージを前記サーバを介して受信した場合に、受信した前記セッション開始メッセージに含まれる情報に基づいて、前記第二送信手段による応答メッセージの送信、および前記第三送信手段による暫定応答メッセージの送信のいずれを実行するかを決定する決定手段とをさらに備え、
   前記第二送信手段および前記第三送信手段は、前記決定手段によって応答メッセージおよび暫定応答メッセージのいずれかを送信することが決定された場合にのみ、決定された応答メッセージまたは暫定応答メッセージを送信することを特徴とする請求項１から３のいずれかに記載の通信装置。
5. 前記決定手段は、
   前記制御メッセージを前記他の通信装置が直接受信するための１つのポートの情報が、前記サーバを介して受信した前記セッション開始メッセージに含まれていれば、前記第二送信手段によって応答メッセージを送信することを決定し、
   前記サーバを介して受信した前記セッション開始メッセージに前記１つのポートの情報が含まれていなければ、前記第三送信手段によって暫定応答メッセージを送信することを決定することを特徴とする請求項４に記載の通信装置。
6. 前記第二送信手段は、前記サーバを介して受信した前記セッション開始メッセージに、前記他の通信装置がメディアデータを受信するポートであるメディア用ポートの情報が含まれている場合に、前記メディア用ポートにメディアデータを送信しないことを示す情報を前記応答メッセージに含めることを特徴とする請求項１から５のいずれかに記載の通信装置。
7. データの送受信を行うサーバを介して他の通信装置との間でセッションを確立することで、前記他の通信装置との間でＰ２Ｐ通信を行う通信装置によって行われる通信方法であって、
   前記他の通信装置に対してセッションの確立を要求する発呼装置として前記通信装置が動作する場合に、前記他の通信装置から制御セッション用のデータを直接受信するためのポートの情報を含むセッション開始メッセージを、前記サーバを介して前記他の通信装置に送信する第一送信ステップと、
   前記他の通信装置からセッションの確立を要求される着呼装置として前記通信装置が動作する場合に、前記他の通信装置が実行した第一送信ステップにおいて送信されたセッション開始メッセージを前記サーバを介して受信することを契機として、前記他の通信装置から制御セッション用のデータを直接受信するためのポートの情報を含む応答メッセージを、前記サーバを介して前記他の通信装置に送信する第二送信ステップと、
   前記サーバを介して前記他の通信装置から受信したセッション開始メッセージまたは応答メッセージ内の情報によって特定される制御セッション用のポートへ制御メッセージを送信することで、前記他の通信装置との間でセッションを確立するセッション確立ステップと、
   前記通信装置が前記着呼装置として動作する場合に、前記他の通信装置からの着信を許可する旨のユーザの指示を受け付ける指示受付ステップと、
   前記セッション確立ステップにおいてセッションが確立された後に、前記指示受付ステップにおいて前記指示が受け付けられることを契機として、前記他の通信装置との間のメディアデータの送受信を開始する開始ステップと
   を備えたことを特徴とする通信方法。
8. データの送受信を行うサーバを介して他の通信装置との間でセッションを確立することで、前記他の通信装置との間でＰ２Ｐ通信を行う通信装置によって実行される通信プログラムであって、
   前記他の通信装置に対してセッションの確立を要求する発呼装置として前記通信装置が動作する場合に、前記他の通信装置から制御セッション用のデータを直接受信するためのポートの情報を含むセッション開始メッセージを、前記サーバを介して前記他の通信装置に送信する第一送信ステップと、
   前記他の通信装置からセッションの確立を要求される着呼装置として前記通信装置が動作する場合に、前記他の通信装置が実行した第一送信ステップにおいて送信されたセッション開始メッセージを前記サーバを介して受信することを契機として、前記他の通信装置から制御セッション用のデータを直接受信するためのポートの情報を含む応答メッセージを、前記サーバを介して前記他の通信装置に送信する第二送信ステップと、
   前記サーバを介して前記他の通信装置から受信したセッション開始メッセージまたは応答メッセージ内の情報によって特定される制御セッション用のポートへ制御メッセージを送信することで、前記他の通信装置との間でセッションを確立するセッション確立ステップと、
   前記通信装置が前記着呼装置として動作する場合に、前記他の通信装置からの着信を許可する旨のユーザの指示を受け付ける指示受付ステップと、
   前記セッション確立ステップにおいてセッションが確立された後に、前記指示受付ステップにおいて前記指示が受け付けられることを契機として、前記他の通信装置との間のメディアデータの送受信を開始する開始ステップと
   を前記通信装置のコントローラに実行させるための指示を含む通信プログラム。

Images