JP2010062776A - 接続制御装置 - Google Patents

Abstract

【課題】通信端末間のデータ通信の信頼性の向上を図る、ことにある。
【解決手段】接続制御装置は、通信端末間にて送受信される接続制御メッセージを中継して、当該通信端末間の接続制御を行う接続制御手段を備えている。そして、接続制御手段は、中継する上記接続制御メッセージに含まれる上記通信端末で使用可能な通信データの符号化形式を表すコーデック情報を予め設定されたコーデック設定情報に基づいて書き換えるコーデック情報書換手段と、当該コーデック情報書換手段による書き換えによって変化する上記接続制御メッセージのデータ構造に対応して当該接続制御メッセージ内の特定の情報を書き換えて上記接続制御メッセージを再構築するメッセージ再構築手段と、を備える。
【選択図】図２

Description

本発明は、接続制御装置にかかり、特に、ネットワーク上に接続された通信端末間の接続制御を行う接続制御装置に関する。

近年、ネットワーク技術の進歩に伴い、音声や動画といった様々なメディアデータの通信が実現可能となっている。例えば、音声通話では、通話端末間の接続制御（呼制御）をＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）といったプロトコルを用いて実現し、その後、ＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）にて音声データの通信を行う。

一方で、メディアデータの通信では、様々なコーデック（符号化形式）が存在しており、通信端末間でサポートされているコーデックにて、音声データなどのデータ通信を行う必要がある。例えば、上述したＳＩＰでは、端末が対応する音声コーデック種別を、ＳＩＰメッセージのメッセージボディにＳＤＰ（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ）として格納し、これにより相手側に通知している。これにより、各端末がこのメッセージを参照することで、送受信する音声データのコーデック種別を決定し、通信を行う。

ところが、上述した通信方法では、サポートされているコーデック種別の異なる端末間では、通話接続を行うことができない。従って、ＳＩＰ通信におけるメディアネゴシエーションを統一したい場合には、使用するＳＩＰ−ＵＡ（Ｕｓｅｒ Ａｇｅｎｔ）端末すべての設定を変更する必要があるが、その場合には、端末台数が多いほど運用コストが増加する、という問題が生じる。

これに対して、特許文献１では、端末間の通話においてＳＩＰ制御メッセージ及び音声データパケットの中継点として機能する音声データ変換を行う音声変換装置を備えている。そして、この音声変換装置が、ＳＩＰメッセージのＳＤＰ部のメディア情報を、呼の接続先端末のコーデック種別に従って編集する、という機能を有している。具体的には、音声変換装置は、一方の端末から当該端末が対応する音声コーデックの情報を含むメッセージを受信すると、音声変換装置自身が処理可能な音声コーデックを他方の端末に送信するメッセージに書き込む。これにより、端末間で使用するコーデックを一致させ、以降のＲＴＰの音声データの転送の際に、指定されたコーデック情報をもとに、音声コーデックの変換を実行する。

特開２００７−４９４１５号公報

しかしながら、上述した技術では、ＳＤＰ部分の書換え後に、ＳＩＰメッセージ内のＳＤＰ部分のサイズ（Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈヘッダ）が変更されている可能性がある。すると、かかるメッセージが送信されたＳＩＰサーバやＳＩＰ−ＵＡで、ＳＤＰが正しく解釈されないおそれがあり、コーデック変換を実現できない場合が生じうる。その結果、データ通信の信頼性が低下する、という問題が生じる。

このため、本発明の目的は、上述した課題である、通信端末間のデータ通信の信頼性の向上を図る、ことにある。

かかる目的を達成するため本発明の一形態である接続制御装置は、
通信端末間にて送受信される接続制御メッセージを中継して、当該通信端末間の接続制御を行う接続制御手段を備え、
上記接続制御手段は、中継する上記接続制御メッセージに含まれる上記通信端末で使用可能な通信データの符号化形式を表すコーデック情報を予め設定されたコーデック設定情報に基づいて書き換えるコーデック情報書換手段と、当該コーデック情報書換手段による書き換えによって変化する上記接続制御メッセージのデータ構造に対応して当該接続制御メッセージ内の特定の情報を書き換えて上記接続制御メッセージを再構築するメッセージ再構築手段と、を備えた、
ことを特徴とする。

また、本発明の他の形態であるプログラムは、
通信端末間にて送受信される接続制御メッセージを中継して、当該通信端末間の接続制御を行うコンピュータに、
中継する上記接続制御メッセージに含まれる上記通信端末で使用可能な通信データの符号化形式を表すコーデック情報を予め設定されたコーデック設定情報に基づいて書き換えるコーデック情報書換手段と、当該コーデック情報書換手段による書き換えによって変化する上記接続制御メッセージのデータ構造に対応して当該接続制御メッセージ内の特定の情報を書き換えて上記接続制御メッセージを再構築するメッセージ再構築手段と、
を実現させるためのプログラムである。

また、本発明の他の形態である接続制御方法は、
通信端末間にて送受信される接続制御メッセージを中継して、当該通信端末間の接続制御を行う接続制御工程を有し、
上記接続制御工程は、中継する上記接続制御メッセージに含まれる上記通信端末で使用可能な通信データの符号化形式を表すコーデック情報を予め設定されたコーデック設定情報に基づいて書き換えるコーデック情報書換工程と、当該コーデック情報書換工程による書き換えによって変化する上記接続制御メッセージのデータ構造に対応して当該接続制御メッセージ内の特定の情報を書き換えて上記接続制御メッセージを再構築するメッセージ再構築工程と、を有する、
ことを特徴とする。

本発明は、以上のように構成されることにより、通信端末間におけるデータ通信の信頼性の向上を図ることができる。

本発明の一形態である接続制御装置は、
通信端末間にて送受信される接続制御メッセージを中継して、当該通信端末間の接続制御を行う接続制御手段を備え、
上記接続制御手段は、中継する上記接続制御メッセージに含まれる上記通信端末で使用可能な通信データの符号化形式を表すコーデック情報を予め設定されたコーデック設定情報に基づいて書き換えるコーデック情報書換手段と、当該コーデック情報書換手段による書き換えによって変化する上記接続制御メッセージのデータ構造に対応して当該接続制御メッセージ内の特定の情報を書き換えて上記接続制御メッセージを再構築するメッセージ再構築手段と、を備えた、
ことを特徴とする。

そして、上記接続制御装置では、
上記メッセージ再構築手段は、上記特定の情報として、上記接続制御メッセージ内の特定範囲のデータサイズを表すデータサイズ情報を書き換える、
ことを特徴とする。

また、上記接続制御装置では、
上記メッセージ再構築手段は、上記コーデック情報書換手段にて上記接続制御メッセージ内に上記コーデック情報を追加したときに、上記データサイズ情報を書き換える、
ことを特徴とする。

また、上記接続制御装置では、
上記接続制御メッセージは、ＳＩＰ（Session Initiation Protocol）メッセージであり、
上記メッセージ再構築手段は、上記ＳＩＰメッセージに含まれるメッセージボディのデータサイズを上記データサイズ情報として書き換える、
ことを特徴とする。

上記発明によると、使用可能な通信データの符号化形式が異なる通信端末間において接続制御メッセージの送受信が行われる際に、当該接続制御メッセージを中継する接続制御装置が、接続制御メッセージに含まれる符号化形式を表すコーデック情報を書き換える。このとき、一方の通信端末から他方の通信端末に接続要求するときには、両通信端末でサポートされている符号化形式が含まれるようコーデック情報を書き換える。すると、コーデック情報の書き換えにより、接続制御メッセージのデータ構造、例えば、ＳＩＰ（Session Initiation Protocol）メッセージに含まれるメッセージボディのデータサイズが変化する。このため、接続制御装置は、データ構造（データサイズ）の変化に対応するよう、接続制御メッセージ内のデータサイズを表すデータサイズ情報を書き換える。このようにして接続制御メッセージを再構築して、当該接続制御メッセージを送信先となる通信端末に中継送信する。

