JP2007194721A - 通信装置及び通信システム - Google Patents

Abstract

【課題】通信システムを高効率・低コストで実現する。
【解決手段】ＳＩＰプロキシ部２１は音声データを多重する際の自局の多重対象エリアを示すローカルＩＰＣＭＥドメインと相手局の多重対象エリアを示すリモートＩＰＣＭＥドメインを登録し、受信したＳＩＰメッセージの送信元が自局のローカルＩＰＣＭＥドメインと一致し、受信したＳＩＰメッセージの送信先が相手局のリモートＩＰＣＭＥドメインに一致する場合に、受信したＳＩＰメッセージを相手局に転送し、メディアプロキシ部２２は自局の送信元からの音声データのＲＴＰパケットを多重してＩＰＣＭＥパケットを相手局に転送する。
【選択図】図３

Description

この発明は、ショートパケット多重／分離機能を有する通信装置及び通信システムに関するものであり、特に、ＶｏＩＰ（Voice Oever Internet Protocol）において、音声データを収容した複数のショートパケットを一つのＩＰパケットに多重する通信装置及び通信システムに関するものである。

ショートパケット多重／分離機能を有するＩＰ（Internet Protocol）ベースの通信装置としては、例えば、非特許文献１としてのITU-T（International Telecommunication Union-Telecommunication standard） G.769で示されているＩＰベースの回線多重化装置（ＩＰＣＭＥ：Cicuit Multiplication Equipment for IP-based networks）がある。この勧告では、複数のショートパケットをＲＴＰ（Real-time Transpoprt Protocol）／ＵＤＰ（Ueser Datagram Protocol）／ＩＰパケットの中に多重し伝送する方式が提案されている。後述の図２に示すＩＰパケットは、この勧告に沿った方式であり、ＲＴＰ／ＵＤＰ／ＩＰというＶｏＩＰ（Voice Oever Internet Protocol）の標準のプロトコルを用いて、ＲＴＰペイロード中に複数のショートパケットを多重するものである。

