(57)【要約】【課題】システムリソースを効果的に活用すること。【解決手段】通話に先立つ端末間でのネゴシエーションにより通信で使用するコーデックを選択決定する機能を持つＩＰ電話システムにあって、個々の通話ごとにＱｏＳ情報を収集し、その成績を通話相手先とコーデックごとに対応付けてメモリ４４に蓄積する。この蓄積された内容を参照し、良好なＱｏＳを得るべくコーデックの優先順位を入れ替え、次回のネゴシエーションに際して通話相手先に送信する。【選択図】      図２
2010119150.tif 000002
【特許請求の範囲】
【請求項１】
複数の通信装置が接続された通信システムにおいて、
前記通信装置は、
ピアツーピア通信の開始に先立つネゴシエーションにおいて、複数のコーデック間の優先順位を発信側から着信側に通知して前記ピアツーピア通信に使用するコーデックを決定するネゴシエーション手段と、
前記ピアツーピア通信を行う通信ネットワークに確認パケットを送出して、その応答を受けるまでに要する時間から当該通信ネットワークの伝送負荷を計測する計測手段と、
前記ピアツーピア通信の品質を最適化すべく、前記伝送負荷を基準として前記優先順位を入れ替える入れ替え手段とを具備することを特徴とする通信システム。
【請求項２】
前記複数のコーデックはそれぞれ音声データに関わるコーデックであることを特徴とする請求項１に記載の通信システム。
【請求項３】
前記複数のコーデックはそれぞれ映像データに関わるコーデックであることを特徴とする請求項１に記載の通信システム。
【請求項４】
複数の通信装置が接続された通信システムにおいて、
前記通信装置は、
ピアツーピア通信の開始に先立つネゴシエーションにおいて、複数のコーデック間の優先順位を発信側から着信側に通知して前記ピアツーピア通信に使用するコーデックを決定するネゴシエーション手段と、
自装置の処理負荷をモニタするモニタ手段と、
前記ピアツーピア通信の品質を最適化すべく、前記処理負荷を基準として前記優先順位を入れ替える入れ替え手段とを具備することを特徴とする通信システム。
【請求項５】
前記複数のコーデックはそれぞれ音声データに関わるコーデックであることを特徴とする請求項４に記載の通信システム。
【請求項６】
前記複数のコーデックはそれぞれ映像データに関わるコーデックであることを特徴とする請求項４に記載の通信システム。
【請求項７】
複数の通信装置が接続された通信システムにおいて、
前記通信装置は、
ピアツーピア通信の開始に先立つネゴシエーションにおいて、複数のコーデック間の優先順位を発信側から着信側に通知して前記ピアツーピア通信に使用するコーデックを決定するネゴシエーション手段と、
前記コーデックごとに前記着信側との通信品質をデータベース化した品質管理テーブルと、
前記着信側とのピアツーピア通信の履歴から前記コーデックごとの通信品質をこの品質管理テーブルに管理する管理手段と、
前記ピアツーピア通信の品質を最適化すべく、前記品質管理テーブルに管理される前記コーデックごとの通信品質を基準として前記優先順位を入れ替える入れ替え手段とを具備することを特徴とする通信システム。
【請求項８】
前記複数のコーデックはそれぞれ音声データに関わるコーデックであることを特徴とする請求項７に記載の通信システム。
【請求項９】
前記複数のコーデックはそれぞれ映像データに関わるコーデックであることを特徴とする請求項７に記載の通信システム。
【請求項１０】
複数の通信装置が接続された通信システムに適用される通信制御方法において、
発信側装置が、ピアツーピア通信の開始に先立つ前記通信装置間のネゴシエーションにおいて、複数のコーデック間の優先順位を着信側装置に通知し、
前記着信側装置が、前記通知された優先順位に基づいて前記ピアツーピア通信に使用するコーデックを決定し、
前記発信側装置が、前記ピアツーピア通信を行う通信ネットワークに確認パケットを送出し、
前記発信側装置が、前記確認パケットの応答を受けるまでに要する時間から当該通信ネットワークの伝送負荷を計測し、
前記発信側装置が、前記ピアツーピア通信の品質を最適化すべく、前記伝送負荷を基準として前記優先順位を入れ替えることを特徴とする通信制御方法。
【請求項１１】
前記複数のコーデックはそれぞれ音声データに関わるコーデックであることを特徴とする請求項１０に記載の通信制御方法。
【請求項１２】
前記複数のコーデックはそれぞれ映像データに関わるコーデックであることを特徴とする請求項１０に記載の通信制御方法。
【請求項１３】
複数の通信装置が接続された通信システムに適用される通信制御方法において、
発信側装置が、ピアツーピア通信の開始に先立つ前記通信装置間のネゴシエーションにおいて、複数のコーデック間の優先順位を着信側装置に通知し、
前記着信側装置が、前記通知された優先順位に基づいて前記ピアツーピア通信に使用するコーデックを決定し、
前記発信側装置が、自装置の処理負荷をモニタし、
前記発信側装置が、前記ピアツーピア通信の品質を最適化すべく、前記処理負荷を基準として前記優先順位を入れ替えることを特徴とする通信制御方法。
【請求項１４】
前記複数のコーデックはそれぞれ音声データに関わるコーデックであることを特徴とする請求項１３に記載の通信制御方法。
【請求項１５】
前記複数のコーデックはそれぞれ映像データに関わるコーデックであることを特徴とする請求項１３に記載の通信制御方法。
【請求項１６】
複数の通信装置が接続された通信システムに適用される通信制御方法において、
発信側装置が、ピアツーピア通信の開始に先立つ前記通信装置間のネゴシエーションにおいて、複数のコーデック間の優先順位を着信側装置に通知し、
前記着信側装置が、前記通知された優先順位に基づいて前記ピアツーピア通信に使用するコーデックを決定し、
前記発信側装置が、前記コーデックごとに前記着信側装置との通信品質をデータベース化した品質管理テーブルに、前記着信側装置とのピアツーピア通信の履歴から前記コーデックごとの通信品質を管理し、
前記発信側装置が、前記ピアツーピア通信の品質を最適化すべく、前記品質管理テーブルに管理される前記コーデックごとの通信品質を基準として前記優先順位を入れ替えることを特徴とする通信制御方法。
【請求項１７】
前記複数のコーデックはそれぞれ音声データに関わるコーデックであることを特徴とする請求項１３に記載の通信制御方法。
【請求項１８】
前記複数のコーデックはそれぞれ映像データに関わるコーデックであることを特徴とする請求項１３に記載の通信制御方法。
【請求項１９】
複数の通信装置が接続された通信システムで用いられる前記通信装置において、
着信側装置とのピアツーピア通信の開始に先立つネゴシエーションにおいて、複数のコーデック間の優先順位を前記着信側装置に通知して前記ピアツーピア通信に使用するコーデックを決定するネゴシエーション手段と、
前記ピアツーピア通信を行う通信ネットワークに確認パケットを送出して、その応答を受けるまでに要する時間から当該通信ネットワークの伝送負荷を計測する計測手段と、
前記ピアツーピア通信の品質を最適化すべく、前記伝送負荷を基準として前記優先順位を入れ替える入れ替え手段とを具備することを特徴とする通信装置。
【請求項２０】
前記複数のコーデックはそれぞれ音声データに関わるコーデックであることを特徴とする請求項１９に記載の通信装置。
【請求項２１】
前記複数のコーデックはそれぞれ映像データに関わるコーデックであることを特徴とする請求項１９に記載の通信装置。
【請求項２２】
複数の通信装置が接続された通信システムで用いられる前記通信装置において、
着信側装置とのピアツーピア通信の開始に先立つネゴシエーションにおいて、複数のコーデック間の優先順位を前記着信側装置に通知して前記ピアツーピア通信に使用するコーデックを決定するネゴシエーション手段と、
自装置の処理負荷をモニタするモニタ手段と、
前記ピアツーピア通信の品質を最適化すべく、前記処理負荷を基準として前記優先順位を入れ替える入れ替え手段とを具備することを特徴とする通信装置。
【請求項２３】
前記複数のコーデックはそれぞれ音声データに関わるコーデックであることを特徴とする請求項２２に記載の通信装置。
【請求項２４】
前記複数のコーデックはそれぞれ映像データに関わるコーデックであることを特徴とする請求項２２に記載の通信装置。
【請求項２５】
複数の通信装置が接続された通信システムで用いられる前記通信装置において、
ピアツーピア通信の開始に先立つネゴシエーションにおいて、複数のコーデック間の優先順位を着信側装置に通知して前記ピアツーピア通信に使用するコーデックを決定するネゴシエーション手段と、
前記コーデックごとに前記着信側装置との通信品質をデータベース化した品質管理テーブルと、
前記着信側装置とのピアツーピア通信の履歴から前記コーデックごとの通信品質をこの品質管理テーブルに管理する管理手段と、
前記ピアツーピア通信の品質を最適化すべく、前記品質管理テーブルに管理される前記コーデックごとの通信品質を基準として前記優先順位を入れ替える入れ替え手段とを具備することを特徴とする通信装置。
【請求項２６】
前記複数のコーデックはそれぞれ音声データに関わるコーデックであることを特徴とする請求項２５に記載の通信装置。
【請求項２７】
前記複数のコーデックはそれぞれ映像データに関わるコーデックであることを特徴とする請求項２５に記載の通信装置。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、ＩＰ（Internet Protocol）ネットワークを利用して音声通話の可能な電話システムとその通信制御方法および通信装置に関する。特にこの発明は、利用可能なコーデック方式（以下コーデックと称する）、あるいはパケットの送出間隔を通話の開始前に端末間でネゴシエーションする機能を備える電話システムに関する。
【背景技術】
【０００２】
多くのＩＰ電話システムには、電話端末間でのセッション確立ののち、利用可能なコーデックを通話に先立って端末が相互にネゴシエーションする機能が設けられている。端末は自らが処理可能なコーデックを相手方に通知し、複数の方式のなかから一つの方式を選択する。コーデックの通知にあたり、複数のコーデック間の優先順位も相互に通知される。
【０００３】
ところで既存の技術では、各端末における機能の実装あるいは初期設定により、利用可能なコーデックの優先順位が固定的である。つまり端末はネゴシエーションに際して、常に決まった優先順位しか相手方に通知できない。このため、広帯域を要するコーデックの優先順位がお互いに高ければ、利用環境（通信環境や端末の処理能力など）が悪化するとパケットロスやパケット遅延が増加し、通話品質が劣化することになる。また、狭帯域（従って低品質）のコーデックが設定されていると、ネットワーク負荷やＣＰＵ負荷が軽い状況においてもリソースを有効に活用できず、得られるはずの通話品質を享受できないことになる。
【０００４】
特許文献１には、ＩＰ電話システムにおいて、エンドポイント装置の対をなす組み合わせごとに音声コーデックの識別名を優先順位を付けて保持し、呼接続要求が発生した度に、組み合わせに対応する１つの音声コーデックを使用音声コーデックとして設定する。空伝送帯域を越えない音声コーデックが使用される。しかしながらこのような方式では、エンドポイント装置の数が増えるにつれ組み合わせの数が幾何級数的に増大するのは明らかで、膨大なリソースが消費される。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００７−２２８３２４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
以上述べたように既存の技術では、端末間で用いられるコーデックの優先順位が固定的に決められているので、ネットワークの負荷の状態、あるいはＣＰＵの負荷の状況に応じて最適なコーデックを選ぶことができない。これはネットワークリソースあるいはＣＰＵリソース（以下、システムリソースと総称する）を効果的に活用できないことを意味し、何らかの対処が望まれている。  
この発明は上記事情によりなされたもので、その目的は、システムリソースを効果的に活用することの可能な通信システムとその通信制御方法および通信装置を提供することにある。
【課題を解決するための手段】
【０００７】
上記目的を達成するためにこの発明の一態様によれば、通信ネットワークに接続される複数の通信装置を具備し、前記通信装置は、ピアツーピア通信の開始に先立つネゴシエーションにおいて、複数のコーデック間の優先順位を発信側から着信側に通知して前記ピアツーピア通信に使用するコーデックを決定するネゴシエーション手段と、前記優先順位を前記ピアツーピア通信の品質を最適化すべく規定の基準のもとで入れ替える入れ替え手段とを備えることを特徴とする通信システムが提供される。
【０００８】
このような手段を講じることにより、例えばネットワーク負荷、あるいは通信装置（端末）の処理負荷のそのときの状況に応じて、コーデックの優先順位をダイナミックに変更することが可能になる。従ってネットワークリソース、あるいはＣＰＵリソースを効果的に活用できるようになり、ひいては通信の品質を向上させることが可能となる。
【発明の効果】
【０００９】
この発明によれば、システムリソースを効果的に活用することの可能な通信システムとその通信制御方法および通信装置を提供することができる。
【図面の簡単な説明】
【００１０】
【図１】この発明に関わる通信システムの実施の形態の一例を示すシステム図。
【図２】図１のＩＰＴの実施の形態を示す機能ブロック図。
【図３】ＱｏＳ集計テーブル４４ａ、ＱｏＳ判定結果テーブル４４ｂ、およびＣＯＤＥＣ優先順位テーブル４４ｃの一例を示す図。
【図４】発信側のＩＰＴにおける呼の発生に関わる処理手順を示すフローチャート。
【図５】発信側のＩＰＴにおける呼の終了に関わる処理手順を示すフローチャート。
【図６】ＣＯＤＥＣの優先順位を通話相手に通知するときに用いる通知フォーマットの一例を示す図。
【図７】この発明に関わる通信システムの第２の実施形態を示すシステム図。
【図８】この発明の第２の実施形態における制御部４２およびメモリ４４の一例を示す機能ブロック図。
【図９】ＣＯＤＥＣ判定テーブル４４ｄの一例を示す図。
【図１０】この発明に関わる通信システムの第３の実施形態を示すシステム図。
【図１１】この発明の第３の実施形態における制御部４２およびメモリ４４の一例を示す機能ブロック図。
【図１２】ＣＰＵ使用量の一例を示す図。
【図１３】この発明の第４の実施形態における制御部４２およびメモリ４４の一例を示す機能ブロック図。
【図１４】タイムテーブル４４ｅの一例を示す図。
【発明を実施するための形態】
【００１１】
図１は、この発明に関わる通信システムの実施の形態の一例を示すシステム図である。この例ではＩＰネットワーク１００を利用して音声通話を行う、いわゆるＶｏＩＰ（Voice over IP）を想定する。ここでは呼接続処理に関わるプロトコルとしてＳＩＰ（Session Initiation Protocol）を想定するが、これに限らずＭｅｇａｃｏ（Media Gateway Control）、あるいはＨ．３２３などのプロトコルも同様に利用できる。
【００１２】
図１において、ＩＰネットワーク１００に複数のＬＡＮ（Local Area Network）が接続され、各ＬＡＮには端末装置としてのＩＰＴ（IP Terminal：ＩＰＴ）が属する。このうち一方のＬＡＮにはグループ１（Group-1）およびグループ２（Group-2）の端末群が属する。つまりＬＡＮに接続されるＩＰＴは複数のグループに組み分けされる。ここではグループ１にＩＰＴ−１が属し、グループ２にＩＰＴ−２が属するとする。また、これらのグループが属するＬＡＮにはビジネス電話主装置（以下、主装置と表記する）５０も接続される。この主装置５０は例えばＳＩＰサーバとしての機能を担う。
【００１３】
もう一方のＬＡＮにはグループ３（Group-3）およびグループ４（Group-4）の端末群が属する。ここではグループ３にＩＰＴ−３が属し、グループ４にＩＰＴ−４が属するとする。ＩＰＴ−１〜ＩＰＴ−４は専用の固定電話端末のほか、移動通信端末、あるいは電話機能をインストールしたコンピュータ（いわゆるソフトフォン）などであってよい。要するにこの実施形態では、通信相手先とのセッション確立ののち通話開始に先立って、利用可能なコーデックを相互にネゴシエーションする機能を備える端末を想定する。
【００１４】
図２は、図１のＩＰＴの実施の形態を示す機能ブロック図である。この例ではグループ１のＩＰＴ−１の構成につき説明するが、他のＩＰＴ−２〜ＩＰＴ−４も同様である。ＩＰＴは、ＬＡＮケーブル６０を介してＬＡＮに接続されるインタフェース（Ｉ／Ｆ）部４１と、表示器４０と、制御部４２と、キーパッド部４３と、メモリ４４とを備える。このうち表示器４０は例えばＬＣＤ（Liquid Crystal Display）であり、種々のメッセージを視覚的に表示する。キーパッド部４３はソフトキーや数字キーなどを備え、ユーザの入力操作を受け付ける。
【００１５】
メモリ４４は、例えばフラッシュメモリなどの書き換え可能な半導体記憶デバイスである。メモリ４４はその記憶領域に、ＱｏＳ（Quality of Service）集計テーブル４４ａと、ＱｏＳ判定結果テーブル４４ｂと、ＣＯＤＥＣ優先順位テーブル４４ｃとを記憶する。ＱｏＳ集計テーブル４４ａ、ＱｏＳ判定結果テーブル４４ｂ、およびＣＯＤＥＣ優先順位テーブル４４ｃはそれぞれ単独で、あるいはこれらの組み合わせにより、着信先との通信品質をコーデックごとに管理するために用いられるデータベースである。
【００１６】
図３は、ＱｏＳ集計テーブル４４ａ、ＱｏＳ判定結果テーブル４４ｂ、およびＣＯＤＥＣ優先順位テーブル４４ｃの一例を示す図である。図３（ａ）に示すようにＱｏＳ集計テーブル４４ａにおいては、過去の通話履歴において使用したコーデックごとのＱｏＳ情報が、相手先の属するグループ（Ｇｒ）、つまりＧｒ−２、Ｇｒ−３、およびＧｒ−４ごとに管理される。ＱｏＳ情報には例えばパケットロス率（単位％）と遅延時間（単位ミリ秒）とが挙げられ、いずれも通話のたびに計測される値である。
【００１７】
ＱｏＳ判定結果テーブル４４ｂは図３（ｂ）に示すように、ＱｏＳ集計テーブル４４ａにおける各項目ごとにＯＫまたはＮＧを、一定の判定基準のもとで判定した結果を記載したテーブルである。例えばＱｏＳ集計テーブル４４ａでは、Ｇｒ−２とのＧ．７２２を用いた通話ではパケットロス率３０％、遅延１００ミリ秒となっている。これは、判定結果としていずれもＮＧとされ、その旨がＱｏＳ判定結果テーブル４４ｂに記載される。Ｇ．７１１を用いたケースのパケットロス率は１５％であり、これはＯＫとして記載される。ＣＯＤＥＣ優先順位テーブルは図３（ｃ）に示すように、コーデック間の優先順位を通話相手先グループごとにセットした状態を管理するためのテーブルである。
【００１８】
図２に戻り、制御部４２はこの実施形態に関わる処理機能としてネゴシエーション処理部４２ａと、ＱｏＳ管理部４２ｂと、優先順位入れ替え部４２ｃとを備える。ネゴシエーション処理部４２ａは、ピアツーピア通信の開始に先立つネゴシエーションにおいて、各コーデック間の優先順位を発信側から着信側に通知し、着信側からの返答の結果をもとに、そのときのピアツーピア通信に使用するコーデックを決定する。
【００１９】
ＱｏＳ管理部４２ｂは、着信側とのピアツーピア通信の履歴から、コーデックごとの通信品質（ＱｏＳ情報）を計測して、その結果をＱｏＳ集計テーブル４４ａに記載して管理する。ここではＱｏＳ管理部４２ｂは、図１各グループGroup-2、Group-3、およびGroup-4に所属するＩＰＴとの通話に対するＱｏＳ情報を収集し、その結果をＱｏＳ集計テーブル４４ａに蓄積する。
【００２０】
優先順位入れ替え部４２ｃは、ネゴシエーションにおける本来固定的なコーデック間の優先順位を、ピアツーピア通信の品質を最適化すべく、規定の基準のもとで入れ替える。その際、優先順位入れ替え部４２ｃは、ＱｏＳ集計テーブル４４ａ、および、特にＱｏＳ判定結果テーブル４４ｂの内容を参照し、ＱｏＳを基準に、つまり良好なＱｏＳを得られる順にコーデックの優先順位をセットする。つまり優先順位入れ替え部４２ｃは、ＱｏＳ判定結果テーブル４４ｂに基づいてコーデック間での優先順位を入れ替えることにより、ＣＯＤＥＣ優先順位テーブル４４ｃを更新する。次に、この発明の実施の形態を第１ないし第４の実施形態に分けて詳しく説明する。
【００２１】
（第１の実施形態）
図４は、発信側のＩＰＴにおける呼の発生に関わる処理手順を示すフローチャートである。このフローチャートは、グループ１に属するＩＰＴ−１が他のグループに属するＩＰＴに発信する際の、コーデックの優先順位を決定する手順を示す。ユーザの相手先番号入力などを契機として、ＩＰＴ−１は呼接続処理を開始する。まずＩＰＴ−１はメモリ４４における通話相手先のＣＯＤＥＣ優先順位テーブル４４ｃの有無を判定する。（ブロックＢ１）。テーブルが無ければ、ＩＰＴ−１は次に示すようなデフォルトのＣＯＤＥＣ優先順位を通話相手（着信側）に通知する（ブロックＢ３）。  
［デフォルトの優先順位］
・  第１優先コーデック：Ｇ．７２２
・  第２優先コーデック：Ｇ．７１１
・  第３優先コーデック：Ｇ．７２９Ａ
ブロックＢ１で、ＣＯＤＥＣ優先順位テーブル４４ｃが見つかれば、ＩＰＴ−１はこのＣＯＤＥＣ優先順位テーブル４４ｃに従う優先順位を通話相手に通知する。例えば図３（ｃ）を参照すると、Ｇｒｏｕｐ−２に属するＩＰＴ−２とのＣＯＤＥＣ優先順位は、次に示す順でＣＯＤＥＣ優先順位テーブル４４ｃに記載されている。  
［入れ替え後の優先順位］
・  第１優先コーデック：Ｇ．７１１
・  第２優先コーデック：Ｇ．７２９Ａ
・  第３優先コーデック：Ｇ．７２２
優先順位の通知にあたり、ＩＰＴは図６に示すようなフォーマットを用いる。図６は、ＣＯＤＥＣの優先順位を通話相手に通知するときの通知フォーマットをＳＤＰ（Session Description Protocol）で記述した例を示す。ＳＤＰは、マルチメディアセッションの内容を記述する書式としてＲＦＣ２３２７に定義され、ＳＩＰやＭｅｇａｃｏ等、多くのシグナリングプロトコルで採用されている。
【００２２】
図６（ａ）は［デフォルトの優先順位］を通知するフォーマットであり、Ｇ．７２２、Ｇ．７１１、Ｇ．７２９Ａの順に優先順位の下がることが示される。図６（ｂ）は［入れ替え後の優先順位］を通知するフォーマットであり、Ｇ．７１１、Ｇ．７２９Ａ、Ｇ．７２２の順に優先順位が下がるようになっている。
【００２３】
図４に戻り、図６のようなフォーマットで通知された優先順位を受けた通話相手は、自端末（つまり通知を受けた側の端末）がサポートするコーデックのなかから優先順位の最も高いコーデックを選択し、その結果をＩＰＴ−１へ通知する。これを受けたＩＰＴ−１は、通話相手により選択されたコーデックを使用して通話を開始する（ブロックＢ４）。このような手順を経て、今回のピアツーピア通信に使用すべきコーデックが確定し、通話が開始される。ひきつづきＩＰＴ−１はＱｏＳ情報の収集を開始する（ブロックＢ５）。
【００２４】
図５は、発信側のＩＰＴにおける呼の終了に関わる処理手順を示すフローチャートである。通話が終了すると（ブロックＢ１１）、ＩＰＴ−１は収集したＱｏＳ情報をまとめて、通話相手のＱｏＳ集計テーブル４４ａを作成する（ブロックＢ１２）。続いてＩＰＴ−１は、ＱｏＳの判定条件に従ってコーデックにＯＫまたはＮＧを付与し、ＱｏＳ判定結果テーブル４４ｂを更新する。初めての通話相手であればＱｏＳ判定結果テーブル４４ｂは新規作成されることになる（ブロックＢ１３）。次にＩＰＴ−１は、ＱｏＳ判定結果テーブル４４ｂに従ってコーデックの優先順位を入れ替え、ＣＯＤＥＣ優先順位テーブル４４ｃを作成（または更新）する（ブロックＢ１４）。
【００２５】
以上述べたようにこの実施形態では、通話に先立つ端末間でのネゴシエーションにより通信で使用するコーデックを選択決定する機能を持つＩＰ電話システムにあって、個々の通話ごとにＱｏＳ情報を収集し、その成績を通話相手先とコーデックごとに対応付けてメモリ４４に蓄積する。この蓄積された内容を参照し、良好なＱｏＳを得るべくコーデックの優先順位を入れ替え、次回のネゴシエーションに際して通話相手先に送信するようにしている。
【００２６】
このようにしたので、計測されたＱｏＳに基づいて、ＱｏＳを向上させることを主眼としてコーデックの優先順位をダイナミックに変更することが可能になる。従ってネットワークリソース、あるいはＣＰＵリソースを効果的に活用できるようになり、ひいては通信の品質を向上させることが可能となる。これらのことから、システムリソースを効果的に活用することの可能な通信システムとその通信制御方法を提供することが可能になる。
【００２７】
（第２の実施形態）
図７は、この発明に関わる通信システムの第２の実施形態を示すシステム図である。図７においても図１と同様のシステム構成が示されるが、第２の実施形態では必ずしもＩＰＴをグループ化する必要は無い。
【００２８】
図８は、この発明の第２の実施形態における制御部４２およびメモリ４４の一例を示す機能ブロック図である。第２の実施形態では、制御部４２はその処理機能として負荷計測部４２ｄを備え、メモリ４４はＣＯＤＥＣ判定テーブル４４ｄを記憶する。  
負荷計測部４２ｄは、ＩＰネットワーク１００の伝送負荷（例えばネットワーク負荷、あるいはネットワーク帯域の空き量）を測定する。具体的には負荷計測部４２ｄは、ＩＰネットワーク１００に試験用の確認パケットを送出し、その応答を受けるまでに要する時間から伝送負荷を計測する。確認パケットには例えばキープアライブメッセージなどを流用できる。第２の実施形態において、負荷計測部４２ｄにより計測された伝送負荷を基準として、優先順位入れ替え部４２ｃはコーデック間の優先順位を入れ替える。次にこの実施形態における作用を説明する。
【００２９】
図７に示すように、発信側のＩＰＴ−１は、着信側のＩＰＴ−４との通話を行う前に、ＩＰＴ−４に確認パケットを送信する。これを受けてＩＰＴ−４は、この確認パケットに対する応答パケットをＩＰＴ−１に返信する。ＩＰＴ−１は、確認パケットを送信してから応答パケットを受信するまでにかかる応答時間を測定しメモリ４４に記憶する。
【００３０】
メモリ４４に記憶されるＣＯＤＥＣ判定テーブル４４ｄは、図９（ａ）に示すように、応答時間の範囲と、適用すべきＣＯＤＥＣとを対応付けたテーブルである。例えば応答時間が０ミリ秒以上３ミリ秒以下であれば、Ｇ．７２２コーデックが適用される。図９の例では４ミリ秒の応答時間が計測されたとし、これはＧ．７１１を適用すべき範囲の値である。よって第２の実施形態では、ＩＰＴ−１はＣＯＤＥＣ優先順位テーブルにおいてＧ．７１１の優先順位が最高になるように入れ替える。その結果は例えば次のようになる。  
［判定後の優先順位］
・  第１優先コーデック：Ｇ．７１１
・  第２優先コーデック：Ｇ．７２９Ａ
・  第３優先コーデック：Ｇ．７２２
ＩＰＴ−１はこの判定結果に従い、図６の通知フォーマットに従って通話相手にコーデックの優先順位を通知する。このように第２の実施形態ではネットワークの負荷を考慮してコーデックの優先順位を決めることが可能になる。このようにしてもシステムリソースを最適化しつつＱｏＳを向上させることが可能になる。
【００３１】
（第３の実施形態）
図１０は、この発明に関わる通信システムの第３の実施形態を示すシステム図である。図１０においても図７と同様のシステム構成が示される。  
図１１は、この発明の第３の実施形態における制御部４２およびメモリ４４の一例を示す機能ブロック図である。第３の実施形態では、制御部４２はその処理機能として負荷モニタ部４２ｅを備える。  
負荷モニタ部４２ｅは、自端末の処理負荷、具体的にはＣＰＵ（Central Processing Unit）の使用量や残存メモリ容量などを逐次、あるいはこの発生に伴ってモニタする。その結果はメモリ４４に記憶される。
【００３２】
ＩＰＴ−１は、通話相手（ここではＩＰＴ−４）との呼の発生に際し、そのときのＣＰＵ使用量をモニタする。一方、メモリ４４には、コーデックごとに要するＣＰＵの使用量が例えば図１０（ａ）に示すように、予めテーブル化されて記憶されている。図１０に示すようにモニタしたＣＰＵ使用量が６０％であれば、各コーデックを適用した結果、必要になるＣＰＵ使用量は例えば単純な加算により次のようになる。
【００３３】
［現在のＣＰＵ使用量にＣＯＤＥＣ毎のＣＰＵ使用量を加算した結果］
・  Ｇ．７２２  ：９０％
・  Ｇ．７１１  ：７０％
・  Ｇ．７２９Ａ：１１０％
Ｇ．７２９Ａは必要帯域を狭くできる方式であるが、その分、多くのＣＰＵパワーを必要とする。仮にこれを適用すると使用量が１００％を超えて（１１０％）しまい、現実的ではない。そこでこの実施形態では、例えば次のような判定基準を設ける。
【００３４】
［判定基準］
・３０％未満            ：（１）Ｇ．７２２、（２）Ｇ．７１１、（３）Ｇ．７２９Ａ
・３０％以上、５０％未満：（１）Ｇ．７１１、（２）Ｇ．７２２、（３）Ｇ．７２９Ａ
・５０％以上            ：ＣＰＵ使用率が少ない順番
（  ）は優先順位を示す。図９では、全てのＣＯＤＥＣで使用率が５０％を超えているため、「ＣＰＵ使用率が少ない順番」が採択される。このような判定基準に従えば、コーデック間の優先順位は次のようになる。
【００３５】
［判定後の優先順位］
・  第１優先コーデック：Ｇ．７１１
・  第２優先コーデック：Ｇ．７２２
・  第３優先コーデック：Ｇ．７２９Ａ
ＩＰＴ−１はこの判定結果に従い、図６の通知フォーマットに従ってＩＰＴ−４にコーデックの優先順位を通知する。このように第３の実施形態ではＩＰ端末の負荷を考慮してコーデックの優先順位を決めることが可能になる。このようにしてもシステムリソースを最適化しつつＱｏＳを向上させることが可能になる。
【００３６】
（第４の実施形態）
図１３は、この発明の第４の実施形態における制御部４２およびメモリ４４の一例を示す機能ブロック図である。第４の実施形態では、メモリ４４にタイムテーブル４４ｅが記憶される。  
図１４（ａ）に示すように、タイムテーブル４４ｅは、タイムゾーンごとにコーデック間の優先順位を定義したテーブルである。図１４（ａ）においては曜日および時間帯に応じた３つのタイムゾーンが定義されており、各タイムゾーンごとに異なる優先順位が記載されている。なおタイムゾーンは、曜日または時間のいずれか一方を指定する形態でもよいし、あるいは季節などを基準とする、もっと緩やか（あるいは細かな）なものであってもよい。
【００３７】
ＩＰＴ−１の優先順位入れ替え部４２ｃは、ネゴシエーションに際してタイムテーブル４４ｅを参照し、その時点での日時に対応する優先順位をセットして通話相手に通知する。すなわちＩＰＴ−１は、ネゴシエーションに際してタイムテーブル４４ｅを参照し、現在の日時がどのタイムゾーンに属するかを判定してＣＯＤＥＣの優先順位を決定する。図１４に示すように、呼の発生した日時が「２００８年８月１日（金）１４：００」であればタイムゾーン「（月）〜（金）の８：００〜１７：００」に含まれることになり、コーデックの優先順位は以下に示すようになる。
【００３８】
［判定後の優先順位］
・  第１優先コーデック：Ｇ．７２９Ａ
・  第２優先コーデック：Ｇ．７１１
・  第３優先コーデック：Ｇ．７２２
ＩＰＴ−１はこの判定結果に従い、図６の通知フォーマットに従って通話相手にコーデックの優先順位を通知する。このように第４の実施形態では時間帯を考慮してコーデックの優先順位を決めることが可能になる。このようにしてもシステムリソースを最適化しつつＱｏＳを向上させることが可能になる。
【００３９】
なお、この発明は上記実施の形態に限定されるものではない。例えば第１ないし第４の実施形態に示した処理はその実施形態だけでなく、他の実施形態との組み合わせても利用することができる。例え第３の実施形態と第４の実施形態とを組み合わせれば、時間帯とＣＰＵ負荷との双方を考慮した、さらにきめ細かなリソース最適化を実現できる。
【００４０】
また各実施形態ではコーデックの優先順位の入れ替えに焦点を当てたが、パケットの送出間隔も同様の手順で決定できる。またこの発明は音声通話だけに限られるものではない。周知のように映像信号の伝送に当たってもＭＰＥＧ２、ＭＰＥＧ４をはじめとする種々のコーデック方式が提供されており、方式ごとに必要な帯域、ＣＰＵ負荷も多様に異なる。この実施形態で示した手順によれば、このような映像のコーデック方式に対してもリソースを最適化することが可能になる。
【００４１】
さらに上記実施形態では、「コーデックの優先順位を発信側から着信側に通知する」ことを主眼としたが、立場を入れ替えて、「発信側から通知されたコーデックから選択する優先順位を受信側で決める」ことにも、同様の考えを応用できる。  
さらに、上記実施形態ではＩＰネットワークを利用するＩＰ電話システムを例に取り上げたが、アナログネットワークを利用する通話端末にもこの例を適用できる。例えばアナログ電話機を収容する交換装置と、ＩＰネットワークの発呼端末との間で、同様のネゴシエーション手順を実現することができる。
【００４２】
さらに、この発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
【符号の説明】
【００４３】
１００…ＩＰネットワーク、ＩＰＴ−１〜ＩＰＴ−４…ＩＰ端末、５０…ビジネス電話主装置、６０…ＬＡＮケーブル、４０…表示器、４１…インタフェース部、４２…制御部、４２ａ…ネゴシエーション処理部、４２ｂ…ＱｏＳ管理部、４２ｃ…優先順位入れ替え部、４２ｄ…負荷計測部、４２ｅ…負荷モニタ部、４３…キーパッド部、４４…メモリ、４４ａ…ＱｏＳ集計テーブル、４４ｂ…ＱｏＳ判定結果テーブル、４４ｃ…ＣＯＤＥＣ優先順位テーブル、４４ｄ…ＣＯＤＥＣ判定テーブル、４４ｅ…タイムテーブル
【図１】
2010119150.tif 000003
【図２】
2010119150.tif 000004
【図３】
2010119150.tif 000005
【図４】
2010119150.tif 000006
【図５】
2010119150.tif 000007
【図６】
2010119150.tif 000008
【図７】
2010119150.tif 000009
【図８】
2010119150.tif 000010
【図９】
2010119150.tif 000011
【図１０】
2010119150.tif 000012
【図１１】
2010119150.tif 000013
【図１２】
2010119150.tif 000014
【図１３】
2010119150.tif 000015
【図１４】
2010119150.tif 000016