これにより、接続制御メッセージが適切な情報となるため、接続制御装置や通信端末間で正常に解釈され、確実な接続制御メッセージのやり取りを実現できる。従って、両通信端末がそれぞれサポートしている符号化形式（こーデック）で通信できるよう、通信データのコーデック変換を行うことができる。その結果、確実にデータ通信を行うことができ、データ通信の信頼性の向上を図ることができる。

また、上記接続制御装置では、
上記コーデック情報書換手段は、予め設定された符号化形式の使用優先度を表す優先度情報に基づいて、上記通信端末が使用する符号化形式の優先順位を変更するよう上記接続制御メッセージ内の上記コーデック情報を書き換える、
ことを特徴とする。

これにより、両通信端末が共通の符号化形式（コーデック）を使用可能である場合に、優先されたコーデックを使用した通信を実現できる。その結果、両通信端末が確実にデータ通信を行うことができ、データ通信の信頼性の向上を図ることができる。

また、上記接続制御装置では、
上記接続制御手段は、上記コーデック情報書換手段による上記接続制御メッセージ内の上記コーデック情報の書き換えに対応して、上記通信端末間で上記通信データを送受信可能なよう当該通信データの符号化形式を変換するルールを表すコーデック変換テーブルを設定する、
ことを特徴とする。

また、上記接続制御装置では、
上記通信端末間で送受信される通信データを中継するデータ中継手段を備え、
上記データ中継手段は、上記コーデック変換テーブルに基づいて上記通信データの符号化形式を変換して当該通信データを中継する、
ことを特徴とする。

これにより、上述したコーデック情報の書き換えに応じて、通信端末間において送受信される通信データのコーデック変換ルールを表すコーデック変換テーブルを設定する。従って、かかるコーデック変換テーブルを用いることで、接続制御装置は、通信端末間における通信データを各通信端末が使用可能な符号化形式に適切に変換することができる。その結果、両通信端末が確実にデータ通信を行うことができ、データ通信の信頼性の向上を図ることができる。

また、本発明の他の形態であるプログラムは、
通信端末間にて送受信される接続制御メッセージを中継して、当該通信端末間の接続制御を行うコンピュータに、
中継する上記接続制御メッセージに含まれる上記通信端末で使用可能な通信データの符号化形式を表すコーデック情報を予め設定されたコーデック設定情報に基づいて書き換えるコーデック情報書換手段と、当該コーデック情報書換手段による書き換えによって変化する上記接続制御メッセージのデータ構造に対応して当該接続制御メッセージ内の特定の情報を書き換えて上記接続制御メッセージを再構築するメッセージ再構築手段と、
を実現させるためのプログラムである。

そして、上記プログラムでは、上記メッセージ再構築手段は、上記特定の情報として、上記接続制御メッセージ内の特定範囲のデータサイズを表すデータサイズ情報を書き換える、
ことを特徴とする。

また、本発明の他の形態である接続制御方法は、
通信端末間にて送受信される接続制御メッセージを中継して、当該通信端末間の接続制御を行う接続制御工程を有し、
上記接続制御工程は、中継する上記接続制御メッセージに含まれる上記通信端末で使用可能な通信データの符号化形式を表すコーデック情報を予め設定されたコーデック設定情報に基づいて書き換えるコーデック情報書換工程と、当該コーデック情報書換工程による書き換えによって変化する上記接続制御メッセージのデータ構造に対応して当該接続制御メッセージ内の特定の情報を書き換えて上記接続制御メッセージを再構築するメッセージ再構築工程と、を有する、
ことを特徴とする。

そして、上記接続制御方法では、
上記メッセージ再構築工程は、上記特定の情報として、上記接続制御メッセージ内の特定範囲のデータサイズを表すデータサイズ情報を書き換える、
ことを特徴とする。

上述した構成を有する、プログラム、又は、接続制御方法、の発明であっても、上記接続制御装置と同様の作用を有するために、上述した本発明の目的を達成することができる。

以下、本発明に係る、接続制御装置、プログラム、及び、接続制御方法、の各実施形態について図１乃至図１５を参照しながら説明する。

＜実施形態１＞
本発明の第１の実施形態を、図１乃至図１２を参照して説明する。図１は、通信システム全体の構成を示す図である。図２は、ＳＩＰサーバの構成を示す機能ブロック図である。図３は、ＳＩＰメッセージのデータ構造を示す図である。図４乃至図６は、ＳＩＰサーバに記憶されるデータの構造を示す図である。図７は、通信システム全体の動作を示すシーケンス図である。図８乃至図９は、ＳＩＰサーバの動作を示すフローチャートである。図１０乃至図１２は、ＳＩＰメッセージの送受信の具体例を示す図である。

［構成］
本実施形態における通信システムは、ＩＰ電話などのユーザ端末１０１，２０１間をＳＩＰ（Session Initiation Protocol）を用いて接続するシステムである。具体的には、図１に示すように、ユーザ端末１０１，２０１はそれぞれ異なるネットワーク網Ｎ１，Ｎ２に接続している。また、それぞれのネットワーク間Ｎ１，Ｎ２のルーティングを行うルータ１０２，２０２が、上記ネットワーク網Ｎ１，Ｎ２に接続している。そして、各ネットワーク網Ｎ１，Ｎ２は、各ルータ１０２，２０２を経由してＩＰ網などのネットワークＮ３を介して接続している。また、各ネットワークＮ１，Ｎ２にはそれぞれＳＩＰサーバ１００，２００が接続されており、ユーザ端末１０１，２０１間の接続制御を行う。

そして、具体的にＳＩＰサーバ１００，２００は、ユーザ端末１０１，２０１から送信されるＳＩＰメッセージ（接続制御メッセージ）を送受信することにより、これらユーザ端末１０１，２０１間のセッションを確立する。さらに、本実施形態におけるＳＩＰサーバ１００，２００は、セッションが確立されたユーザ端末１０１，２０１間の音声データ（通信データ）を中継する機能を有し、ユーザ間の音声通話を可能としている。特に、符号１００に示すＳＩＰサーバは、音声データの符号化形式（コーデック）を変換する機能を有している。以下、ＳＩＰサーバ１００の構成について詳述する。

ＳＩＰサーバ１００は、演算装置と記憶装置を備えたコンピュータにて構成されており、通信手段としてＬＡＮ（Local Area Network）インタフェース１１０を備えている。そして、ＬＡＮインタフェース１１０は、パケット受信部１１１と、パケット送信部１１２を有している。パケット受信部１１１は、ネットワークＮ１を介して受信したパケットデータをプロトコル制御部１２０に渡す。また、パケット送信部１１２は、プロトコル制御部１２０から渡されたパケットデータをネットワークＮ１に送出する。

また、ＳＩＰサーバ１００は、演算装置（図示せず）にプログラムが組み込まれることによって構築される種々の処理を実行する各処理部を備えている。具体的に、ＳＩＰサーバ１００は、図２に示すように、プロトコル制御部１２０と、ＳＩＰ制御部１３０と、メディア制御部１４０と、を備えている。また、ＳＩＰサーバ１００は、記憶装置（図示せず）に、ＳＩＰセッション管理テーブル１５０と、装置設定データ１６０と、メディア変換管理テーブル１７０と、を記憶している。以下、各構成について詳述する。