現在、ＶｏＩＰの呼制御方式としては、ＩＥＴＦ(Internet Engineering Task Force）のＲＦＣ（Request For Comments）３２６１〜３２６４等で規格されているＳＩＰ（Session Initiation Protocol）が主流となっている。ＳＩＰはＨＴＴＰ（HyperText Transfer Protocol）に似たテキストベースのプロトコルであり、ＳＩＰメッセージはＳＩＰヘッダ群とＳＩＰボディから成る。ＳＩＰボディはＳＤＰ（Session Description Protocol）という記述ルールが用いられ、音声セッション情報（例えば符号化方式やポート番号等）を記述し、エンド−エンドのネゴシエーションに使用される。
音声データの伝送については、ＲＦＣ３５５０等で規格されているＲＴＰで伝送する。

ＳＩＰ方式によってＩＰ電話を運用するネットワークでは、ＳＩＰメッセージを乗せたＩＰパケットとＲＴＰを乗せたＩＰパケットは、それぞれ別のセッション、ルートをたどって伝送される。なお、ＳＩＰ及びＲＴＰのトランスポート層プロトコルはＵＤＰが一般的であるが、ＴＣＰ(Transmission Control Protocol）／ＩＰでも可能である。

ＳＩＰによるＶｏＩＰネットワークでは、ＳＩＰプロキシと呼ばれるＩＰ電話サーバが設置され、ＩＰ電話等のＶｏＩＰ端末はそのＳＩＰプロキシを記憶している。位置付けとしては、ＨＴＴＰにおけるＤＮＳ（Domain Name System）と同様の位置付けとなる。このＳＩＰプロキシはＩＰ電話の位置登録や、発着・着信・切断の制御等を行うＩＰ電話のための回線交換サーバである。

一方、メディアプロキシ（又はＲＴＰプロキシ）とは、音声データや画像データのためのプロキシで、ＨＴＴＰプロキシと同様にネットワークの境界に設置され、複数の端末のチャネルを一旦集約し伝送する装置であり、ゲートウェイやＮＡＴ（Network Address Translator）／ファイヤーウォール通過の手段として使われる。

ＳＩＰプロキシとメディアプロキシを一体化すると、ＳＩＰプロキシとメディアプロキシの機能を合わせ持ったサーバとなり、ＩＰ電話端末２台を背中合わせにした振舞いをし、ＳＩＰプロキシ処理とメディアプロキシ処理をすることから、Ｂ２ＢＵＡ（Back to Back User Agent）と呼ばれる。

ＳＩＰはＨＴＴＰと類似のテキストベースの通信手順であり、他の方式よりも通信システムを組み易く拡張し易いために、通信システムを高効率・低コストで実現することができる。

また、従来の通信装置や通信システムとして、例えば、特許文献１では、送信先網接続装置が同一である複数呼の情報信号を送信する際に、通信におけるオーバヘッドの少ないＩＰパケットに構成して送信する網接続装置が開示されており、特許文献２では、配信されるコンテンツを取得する側において、コンテンツの再生される映像音声信号の品質が劣化することなく、また、より短い時間でより高い秘匿性を維持して、コンテンツの映像音声信号を伝送することができるコンテンツ配信システムが開示されている。

特許第３３１９３６７号公報（段落０００６） 特開２００４−９６６４８号公報（段落００１４） ITU-T G.769,Aug.2002

従来の通信装置及び通信システムは以上のように構成されており、例えば上記非特許文献１に示すＩＰベースの回線多重化装置（ＩＰＣＭＥ）は、今日主流となっているＶｏＩＰの呼制御方式であるＳＩＰに対応したものではないため、既存のＶｏＩＰシステムで適用できるものではなく、衛星回線のような限られた帯域でＶｏＩＰを実現しようとした場合や、企業通信網におけるアクセス回線の契約帯域削減や音声回線のＱｏＳ（Quality of Service）を実現しようとした場合に、高効率・低コストで実現することができないという課題があった。

この発明は上記のような課題を解決するためになされたもので、衛星回線のような限られた帯域でＶｏＩＰを実現しようとした場合や、企業通信網におけるアクセス回線の契約帯域削減や音声回線のＱｏＳを実現しようとした場合に、ＳＩＰを適用することにより高効率・低コストで実現することができる通信装置及び通信システムを得ることを目的とする。

この発明に係る通信装置は、音声データを多重する際の自局の多重対象エリアを示すローカルＩＰＣＭＥドメインと相手局の多重対象エリアを示すリモートＩＰＣＭＥドメインを登録し、受信したＳＩＰメッセージの送信元が自局のローカルＩＰＣＭＥドメインと一致し、受信したＳＩＰメッセージの送信先が相手局のリモートＩＰＣＭＥドメインに一致する場合に、受信したＳＩＰメッセージを相手局に転送することにより呼接続制御を行うＳＩＰプロキシ部と、該ＳＩＰプロキシ部による呼接続制御に基づき、自局の送信元からの音声データのＲＴＰパケットを多重してＩＰＣＭＥパケットを相手局に転送するメディアプロキシ部とを備えたものである。

この発明により、通信装置を既存のＳＩＰ端末と共存して運用することができ、また、ＩＰ端末やエンドユーザは通信装置の存在を意識せずにシームレスに音声回線を利用することができ、最終的には、通信事業者が高効率符号化多重伝送の恩恵を受け、音声回線を低コストで効率良く運用することができるという効果が得られる。

実施の形態１．
図１はこの発明の実施の形態１による通信システムの構成を示すブロック図である。この通信システムでは、センター局１、超小型地上局（ＶＳＡＴ：Very Small Aperture Terminal）２及び超小型地上局３は人工衛星４を介して通信を行い、超小型地上局２及び超小型地上局３は人工衛星４及びセンター局１を介してのダブルホップ中継による通信を行う。センター局１は、回線多重化装置（ＩＰＣＭＥ）１１ａ、ＩＰ電話（又はターミナルアダプタ）１２ａ、ＩＰ−ＰＢＸ（Interenet Protocol-Private Branch eXchange）１３ａ、衛星ゲートウェイ装置（Ｓａｔ−ＧＷ）１４ａ及びイーサネット（登録商標）ケーブル１５ａを備えており、ＩＰ−ＰＢＸ１３ａは公衆回線網５と接続されている。

超小型地上局１は、回線多重化装置（ＩＰＣＭＥ）１１ｂ、ＩＰ電話（又はターミナルアダプタ）１２ｂ、ＩＰ−ＰＢＸ１３ｂ、衛星ゲートウェイ装置（Ｓａｔ−ＧＷ）１４ｂ及びイーサネット（登録商標）ケーブル１５ｂを備えており、ＩＰ−ＰＢＸ１３ｂは公衆回線網６と接続されている。超小型地上局２は、回線多重化装置（ＩＰＣＭＥ）１１ｃ、ＩＰ電話（又はターミナルアダプタ）１２ｃ、衛星ゲートウェイ装置（Ｓａｔ−ＧＷ）１４ｃ及びイーサネット（登録商標）ケーブル１５ｃを備えている。

センター局１、超小型地上局２及び超小型地上局３において、衛星ゲートウェイ装置１４ａ，１４ｂ，１４ｃは互いに人工衛星４を介して通信を行い、回線多重化装置１１ａ，１１ｂ，１１ｃは、ＳＩＰメッセージを終端・編集・転送するＳＩＰプロキシ機能と、音声データを終端・編集・転送するメディアプロキシ機能と、ショートパケットを多重又は分離するショートパケット多重／分離機能とを一体化したものである。ＩＰ電話１２ａ，１２ｂ，１２ｃ及びＩＰ−ＰＢＸ１３ａ，１３ｂはＳＩＰ方式を採用したＳＩＰ端末で、イーサネット（登録商標）ケーブル１５ａ，１５ｂ，１５ｃは各局における各装置を接続している。
なお、この明細書及び図１では、ルータやスイッチングハブ等のネットワーク機器を省略している。

このように、回線多重化装置１１ａ，１１ｂ，１１ｃがショートパケット多重／分離機能を有していることにより、多重化によるオーバヘッドの削減とパケット数の削減を行うことができ、音声回線の帯域を大幅に削減することができる。そのため、衛星通信、拠点間通信、離島通信に有効に適用することができる。

センター局１、超小型地上局２及び超小型地上局３に設置された回線多重化装置１１ａ，１１ｂ，１１ｃは、ＳＩＰプロキシ機能、メディアプロキシ機能、ショートパケット多重／分離機能を一体化した通信装置であり、この通信装置はセンター局１、超小型地上局２及び超小型地上局３に設置された衛星ゲートウェイ装置１４ａ，１４ｂ，１４ｃに備えられていても良い。

図２はこの発明の実施の形態１による通信システムで使用するＶｏＩＰパケットを示す図である。センター局１、超小型地上局２及び超小型地上局３において、回線多重化装置１１とＩＰ電話１２間の通常のＶｏＩＰパケット（ＲＴＰパケット）はヘッダ部１００と音声符号化された音声データであるペイロード部１０４から構成され、ヘッダ部１００はＩＰヘッダ１０１とＵＤＰヘッダ１０２とＲＴＰヘッダ１０３から構成されている。

回線多重化装置１１間のＶｏＩＰパケット（ＩＰＣＭＥパケット）は、ヘッダ部１００とショートパケット１０５−１，１０５−２，・・・，１０５−ｘから構成され、ヘッダ部１００はＩＰヘッダ１０１とＵＤＰヘッダ１０２とＲＴＰヘッダ１０３から構成され、各ショートパケット１０５−１，１０５−２，・・・，１０５−ｘは、それぞれヘッダ部１０６と音声符号化された音声データであるペイロード部１０７から構成されている。ショートパケット１０５−１，１０５−２，・・・，１０５−ｘは一つのＩＰパケットに複数チャネル分の音声データを収容することが可能である。
ここでは、チャネルとは一通話と同意であるが、多重に際しては同一チャネルの複数のデータが一つのパケットに多重されても構わない。

なお、図２に示すＶｏＩＰパケットは後述の呼接続シーケンスでメディアプロキシ部２２が使用するＶｏＩＰパケットを示し、図２では後述の呼接続シーケンスでＳＩＰプロキシ部２１が使用するパケットは示されていない。

図３はこの発明の実施の形態１による通信システムにおける超小型地上局２とセンター局１の呼接続シーケンスの一例を示す図である。ここでは、ＩＰ電話１２ｂ，１２ａ間の呼接続を行うものとする。図３において、ＩＰＣＭＥドメイン１０ａ，１０ｂは、回線多重化装置１１ａ，１１ｂが音声データを多重する際の多重対象エリアを示し、例えば、a.ipcme.comのようなドメイン表現、又は192.168.1.0/24のようなネットワーク表現が使用され、通常はセンター局１、超小型地上局２及び超小型地上局３の各局単位に設定される。

なお、図３では図示していないが、超小型地上局３の回線多重化装置１１ｃもＩＰＣＭＥドメイン１０ｃを有している。このＩＰＣＭＥドメイン１０ａ，１０ｂ，１０ｃは回線多重化装置１１ａ，１１ｂ，１１ｃに登録されている。

回線多重化装置１１ａ，１１ｂは内部機能エンティティであるＳＩＰプロキシ部２１ａ，２１ｂとメディアプロキシ部２２ａ，２２ｂをそれぞれ備えている。図３では図示していないが、超小型地上局３の回線多重化装置１１ｃも、同様にＳＩＰプロキシ部２１ｃとメディアプロキシ部２２ｃを備えている。

ＳＩＰプロキシ部２１は、音声データを多重する際の自局の多重対象エリアを示すローカルＩＰＣＭＥドメインと相手局の多重対象エリアを示すリモートＩＰＣＭＥドメインを登録し、受信したＳＩＰメッセージの送信元が自局のローカルＩＰＣＭＥドメインと一致し、受信したＳＩＰメッセージの送信先が相手局のリモートＩＰＣＭＥドメインに一致する場合に、受信したＳＩＰメッセージを相手局に転送することにより呼接続制御を行い、相手局から受信したＳＩＰメッセージの送信先が自局のローカルＩＰＣＭＥドメインと一致する場合に、受信したＳＩＰメッセージを自局の送信先に転送する。

メディアプロキシ部２２は、ＳＩＰプロキシ部２１による呼接続制御に基づき、自局の送信元からの音声データのＲＴＰパケットを多重してＩＰＣＭＥパケットを相手局に転送し、相手局から受信したＩＰＣＭＥパケットを分離してＲＴＰパケットを自局の送信先に転送する。

図３において、Ｆ１，Ｆ２，Ｆ３は、超小型地上局２のＩＰ電話１２ｂをオフフックし電話をかけたときに発せられるＩＮＶＩＴＥメッセージ（ＳＩＰメッセージの一つ）のフローであり、Ｆ１０，Ｆ１１，Ｆ１２はセンター局１のＩＰ電話１２ａが受話器を取ったときに発せられる２００ ＯＫメッセージ（ＳＩＰメッセージの一つで、２００番台は成功応答）のフローである。Ｆ１６，Ｆ１８，Ｆ１９，Ｆ２１は通常のＶｏＩＰパケット（ＲＴＰパケット）による音声データのフロー、Ｆ１７，Ｆ２０は回線多重化装置１１ｂ，１１ａ間のＶｏＩＰパケット（ＩＰＣＭＥパケット）による音声データの多重伝送フローである。

Ｆ１１ｓは、Ｆ１１のフローと同時に、回線多重化装置１１ａ内部でＳＩＰプロキシ部２１ａからメディアプロキシ部２２ａへ運用情報を伝えるフローである。Ｆ１２ｓは、Ｆ１２のフローと同時に、回線多重化装置１１ｂ内部でＳＩＰプロキシ部２１ｂからメディアプロキシ部２２ｂへ運用情報を伝えるフローである。

なお、Ｆ１１ｓ及びＦ１２ｓにより伝えられる運用情報とは、Ｆ１７及びＦ２０でのＩＰＣＭＥ待受ポート番号、Ｆ１６及びＦ１９でのＲＴＰ待受ポート番号、チャネルＩＤである。ＩＰＣＭＥ待受ポート番号は予め決めてしまうことも可能であり、その場合は伝達不要である。チャネルＩＤは回線多重化装置１１ｂ，１１ａによる音声データの多重フローＦ１７，Ｆ２０の中で呼を識別するためのＩＤであり、ＳＩＰで伝達されるＣａｌｌ−ＩＤから回線多重化装置１１ｂ，１１ａ間のＶｏＩＰパケットで伝送されるショートパケットヘッダ値へと関連付けられるものである。このチャネルＩＤにより同一のエンド・エンド間の複数呼を識別することができる。

図４はこの発明の実施の形態１による通信システムにおける超小型地上局２とセンター局１の呼接続シーケンスの一例を示す図であり、図３の呼接続シーケンスの詳細を示すものである。
Ｆ１，Ｆ２，Ｆ３はＩＰ電話１２ｂをオフフックし電話をかけたときに発せられるＩＮＶＩＴＥメッセージのフローで、Ｆ４，Ｆ５，Ｆ６は呼接続処理中であることを示す１００Ｔｒｙｉｎｇメッセージ（ＳＩＰメッセージの一つで、１００番台は暫定応答）のフローである。Ｆ７，Ｆ８，Ｆ９は相手呼出中であることを示す１８０Ｒｉｎｇｉｎｇメッセージ（ＳＩＰメッセージの一つ）のフローで、Ｆ１０，Ｆ１１，Ｆ１２は呼接続が受け入れられたことを示す２００ＯＫメッセージのフローである。

Ｆ１３，Ｆ１４，Ｆ１５はＡＣＫメッセージ（ＳＩＰメッセージの一つ）のフローで、Ｆ１６〜Ｆ２１は音声データのフローで、Ｆ１６，Ｆ１８，Ｆ１９，Ｆ２１は通常のＶｏＩＰパケット（ＲＴＰパケット）の伝送のフローで、Ｆ１７，Ｆ２０は回線多重化装置１１ａ，１１ｂ間のＶｏＩＰパケット（ＩＰＣＭＥパケット）による音声データの多重伝送フローである。Ｆ２２〜Ｆ２７はＢＹＥメッセージ（ＳＩＰメッセージの一つ）と２００ＯＫメッセージによる呼切断のフローである。

図４において、Ｆ２，Ｆ４，Ｆ９，Ｆ１２，Ｆ１４，Ｆ２３，Ｆ２７のフローは回線多重化装置１１ｂのＳＩＰプロキシ部２１ｂの処理で、Ｆ３，Ｆ５，Ｆ８，Ｆ１１，Ｆ１５，Ｆ２４，Ｆ２６のフローは回線多重化装置１１ａのＳＩＰプロキシ部２１ａの処理で、Ｆ１７，Ｆ２１の処理はメディアプロキシ部２２ｂの処理で、Ｆ１８，Ｆ２０の処理はメディアプロキシ部２２ａの処理である。
なお、図４で示すシーケンスは説明のため簡略化したものであり、実際にはこの通りでない場合がある。

図５及び図６はこの発明の実施の形態１による通信システムにおける回線多重化装置１１のＳＩＰプロキシ部２１のＩＮＶＩＴＥメッセージの処理例を示すフローチャートである。
前提として、音声データを多重する際の多重対象エリアを示すＩＰＣＭＥドメイン１０は予め回線多重化装置１１に登録されているものとする。また、自局のドメインをローカルＩＰＣＭＥドメインと呼び、相手局のドメインをリモートＩＰＣＭＥドメインと呼ぶ。例えば、超小型地上局２の回線多重化装置１１ｂから見た場合、ＩＰＣＭＥドメイン１０ｂはローカルＩＰＣＭＥドメインで、ＩＰＣＭＥドメイン１０ａ，１０ｃはリモートＩＰＣＭＥドメインである。
ここでは、ＲＦＣ３２６１に基づく標準ＳＩＰ処理以外の回線多重化装置１１特有の処理を中心に、このフローチャートに沿って説明する。

図５において、回線多重化装置１１のＳＩＰプロキシ部２１がＩＮＶＩＴＥメッセージを受信すると、ステップＳＴ１１において、ＳＩＰプロキシ部２１は、送信元ＩＰアドレスが予め登録された相手局の回線多重化装置１１と一致するか否かをチェックする。一致する場合は相手局の回線多重化装置１１から発せられたＩＮＶＩＴＥメッセージであるため図６のステップＳＴ２１へ進み、一致しない場合は自局の回線多重化装置１１以外の例えばＩＰ電話１２やＩＰ−ＰＢＸ１３のＳＩＰ端末からのＩＮＶＩＴＥメッセージであるためステップＳＴ１２へ進む。

ステップＳＴ１２において、ＳＩＰプロキシ部２１は、ＳＩＰ−ＵＲＩ（ＳＩＰ−Uniform Resource Identifier）又はＴｏヘッダの宛先が予め登録されたリモートＩＰＣＭＥドメインにヒットするか否かをチェックする。

ステップＳＴ１２でヒットしない場合は、リモートＩＰＣＭＥドメインを管理している回線多重化装置１１宛てのＩＮＶＩＴＥメッセージでないため、ステップＳＴ１８のＲＦＣ３２６１に基づく標準ＳＩＰ処理へ進み、転送ルールにヒットすればＩＮＶＩＴＥメッセージを転送し、転送ルールにヒットしなければ４０４Ｎｏｔ Ｆｏｕｎｄメッセージ（４００番台はリクエストエラー応答）の応答を行う。ここで、転送ルールとは、例えば、ＳＩＰヘッダのＲｅｃｏｒｄ−Ｒｏｕｔｅに従うルーティングや、ＳＩＰ−ＵＲＩに基づきＳＩＰプロキシ部２１予め設定されたルーティングを示している。
ステップＳＴ１２でヒットする場合は、リモートＩＰＣＭＥドメインを管理している回線多重化装置１１宛てのＩＮＶＩＴＥメッセージであるため、ステップＳＴ１３へ進む。

ステップＳＴ１３において、ＳＩＰプロキシ部２１は、Ｆｒｏｍヘッダで示された端末又は送信元ＩＰアドレスが予め登録されたローカルＩＰＣＭＥドメインにヒットするか否かをチェックする。
ヒットしない場合は多重対象でないため、ステップＳＴ１８のＲＦＣ３２６１に基づく標準ＳＩＰ処理へ進み、ヒットする場合は多重対象であるためステップＳＴ１４へ進む。

ステップＳＴ１４において、ＳＩＰプロキシ部２１は、宛先の回線多重化装置１１のステータス情報が正常か否かをチェックする。ここで、ステータス情報とは、宛先の回線多重化装置１１の生存情報（キープアライブ）、宛先の回線多重化装置１１のエラー情報有無、相手の回線多重化装置１１との帯域制限オーバ、相手の回線多重化装置１１とのチャネル数制限オーバ等である。
これらのステータス情報が異常な場合にはステップＳＴ１９へ進み、送信元へＢＵＳＹメッセージ応答を返して呼接続を拒否し、ＩＮＶＩＴＥメッセージの受信に係るＳＩＰ処理を終了する。ステータス情報が正常な場合はステップＳＴ１５へ進む。

ステップＳＴ１５において、ＳＩＰプロキシ部２１はＳＩＰヘッダにＩＰＣＭＥ−Ｇａｔｅｗａｙヘッダを追加する。ここで追加するＩＰＣＭＥ−Ｇａｔｅｗａｙヘッダは以下のテキストデータから構成されている。
ＩＰＣＭＥ−Ｇａｔｅｗａｙ：＜この回線多重化装置１１のＩＰアドレス＞＜ポート番号＞＜ＩＤ＞＜ＩＰＣＭＥドメイン（オプション）＞
ここで、ポート番号は回線多重化装置１１の待受ポート番号であるが、予め決められていれば不要となる。また、ＩＤはＳＩＰで呼を一意に表すＣａｌｌ−ＩＤに対応するものであり、ショートパケットヘッダと関連付けられるものである。ＩＰＣＭＥドメインは相手側へ自動的にＩＰＣＭＥドメインを追加するためのものであるが、各回線多重化装置１１で予めリモートＩＰＣＭＥを予め登録するようであれば不要である。
なお、後述の図７及び図１０にはＩＰＣＭＥ−Ｇａｔｅｗａｙヘッダの具体的表現例を示している。

ステップＳＴ１５の処理を終了後、ステップＳＴ１６において、ＳＩＰプロキシ部２１はＣａｌｌ−ＩＤをＳＩＰプロキシ部２１の内部に備えているＩＰＣＭＥセッション管理領域へ記憶する。この記憶領域は２００ＯＫを受信した際に参照する。最後に、ステップＳＴ１７において、ＳＩＰプロキシ部２１は、ＲＦＣ３２６１に基づき標準ＳＩＰ処理を実施し、ＳＩＰヘッダの処理後、図３及び図４のフローＦ２に示すように、リモートＩＰＣＭＥドメインを管理する回線多重化装置１１にＩＮＶＩＴＥメッセージを転送する。ここで、ＳＩＰヘッダの処理としては、Ｒｅｃｏｒｄ−ＲｏｕｔｅヘッダにＩＰアドレスを記述した行を追加したり、ＳＩＰ−ＵＲＩを書き換えたりする。

上記ステップＳＴ１３で、Ｆｒｏｍヘッダで示された端末又は送信元ＩＰアドレスがローカルＩＰＣＭＥドメインにヒットしない場合は多重対象でないため、ステップＳＴ１８において、ＳＩＰプロキシ部２１はＲＦＣ３２６１に基づき標準ＳＩＰ処理を実施し、転送ルールにヒットすればＩＮＶＩＴＥメッセージを転送し、ヒットしなければ４０４Ｎｏｔ Ｆｏｕｎｄの応答を行う。

図６の処理はリモートＩＰＣＭＥドメインを管理する回線多重化装置１１から転送されたＩＮＶＩＴＥメッセージの処理であり、ステップＳＴ２１において、ＳＩＰプロキシ部２１は受信したＩＮＶＩＴＥメッセージのＳＩＰヘッダにＩＰＣＭＥ−Ｇａｔｅｗａｙヘッダがあるか否かをチェックする。このＩＰＣＭＥ−Ｇａｔｅｗａｙヘッダがない場合はステップＳＴ２６に進み、通常のＶｏＩＰ処理を実施し、ＲＦＣ３２６１に基づくＳＩＰヘッダの処理後、ＩＰ電話１２等の端末にＩＮＶＩＴＥメッセージを転送する。ＩＰＣＭＥ−Ｇａｔｅｗａｙヘッダがある場合はステップＳＴ２２の処理へ進む。

ステップＳＴ２２において、ＳＩＰプロキシ部２１は受信したＩＮＶＩＴＥメッセージの宛先がローカルＩＰＣＭＥドメインにヒットするか否かをチェックする。ヒットしない場合はステップＳＴ２５に進み、ヒットする場合はステップＳＴ２３の処理へ進む。

ステップＳＴ２３において、ＳＩＰプロキシ部２１はＩＮＶＩＴＥメッセージにおけるＳＤＰの記述の書替処理を実施する。書替対象は、１文字のニーモニック「ｏ＝」のＩＰアドレス、「ｃ＝」のＩＰアドレス、「ｍ＝」のポート番号である。ここで、「ｏ」はセッション開始者とセッションの識別に使用され、「ｃ」はネットワーク種別、アドレス種別、セッション開始者の識別に使用され、「ｍ」はメディア種別、ポート番号、トランスポートプロトコル、メディアリストの識別に識別に使用される。ここでの書替内容は、「ｏ＝」のＩＰアドレスと「ｃ＝」のＩＰアドレスにはこの回線多重化装置１１のＩＰアドレス、ポート番号はこの回線多重化装置１１が待ち受けるＦ１９のフローのＲＴＰ待受ポート番号である。
後述の図８はこのステップＳＴ２３でのＩＮＶＩＴＥメッセージの例であり、アンダーライン部分がＳＤＰの書替部分である。

ステップＳＴ２４において、ＳＩＰプロキシ部２１は、Ｃａｌｌ−ＩＤ、又はＣａｌｌ−ＩＤ，Ｆｒｏｍタグ、Ｔｏタグから成るＣａｌｌダイアログと呼ばれるセットをＳＩＰプロキシ部２１の内部に備えているＩＰＣＭＥセッション管理領域へ記憶する。

ステップＳＴ２５において、ＳＩＰプロキシ部２１は、ＩＰＣＭＥ−Ｇａｔｅｗａｙヘッダに記述されているテキストデータを獲得した後、ＩＰＣＭＥ−Ｇａｔｅｗａｙヘッダを削除する。ここで、テキストデータを獲得する具体的な手段としては、データベースやメモリ上の管理テーブルに記憶しておく方法が考えられる。このような機能及び手段を確保しておけば、ネットワーク運用管理者はテキストデータを予め入力しなくて済み、リモートＩＰＣＭＥドメイン等を予め登録しなくても良い。

最後に、ステップＳＴ２６において、ＳＩＰプロキシ部２１はＲＦＣ３２６１に基づき標準ＳＩＰ処理を実施し、ＳＩＰヘッダの処理後、ＩＰ電話１２等の端末にＩＮＶＩＴＥメッセージを転送する。

図７及び図８は回線多重化装置１１が出力するＩＮＶＩＴＥメッセージの例を示す図である。図７は図３及び図４のＦ２のフロー並びに後述する図１２のＧ２，Ｇ５のフローでの回線多重化装置１１間のＩＮＶＩＴＥメッセージに相当する。図８は図３及び図４のＦ３のフロー並びに後述する図１２のＧ３，Ｇ６のフローでのＩＮＶＩＴＥメッセージに相当する。

図７及び図８に示すＩＮＶＩＴＥメッセージにおいて、空行の上の部分の各行がＳＩＰヘッダであり、図７ではＩＰＣＭＥ−Ｇａｔｅｗａｙヘッダが追加されている。また、空行の下の部分がＳＤＰであり、図８ではＳＤＰの１文字のニーモニック「ｏ＝」のＩＰアドレス、「ｃ＝」のＩＰアドレス、「ｍ＝」のポート番号が書き換えられている。

図９はこの発明の実施の形態１による通信システムにおける回線多重化装置１１のＳＩＰプロキシ部２１の２００ＯＫメッセージの処理例を示すフローチャートである。２００ＯＫメッセージを受信した回線多重化装置１１のＳＩＰプロキシ部２１は、ステップＳＴ３１において、Ｃａｌｌ−ＩＤが図５のステップＳＴ１６又は図６のステップＳＴ２４で登録されているものにヒットするか否かをチェックする。ヒットしない場合は、ステップＳＴ３５の通常のＶｏＩＰ処理へ進み、Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダに記載の転送処理を実施し、ヒットする場合はステップＳＴ３２に進む。

ステップＳＴ３２において、ＳＩＰプロキシ部２１はＩＰＣＭＥ−Ｇａｔｅｗａｙヘッダの有無を調べる。ＩＰＣＭＥ−Ｇａｔｅｗａｙヘッダがある場合は発呼側の回線多重化装置１１としてのステップＳＴ４１の処理へ進み、ＩＰＣＭＥ−Ｇａｔｅｗａｙヘッダがない場合には着呼側の回線多重化装置１１としてのステップＳＴ３３の処理へ進む。

ステップＳＴ３３において、着呼側の回線多重化装置１１のＳＩＰプロキシ部２１はＳＩＰヘッダにＩＰＣＭＥ−Ｇａｔｅｗａｙヘッダを追加する。追加するＩＰＣＭＥ−Ｇａｔｅｗａｙヘッダの内容は図５のステップＳＴ１５の内容と同じである。その後は、ステップＳＴ３４において、ＳＩＰプロキシ部２１はＲＦＣ３２６１に基づき標準ＳＩＰ処理を実施し、Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダに記載の転送処理を実施する。

ステップＳＴ４１において、発呼側の回線多重化装置１１のＳＩＰプロキシ部２１はＳＤＰの記述の書替処理を実施する。書替対象は、「ｏ＝」のＩＰアドレス、「ｃ＝」のＩＰアドレス、「ｍ＝」のポート番号である。ここでの書替内容は、「ｏ＝」のＩＰアドレスと「ｃ＝」のＩＰアドレスにはこの回線多重化装置１１のＩＰアドレス、ポート番号はこの回線多重化装置１１が待ち受ける図３及び図４に示すＦ１６のフローのＲＴＰ待受ポート番号である。後述の図１１はこのステップＳＴ４１での２００ＯＫメッセージの例であり、アンダーライン部分がＳＤＰの書替部分である。

ステップＳＴ４２において、ＳＩＰプロキシ部２１は、図６のステップＳＴ２５と同様に、ＩＰＣＭＥ−Ｇａｔｅｗａｙヘッダに記述されているテキストデータを獲得した後、ＩＰＣＭＥ−Ｇａｔｅｗａｙヘッダを削除する。その後は、ステップＳＴ４３において、ＳＩＰプロキシ部２１は、ＲＦＣ３２６１に基づき標準ＳＩＰ処理を実施し、Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダに記載の転送処理を実施する。

図１０及び図１１は回線多重化装置１１が出力する２００ＯＫメッセージの例を示す図である。図１０は図３及び図４に示すＦ１１のフロー、並びに後述する図１２のＧ８，Ｇ１１のフローでの回線多重化装置１１間のＳＩＰメッセージに相当する。図１１は図３及び図４に示すＦ１２のフロー、並びに後述する図１２のＧ９，Ｇ１２のフローでのＳＩＰメッセージに相当する。

図１０及び図１１に示す２００ＯＫメッセージにおいて、空行の上の部分の各行がＳＩＰヘッダであり、図１０ではＩＰＣＭＥ−Ｇａｔｅｗａｙヘッダが追加されている。また、空行の下の部分がＳＤＰであり、図１１ではＳＤＰの１文字のニーモニック「ｏ＝」のＩＰアドレス、「ｃ＝」のＩＰアドレス、「ｍ＝」のポート番号が書き換えられている。

図１２はこの発明の実施の形態１による通信システムにおける超小型地上局２と超小型地上局３間の呼接続シーケンスを示す図である。この呼接続シーケンスでは、センター局１に設置されたＩＰ−ＰＢＸ１３ａを介して通信する。センター局１において、ＩＰ−ＰＢＸ１３ａには、セカンドコール機能又はＢ２ＢＵＡ機能を搭載しているものとし、回線多重化装置１１ａ−１は超小型地上局２との通信用に設置され、回線多重化装置１１ａ−２は超小型地上局３との通信用に設置されている。回線多重化装置１１ａ−１、回線多重化装置１１ａ−２は一つの回線多重化装置１１ａであっても構わない。
なお、この図１２では、１００Ｔｒｙｉｎｇ、１８０Ｒｉｎｇｉｎｇ、ＰＲＡＣＫ等、この発明と直接関与しないＳＩＰメッセージについては記載を省略している。また、この図１２で示す機器は図１に示す各機器と同一である。

図１２で示す超小型地上局２とセンター局１の通信は、図４で示したシーケンスと同一である。また、図１２で示すセンター局１と超小型地上局３の通信は、図４で示したシーケンスについて、超小型地上局２をセンター局１と置き換え、センター局１を超小型地上局３と置き換えたシーケンスになる。

図１２における各回線多重化装置１１の処理について、Ｇ２，Ｇ３，Ｇ５，Ｇ６，Ｇ８，Ｇ９，Ｇ１１，Ｇ１２，Ｇ１４，Ｇ１５，Ｇ１７，Ｇ１８のフローは、図３に示すＳＩＰプロキシ部２１の処理で、Ｇ２０，Ｇ２１，Ｇ２３，Ｇ２４，Ｇ２６，Ｇ２７，Ｇ２９，Ｇ３０のフローは、図３に示すメディアプロキシ部２２の処理である。

超小型地上局２のＩＰ電話１２ｂが超小型地上局３のＩＰ電話１２ｃに電話をかけると、ＩＰ電話１２ｂはＧ１のフローでＩＮＶＩＴＥメッセージを回線多重化装置１１ｂに発信する。回線多重化装置１１ｂは、図５に示すフローチャートのステップＳＴ１１〜ＳＴ１７の処理を実施し、Ｇ２のフローでＩＮＶＩＴＥメッセージをセンター局１の回線多重化装置１１ａ−１に発信する。

センター局１の回線多重化装置１１ａ−１は、図５及び図６に示すフローチャートのステップＳＴ１１，ＳＴ２１〜ＳＴ２６の処理を実施し、Ｇ３のフローでＩＮＶＩＴＥメッセージをＩＰ−ＰＢＸ１３ａに発信する。ＩＰ−ＰＢＸ１３ａはセカンドコール機能又はＢ２ＢＵＡ機能により、Ｇ４のフローでＧ１〜Ｇ３のフローのＩＮＶＩＴＥメッセージとは独立した新たなＩＮＶＩＴＥメッセージを回線多重化装置１１ａ−２に発信すると共に、超小型地上局３側から２００ＯＫメッセージが来るのを待つ。回線多重化装置１１ａ−２は、図５に示すフローチャートのステップＳＴ１１〜ＳＴ１７の処理を実施し、Ｇ５のフローでＩＮＶＩＴＥメッセージを超小型地上局３の回線多重化装置１１ｃに発信する。

超小型地上局３の回線多重化装置１１ｃは、図５及び図６に示すフローチャートのステップＳＴ１１，ＳＴ２１〜ＳＴ２６の処理を実施し、Ｇ６のフローでＩＮＶＩＴＥメッセージをＩＰ電話１２ｃに発信する。

ＩＰ電話１２ｃは、Ｇ６のフローでＩＮＶＩＴＥメッセージを受信して受話器を取ると、Ｇ７のフローで２００ＯＫメッセージを回線多重化装置１１ｃに発信する。回線多重化装置１１ｃは、図９に示すフローチャートのステップＳＴ３１〜ＳＴ３４の処理を実施し、Ｇ８のフローで２００ＯＫメッセージをセンター局１の回線多重化装置１１ａ−２に発信する。

センター局１の回線多重化装置１１ａ−２は、図９に示すフローチャートのステップＳＴ３１，ＳＴ３２，ＳＴ４１〜ＳＴ４３の処理を実施し、Ｇ９のフローで２００ＯＫメッセージをＩＰ−ＰＢＸ１３ａに発信する。ＩＰ−ＰＢＸ１３ａは超小型地上局３側の呼接続が完了したことを受け、Ｇ１０のフローで２００ＯＫメッセージを回線多重化装置１１ａ−１に発信する。回線多重化装置１１ａ−１は、図９に示すフローチャートのステップＳＴ３１〜ＳＴ３４の処理を実施し、Ｇ１１のフローで２００ＯＫメッセージを超小型地上局２の回線多重化装置１１ｂに発信する。

超小型地上局２の回線多重化装置１１ｂは、図９に示すフローチャートのステップＳＴ３１，ＳＴ３２，ＳＴ４１〜ＳＴ４３の処理を実施し、Ｇ１２のフローで２００ＯＫメッセージをＩＰ電話１２ｂに発信する。

ＩＰ電話１２ｂは、Ｇ１２のフローで２００ＯＫメッセージを受信して、Ｇ１３のフローでＡＣＫメッセージを回線多重化装置１１ｂに返し、Ｇ１９のフローで音声データを乗せたＲＴＰパケットの送出を開始する。ここで、２００ＯＫメッセージに対するＡＣＫメッセージは標準ＳＩＰに沿った処理であり、Ｇ１３〜Ｇ１８のフローで転送されるが、Ｇ１６のフローのＡＣＫメッセージについては、Ｇ１５のフローのＡＣＫメッセージの受信を待つのではなく、Ｇ１０のフローでの２００ＯＫメッセージの発信と同時に発信しても良い。

Ｇ１９のフローでＲＴＰパケットを受信した回線多重化装置１１ｂは、ＲＴＰパケットに含まれる音声データをショートパケットに乗せ、複数のショートパケットがある場合にはそれらを多重したＲＴＰパケットを生成して、Ｇ２０のフローでＩＰＣＭＥパケットをセンター局１の回線多重化装置１１ａ−１に発信する。

センター局１の回線多重化装置１１ａ−１は、Ｇ２０のフローで受信したＩＰＣＭＥパケットを分解してショートパケットを抽出し、Ｇ２１のフローでＶｏＩＰ標準のＲＴＰパケットをＩＰ−ＰＢＸ１３ａに伝送する。ＩＰ−ＰＢＸ１３ａは、セカンドコール機能又はＢ２ＢＵＡ機能により、Ｇ２１のフローで受信したＲＴＰパケットから音声データを取り出すと、音声データをそのままに、Ｇ２２のフローで新たにＶｏＩＰ標準のＲＴＰパケットを回線多重化装置１１ａ−２に送出する。Ｇ２２のフローでＲＴＰパケットを受けた回線多重化装置１１ａ−２は、ＲＴＰパケットに含まれる音声データをショートパケットに乗せ、複数のショートパケットがある場合はそれらを多重したＲＴＰパケットを生成して、Ｇ２３のフローでＩＰＣＭＥパケットを超小型地上局３の回線多重化装置１１ｃに発信する。

超小型地上局３の回線多重化装置１１ｃは、Ｇ２３のフローで受信したＩＰＣＭＥパケットを分解してショートパケットを抽出し、Ｇ２４のフローでＶｏＩＰ標準のＲＴＰパケットをＩＰ電話１２ｃに伝送する。ＩＰ電話１２ｃは、Ｇ２４のフローで受信したＲＴＰパケットから音声データを取り出し、復号処理等を行って受話器へ再生する。
Ｇ２５〜Ｇ３０のフローについては、上記Ｇ１９〜Ｇ２４のフローでの処理と同様である。

以上のように、この実施の形態１によれば、センター局１、超小型地上局２，３の回線多重化装置１１にＳＩＰプロキシ部２１を備え、このＳＩＰプロキシ部２１が例えば図５及び図６に示すＳＩＰメッセージに対する処理を行うことにより、回線多重化装置１１を既存のＳＩＰ端末と共存して運用することができ、また、ＩＰ端末やエンドユーザは回線多重化装置１１の存在を意識せずにシームレスに音声回線を利用することができ、最終的には、通信事業者が回線多重化装置１１の適用で高効率符号化多重伝送の恩恵を受け、音声回線を低コストで効率良く運用することができるという効果が得られる。

また、この実施の形態１によれば、複数の超小型地上局が存在し、さらに、センター局１と超小型地上局２が大規模でＩＰ電話の頻度が高いケースでは、センター局１と超小型地上局２局の間の多重効果を確定することができ、高効率運用が可能となるという効果が得られる。

この発明の実施の形態１による通信システムの構成を示すブロック図である。 この発明の実施の形態１による通信システムで使用するＶｏＩＰパケットを示す図である。 この発明の実施の形態１による通信システムにおける超小型地上局とセンター局の呼接続シーケンスの一例を示す図である。 この発明の実施の形態１による通信システムにおける超小型地上局とセンター局の呼接続シーケンスの一例を示す図である。 この発明の実施の形態１による通信システムにおける回線多重化装置のＳＩＰプロキシ部のＩＮＶＩＴＥメッセージの処理例を示すフローチャートである。 この発明の実施の形態１による通信システムにおける回線多重化装置のＳＩＰプロキシ部のＩＮＶＩＴＥメッセージの処理例を示すフローチャートである。 この発明の実施の形態１による通信システムにおける回線多重化装置が出力するＩＮＶＩＴＥメッセージの例を示す図である。 この発明の実施の形態１による通信システムにおける回線多重化装置が出力するＩＮＶＩＴＥメッセージの例を示す図である。 この発明の実施の形態１による通信システムにおける回線多重化装置のＳＩＰプロキシ部の２００ＯＫメッセージの処理例を示すフローチャートである。 この発明の実施の形態１による通信システムにおける回線多重化装置が出力する２００ＯＫメッセージの例を示す図である。 この発明の実施の形態１による通信システムにおける回線多重化装置が出力する２００ＯＫメッセージの例を示す図である。 この発明の実施の形態１による通信システムにおける超小型地上局間の呼接続シーケンスを示す図である。

符号の説明

１ センター局、２ 超小型地上局、３ 超小型地上局、４ 人工衛星、５ 公衆電話網、６ 公衆電話網、１０ａ，１０ｂ，１０ｃ ＩＰＣＭＥドメイン、１１ａ，１１ｂ，１１ｃ 回線多重化装置、１２ａ，１２ｂ，１２ｃ ＩＰ電話、１３ａ，１３ｂ ＩＰ−ＰＢＸ、１４ａ，１４ｂ，１４ｃ 衛星ゲートウェイ装置、１５ａ，１５ｂ，１５ｃ イーサネット（登録商標）ケーブル、２１ａ ＳＩＰプロキシ部、２１ｂ ＳＩＰプロキシ部、２２ａ メディアプロキシ部、２２ｂ メディアプロキシ部、１００ ヘッダ部、１０１ ＩＰヘッダ、１０２ ＵＤＰヘッダ、１０３ ＲＴＰヘッダ、１０４ ペイロード部、１０５ ショートパケット、１０６ ヘッダ部、１０７ ペイロード部。

Claims (7)

1. 音声データを多重する際の自局の多重対象エリアを示すローカルＩＰＣＭＥ（Cicuit Multiplication Equipment for IP-based networks）ドメインと相手局の多重対象エリアを示すリモートＩＰＣＭＥドメインを登録し、受信したＳＩＰ（Session Initiation Protocol）メッセージの送信元が自局のローカルＩＰＣＭＥドメインと一致し、受信したＳＩＰメッセージの送信先が相手局のリモートＩＰＣＭＥドメインに一致する場合に、受信したＳＩＰメッセージを相手局に転送することにより呼接続制御を行うＳＩＰプロキシ部と、
   該ＳＩＰプロキシ部による呼接続制御に基づき、自局の送信元からの音声データのＲＴＰ（Real-time Transpoprt Protocol）パケットを多重してＩＰＣＭＥパケットを相手局に転送するメディアプロキシ部とを備えた通信装置。
2. ＳＩＰプロキシ部は、相手局から受信したＳＩＰメッセージの送信先が自局のローカルＩＰＣＭＥドメインと一致する場合に、受信したＳＩＰメッセージを自局の送信先に転送し、
   メディアプロキシ部は、相手局から受信したＩＰＣＭＥパケットを分離してＲＴＰパケットを自局の送信先に転送することを特徴とする請求項１記載の通信装置。
3. ＳＩＰプロキシ部は、
   自局のローカルＩＰＣＭＥドメインの送信元からＳＩＰメッセージを受信した場合に、受信したＳＩＰメッセージのＳＩＰヘッダに、自局のローカルＩＰＣＭＥドメインを含むテキストデータを記述したＩＰＣＭＥ−Ｇａｔｅｗａｙヘッダを追加し、
   相手局のリモートＩＰＣＭＥドメインの送信元からＳＩＰメッセージを受信した場合に、ＳＩＰヘッダに追加されているＩＰＣＭＥ−Ｇａｔｅｗａｙヘッダに記述された相手局のリモートＩＰＣＭＥドメインを取得して登録することを特徴とする請求項２記載の通信装置。
4. ＳＩＰプロキシ部が登録するローカルＩＰＣＭＥドメインとリモートＩＰＣＭＥドメインは、ドメイン表現又はネットワーク表現されていることを特徴とする請求項１記載の通信装置。
5. ＳＩＰプロキシ部は、相手局の通信装置のステータス情報が正常か否かをチェックし、異常がある場合には、送信元へＢＵＳＹメッセージ応答を返して呼接続を拒否することを特徴とする請求項１記載の通信装置。
6. センター局及び複数の超小型地上局で構成される衛星回線を利用した通信システムにおいて、
   上記センター局及び上記複数の超小型地上局に請求項１記載の通信装置を備え、
   上記超小型地上局は、上記センター局を介して、ＳＩＰメッセージ及び音声データを相手局の超小型地上局に送信することを特徴とする通信システム。
7. 上記センター局及び上記複数の超小型地上局に設置され人工衛星との通信を行う衛星ゲートウェイ装置の内部に上記通信装置を設置することを特徴とする請求項６記載の通信システム。

Images