(57)【要約】【課題】端末とサーバとのセッション形成プロトコルを、端末のサーバへの再登録手続きを要さずに切り替え可能にすること。【解決手段】ＵＤＰによるセッションの形成後も、ＩＰＴ−ａ１からＳＩＰサーバ１０に対して、ＴＣＰによるセッションの形成を定期的にリクエストする。ＳＩＰサーバ１０はＴＣＰ接続の空きリソースを監視し、空きが生じればリクエストにＯＫメッセージを返送する。これに応じてＩＰＴ−ａ１はＳＩＰサーバ１０にＴＣＰへの切替を要求し、これ以降、ＳＩＰサーバ１０とＩＰＴ−ａ１との間で、ＳＩＰメッセージをＵＤＰからＴＣＰに載せ替えてＳＩＰ接続を継続する。【選択図】  図６
2010220112.tif 000002
【特許請求の範囲】
【請求項１】
シグナリングプロトコルを処理可能な複数の端末デバイスと、前記シグナリングプロトコルの下位層プロトコルである第１または第２転送プロトコルにより各端末デバイスとの間にセッションを形成するサーバとを具備し、
前記端末デバイスは、
前記第１転送プロトコルによるセッション形成を前記サーバにリクエストするリクエスト手段を備え、
前記サーバは、
前記リクエストへの許否を判定する判定手段と、
リクエスト元の端末デバイスとのセッションを、前記判定手段に許可されれば前記第１転送プロトコルにより形成し、そうでなければ前記第２転送プロトコルにより形成するセッション形成手段と、
前記第２転送プロトコルによりセッションを形成済みの端末デバイスからのリクエストが前記判定手段から許可されれば、この端末デバイスとの間に形成済みのセッションの下位層プロトコルを前記第２転送プロトコルから前記第１転送プロトコルに切り替える切替手段とを備えることを特徴とする電話システム。
【請求項２】
前記判定手段は、規定のリソースを超えるセッションの形成を要求するリクエストを拒否することを特徴とする請求項１に記載の電話システム。
【請求項３】
前記サーバ装置は、さらに、端末デバイスごとに前記第１転送プロトコルによるセッション形成の優先度を割り当てた管理テーブルを備え、
前記切替手段は、リクエスト元の端末デバイスよりも前記優先度の低い端末デバイスとの間に形成済みのセッションの下位層プロトコルを前記第１転送プロトコルから前記第２転送プロトコルに変更し、
前記判定手段は、前記下位層プロトコルの変更によりリソースが確保されれば当該リクエスト元の端末デバイスからのリクエストを許可することを特徴とする請求項２に記載の電話システム。
【請求項４】
前記リクエスト手段は、前記セッションが前記第２転送プロトコルにより形成された状態で、前記第１転送プロトコルによるセッション形成を継続的にリクエストすることを特徴とする請求項１に記載の電話システム。
【請求項５】
前記端末デバイスは、さらに、前記第１転送プロトコルにより形成されたセッションを介して秘匿通信を行う通信秘匿手段を備えることを特徴とする請求項１に記載の電話システム。
【請求項６】
前記端末デバイスは、さらに、前記秘匿通信を実施可能な旨をユーザに報知する報知手段を備えることを特徴とする請求項５に記載の電話システム。
【請求項７】
前記第１転送プロトコルはＴＣＰ（Transmission Control Protocol）であり、前記第２転送プロトコルはＵＤＰ（User Datagram Protocol）であることを特徴とする請求項１に記載の電話システム。
【請求項８】
シグナリングプロトコルを処理可能な端末デバイスとの間に、前記シグナリングプロトコルの下位層プロトコルである第１または第２転送プロトコルによりセッションを形成するサーバにおいて、
前記端末デバイスからの、前記第１転送プロトコルによるセッション形成のリクエストへの許否を判定する判定手段と、
リクエスト元の端末デバイスとのセッションを、前記判定手段に許可されれば前記第１転送プロトコルにより形成し、そうでなければ前記第２転送プロトコルにより形成するセッション形成手段と、
前記第２転送プロトコルによりセッションを形成済みの端末デバイスからのリクエストが前記判定手段から許可されれば、この端末デバイスとの間に形成済みのセッションの下位層プロトコルを前記第２転送プロトコルから前記第１転送プロトコルに切り替える切替手段とを具備するサーバ。
【請求項９】
前記判定手段は、規定のリソースを超えるセッションの形成を要求するリクエストを拒否することを特徴とする請求項８に記載のサーバ。
【請求項１０】
さらに、端末デバイスごとに前記第１転送プロトコルによるセッション形成の優先度を割り当てた管理テーブルを備え、
前記切替手段は、リクエスト元の端末デバイスよりも前記優先度の低い端末デバイスとの間に形成済みのセッションの下位層プロトコルを前記第１転送プロトコルから前記第２転送プロトコルに変更し、
前記判定手段は、前記下位層プロトコルの変更によりリソースが確保されれば当該リクエスト元の端末デバイスからのリクエストを許可することを特徴とする請求項９に記載のサーバ。
【請求項１１】
シグナリングプロトコルの下位層プロトコルである第１または第２転送プロトコルによりセッションを形成するサーバに、前記第１転送プロトコルによるセッション形成をリクエストするリクエスト手段と、
前記サーバとの間のセッションが前記第２転送プロトコルにより形成された状態で、前記第１転送プロトコルによるセッション形成を継続的にリクエストする手段とを具備することを特徴とする端末デバイス。
【請求項１２】
さらに、前記第１転送プロトコルにより形成されたセッションを介して秘匿通信を行う通信秘匿手段を備えることを特徴とする請求項１１に記載の端末デバイス。
【請求項１３】
さらに、前記秘匿通信を実施可能な旨をユーザに報知する報知手段を備えることを特徴とする請求項１２に記載の端末デバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、ＩＰ（Internet Protocol）ネットワークを利用して、例えばＳＩＰ（Session Initiation Protocol）やＭｅｇａｃｏ（Media Gateway Control）などのシグナリングプロトコルを用いて音声通話の可能な電話システムに関する。特にこの発明は、サーバとのセッションをＴＣＰ（Transmission Control Protocol）またはＵＤＰ（User Datagram Protocol）を用いて形成するシステムの改良に関する。
【背景技術】
【０００２】
ＩＰネットワークを介して音声パケットを伝送する電話システムが近年、注目されている。代表的なＳＩＰ電話システムを例にとり技術的背景を説明する。ＳＩＰ電話システムには、電話端末（以下、ＩＰ端末）のアドレスや内線番号などを管理するためのサーバ（ＳＩＰサーバ）が設けられる。各ＩＰ端末はＳＩＰサーバとのセッションをＵＤＰまたはＴＣＰにより形成するが、いずれのプロトコルを用いるかは端末のサーバへの登録時に固定的に決められてしまう。つまりＵＤＰによる接続からＴＣＰによる接続へ、あるいはその逆へと切り替えるには端末の再登録手順を要し、登録の解除に伴って接続が切り離されてしまう。
【０００３】
ＴＣＰはＵＤＰに比べシステムへの負荷が高いことからＴＣＰ接続によるセッションには限度数が設けられ、限度数を超えるセッションはＵＤＰ接続で形成される。しかしＴＣＰならではのサービスもあり、例えばＴＬＳ（Transport Layer Security）などの暗号化プロトコルはＵＤＰでは利用することができない。よってＵＤＰ接続された端末から暗号化通信を行うには、接続を解除したのちＴＣＰセッションの空きを待ち、再接続するという手順を要する。通話中であれば切断を余儀なくされるため何らかの対処が望まれる。
【０００４】
関連する技術が特許文献１〜３に開示される。特許文献１にはインターネットを利用する電話システムにおいてネットワークに余裕があればＵＤＰを用いるが、混雑してくればＴＣＰを利用して音声の途切れを防止するという技術が開示される。これは音声パケットの伝送にＴＣＰまたはＵＤＰを用いるという技術であり、端末のサーバへの登録にそのまま適用することはできない。
【０００５】
特許文献２には、パケット遅延を検出し、遅延が大きければＵＤＰで通信し、遅延が小さければＴＣＰで通信するというネットワークファクシミリ装置が開示される。特許文献３には、サーバからメディアデータを転送する方法において、クライアント側の受信バッファの占有状況に応じてＴＣＰとＵＤＰとを切り替えるという技術が開示される。いずれの技術も特許文献１と同様、端末をサーバに登録するに際して適用可能な技術ではない。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００１−２９８４７９号広報
【特許文献２】特開２００４−３２０３９号広報
【特許文献３】特開２００２−２８１１０３号広報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
以上述べたように既存の電話システムにおいては、ＩＰ端末をサーバに登録するにあたりセッション形成のためのプロトコルが固定的に決められてしまう。よってプロトコルを切り替えるには登録を解除したのち再登録することが必要であり、通話が切断されるなどの不具合がある。加えて、暗号化通信を手軽に行えないなどの不具合もあり、何らかの対処が望まれている。
【０００８】
この発明は上記事情によりなされたもので、その目的は、再登録を要さずに端末とサーバとのセッション形成プロトコルを切り替え可能な電話システム、サーバおよび端末デバイスを提供することにある。
【課題を解決するための手段】
【０００９】
上記目的を達成するためにこの発明の一態様によれば、シグナリングプロトコル（例えばＳＩＰ）を処理可能な複数の端末デバイス（例えばＩＰ端末）と、前記シグナリングプロトコルの下位層プロトコルである第１または第２転送プロトコル（例えばＴＣＰまたはＵＤＰ）により各端末デバイスとの間にセッションを形成するサーバ（例えばＳＩＰサーバ）とを具備する電話システムが提供される。
【００１０】
この電話システムの特徴的な点は、例えばＩＰ端末が、ＴＣＰによるセッション形成をＳＩＰサーバにリクエストするリクエスト手段を備える点、および、ＳＩＰサーバが、リクエストへの許否を判定する判定手段と、この判定手段に許可されればリクエスト元のＩＰ端末とのセッションをＴＣＰにより形成し、拒否されればＵＤＰにより形成するセッション形成手段と、ＵＤＰによりセッションを形成済みのＩＰ端末からのリクエストが判定手段に許可されれば、このＩＰ端末との間に形成済みのセッションの下位層プロトコルをＵＤＰからＴＣＰに切り替える切替手段とを備える点にある。
【００１１】
このような手段を講じることにより、一旦、ＵＤＰによりセッションが形成されたとしても、ＴＣＰへの接続要求がＩＰ端末からＳＩＰサーバにバックグラウンドで送出されるようになる。例えばＴＣＰ接続のためのリソースに空きが生じればリクエストが直ちに許可され、ＵＤＰで接続されていたＩＰ端末はＴＣＰにより再接続される。ＴＣＰ／ＵＤＰのいずれもＳＩＰの下位層プロトコルとして機能するので、ＳＩＰによるセッションを保ったまま相互に切り替えることができる。従って、再登録手順を実施することなく、ＩＰ端末とＳＩＰサーバとの下位層プロトコル（ＴＣＰ／ＵＤＰ）を切り替えることが可能になる。
【発明の効果】
【００１２】
この発明によれば、再登録を要さずに端末とサーバとのセッション形成プロトコルを切り替え可能な電話システム、サーバおよび端末デバイスを提供することができる。
【図面の簡単な説明】
【００１３】
【図１】この発明に係わる電話システムの実施の形態を示すシステム図。
【図２】図１のＳＩＰサーバ１０の実施の形態を示す機能ブロック図。
【図３】図２の管理テーブル１４ａの一例を示す図。
【図４】図１のＩＰ端末（ＩＰＴ）ａ１〜ａｎ、ｂ１〜ｂｍの実施の形態を示す機能ブロック図。
【図５】この実施形態における下位層プロトコルの切替手順の一例を示す模式図。
【図６】下位層プロトコルの切替手順の第１の実施形態を示すシーケンス図。
【図７】下位層プロトコルの切替手順の第２の実施形態を示すシーケンス図。
【図８】下位層プロトコルの切替手順の第３の実施形態を示すシーケンス図。
【発明を実施するための形態】
【００１４】
図１は、この発明に係わる電話システムの実施の形態を示すシステム図である。このシステムはＬＡＮ（Local Area Network）に接続される複数のＩＰ端末（ＩＰＴ）ａ１〜ａｎと、これらのＩＰ端末ａ１〜ａｎとの間に個別にセッションを形成するＳＩＰサーバ１０とを備える。各ＩＰ端末はシグナリングプロトコルとしてのＳＩＰを処理する機能を備え、ＳＩＰサーバ１０との間でＳＩＰメッセージを授受して呼接続制御シーケンスを実行する。このシーケンスを経て通信リンクが形成されると、ＩＰ端末はＬＡＮを介して相互に音声パケットを授受して音声通話を実現する。
【００１５】
ＳＩＰサーバ１０はＩＰ端末からのリクエストに応じて、ＴＣＰまたはＵＤＰによりＬＡＮ上にセッションを形成する。すなわちＳＩＰサーバ１０は、ＴＣＰによるＳＩＰ接続に加え、ＵＤＰによるＳＩＰ接続もサポートする。ＴＣＰおよびＵＤＰのいずれもＳＩＰの下位層プロトコルとして機能する。またＳＩＰサーバ１０は、各ＩＰ端末ａ１〜ａｎに対する呼制御、データ設定、障害検出などの保守運用制御も行う。さらに、ＬＡＮにはルータ２０を介してＩＰ端末ｂ１〜ｂｍも接続される。ＳＩＰサーバ１０はＩＰ端末ａ１〜ａｎ，ｂ１〜ｂｍを統合的に制御する。
【００１６】
図２は、図１のＳＩＰサーバ１０の実施の形態を示す機能ブロック図である。ＳＩＰサーバ１０は、インタフェース部１１、表示部１２、入出力部１３、データベース部１４、および、主制御部１５を備える。インタフェース部１１はＬＡＮに接続されてパケットの授受に関する処理を担う。表示部１２は入出力部１３とともにユーザインタフェースを提供し、ＧＵＩ（Graphical User Interface）環境を構築する。データベース部１４はハードディスクドライブなどのストレージデバイスであり、管理テーブル１４ａを記憶する。
【００１７】
図３は管理テーブル１４ａの一例を示す図である。管理テーブル１４ａは、ＩＰ端末のそれぞれごとに、ＴＣＰ接続によるセッション形成の優先度を割り当てたテーブルである。つまり管理テーブル１４ａは、ＩＰ端末を識別するための内線番号ごとに、ＴＣＰ接続によるセッション形成の優先度を［高］または［低］のいずれかに対応付けたテーブルである。なおこの管理テーブル１４ａには、例えば内線番号ごとに対応付けられるユーザ名、およびＩＰ端末のＩＰアドレスなどを併せて管理するようにしてもよい。
【００１８】
図２に戻り、主制御部１５は、その処理機能として判定処理部１５ａ、セッション制御部１５ｂ、および切替処理部１５ｃを備える。判定処理部１５ａは、ＴＣＰによるセッション形成のリクエストをＩＰ端末から受けると、その許可、または拒否のいずれかを判定する。その判定基準は例えばＳＩＰサーバ１０の処理リソースである。つまりＴＣＰはＵＤＰに比べ多くの処理リソースを要するので、ＴＣＰ接続のセッションの数には限りがある。例えば同時に形成可能なセッション数の上限を１００とすれば、既に１００のセッションが形成されている状態で新たなリクエストを受けると、判定処理部１５ａはそのリクエストの拒否を判定する  
セッション制御部１５ｂは、判定処理部１５ａにより許可されれば、リクエスト元のＩＰ端末とのセッションをＴＣＰ接続のもとで形成する。逆に、判定処理部１５ａにより拒否されれば、リクエスト元のＩＰ端末とのセッションをＵＤＰ接続のもとで形成する。
【００１９】
切替処理部１５ｃは、セッションをＵＤＰ接続のもとで形成済みのＩＰ端末から継続的に送出されるリクエストに対し、リソースに空きが生じたなどの理由で判定処理部１５ａからの許可が与えられれば、セッション形成のための下位層プロトコルをＵＤＰからＴＣＰに切り替える。上位層プロトコルであるＳＩＰはこの切替を関知しない。
【００２０】
図３は、図１のＩＰ端末（ＩＰＴ）ａ１〜ａｎ、ｂ１〜ｂｍの実施の形態を示す機能ブロック図である。ＩＰ端末は、ＬＡＮケーブル６０を介してＬＡＮに接続されるインタフェース（Ｉ／Ｆ）部４１と、表示器４０と、制御部４２と、キーパッド部４３と、メモリ４４とを備える。このうち表示器４０はＬＣＤ（Liquid Crystal Display）であり、種々のメッセージを視覚的に表示する。キーパッド部４３はソフトキーや数字キーなどを備え、ユーザの入力操作を受け付ける。メモリ４４は例えばフラッシュメモリなどの、書き換え可能な半導体記憶デバイスである。
【００２１】
制御部４２はこの発明に関わる処理機能として、リクエスト処理部４２ａ、ＴＬＳ処理部４２ｂ、および、表示制御部４２ｃを備える。リクエスト処理部４２ａは、ＴＣＰによるセッション形成をＳＩＰサーバ１０にリクエストする。このリクエストは例えば起動時、あるいはユーザのログイン操作時にＳＩＰサーバ１０に送信されるＲｅｇｉｓｔｅｒメッセージ、または発呼時にＳＩＰサーバ１０に送信されるＩＮＶＩＴＥメッセージの規定のフィールドにテキストで付記される。
【００２２】
特にこの実施形態では、リクエスト処理部４２ａは、ＳＩＰサーバ１０とのセッションがＵＤＰにより形成された状態であっても、つまりリクエストを拒否されたケースでも、ＴＣＰによるセッションの形成を要求するリクエストを継続的にＳＩＰサーバ１０に送出する。
【００２３】
ＴＬＳ処理部４２ｂは、ＳＩＰサーバ１０との間にＴＣＰによるセッションの形成が成功すると、このセッションを介してＴＬＳによる秘匿通信（暗号化通信）を実施するための制御を行う。ＴＬＳによる暗号化通信が可能になれば、表示制御部４２ｃはそのことを表示器４０に表示してユーザに報知する。
【００２４】
図５は、この実施形態における下位層プロトコルの切替手順の一例を示す模式図である。この実施形態ではＴＣＰ接続でのセッションの数を最大で１００とする。つまりＴＣＰでＳＩＰサーバ１０に接続可能なＩＰ端末の数は、主に処理負荷の軽減を図るために、最大で１００台であるとする。図５（ａ）のステップ（１）は、最大数のＴＣＰセッションが形成されている状態からさらにＴＣＰ接続のリクエストがＩＰＴ−ａ１から与えられたことを示す。新たにＴＣＰ接続を試みたＩＰＴ−ａ１はＴＣＰ接続が不可なので、ステップ（２）でＵＤＰによるＳＩＰサーバ１０への接続を行う。ＵＤＰには、接続の制限する上限の数は無い。ＵＤＰによる接続後も、ＩＰＴ−ａ１はＴＣＰ接続のリクエストを継続してＳＩＰサーバ１０に送出する。
【００２５】
この状態から例えばいずれかのＩＰ端末がログアウトし、ＴＣＰ接続に空きが生じたとする。そうするとＳＩＰサーバ１０はＴＣＰ接続をＩＰＴ−ａ１に許可する。これを受けてＩＰＴ−ａ１はステップ（３）でＳＩＰサーバ１０にＴＣＰ接続を行い、その後、ＳＩＰパケットをＴＣＰで送信する。すなわちＩＰＴ−ａ１はＴＣＰに切り替わることをＳＩＰサーバ１０に通知し、ステップ（４）でＵＤＰポートをクローズする。その後ＳＩＰサーバ１０は、ステップ（５）で、ＵＤＰで受信したパケットをＴＣＰから継続して受信するように切り替える。ＳＩＰはアプリケーション層でのプロトコルであるので、その下位層であるＴＣＰ／ＵＤＰの切替には関知しない。次に、上記構成における作用を第１〜第３の実施形態に分けて説明する。
【００２６】
［第１の実施形態］
図６は、下位層プロトコルの切替手順の第１の実施形態を示すシーケンス図である。図６において、ＩＰＴ−ａ１はＴＣＰのＳＹＮパケットによりＴＣＰ接続リクエストをＳＩＰサーバ１０に送出する。ＴＣＰ接続のためのリソースが既になければ、ＳＩＰサーバ１０はＲＳＴパケットによりＮＧ応答を返送する。これを受けたＩＰＴ−ａ１はＵＤＰによるＳＩＰ接続をＳＩＰサーバ１０に要求し、ＳＩＰ Ｒｅｇｉｓｔｅｒ ＯＫメッセージの返信を受ける。これによりＵＤＰによるＳＩＰ接続が形成され、ＳＩＰによる呼接続処理が可能となる。ただしＵＤＰ接続であるので、ＴＬＳなどのセキュアな接続はできない。
【００２７】
ＵＤＰによるＳＩＰ接続後も、ＩＰＴ−ａ１はＳＩＰサーバ１０に継続的に、例えば数秒〜数１０秒間隔でＴＣＰ接続リクエストを送出する。  
他のＩＰ端末のＵｎ−ＲｅｇｉｓｔｅｒなどによりＴＣＰ接続リソースに空きが生じると、ＴＣＰ接続リクエストに対する接続ＯＫメッセージ（ＳＹＮ ＡＣＫ）がＳＩＰサーバ１０からＩＰＴ−ａ１に返信される。これを受けたＩＰＴ−ａ１は、確認応答であるＴＣＰ接続（ＡＣＫ）メッセージをＳＩＰサーバ１０に返送する。ここまでの手順によりＴＣＰリンクが確立される。次いでＩＰＴ−ａ１はＴＣＰへの切り替え要求をＳＩＰサーバ１０に送信する。その後、切り替えＯＫメッセージがＳＩＰサーバ１０からＩＰＴ−ａ１に返信されると、ＩＰＴ−ａ１とＳＩＰサーバ１０とのセッションは、ＵＤＰによるＳＩＰ接続からＴＣＰによるＳＩＰ接続へと切り替わる。ＴＣＰへの切り替え後、ＩＰＴ−ａ１は使用しなくなったＵＤＰポートをＣｌｏｓｅし、これ以降は、ＵＤＰに載せられていたＳＩＰメッセージはＴＣＰに載せかえられ、ＳＩＰサーバ１０とＩＰＴ−ａ１との間でのＳＩＰ接続が継続される。  
ＩＰＴ−ａ１からのＴＣＰへの切り替え要求メッセージは、例えばＳＩＰメッセージのＯＰＴＩＯＮフィールド、あるいはＢＯＤＹ部分に記載するかたちで実現できる。これはＳＩＰサーバ１０からの切り替えＯＫメッセージも同様である。
【００２８】
このように第１の実施形態では、ＵＤＰによるセッションの形成後も、ＩＰＴ−ａ１からＳＩＰサーバ１０に対して、ＴＣＰによるセッションの形成を定期的にリクエストする。ＳＩＰサーバ１０はＴＣＰ接続の空きリソースを監視し、空きが生じればリクエストにＯＫメッセージを返送する。これに応じてＩＰＴ−ａ１はＳＩＰサーバ１０にＴＣＰへの切替を要求し、これ以降、ＳＩＰサーバ１０とＩＰＴ−ａ１との間で、ＳＩＰメッセージをＵＤＰからＴＣＰに載せ替えてＳＩＰ接続を継続するようにしている。
【００２９】
ＳＩＰはＵＤＰ、ＴＣＰのいずれとも異なる上位層でのアプリケーションであるので、下位層プロトコルに何を用いるかに関係なく機能することが可能である。従ってＵＤＰでＳＩＰ接続したＩＰ端末を、ＳＩＰ登録を解除することなしにＴＣＰに変更することができる。これにより、ＵＤＰで通話中であっても、通話を切断することなくＴＣＰへの切替を行うことが可能である。また、ＴＣＰ接続数の制限により利用できなかったＴＬＳなどの暗号プロトコルを、ＴＣＰ接続のもとで利用することが可能になる。
【００３０】
［第２の実施形態］
図７は、下位層プロトコルの切替手順の第２の実施形態を示すシーケンス図である。第２の実施形態では、ＩＰ端末ごとに割り当てられた優先度に従ってＴＣＰまたはＵＤＰによるセッションを形成する手順を説明する。図７において、ＩＰＴ−ａ１の内線番号（ＤＮ）を３０００とし、ＩＰＴ−ａ２の内線番号を３００１とする。図３の管理テーブルによれば、ＩＰＴ−ａ１の優先度は［高］、ＩＰＴ−ａ２の優先度は［低］である。
【００３１】
まず、ＳＩＰサーバ１０にＴＣＰ接続の空きリソースが無い状態で、ＩＰＴ−ａ２とＳＩＰサーバ１０との間にＴＣＰによるＳＩＰ接続セッションが形成されているとする。この状態から、ＴＣＰによるＳＩＰ接続リクエストがＩＰＴ−ａ１から送出されたとする。ＳＩＰサーバ１０はＴＣＰ接続リソースが残っていないので、一旦はＩＰＴ−ａ１に対してＵＤＰによるＳＩＰ接続を行う。
【００３２】
次にＳＩＰサーバ１０は、管理テーブル１４ａを参照し、セッションを形成したＩＰ端末の優先度をチェックする（ブロックＢ１）。そうすると、優先度の低いＩＰＴ−ａ２がＴＣＰで接続され、優先度の高いＩＰＴ−ａ１がＵＤＰで接続されていることが検出される（ブロックＢ２）。
【００３３】
そこでＳＩＰサーバ１０はＵＤＰへの切り替えをＩＰＴ−ａ２に指示し、ＩＰＴ−ａ２のＳＩＰ接続をＵＤＰに切り替える。これ以降はＩＰＴ−ａ２とＳＩＰサーバ１０とのＳＩＰ接続セッションはＵＤＰ上で継続される。これによりＴＣＰの接続リソースに空きができるので、ＳＩＰサーバ１０はＩＰＴ−ａ１からのＴＣＰ接続要求に接続ＯＫメッセージを返信する。以下、図６と同様の手順を経て、ＳＩＰサーバ１０とＩＰＴ−ａ１との間のＳＩＰ接続セッションは、ＵＤＰからＴＣＰに切り替えられる（ブロックＢ３）。
【００３４】
第２の実施形態では、ＩＰ端末にＴＣＰ接続の優先度を設け、その優先度に従ってＵＤＰ接続端末とＴＣＰ接続端末とを入れ替えるようにしている。すなわち、低優先度のＩＰ端末のＴＣＰコネクションを強制的に解除してリソースの空きを確保し、高優先度のＩＰ端末とＳＩＰサーバ１０との間のＳＩＰセッションをＴＣＰに形成できるようにしている。ＴＣＰによれば、ＴＬＳなどの暗号化プロトコルを利用することが可能になる。第２の実施形態によれば暗号化を必要としないＩＰ端末の優先度を低くし、暗号化を必要とするＩＰ端末の優先度を高くすることでＴＣＰ接続とＵＤＰ接続とを効率的に配分することが可能でき、リソースを有効活用できるメリットを得られる。
【００３５】
［第３の実施形態］
図８は、下位層プロトコルの切替手順の第３の実施形態を示すシーケンス図である。この実施形態では暗号化プロトコルとしてのＴＬＳを例にとり、その使用／未使用を基準としてＩＰ端末のＵＤＰ接続／ＴＣＰ接続を入れ替える手順を説明する。図８において、ＩＰＴ−ａ１はＴＬＳを使用する端末であり、ＩＰＴ−ａ２はＴＬＳを使用しない端末であるとする。ＴＬＳは、例えば特番入力や、ＩＰ端末のキーパッド部４３に備わる暗号化ファンクションキーの押下などにより使用することができる。
【００３６】
まず、ＳＩＰサーバ１０にＴＣＰ接続の空きリソースが無い状態で、ＩＰＴ−ａ２とＳＩＰサーバ１０との間にＴＣＰによるＳＩＰ接続セッションが形成されているとする。ただし、ＩＰＴ−ａ２はＴＬＳを使用していない（未使用）。この状態から、ＴＣＰによるＳＩＰ接続リクエストがＩＰＴ−ａ１から送出されたとする。ＳＩＰサーバ１０はＴＣＰ接続リソースが残っていないので、一旦はＩＰＴ−ａ１に対してＵＤＰによるＳＩＰ接続を行う。
【００３７】
この状態では、ＩＰＴ−ａ１においてＴＬＳは未だ使用されていない（未使用）。そこでＩＰＴ−ａ１の表示制御部４２ｃは、表示器４０（ＬＣＤ）に［ＴＬＳ未使用］のメッセージを表示し、ユーザに報知する。これにより、暗号化されていない状態で秘匿すべき情報を通話することを防止できる。
【００３８】
次にＳＩＰサーバ１０は、ＴＬＳの使用または未使用を、ＳＩＰ接続されたセッションごとに判定する（ブロックＢ１０）。そうすると、ＴＬＳを使用しないＩＰＴ−ａ２がＴＣＰで接続され、ＴＬＳを使用するＩＰＴ−ａ１がＵＤＰで接続されていることが検出される（ブロックＢ２０）。
【００３９】
そこでＳＩＰサーバ１０はＵＤＰへの切り替えをＩＰＴ−ａ２に指示し、ＩＰＴ−ａ２のＳＩＰ接続をＵＤＰに切り替える。これ以降はＩＰＴ−ａ２とＳＩＰサーバ１０とのＳＩＰ接続セッションはＵＤＰ上で継続される。これによりＴＣＰの接続リソースに空きができるので、ＳＩＰサーバ１０はＩＰＴ−ａ１からのＴＣＰ接続要求に接続ＯＫメッセージを返信する。以下、図６と同様の手順を経て、ＳＩＰサーバ１０とＩＰＴ−ａ１との間のＳＩＰ接続セッションは、ＵＤＰからＴＣＰに切り替えられる（ブロックＢ３０）。以上の手順により、ＩＰＴ−ａ１はＴＬＳを使用したＴＣＰによるＳＩＰ接続が可能となる。この状態になれば、ＩＰＴ−ａ１の表示制御部４２ｃは、表示器４０（ＬＣＤ）に［ＴＬＳ使用］のメッセージを表する。これによりユーザは、秘匿すべき情報（音声、データファイルを含む）を安心して送信することができる。
【００４０】
第３の実施形態では、ＴＬＳを使用するＩＰ端末と、使用しないＩＰ端末とを区別し、ＴＬＳを使用するＩＰ端末がＴＣＰ接続できなければ、ＴＬＳを使用しないＩＰ端末をＴＣＰ接続からＵＤＰ接続に変更する。このようにしてＴＣＰ接続リソースを確保し、ＴＬＳを使用するＩＰ端末がＴＣＰで接続できるようにしている。
【００４１】
既存のシステムではＳＩＰサーバのＴＣＰセッション数に空きが無ければＴＬＳを利用できず、ＳＲＴＰなどのセキュアな通話を行うための暗号化用の鍵交換パケットを暗号化することができないことから、安全なＳＲＴＰ通話を実現することができず、ユーザは盗聴の危険を意識しながら会話せざるを得なかった。これに対し第３の実施形態によれば、要求すれば、たとえ通話中であっても即座に、かつ確実に暗号化通信を行えるようになり、ユーザの心配を解消することが可能になる。
【００４２】
なお、この発明は上記実施の形態に限定されるものではない。例えば上記実施形態ではシグナリングプロトコルとしてＳＩＰを採り上げたが、これに限らず、Ｈ．３２３、あるいはＭｅｇａｃｏなどの他のプロトコルであっても良い。また、秘匿通信プロトコルもＴＬＳに限らず、ＳＲＴＰ（Secure RTP）などの、他の暗号化プロトコルを用いることができる。
【００４３】
さらに、この発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
【符号の説明】
【００４４】
ａ１〜ａｎ，ｂ１〜ｂｍ…ＩＰ端末（ＩＰＴ）、１０…ＳＩＰサーバ、１１…インタフェース部、１２…表示部、１３…入出力部、１４…データベース部、１４ａ…管理テーブル、１５…主制御部、１５ａ…判定処理部、１５ｂ…セッション制御部、１５ｃ…切替処理部、２０…ルータ、４０…表示器、４１…インタフェース部、４２…制御部、４２ａ…リクエスト処理部、４２ｂ…ＴＬＳ処理部、４２ｃ…表示制御部、４３…キーパッド部、４４…メモリ、６０…ＬＡＮケーブル
【図１】
2010220112.tif 000003
【図２】
2010220112.tif 000004
【図３】
2010220112.tif 000005
【図４】
2010220112.tif 000006
【図５】
2010220112.tif 000007
【図６】
2010220112.tif 000008
【図７】
2010220112.tif 000009
【図８】
2010220112.tif 000010
【手続補正書】
【提出日】平成22年7月26日(2010.7.26)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
シグナリングプロトコルを処理可能な複数の端末デバイスと、前記シグナリングプロトコルにおけるセッションを形成するために下位層の伝送プロトコルとして第１転送プロトコルまたは第２転送プロトコルにより信号を送受信するサーバとを具備し、
前記端末デバイスは、
前記セッション形成のために、前記第１転送プロトコルによりリクエスト信号を送信するリクエスト手段を備え、
前記サーバは、
前記リクエスト信号によるリクエストに対し、前記第１転送プロトコルによる信号の伝送が可能かどうかを判定する判定手段と、
前記判定手段により可能と判定されれば転送プロトコルを前記第１転送プロトコルとし、そうでなければ前記第２転送プロトコルにより信号を伝送することで、リクエスト元とのセッションを形成するセッション形成手段と、
前記第１の転送プロトコルによる通信が可能となったときに、前記第２転送プロトコルにより通信を行っている端末デバイスとの通信について、前記シグナリングプロトコルにおける形成済みのセッションを維持したまま、下位層の転送プロトコルを前記第２転送プロトコルから前記第１転送プロトコルに切り替える切替手段と
を備えることを特徴とする電話システム。
【請求項２】
前記サーバ装置は、さらに、端末デバイスごとのセッション形成の優先度を割り当てた管理テーブルを備え、
前記判定手段は、端末デバイスからリクエスト信号を受けると、前記管理テーブルを参照し、当該リクエスト元の端末デバイスよりもセッション形成の優先度が低く、第１の転送プロトコルを使用している端末デバイスの有無を確認し、
前記切替手段に対し、リクエスト元の端末デバイスよりも前記優先度の低い端末デバイスとの間に形成済みのセッションの下位層プロトコルを前記第１転送プロトコルから前記第２転送プロトコルに変更するように切替え指示を行い、前記下位層の転送プロトコルの変更によりリソースが確保されれば当該リクエスト元の端末デバイスからのリクエストを許可することを特徴とする請求項１に記載の電話システム。
【請求項３】
前記リクエスト手段は、前記セッションが前記第２転送プロトコルを使用した通信により形成されたときは、当該セッションを維持したまま、使用する転送プロトコルを前記第１転送プロトコルに変更を要求するリクエストを継続することを特徴とする請求項１に記載の電話システム。
【請求項４】
前記端末デバイスは、さらに、前記第１転送プロトコルを使用して形成されたセッションを介して秘匿通信を行う通信秘匿手段を備えることを特徴とする請求項１に記載の電話システム。
【請求項５】
前記端末デバイスは、さらに、前記秘匿通信を実施可能な旨をユーザに報知する報知手段を備えることを特徴とする請求項４に記載の電話システム。
【請求項６】
前記第１転送プロトコルはＴＣＰ（Transmission Control Protocol）であり、前記第２転送プロトコルはＵＤＰ（User Datagram Protocol）であることを特徴とする請求項１に記載の電話システム。
【請求項７】
シグナリングプロトコルを処理可能な端末デバイスとの間に、前記シグナリングプロトコルにおけるセッションを形成するために下位層の伝送プロトコルとして第１転送プロトコルまたは第２転送プロトコルにより信号を送受信するサーバにおいて、
前記端末デバイスからのリクエストに対し、前記第１転送プロトコルによる信号の伝送が可能かどうかを判定する判定手段と、
前記判定手段により可能と判定されれば転送プロトコルを前記第１転送プロトコルとし、そうでなければ前記第２転送プロトコルにより信号を伝送することで、リクエスト元とのセッションを形成するセッション形成手段と、
前記第１の転送プロトコルによる通信が可能となったときに、前記第２転送プロトコルにより通信を行っている端末デバイスとの間の通信について前記シグナリングプロトコルにおける形成済みのセッションを維持したまま、下位層の転送プロトコルを前記第２転送プロトコルから前記第１転送プロトコルに切り替える切替手段とを備えることを特徴とするサーバ。
【請求項８】
さらに、端末デバイスごとに前記第１転送プロトコルによるセッション形成の優先度を割り当てた管理テーブルを備え、
前記切替手段は、リクエスト元の端末デバイスよりも前記優先度の低い端末デバイスとの間に形成済みのセッションの下位層プロトコルを前記第１転送プロトコルから前記第２転送プロトコルに変更し、
前記判定手段は、前記下位層プロトコルの変更によりリソースが確保されれば当該リクエスト元の端末デバイスからのリクエストを許可することを特徴とする請求項７に記載のサーバ。
【請求項９】
シグナリングプロトコルにおけるセッションを形成するために下位層の伝送プロトコルとして第１転送プロトコルまたは第２転送プロトコルにより信号を送受信するサーバとの間で前記シグナリングプロトコルを処理可能な端末デバイスにおいて、
前記セッション形成のために、前記第１転送プロトコルによりリクエスト信号を送信するリクエスト手段と、
前記サーバとの間のセッションが前記第２転送プロトコルによる通信が形成された状態で、セッションが継続された状態で、下位層の伝送プロトコルを前記第１転送プロトコルに変更するリクエストを継続する手段とを具備することを特徴とする端末デバイス。
【請求項１０】
さらに、前記第１転送プロトコルにより形成されたセッションを介して秘匿通信を行う通信秘匿手段を備えることを特徴とする請求項９に記載の端末デバイス。
【請求項１１】
さらに、前記秘匿通信を実施可能な旨をユーザに報知する報知手段を備えることを特徴とする請求項１０に記載の端末デバイス。