上記プロトコル制御部１２０は、ＬＡＮインタフェース１１０にて受信したパケットデータを分析し、プロトコル種別を判別する。そして、受信したパケットデータがＳＩＰプロトコルの場合には、当該パケットデータをＳＩＰ制御部１３０に渡す。また、パケットデータが、セッションが確立された後にユーザ端末１０１，２０１間で送受信される音声データであってＲＴＰあるいはＲＴＣＰの場合には、当該パケットデータをメディア制御部１４０に渡す。また、プロトコル制御部１２０は、ＳＩＰ制御部１３０及びメディア制御部１４０から渡されたデータからパケットデータを構築し、ＬＡＮインタフェース１１０に渡す。

上記ＳＩＰ制御部１３０（接続制御手段）は、上述したように、ＳＩＰプロトコルのパケットデータ、つまり、ＳＩＰメッセージ（接続制御メッセージ）を処理する機能を有する。そして、ＳＩＰ制御部１３０は、図２に示すように、ＳＩＰ処理部１３１と、ＳＤＰ処理部１３２と、を有している。

ここで、上記ＳＩＰ制御部１３０で処理するＳＩＰメッセージについて説明する。ＳＩＰメッセージ１０のデータ構造を図３（ａ）に示す。この図に示すＳＩＰメッセージ１０は、接続要求の際に用いられる「Initial-INVITEリクエスト」であり、ＳＩＰプロトコルで記述されたＳＩＰ部分１１と、メッセージボディ部分でありＳＤＰプロトコルで記述されたＳＤＰ部分１２と、を有している。そして、ＳＤＰ部分１２は、さらに、セッション記述部１３と、メディア記述部１４を有している。なお、図３（ｂ）は、ＳＤＰ部分１２内の各項目のパラメータを示している。このようなＳＩＰメッセージを、まず、ＳＩＰ処理部１３１が処理する。

そして、上記ＳＤＰ部分１２は、ユーザ端末１０１，２０１間で音声データのコーデックを対応させる処理であるメディアネゴシエーションを行うために用いられる。このとき、ＳＤＰは、オファー・アンサーモデルで行われる。例えば、上記「Initial-INVITEリクエスト」にはＳＤＰオファーが含まれ、そのレスポンスメッセージである「200 OK」にはＳＤＰアンサーが含まれる。従って、以下に説明するＳＩＰ制御部１３０による処理は、主にメディアネゴシエーションの必要があってＳＤＰオファー・アンサーモデルとなる他のメッセージ、例えば、「re-INVITEリクエスト」、「UPDATEリクエスト」、それらのレスポンス「200 OK」にも適用される。

そして、上記ＳＩＰ処理部１３１は、主に受信したＳＩＰメッセージを解析し、ユーザ端末１０１，２０１間のセッション制御（呼制御）を行う。具体的に、図３（ａ）に示すような「Initial-INVITEリクエスト」を処理する場合、まず、「Call-IDヘッダ」、「Fromヘッダ」、「Toヘッダ」の内容を、ＳＩＰセッション管理テーブル１５０に登録する。なお、ＳＩＰセッション管理テーブル１５０は、「Call-IDヘッダ」の値で、ＳＩＰセッションを一意に識別することが可能である。このため、ＳＩＰ処理部１３１は、ＳＩＰメッセージを受信すると、当該ＳＩＰメッセージを分析し、まず「Call-IDヘッダ」値を抽出する。そして、ＳＩＰセッション管理テーブル１５０に対して、「Call-ID値」を検索する。このＳＩＰセッション管理テーブル１５０に該当する「Call-ID値」がない場合、受信したＳＩＰメッセージは「Initial-INVITEリクエスト」であると判断し、ＳＩＰセッション管理テーブル１５０に、「Call-ID」、「From」、「To」ヘッダ値を登録する。そして、ＳＩＰ処理部１３１は、「Fromヘッダ」をチェックして、予め記憶されている装置設定データ１６０（後述する）にメディア変換を適用するユーザ端末（ＳＩＰ−ＵＲＩ）として設定されている場合には、以降の処理を実行する。

そして、上記「Initial-INVITEリクエスト」には上述したように「SDPオファー」が含まれているため、ＳＩＰ処理部１３１は、メッセージボディ部分であるＳＤＰ部分１２をＳＤＰ処理部１３２に渡す。なお、「re-INVITEリクエスト」、「UPDATEリクエスト」のときも同様であり、これらに含まれるＳＤＰオファーであるＳＤＰ部分１２をＳＤＰ処理部１３２に渡す。また、上述した「各リクエスト」に対するレスポンス「200 OK」に含まれるＳＤＰは、ＳＤＰアンサーであるが、かかるメッセージに含まれるＳＤＰ部分１２もＳＤＰ処理部１３２に渡す。なお、「Initial-INVITEリクエスト」に関しては、暫定応答である「180 RINGING」にＳＤＰが含まれる場合があるが、そのSDPはアンサーである。

そして、上記ＳＤＰ処理部１３２（コーデック情報書換手段）は、渡されたＳＤＰオファー、あるいは、ＳＤＰアンサーであるＳＤＰ部分１２の解析・再構築を行う。具体的に、ＳＤＰ処理部１３２は、まず、ＳＤＰを解析し、記述されているすべての情報（「v=」行、「o=」行、「s=」行、「m=」行、「a=」行など）を、ＳＩＰセッション管理テーブル１５０内のＳＤＰセッション管理テーブル１５１に登録（コピー）する。なお、ＳＤＰセッション管理テーブル１５１は、受信したＳＤＰのコピーデータ、および、メディア情報に関して再構築された送信するＳＤＰのデータを保持している（図５参照）。そして、ＳＤＰの再構築としては、上述したセッション記述部１３、メディア記述部１４、の変更を行う。特に、メディア記述部１４の変更は、予め設定されている装置設定データ１６０に基づいて、「m=」行にある<media>、<port>、<proto>、<fmt>を変更する。なお、SDPは、インターネットに関する技術標準を規定したRFC（Request For Comment）4566に則った記述をするものとする。

ここで、上述した装置設定データ１６０は、上述したＳＩＰメッセージ内に含まれるコーデック情報を書き換えるための情報（コーデック設定情報）であって、予め登録されている情報である。具体的に、装置設定データ１６０は、図４に示すように、まず、コーデック情報を書き換える対象となるユーザ端末を特定する情報である「メディア変換機能を適用するＳＩＰ端末情報（ＳＩＰ−ＵＲＩ）」を含む。また、ユーザ端末間で使用する音声データの符号化形式（コーデック）を表すペイロードタイプの優先度を表す「ペイロードタイプ優先度情報」を含む。また、この優先度を適用するか否かを表す「ペイロードタイプ優先度制御実行フラグ」を含む。なお、上記「ペイロードタイプ優先度情報」は、「ペイロードタイプ」と、その「優先度」が対応づけられて記憶されている。

さらに、上記装置設定データ１６０は、ＳＩＰサーバ１００にて変換可能な音声データの符号化形式（コーデック）であり、中継するＳＩＰメッセージ内に追加する符号化形式を表す情報（ペイロードタイプ）である「追加するペイロードタイプの指定リスト」を含む。また、装置設定データ１６０は、ユーザ端末１０１，２０１間でセッション確立後に送受信される音声データを受信するＳＩＰサーバ１００上の「ＲＴＰポート番号」を含む。

そして、上述した装置設定データ１６０を参照して、ＳＤＰ処理部１３２は、ＳＤＰ部分１２の解析・再構築処理について説明する。ここで、ＳＤＰ処理部１３２は、受信したＳＤＰがＳＤＰオファーである場合には、図８に示すアルゴリズムにより解析及び再構築を行う。これについて詳述する。
（１）「m=」行を分析する。
（２）装置設定データ１６０内の「ペイロードタイプ優先度制御実行フラグ」を参照し、ペイロードタイプ優先度制御を実行するかしないか判定する。
（３）装置設定データ１６０内の「ペイロードタイプ優先度情報」を参照し、<fmt>にあるペイロードタイプの順番を入れ替える。
（４）装置設定データ１６０内の「追加するペイロードタイプの指定リスト」と比較し、分析した「m=」行に不足しているペイロードタイプの有無を判定する。
（５）ペイロードタイプを追加する場合は、それを<fmt>に追加し、ＳＩＰセッション管理テーブル１５０内の該当するＳＩＰセッション情報にＳＤＰ変更フラグを設定する（図５参照）。
（６）<port>を設定する。ここで、設定するポート番号は、ＳＩＰサーバ１００のメディア中継用インタフェースで使用するメディア受信用のポートを設定する。このとき、既に使用中のポート番号を使用してはならない。
（７）追加したペイロードタイプごとに、その属性を指定する必要があり、「a=」行で設定する。
（８）メディア記述部に「c=」行を追加する。<connection-address>をＳＩＰサーバ１００のメディア中継用インタフェースのＩＰ（Internet Protocol）アドレスに書き換える。

そして、上記処理（１）〜（８）を、すべての「m=」行に対して実行する。なお、上記（２）の処理で、ペイロードタイプの順番を入れ替えるだけの変更を行った場合は、上記（５）の処理で、ＳＤＰ変更フラグは設定しない。これは、優先度の変更によるＳＩＰメッセージの書き換えは、ＳＤＰのサイズの変更を伴わないからである。また、上記（４）の処理で、不足しているペイロードタイプがないと判断された場合は、ＳＤＰの変更は何もしない。

また、ＳＤＰ処理部１３２は、受信したＳＤＰがＳＤＰアンサーである場合には、図９に示すアルゴリズムにより解析及び再構築を行う。これについて詳述する。
（１）「m=」行を分析する。
（２）ＳＤＰアンサーに含まれる選択されたペイロードタイプは、ＳＩＰサーバ１００でＳＤＰオファーに対して追加したペイロードタイプかどうかを判定する。具体的には、ＳＤＰアンサーに含まれるペイロードタイプが、装置設定データ１６０の追加ペイロードタイプに含まれているか否かを判定する。
（３）上記ペイロードタイプがＳＩＰサーバ１００で追加したペイロードタイプである場合、それは、ＳＩＰサーバ１００で変換する必要があるペイロードであるため、<fmt>及び<port>を設定する。具体的には、追加したペイロードタイプに替えて、ＳＤＰセッション管理テーブル１５１に記憶している対応するＳＤＰオファーに含まれていたペイロードタイプに設定する。また、設定するポート番号は、ＳＩＰサーバ１００のメディア中継用インタフェースで使用するメディア受信用のポートを設定する。このとき、既に使用中のポート番号を使用してはならない。さらに、ＳＤＰ変更フラグを設定する。
（４）セッション記述部に「c=」行を追加する。<connection-address>を本装置のメディア中継用インタフェースのIPアドレスに書き換える。

そして、上記処理（１）〜（４）を、すべての「m=」行に対して実行する。なお、上記処理（２）で、ＳＤＰアンサー内に含まれる選択されたペイロードタイプが本装置で追加したペイロードタイプではないと判断された場合は、SDPの変更はしない。

その後、上述したように、ＳＤＰ処理部１３２でＳＤＰを再構築した後に、かかるＳＤＰ部分１２のデータをＳＩＰ処理部１３１に渡す。

また、ＳＤＰ処理部１３２は、さらに、上述したＳＤＰオファー・アンサー内のペイロードタイプ（コーデック情報）の書き換えに対応して、ユーザ端末１０１，２０１間における音声データ通信時の符号化形式の変換ルールを表すメディア変換管理テーブル１７０（コーデック変換テーブル）を設定記憶する。具体的に、上記ＳＤＰ処理部１３２は、ＳＤＰオファー・アンサーの書き換え前後の情報をＳＩＰセッション管理テーブル１５０に記憶しておく。そして、ＳＤＰ処理部１３２は、これら書き換え前後の情報に基づいて、両ユーザ端末１０１，２０１が音声データの送受信を行うことが可能なよう、コーデックの変換ルールを表すコーデック変換情報をメディア変換管理テーブル１７０に記憶する。このとき、メディア変換管理テーブル１７０には、図６に示すように、識別子、ポート番号、ＩＰアドレス、コーデック変換有無フラグ、変換先コーデック種別、を含む。

そして、ＳＩＰ処理部１３１は、ＳＩＰセッション管理テーブル１５１から、ＳＤＰ変更フラグを参照する。このとき、ＳＤＰオファーを処理する際に、ＳＤＰ変更フラグが設定されている場合は、ＳＤＰサイズを計算し、「Content-Lengthヘッダ」を書き換える。その後、「Initial-INVITEリクエスト」を再構築し、プロトコル制御部１２０に渡す。つまり、ＳＩＰ処理部１３１は、上述したＳＤＰ処理部１３２によるペイロードタイプ（コーデック情報）の追加によって変化するメッセージボディ部分のデータサイズを計算し、かかるデータサイズ情報を書き換えてＳＩＰメッセージを再構築するメッセージ再構築手段として機能する。これによって、ＳＤＰ部分のサイズ（Content-Lengthヘッダ）が適切となったＳＩＰメッセージを中継することができる。

また、上記メディア制御部１４０は、ＲＴＰ制御部１４１と、ＲＴＣＰ制御部１４２と、コーデック変換部１４３と、を有しており、ユーザ端末１０１，２０１間で送受信される音声データなどの通信データを中継するデータ中継手段として機能する。このとき、メディア制御部１４０は、さらに、上述したメディア変換管理テーブル１７０に基づいて、中継する音声データの符号化形式（コーデック）を変換して、当該音声データを中継する。

具体的に、メディア制御部１４０に含まれるＲＴＰ制御部１４１は、プロトコル制御部１２０から渡されたＲＴＰパケットを分析し、送信元ＩＰアドレス、送信元ＩＰアドレス、送信元ポート番号、送信先ポート番号を抽出する。そして、メディア変換管理テーブル１７０から送信先のＩＰアドレス、送信元ＩＰアドレス、送信元ポート番号、送信先ポート番号を読出し、コーデック変換の有無をチェックする。コーデック変換する場合は、コーデック変換部１４３にデータを渡す。コーデック変換をしない場合は、ＲＴＰヘッダを書換えて、プロトコル制御部１２０にデータを渡す。

そして、コーデック変換部１４３は、ＲＴＰ制御部１４１から受け取ったデータのコーデック変換を行い、コーデック変換後にＲＴＰ制御部１４１にデータを渡す。また、ＲＴＣＰ制御部１４２は、ＳＩＰサーバ１００自体が送受信するＲＴＰデータに関するＲＴＣＰ（RTP Control Protocol）を作成し、プロトコル制御部１２０に渡す。これにより、ＳＩＰサーバ１００にて、音声データを各ユーザ端末１０１，２０１がそれぞれ対応するコーデックに変換することができる。

［動作］
次に、上記構成の通信システムの動作を、図７乃至図１２を参照して説明する。図７は、ユーザ端末１０１からユーザ端末２０１に発信して、音声通話を行う場合のシーケンス図を示している。そして、図７では、メディア変換機能付きＳＩＰサーバ１００によるパケットを処理するタイミングをそれぞれ処理Ａ〜Ｆとして表しており、以下では、かかる処理について主に説明する。なお、処理Ａ〜Ｅでは、ユーザ端末１０１，２０１間のＳＩＰメッセージを中継して接続制御しており（接続制御工程）、処理Ｆでは、ユーザ端末１０１，２０１でセッションを確立し、音声データの送受信を行っている。

まず、「処理Ａ」について説明する。ＳＩＰサーバ１００は、ユーザ端末１００から「Initial-INVITE」を受信すると、パケット受信部１１１からプロトコル制御部１２０へデータを渡す。このとき、受信したデータは、ＳＩＰプロトコルであるため、プロトコル制御部１２０からＳＩＰ制御部１３０へデータを渡す。

続いて、ＳＩＰ処理部１３１は、「Initial-INVITE」を分析し、その中の「Call-IDヘッダ値」を抽出して、ＳＩＰセッション管理テーブル１５０内から「Call-ID値」を検索する。このとき、ＳＩＰセッション管理テーブル１５０内に該当する「Call-ID値」がない場合には、それは、「Initial-INVITE」であると判断し、ＳＩＰセッション管理テーブル１５０に、「Call-ID」、「From」、「To」ヘッダ値を登録する。そしてさらに、「Fromヘッダ」をチェックして、「Initial-INVITE」を発信したユーザ端末１０１が装置設定データ１６０内のメディア変換機能を適用する「SIP-URI」として設定されている場合には、以降の処理であるＳＤＰ処理を実行する。

具体的に、ＳＩＰ処理部１３１は、「Initial-INVITE」にはＳＤＰオファーが含まれているため、ＳＩＰメッセージ１０に含まれているＳＤＰ部分１２をＳＤＰ処理部２２２に渡す。そして、ＳＤＰ処理部１３２は、渡されたＳＤＰ部分１２を「ＳＤＰオファーＡ」としてＳＤＰオファーをコピーし、図５に示すように、ＳＩＰセッション管理テーブル１５０内のＳＤＰセッション管理テーブル１５１に登録する。

その後、ＳＤＰ処理部１３２は、図８に示すＳＤＰオファー変換アルゴリズムを実行する。まず、「ＳＤＰオファーＡ」を分析して（図８の処理（１））、セッション記述部、メディア記述部の変更を行う。このとき、装置設定データ１６０に「ペイロードタイプ優先度制御実行フラグ」が設定されている場合には、その優先度に基づいて、ＳＤＰオファーに含まれているペイロードタイプの優先度、つまり、記載順序を変更する（図８の処理（２）でＹＥＳ，処理（３））。

また、装置設定データ１６０に追加するペイロードタイプが設定されている場合には（図８の処理（４）でＹＥＳ）、かかるペイロードタイプをＳＤＰオファーに追加する。具体的には、メディア記述部の「m=」行にあるポート番号<port>を変更し、ペイロードタイプ<fmt>を追加する（図８の処理（５），（６）、コーデック情報書換工程）。

ここで、上記処理の一例を示す。まず、「m=」行は以下の書式である。
「m=<media> <port> <proto> <fmt>」
そして、例えば、
「m=audio 8002 RTP/AVP 0 8 」を、
「m=audio 30000 RTP/AVP 0 8 18 」
のように、ポート番号を変更し、ペイロードタイプ「18」を追加して、ＳＤＰオファーを変更する。

また、ＳＤＰ処理部１３２は、追加したペイロードタイプの属性を指定する必要がある。これは、「a=」行で指定され、ＳＩＰサーバ１００自体が対応している適切なペイロード周期などの属性を設定する（図８の処理（７））。

例えば、ペイロードタイプ「18」を追加した場合は、以下のようになる。
「a=rtpmap:18 G729/8000」
このとき、メディア属性としての（「a=」行で記述する）ペイロード周期は、他のコーデック情報と同じ周期を設定する。

また、セッション記述部に「c=」行を追加し、<connection-address>をＳＩＰサーバ１００のメディア中継用インタフェースのIPアドレスに書き換える（図８の処理（８））。

次に、ＳＤＰ処理部１３２で変更を加えた「ＳＤＰオファーＡ」を、「ＳＤＰオファーＢ」として、図５に示すように、ＳＩＰセッション管理テーブル１５０内のＳＤＰセッション管理テーブル１５１に登録する。

その後、ＳＤＰ処理部１３２は、変更した「ＳＤＰオファーＢ」をＳＩＰ処理部１３１に渡す。ＳＩＰ処理部１３１では、「ＳＤＰオファーＢ」のデータサイズを計算し、「Content-Lengthヘッダ」を書き換え、ＳＩＰプロキシサーバの処理をするなどして、「Initial-INVITEリクエスト」を再構築し（メッセージ再構築工程）、プロトコル制御部１２０に渡す。

そして、プロトコル制御部１２０では、IPパケットを構築し、パケット送信部１１２に渡す。そして、パケット送信部１１２からＳＩＰサーバ２００に送信する。

続いて、ＳＩＰサーバ１００は、図７に示すように、ＳＩＰプロキシサーバの一般的な処理である処理Ｂを実行する。処理Ａの終了後、暫定応答として、「100 TRYING」をユーザ端末１０１に送信する。続いて、ＳＩＰサーバ１００は、ＳＩＰプロキシサーバの一般的な処理である処理Ｃを実行する。ＳＩＰサーバ２００から「100 TRYING」、「180 RINGING」を受信後、処理Ａと同様に、「Call-ID値」を検索し、ＳＩＰセッションを特定し、「180 RINGING」をユーザ端末１０１に送信する。

続いて、図７に示す処理Ｄについて説明する。ＳＩＰサーバ２００から「200 OK」（Initial-INVITEに対する応答）を受信すると、処理Ａと同様に、「Call-ID値」を検索し、ＳＩＰセッションを特定する。「200 OK」には、ＳＤＰアンサーが含まれているため、ＳＤＰ処理部１３２にデータを渡す。

そして、ＳＤＰ処理部１３２は、「ＳＤＰアンサーＢ」として、ＳＤＰアンサーをコピーし、図５に示すように、ＳＤＰセッション管理テーブル１５１に登録する。また、ＳＤＰ変更フラグを確認し、ＳＤＰを変更している場合は、以下の処理を行う。なお、ＳＤＰを変更していない場合は、処理Ｄを終了する。

その後、ＳＤＰを変更している場合に、ＳＤＰ処理部１３２は、図９に示すＳＤＰアンサー変換アルゴリズムを実行し、「ＳＤＰアンサーＢ」を分析して（図９の処理（１））、セッション記述部、メディア記述部の変更を行う。

このとき、ＳＤＰアンサーＢの「m=」行にあるペイロードタイプ<fmt>が、上記ＳＤＰオファーの処理時にＳＩＰサーバ１００で追加したペイロードタイプの場合は（図９の処理（２）でＹＥＳ）、それは、ユーザ端末１０１が対応していないコーデックである。このため、ＳＩＰサーバ１００で変換する必要があるペイロード（コーデック）であるため、コーデック変換の必要があり、<fmt>をユーザ端末１０１が対応しているコーデックに変更し、<port>をＳＩＰサーバ１００のものに書き換える（図９の処理（３））。

また、セッション記述部に「c=」行を追加し、<connection-address>をＳＩＰサーバ１００のメディア中継用インタフェースのIPアドレスに書き換える（図９の処理（４））。また、変更を加えた「ＳＤＰアンサーＢ」を「ＳＤＰアンサーＡ」として、ＳＤＰセッション管理テーブル１５１に登録する。

続いて、ＳＤＰ処理部１３２は、上述したＳＤＰオファー・アンサー内のペイロードタイプ（コーデック情報）の書き換えに対応して、ユーザ端末間における音声データ通信時の符号化形式の変換ルールを表すメディア変換管理テーブル１７０（コーデック変換テーブル）を設定記憶する。具体的には、メディア変換管理テーブル１７０に次の情報ＲＴＰ＿Ｓ１，ＲＴＰ＿Ｓ２，ＲＴＰ＿Ｒ１，ＲＴＰ＿Ｒ２を登録する。

・ＲＴＰ＿Ｓ１：ＳＩＰサーバ１００からユーザ端末１０１への送信ＲＴＰストリーム
（１）識別子S1
（２）オファーAの「m=」行に記述されているポート番号
（３）オファーAの「c=」行に記述されているIPアドレス
（４）コーデック変換有無フラグ（未使用）
（５）変換先コーデック種別（未使用）
・ＲＴＰ＿Ｓ２：ＳＩＰサーバ１００からユーザ端末２０１への送信ＲＴＰストリーム
（１）識別子S2
（２）アンサーBの「m=」行に記述されているポート番号
（３）アンサーBの「c=」行に記述されているIPアドレス
（４）コーデック変換有無フラグ（未使用）
（５）変換先コーデック種別（未使用）
・ＲＴＰ＿Ｒ１：ユーザ端末１０１からＳＩＰサーバ１００への受信RTPストリーム
（１）識別子R1
（２）アンサーAの「m=」行に記述されているポート番号
（３）アンサーAの「c=」行に記述されているIPアドレス
（４）コーデック変換有無フラグ
（５）変換先コーデック種別
・ＲＴＰ＿Ｒ２：ユーザ端末２０１からＳＩＰサーバ１００への受信RTPストリーム
（１）識別子R2
（２）オファーBの「m=」行に記述されているポート番号
（３）オファーBの「c=」行に記述されているIPアドレス
（４）コーデック変換有無フラグ
（５）変換先コーデック種別

その後、上述したように、ＳＤＰ処理部１３２でＳＤＰを再構築した後に、かかるＳＤＰ部分１２のデータをＳＩＰ処理部１３１に渡す。そして、上述した処理Ａと同様に、ＳＩＰメッセージを再構築し、ユーザ端末１０１に送信する。

続いて、ＳＩＰ制御部１３０は、メディア制御部１４０に対して、ＲＴＰの送受信準備を指示する。具体的には、ＳＩＰ制御部１３０は、メディア制御部１４０に対して、上記の（RTP_S1）、（RTP_S2）、（RTP_R1）、（RTP_R2）の識別子情報を通知する。なお、SDP変更フラグが設定されていない場合は、ＳＩＰサーバ１００はRTP送受信に関与しないので、RTPの送受信準備の指示は行わない。

続いて、ＳＩＰサーバ１００は、図７に示すように、ＳＩＰプロキシサーバの一般的な処理である処理Ｅを実行する。ここでは、ユーザ端末１０１から「ACK」を受信後、上記処理Ａと同様に、「Call-ID値」を検索し、ＳＩＰセッションを特定し、ＳＩＰサーバ２００に送信する。これにより、ユーザ端末１０１，２０１間の音声通話セッションを確立することができる。

続いて、図７に示す処理Ｆについて説明する。ＳＩＰサーバ１００のメディア制御部１４０は、処理Ｄの後、ＳＩＰ制御部１３０から、ＲＴＰ送受信準備指示を受けると、指示されたＲＴＰおよびＲＴＣＰポートの送受信準備を行う。このとき、指示された識別子情報を基に、メディア変換管理テーブル１７０を参照して、ＲＴＰの送受信ポートを開く。

そして、ユーザ端末１０１からＲＴＰパケットを受信すると、パケット受信部１１１からプロトコル制御部１２０へデータが渡される。このとき、ＲＴＰプロトコルであるため、プロトコル制御部１２０からメディア制御部１４０へデータが渡される。メディア制御部１４０では、該当するメディア変換管理テーブル１７０を参照し、コーデック変換有無フラグを確認し、変換の必要がある場合は、コーデック変換部１４３に、変換先コーデック種別とデータを渡す。そして、コーデック変換部１４３は、指示されたコーデック変換を実行後、ＲＴＰ制御部１４１にデータを渡す。

ＲＴＰ制御部１４１は、上記メディア変換管理テーブル１７０を参照して、ＲＴＰパケットのヘッダ部を変更する。例えば、送信元ＩＰアドレス、送信元ポート番号として、識別子Ｒ２に関連付けられた値を設定する。また、送信先ＩＰアドレス、送信先ポート番号として、識別子Ｓ２に関連付けられた値を設定する。そして、変換後の適切なペイロードタイプを設定する。

その後、ＳＩＰサーバ１００は、プロトコル制御部１２０、ＬＡＮインタフェース１１０の処理を経て、ＲＴＰパケットを送信する。

なお、ユーザ端末２０１からＲＴＰパケットを受信した場合も上記と同様の処理を行うが、ＲＴＰ制御部１４１でのＲＴＰパケットのヘッダ部変更処理に関しては、以下のようになる。つまり、送信元ＩＰアドレス、送信元ポート番号として、識別子Ｒ１に関連付けられた値を設定する。また、送信先ＩＰアドレス、送信先ポート番号として、識別子Ｓ１に関連付けられた値を設定する。そして、変換後の適切なペイロードタイプを設定する。その後、プロトコル制御部１２０、ＬＡＮインタフェース１１０の処理を経て、ＲＴＰパケットが送信される。

また、ＲＴＣＰ制御部１４２は、ＳＩＰサーバ１００自体が送受信するＲＴＰストリームに対する、送受信レポートとしてＲＴＣＰを送信する。

ここで、上述したＳＩＰサーバ１００、つまり、通信システム全体の処理の具体例を、図１０乃至図１２を参照して説明する。はじめに図１０では、ユーザ端末１０１では対応コーデックが「ｃ」であり、ユーザ端末２０１では対応コーデックが「ａ，ｂ」であって、相互に音声通信を行うユーザ端末１０１，２０１間で対応するコーデックが異なる場合を示している。

この図１０の場合には、まず、ユーザ端末１０１から、ＳＤＰにコーデック情報「ｃ」を含む「Initial-INVITEリクエスト」をユーザ端末２０１に送信する。すると、ＳＩＰサーバ１００は、この「Initial-INVITEリクエスト」内のコーデック情報「ｃ」に、ＳＩＰサーバ１００自体が対応可能なコーデック情報「ａ，ｂ」を追加して「ｃ，ａ，ｂ」書き換え、ユーザ端末２０１に送信する。このとき、書き換えた「Initial-INVITEリクエスト」内のＳＤＰ部分のデータサイズを計算し、「Content-Lengthヘッダ」も適切に書き換えられている。

その後、この「Initial-INVITEリクエスト」に対応して、ユーザ端末２０１から、音声通信に使用するコーデック情報「ａ」が選択された「200 OK」が送信される。すると、ＳＩＰサーバ１００は、選択されたコーデック情報「ａ」が、上記「Initial-INVITEリクエスト」に対して追加されたものであるため、当該コーデック情報「ａ」をユーザ端末１０１が対応可能なコーデック情報「ｃ」に書き換える。このとき、上記「Initial-INVITEリクエスト」の書き換え、及び、「200 OK」の書き換えに応じて、音声データのコーデックの変換およびポートの設定、つまり、メディア変換管理テーブル１７０の設定を行う。

その後、ユーザ端末１０１とユーザ端末２０１との間でセッションが確立されると、設定されたメディア変換管理テーブル１７０に基づいて、ＳＩＰサーバ１００が音声データのコーデックを変換して中継する。具体的には、ＳＩＰサーバ１００は、ユーザ端末１０１とはコーデック「ｃ」で音声データを送受信し、かかる音声データをコーデック「ｃ」とコーデック「ａ」とで変換を行う。そして、ＳＩＰサーバ１００は、ユーザ端末２０１とはコーデック「ａ」で音声データを送受信する。

次に、図１１では、ユーザ端末１０１では対応コーデックが「ｂ」であり、ユーザ端末２０１では対応コーデックが「ａ，ｂ」であって、相互に共通する対応コーデックがある場合を示している。

この図１１の場合には、まず、ユーザ端末１０１から、ＳＤＰにコーデック情報「ｂ」を含む「Initial-INVITEリクエスト」をユーザ端末２０１に送信する。すると、ＳＩＰサーバ１００は、この「Initial-INVITEリクエスト」内のコーデック情報「ｂ」に、ＳＩＰサーバ１００自体が対応可能なコーデック情報「ａ，ｃ」を追加して「ｂ，ａ，ｃ」書き換え、ユーザ端末２０１に送信する。このとき、書き換えた「Initial-INVITEリクエスト」内のＳＤＰ部分のデータサイズを計算し、「Content-Lengthヘッダ」も適切に書き換えられている。

その後、この「Initial-INVITEリクエスト」に対応して、ユーザ端末２０１から、音声通信に使用するコーデック情報「ｂ」が選択された「200 OK」が送信される。このとき、ＳＩＰサーバ１００は、選択されたコーデック情報「ｂ」が、上記「Initial-INVITEリクエスト」に対して追加されたものでないため、上記とは異なりコーデック情報の書き換えは行わない。その後、ユーザ端末１０１とユーザ端末２０１との間でセッションが確立されると、そのままコーデック「ｂ」で相互に音声データの通信を行う。

次に、図１２では、ユーザ端末１０１では対応コーデックが「ａ，ｂ」であり、ユーザ端末２０１では対応コーデックが「ｂ」であって、相互に共通する対応コーデックがある場合を示している。また、この例では、ＳＩＰサーバ１００内の装置設定データ１６０に、コーデック情報の優先度が設定されていることとする。

この図１２の場合には、まず、ユーザ端末１０１から、ＳＤＰにコーデック情報「ａ，ｂ」を含む「Initial-INVITEリクエスト」をユーザ端末２０１に送信する。すると、ＳＩＰサーバ１００は、設定されているコーデックの優先順位に基づいて、「Initial-INVITEリクエスト」内のコーデック情報「ａ，ｂ」の順番を入れ替えて、「ｂ，ａ」に書き換え、ユーザ端末２０１に送信する。なお、この場合には、書き換えた「Initial-INVITEリクエスト」内のＳＤＰ部分のデータサイズの変更はないため、上記とは異なり「Content-Lengthヘッダ」を書き換える必要はない。

その後、この「Initial-INVITEリクエスト」に対応して、ユーザ端末２０１から、音声通信に使用するコーデック情報「ｂ」が選択された「200 OK」が送信される。このとき、ＳＩＰサーバ１００は、選択されたコーデック情報「ｂ」が、上記「Initial-INVITEリクエスト」に対して追加されたものでないため、上記とは異なりコーデック情報の書き換えは行わない。その後、ユーザ端末１０１とユーザ端末２０１との間でセッションが確立されると、そのままコーデック「ｂ」で相互に音声データの通信を行う。

以上のように、本発明によると、ユーザ端末間で送受信されるＳＩＰメッセージが適切な情報となるため、ＳＩＰサーバやユーザ端末間で正常に解釈され、確実なＳＩＰメッセージのやり取りを実現できる。従って、両ユーザ端末がそれぞれサポートしている符号化形式（コーデック）で通信できるよう、通信データのコーデック変換を行うことができ、確実にデータ通信を行うことができる。その結果、データ通信の信頼性の向上を図ることができると共に、新規コーデックにも対応することができる。また、コーデックの優先順位を設定する場合には、その優先されたコーデックをユーザ端末間で使用させることができ、使用するコーデックを統一させることができる。その結果、両ユーザ端末感が確実にデータ通信を行うことができる。

なお、上記では、ユーザ端末１０１，２０１間で音声データの送受信を行う場合を例示したが、本発明は、音声データのコーデックを変換する場合に適用されることに限定されない。本発明は、例えば、映像データなどあらゆる通信データのコーデックを変換する場合に適用可能である。

＜実施形態２＞
次に、本発明の第２の実施形態を、図１３乃至図１４を参照して説明する。図１３は、通信システム全体の構成を示すブロック図である。図１４は、ＳＩＰサーバとメディア変換装置の構成を示す機能ブロック図である。

本実施形態における通信システムでは、上記実施形態１ではＳＩＰサーバ１００が備えている音声データ（通信データ）の中継機能を実現するメディア制御部１４０が、ＳＩＰサーバ１００とは異なる装置で実現されている。つまり、図１３に示すように、上述したＳＩＰサーバ１００が接続されているネットワークＮ１上に、ユーザ端末１０１，２０１間における音声データの中継を行うメディア変換装置１０３を備えている。

このため、本実施形態におけるＳＩＰサーバ１００は、図１４に示すように、メディア制御部１４０を備えていない点を除いて、実施形態１で説明したものとほぼ同一の構成を取っている。但し、本実施形態におけるＳＩＰ制御部１３０は、ＳＤＰ制御部１３２でＳＩＰメッセージの書き換えを行う際やメディア変換管理テーブル１７０の設定を行う際には、音声データを受信するポートとして、メディア変換装置のポートを設定する。また、ＳＩＰ制御部１３０は、メディア変換管理テーブル１７０の設定内容を、メディア変換装置１０３に通知する機能を有する。

そして、本実施形態におけるメディア変換装置１０３は、通信部としてＬＡＮインタフェース３１０と、送受信するパケットデータを処理するプロトコル制御部３２０と、を備えている。さらに、メディア変換装置１０３は、上述したように、ユーザ端末１０１，２０１間で送受信される音声データなどの通信データを中継するデータ中継手段として機能するメディア制御部３４０を備えている。このメディア制御部３４０は、実施形態１でＳＩＰサーバ１００が備えるＲＴＰ制御部３４１と、ＲＴＣＰ制御部３４２と、コーデック変換部３４３と、を有している。

これにより、本実施形態では、ＳＩＰサーバ１００でユーザ端末１０１，２０１間のセッションの確立を行うと共に、音声データ（通信データ）のコーデック変換管理テーブルを設定する。そして、ユーザ端末１０１，２０１間でセッションが確立された後は、ＳＩＰサーバ１００にて設定されたコーデック変換管理テーブルに基づいて、音声データのコーデック変換を実行して、音声データの中継を行う。これにより、ＳＩＰサーバ１００の負荷を軽減することができる。

＜実施形態３＞
次に、本発明の第３の実施形態を、図１５を参照して説明する。図１５は、ＳＩＰサーバの構成を示す機能ブロック図である。

本実施形態におけるＳＩＰサーバ１００は、ユーザ端末１０１，２０１間におけるＳＩＰメッセージの送受信制御を行う機能であるＳＩＰ制御部１３０を備えている。そして、このＳＩＰ制御部１３０は、上述した実施形態１，２におけるＳＤＰ処理部１３２と同様に機能するコーデック情報書換部１３０ｂ（コーデック情報書換手段）と、ＳＩＰ処理部１３１と同様の機能を有するメッセージ再構築部１３０ａ（メッセージ再構築手段）と、を備えている。

これにより、ＳＩＰサーバ１００は、ユーザ端末間で送受信されるＳＩＰメッセージ内のコーデック情報を書き換えると共に、また、この書き換えに応じてＳＩＰメッセージのデータサイズ情報を適切に書き換える。従って、ＳＩＰメッセージが他のＳＩＰサーバやユーザ端末間で正常に解釈され、確実なＳＩＰメッセージのやり取りを実現できる。

本発明は、ＩＰ電話機などのユーザ端末間の接続制御を行って当該ユーザ端末間のセッションを確立する接続制御装置に適用することができ、産業上の利用可能性を有する。

本発明の実施形態１における通信システム全体の構成を示す図である。 図１に開示したＳＩＰサーバの構成を示す機能ブロック図である。 ＳＩＰメッセージのデータ構造を示す図である。 図１に開示した装置設定データのデータ構造を示す図である。 図１に開示したＳＩＰセッション管理テーブルのデータ構造を示す図である。 図１に開示したメディア変換管理テーブルのデータ構造を示す図である。 図１に開示した通信システム全体の動作を示すシーケンス図である。 図１に開示したＳＩＰサーバの動作を示すフローチャートである。 図１に開示したＳＩＰサーバの動作を示すフローチャートである。 図１に開示した通信システムにおける通信例を示す図である。 図１に開示した通信システムにおける通信例を示す図である。 図１に開示した通信システムにおける通信例を示す図である。 本発明の実施形態２における通信システム全体の構成を示す図である。 図１３に開示したＳＩＰサーバ及びメディア変換装置の構成を示す機能ブロック図である。 本発明の実施形態３におけるＳＩＰサーバの構成を示す機能ブロック図である。

符号の説明

１０ ＳＩＰメッセージ
１１ ＳＩＰ部分
１２ ＳＤＰ部分
１３ セッション記述部
１４ メディア記述部
１００ ＳＩＰサーバ（メディア変換機能付き）
１０１，２０１ ユーザ端末
１０２，２０２ ルータ
１０３ メディア変換装置
１１０ ＬＡＮインタフェース
１１１ パケット受信部
１１２ パケット送信部
１２０ プロトコル制御部
１３０ ＳＩＰ制御部
１３０ａ メッセージ再構築部
１３０ｂ コーデック情報書換部
１３１ ＳＩＰ処理部
１３２ ＳＤＰ処理部
１４０ メディア制御部
１４１ ＲＴＰ制御部
１４２ ＲＴＣＰ制御部
１４３ コーデック変換部
１５０ ＳＩＰセッション管理テーブル
１５１ ＳＤＰセッション管理テーブル
１６０ 装置設定データ
１７０ メディア変換管理テーブル
２００ ＳＩＰサーバ
３１０ ＬＡＮインタフェース
３２０ プロトコル制御部
３４０ メディア制御部
３４１ ＲＴＰ制御部
３４２ ＲＴＣＰ制御部
３４３ コーデック変換部
Ｎ１，Ｎ２，Ｎ３ ネットワーク

Claims (11)

1. 通信端末間にて送受信される接続制御メッセージを中継して、当該通信端末間の接続制御を行う接続制御手段を備え、
   前記接続制御手段は、中継する前記接続制御メッセージに含まれる前記通信端末で使用可能な通信データの符号化形式を表すコーデック情報を予め設定されたコーデック設定情報に基づいて書き換えるコーデック情報書換手段と、当該コーデック情報書換手段による書き換えによって変化する前記接続制御メッセージのデータ構造に対応して当該接続制御メッセージ内の特定の情報を書き換えて前記接続制御メッセージを再構築するメッセージ再構築手段と、
   を備えたことを特徴とする接続制御装置。
2. 前記メッセージ再構築手段は、前記特定の情報として、前記接続制御メッセージ内の特定範囲のデータサイズを表すデータサイズ情報を書き換える、
   ことを特徴とする請求項１記載の接続制御装置。
3. 前記メッセージ再構築手段は、前記コーデック情報書換手段にて前記接続制御メッセージ内に前記コーデック情報を追加したときに、前記データサイズ情報を書き換える、
   ことを特徴とする請求項２記載の接続制御装置。
4. 前記接続制御メッセージは、ＳＩＰ（Session Initiation Protocol）メッセージであり、
   前記メッセージ再構築手段は、前記ＳＩＰメッセージに含まれるメッセージボディのデータサイズを前記データサイズ情報として書き換える、
   ことを特徴とする請求項２又は３記載の接続制御装置。
5. 前記コーデック情報書換手段は、予め設定された符号化形式の使用優先度を表す優先度情報に基づいて、前記通信端末が使用する符号化形式の優先順位を変更するよう前記接続制御メッセージ内の前記コーデック情報を書き換える、
   ことを特徴とする請求項１，２，３又は４記載の接続制御装置。
6. 前記接続制御手段は、前記コーデック情報書換手段による前記接続制御メッセージ内の前記コーデック情報の書き換えに対応して、前記通信端末間で前記通信データを送受信可能なよう当該通信データの符号化形式を変換するルールを表すコーデック変換テーブルを設定する、
   ことを特徴とする請求項１，２，３，４又は５記載の接続制御装置。
7. 前記通信端末間で送受信される通信データを中継するデータ中継手段を備え、
   前記データ中継手段は、前記コーデック変換テーブルに基づいて前記通信データの符号化形式を変換して当該通信データを中継する、
   ことを特徴とする請求項６記載の接続制御装置。
8. 通信端末間にて送受信される接続制御メッセージを中継して、当該通信端末間の接続制御を行うコンピュータに、
   中継する前記接続制御メッセージに含まれる前記通信端末で使用可能な通信データの符号化形式を表すコーデック情報を予め設定されたコーデック設定情報に基づいて書き換えるコーデック情報書換手段と、当該コーデック情報書換手段による書き換えによって変化する前記接続制御メッセージのデータ構造に対応して当該接続制御メッセージ内の特定の情報を書き換えて前記接続制御メッセージを再構築するメッセージ再構築手段と、
   を実現させるためのプログラム。
9. 前記メッセージ再構築手段は、前記特定の情報として、前記接続制御メッセージ内の特定範囲のデータサイズを表すデータサイズ情報を書き換える、
   ことを特徴とする請求項８記載のプログラム。
10. 通信端末間にて送受信される接続制御メッセージを中継して、当該通信端末間の接続制御を行う接続制御工程を有し、
    前記接続制御工程は、中継する前記接続制御メッセージに含まれる前記通信端末で使用可能な通信データの符号化形式を表すコーデック情報を予め設定されたコーデック設定情報に基づいて書き換えるコーデック情報書換工程と、当該コーデック情報書換工程による書き換えによって変化する前記接続制御メッセージのデータ構造に対応して当該接続制御メッセージ内の特定の情報を書き換えて前記接続制御メッセージを再構築するメッセージ再構築工程と、を有する、
    ことを特徴とする接続制御方法。
11. 前記メッセージ再構築工程は、前記特定の情報として、前記接続制御メッセージ内の特定範囲のデータサイズを表すデータサイズ情報を書き換える、
    ことを特徴とする請求項１０記載の接続制御方法。
    

Images