(57)【要約】【課題】着網がサポートしないコーデックのネゴシェーションによりエラーが発生しても呼接続を可能とする呼制御処理システムおよび呼制御処理方法を提供する。【解決手段】本発明の呼制御処理システムは、発端末５１からセッション開始オファーを含む呼制御プロトコル信号を送信するオファー送信手段３１１と、着網２３の受入不能の応答または着端末５３の受入可能の応答を受信したならば、サポートコーデックを取得するコーデック取得手段３１２と、着端末５３と発端末５１との各サポートコーデックとを変換するコーデック変換手段４１とを含む。オファー送信手段３１１は、取得した着網２３のサポートコーデックを、コーデック変換手段４１が発端末５１のサポートコーデックに変換可能なものと、発端末５１のサポートコーデックとに絞り込んでセッション開始オファーに上書きし、当該セッション開始オファーを含む呼制御プロトコル信号を再送する。【選択図】図２
2016149671.tif 000002
【特許請求の範囲】
【請求項１】
発端末からセッション開始オファーを含む呼制御プロトコル信号を中継網を介して送信するオファー送信手段と、
前記セッション開始オファーに含まれる着網の受入不能の応答または着端末の受入可能の応答を受信したならば、前記応答に含まれるサポートコーデックを取得するコーデック取得手段と、
前記着端末が受入可能なサポートコーデックと前記発端末のサポートコーデックとを相互に変換するコーデック変換手段と、
を含んで構成され、
前記オファー送信手段は、
前記コーデック取得手段によって前記着網のサポートコーデックを取得したならば、前記着網のサポートコーデックを、前記コーデック変換手段が前記発端末のサポートコーデックに変換可能なものと、前記発端末のサポートコーデックとに絞り込んで前記セッション開始オファーに上書きし、当該セッション開始オファーを含む呼制御プロトコル信号を前記中継網を介して再送する、
ことを特徴とする呼制御処理システム。
【請求項２】
前記コーデック取得手段は、
前記着網からサポートコーデックの情報を受信すると、当該サポートコーデックと前記着網の対応を記憶手段に登録する、
ことを特徴とする請求項１に記載の呼制御処理システム。
【請求項３】
前記セッション開始オファーは、ＳＤＰ（Session Description Protocol）オファーであり、
前記呼制御プロトコル信号は、ＳＩＰ（Session Initiation Protocol）信号である、
ことを特徴とする請求項１または請求項２に記載の呼制御処理システム。
【請求項４】
発端末と中継網を介して接続される着端末との間の通話に際して、呼制御処理システムが実行する呼制御処理方法であって、
発端末からセッション開始オファーを含む呼制御プロトコル信号を受信するステップと、
前記発端末から当初に受信した呼制御プロトコル信号を前記中継網を介して着端末へ送信するステップと、
応答に含まれる着網のサポートコーデックを取得するステップと、
前記着網のサポートコーデックを、前記発端末のサポートコーデックに変換可能なものと前記発端末のサポートコーデックとに絞り込んで前記セッション開始オファーに上書きするステップと、
上書きされた前記セッション開始オファーを含む呼制御プロトコル信号を前記中継網を介して再送するステップと、
前記着端末の受入可能の応答を受信するステップと、
前記着端末が受入可能なサポートコーデックと前記発端末のサポートコーデックとを相互に変換するステップと、
を含んで構成されることを特徴とする呼制御処理方法。
【請求項５】
前記着網からの応答に含まれる前記着網のサポートコーデックを取得したならば、当該サポートコーデックと前記着網との対応を記憶手段に記録するステップ、
を更に含むことを特徴とする請求項４に記載の呼制御処理方法。
【請求項６】
前記記憶手段から前記着網のサポートコーデックを取得したならば、取得した前記網のサポートコーデックを、前記発端末のサポートコーデックに変換可能なものと前記発端末のサポートコーデックとに絞り込むステップと、
絞り込んだ前記サポートコーデックを前記発端末から当初に受信した呼制御プロトコル信号のセッション開始オファーに上書きするステップと、
前記セッション開始オファーを含む呼制御プロトコル信号を前記中継網を介して送信するステップと、
を含むことを特徴とする請求項５に記載の呼制御処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、発端末と着端末が通話を開始する際に遂行されるコーデックネゴシエーションに係る呼制御処理システムおよび呼制御処理方法に関する。
【背景技術】
【０００２】
従来、ＩＰ電話、携帯電話等で通話する際のコーデックネゴシエーションシステムの構成は、図１０に示すような構成である。図１０は、比較例のコーデックネゴシエーションシステムの構成を示す構成図である。
【０００３】
コーデックネゴシエーションシステム１０Ｓは、例えば、携帯電話、PDA（Personal Digital Assistant）やIP電話の通話に際して呼制御を司るシステムである。ここでは、電話による通話において、発端末５１を発信側とし、着端末５３を着信側とする。
【０００４】
コーデックネゴシエーションシステム１０Ｓは、発端末５１に接続される発網２１と、着端末５３に接続される着網２３と、発網２１と着網２３とをつなぐ中継網２２とにおいて用いられる。
発網２１は、例えば、国内の電話事業者の電話網である。着網２３は、例えば、外国の電話事業者の電話網である。
【０００５】
発網２１は、国際電話など着網２３と中継網２２を介して接続されており、利用コーデックに関して双方の合意がないものとする。
発網２１には、発側IBCF（Interconnection Border Control Function）３１ＡとTrGW（Transition GateWay）４１とが備わる。同様に、着網２３には、着側IBCF３３ＡとTrGW４３とが備わる。
【０００６】
従来、電話をかける場合、通話前に図１１に示す呼制御が行われる。図１１は比較例の非特許文献１の呼制御を示すシーケンス図である。
ユーザが発端末５１から着端末５３に発呼すると、発端末５１からOffer（AMR）（セッション開始要求）の信号が発側IBCF３１Ａに送信される（図１１のステップＳ９０）。発側IBCF３１Ａは、ＳＤＰオファーのコーデックリスト“AMR”に自身がサポートするコーデック“G.711μ-law”，“G.711A-law”を追加する。そして、発側IBCF３１Ａは、着側IBCF３３ＡにOffer（AMR,G.711μ-law, G.711A-law）（セッション開始要求）の信号を送り、G.711μ-lawやG.711A-lawのコーデックが可能か否かネゴシエーション（交渉）する（ステップＳ９１）。なお、各図面では、“G.711μ-law”を“G.711μ”と省略記載し、“G.711A-law”を“G.711A”と記載する場合がある。
【０００７】
着側IBCF３３Ａは、着端末５３にOffer（AMR,G.711μ-law, G.711A-law）の信号を送り、G.711μ-lawやG.711A-lawのコーデックが可能か否か問い合わせる（ステップＳ９２）。
着端末５３は、Answer（G.711A-law）（応答コマンド）の信号を発側IBCF３１Ａに送り、コーデック“G.711A-law”が可能であると答える（ステップＳ９３）。着側IBCF３３Ａは、Answer（G.711A-law）の信号を発側IBCF３１Ａに送り、コーデック“G.711A-law”が可能であると答える（ステップＳ９４）。
発側IBCF３１Ａは、発端末５１にAnswer（AMR）の信号を送る（ステップＳ９５）。これにより、発端末５１は、着端末５３に呼接続する。
【０００８】
その後、ステップＳ９６において、発信者が発端末５１で話すと、その音声がAMRの形式に符号化され、AMRに符号化された信号が発側IBCF３１ＡのTrGW４１に送られる。発側IBCF３１ＡのTrGW４１は、AMRに符号化された信号をG.711A-lawにコーデック変換し、その信号が着側IBCF３３Ａに送られる。着側IBCF３３Ａは、G.711A-lawに符号化された信号を着端末５３に転送する。着端末５３側では、G.711A-lawに符号化された信号が復号化され、発端末５１で話された音声を聴き取ることができる。着端末５３の音声は、G.711A-lawに符号化されたのち、TrGW４１によりAMRにコーデック変換されて発端末５１に送られる。
【０００９】
上述の場合、SDPアンサーのコーデックリスト（Answer（G.711A-law）の（G.711A-law））にＳＤＰオファーのコーデック“AMR”が存在せず、追加コーデック“G.711A-law”のみ存在するので、発側IBCF３１ＡはTrGW４１を制御して、コーデック“AMR”とコーデック“G.711A-law”との間のコーデック変換を行う。
これにより、発端末５１と着端末５３との通話が遂行される。
【先行技術文献】
【非特許文献】
【００１０】
【非特許文献１】"3GPP TS 24.229 V12.5.0",[online],2014-06-27, 3GPP Organizational Partners,[平成27年２月２日検索]，インターネット<URL:http://www.3gpp.org/ftp/Specs/archive/24_series/24.229/24229-c50.zip>
【発明の概要】
【発明が解決しようとする課題】
【００１１】
上述の図１１での呼制御は、発端末と着端末の両方がサポートするコーデック“G.711A-law”が存在する場合であり、通話が行える。
ところが、従来、IMS（IP Multimedia Subsystem）が相互接続する際に、発端末５１と着端末５３のコーデック変換が行われない場合は、図１２に示すように行われる。図１２は比較例のコーデック変換が行われない場合の非特許文献１の呼制御を示すシーケンス図である。
【００１２】
着端末５１からOffer（AMR）（セッション開始要求）の信号が発側IBCF３１Ａに送信される（図１２のステップＳ１００）。発側IBCF３１Ａは、着側IBCF３３ＡにOffer（AMR,G.711μ-law,G.711A-law）の信号を送り、G.711μ-lawやG.711A-lawのコーデックが可能か否かネゴシエーション（交渉）する（ステップＳ１０１）。
【００１３】
着側IBCF３３Ａは、SDPオファーのコーデックリストに、サポート外のコーデック“AMR”，“G.711μ-law”が含まれるので、エラーレスポンスの４８８（G.711A-law）の信号を発側IBCF３１Ａに送る（ステップＳ１０２）。発側IBCF３１Ａは、４８８（G.711A-law）の信号を発端末５１に送る（ステップＳ１０３）。この場合、発端末５１にエラーレスポンスの４８８（G.711A-law）が送られるので通話不能となる。
【００１４】
ところで、発端末５１がサポートするコーデック“AMR”と、着端末５３がサポートするコーデック“G.711A-law”との間でコーデック変換（トランスコーディング）を行わなければ接続不能となる。比較例では、そのような網に対して、呼制御において、エラーコードとともにサポート外のコーデックが提案されることがあり、コーデック変換されないと呼接続ができないという課題があった。
【００１５】
本発明は上記実状に鑑み、着網がサポートしないコーデックのネゴシェーションによりエラーが発生しても呼接続を可能とする呼制御処理システムおよび呼制御処理方法の提供を目的とする。
【課題を解決するための手段】
【００１６】
請求項１に記載の発明では、発端末からセッション開始オファーを含む呼制御プロトコル信号を中継網を介して送信するオファー送信手段と、前記セッション開始オファーに含まれる着網の受入不能の応答または着端末の受入可能の応答を受信したならば、前記応答に含まれるサポートコーデックを取得するコーデック取得手段と、前記着端末が受入可能なサポートコーデックと前記発端末のサポートコーデックとを相互に変換するコーデック変換手段とを含んで構成され、前記オファー送信手段は、前記コーデック取得手段によって前記着網のサポートコーデックを取得したならば、前記着網のサポートコーデックを、前記コーデック変換手段が前記発端末のサポートコーデックに変換可能なものと、前記発端末のサポートコーデックとに絞り込んで前記セッション開始オファーに上書きし、当該セッション開始オファーを含む呼制御プロトコル信号を前記中継網を介して再送する、ことを特徴とする呼制御処理システムとした。
【００１７】
このようにすることで、取得した着網のサポートコーデックを用いて呼接続することができる。そのため、呼損の発生を抑えることができる。
【００１８】
請求項２に記載の発明では、前記コーデック取得手段は、前記着網からサポートコーデックの情報を受信すると、当該サポートコーデックと前記着網の対応を記憶手段に登録することを特徴とする請求項１に記載の呼制御処理システムとした。
【００１９】
このようにすることで、着網からサポートコーデックの情報を受信すると、当該サポートコーデックと着網の対応を記憶手段に登録するので、記憶手段に登録したサポートコーデックと着側ドメインの対応関係を用いて呼接続できる。
【００２０】
請求項３に記載の発明では、前記セッション開始オファーは、ＳＤＰ（Session Description Protocol）オファーであり、前記呼制御プロトコル信号は、ＳＩＰ（Session Initiation Protocol）信号であることを特徴とする請求項１または請求項２に記載の呼制御処理システムとした。
【００２１】
このようにすることで、ＳＤＰオファーを使用し、かつ呼制御プロトコルのＳＩＰを使用することができる。
【００２２】
請求項４に記載の発明では、発端末と中継網を介して接続される着端末との間の通話に際して、呼制御処理システムが実行する呼制御処理方法であって、発端末からセッション開始オファーを含む呼制御プロトコル信号を受信するステップと、前記発端末から当初に受信した呼制御プロトコル信号を前記中継網を介して着端末へ送信するステップと、応答に含まれる着網のサポートコーデックを取得するステップと、前記着網のサポートコーデックを、前記発端末のサポートコーデックに変換可能なものと前記発端末のサポートコーデックとに絞り込んで前記セッション開始オファーに上書きするステップと、上書きされた前記セッション開始オファーを含む呼制御プロトコル信号を前記中継網を介して再送するステップと、前記着端末の受入可能の応答を受信するステップと、前記着端末が受入可能なサポートコーデックと前記発端末のサポートコーデックとを相互に変換するステップと、を含んで構成されることを特徴とする呼制御処理方法とした。
【００２３】
このようにすることで、取得した着網のサポートコーデックを用いて呼接続することができる。そのため、呼損の発生を抑えることができる。
【００２４】
請求項５に記載の発明では、前記着網からの応答に含まれる前記着網のサポートコーデックを取得したならば、当該サポートコーデックと前記着網との対応を記憶手段に記録するステップ、を更に含むことを特徴とする請求項４に記載の呼制御処理方法とした。
【００２５】
このようにすることで、着網からサポートコーデックの情報を受信すると、当該サポートコーデックと着網の対応を記憶手段に登録するので、記憶手段に登録したサポートコーデックと着側ドメインの対応関係を用いて呼接続できる。
【００２６】
請求項６に記載の発明では、前記記憶手段から前記着網のサポートコーデックを取得したならば、取得した前記網のサポートコーデックを、前記発端末のサポートコーデックに変換可能なものと前記発端末のサポートコーデックとに絞り込むステップと、絞り込んだ前記サポートコーデックを前記発端末から当初に受信した呼制御プロトコル信号のセッション開始オファーに上書きするステップと、前記セッション開始オファーを含む呼制御プロトコル信号を前記中継網を介して送信するステップと、を含むことを特徴とする請求項５に記載の呼制御処理方法とした。
【００２７】
このようにすることで、発端末のサポートコーデックに変換可能なコーデックと発端末のサポートコーデックとに絞り込むので、着網との間の呼損の発生を抑えることができる。
【発明の効果】
【００２８】
本発明によれば、着網がサポートしないコーデックのネゴシェーションによりエラーが発生しても呼接続を可能とする呼制御処理システムおよび呼制御処理方法を実現することができる。
【図面の簡単な説明】
【００２９】
【図１】（ａ）は本発明に係る実施形態の呼制御処理システムの構成を示す構成図、（ｂ）はサポートコーデックDBのレコードレイアウトを示す図。
【図２】呼制御処理システムの実施形態１の動作を示すシーケンス図。
【図３】実施形態１の呼制御処理システムの具体例を示すシーケンス図。
【図４】実施形態１の呼制御処理システムの具体例を示すシーケンス図。
【図５】呼制御処理システムの実施形態２の動作を示すシーケンス図。
【図６】呼制御処理システムの具体例を示す実施形態２のシーケンス図。
【図７】変形例１の規格RFC3261での呼制御のパターンを示す図。
【図８】変形例２の規格100rel(RFC3262)での呼制御のパターンを示す図。
【図９】変形例３の規格Precondition(RFC3312/4032)での呼制御のパターンを示す図。
【図１０】比較例のコーデックネゴシエーションシステムの構成を示す構成図。
【図１１】比較例の非特許文献１の呼制御を示すシーケンス図。
【図１２】比較例のコーデック変換が行われない場合の非特許文献１の呼制御を示すシーケンス図。
【発明を実施するための形態】
【００３０】
以下、本発明の実施形態について、適宜図面を参照しながら詳細に説明する。
図１（ａ）は、本発明に係る実施形態の呼制御処理システムＳの構成を示す構成図であり、図１（ｂ）は、サポートコーデックDB7のレコードレイアウトを示す図である。
実施形態１の呼制御処理システムＳは、例えば、携帯電話、PDA（Personal Digital Assistant）やIP電話による通話に際し、セッションを開始するための呼制御を司るシステムである。
【００３１】
発端末５１は、通話において、例えば、電話をかける側の携帯電話、PDA（Personal Digital Assistant）等の携帯端末とし、着端末５３は、電話を受ける側のIP電話等の固定電話とする。
呼制御処理システムＳは、発端末５１が接続される発網２１と、着端末５３が接続される着網２３と、発網２１と着網２３とを中継する中継網２２とにおいて使用される。
発網２１は、例えば国内の電話会社の電話網である。着網２３は、例えば外国の電話会社の電話網である。
中継網２２は、海底ケーブル、バックボーンネットワーク等である。
【００３２】
呼制御処理システムＳは、日本国内の発網２１と国際通話などの外国の着網２３とが、中継網２２を介して接続しており、発網２１の事業者と着網２３の事業者との間で利用するコーデックに関して双方の合意がない場合に使用されるシステムである。そして、着側IBCF３３はサポートしていないコーデックがオファーされた場合、エラーレスポンス(488 with SDP)を返却するものとする。
【００３３】
呼制御処理システムＳは、コーデックデータ処理部６と、サポートコーデックDB（データベース）７と、発側IBCF３１と、TrGW４１とを備える。
コーデックデータ処理部６とサポートコーデックDB７（以下、DB７と称す）は、例えば同じサーバまたは違うサーバに格納される。
コーデックデータ処理部６は、着網２３のドメイン（またはIPアドレス）と、該着網２３のドメインがサポートするコーデックとをDB７に記録する。
DB７は、着網２３のドメイン（またはIPアドレス）と該着網２３がサポートするコーデックの情報をレコードとしてもつ。
【００３４】
発網２１に、発側IBCF３１とTrGW４１とがある。
発側IBCF３１は、オファー送信部３１１とコーデック取得部３１２とを有する。
オファー送信部３１１は、通話に際して、セッション開始要求として、着網２３の着側ICBF３３に対してサポートするコーデックの問い合わせ（要求）を行う。
【００３５】
コーデック取得部３１２は、発端末５１がサポートするコーデックと、着端末５３がサポートするコーデックとを取得して、両コーデックが異なる場合、TrGW４１に両コーデック間のコーデック変換を指示する。
TrGW４１は、コーデック取得部３１２の指令を受けて、コーデック変換を行うゲートウェイである。
着網２３には、着側IBCF３３とTrGW４３とが備わる。
着側IBCF３３は、発側IBCF３１の要求に対してリプライ（応答）する。
TrGW４３は、着側IBCF３３の指令を受けて、コーデック変換を行うゲートウェイである。
【００３６】
＜＜実施形態１＞＞
＜呼制御処理システムＳの実施形態１の動作概要＞
次に、呼制御処理システムＳの実施形態１の動作の概要について説明する。
図２は、呼制御処理システムＳの実施形態１の動作を示すシーケンス図である。
利用者が発端末５１から着端末５３に発呼すると、発端末５１は、Offer（AMR）（セッション開始要求）の信号を発側IBCF３１に送る（図２のステップＳ１０）。“AMR”は発端末５１がサポートする音声の圧縮形式である。ステップＳ１０は、発端末５１から、発側IBCF３１が発端末５１のサポートコーデックが“AMR”であり、通話開始の要求を受けることを意味する。
【００３７】
発側IBCF３１は、Offer（AMR）（セッション開始要求）の情報をコーデックデータ処理部６に送る（ステップＳ１１）。詳細には、発端末５１からのOffer（AMR）の情報には、着ドメイン（着網２３のドメイン）が含まれ、この信号をコーデックデータ処理部６に送る。
【００３８】
そして、コーデックデータ処理部６は、着ドメインがサポートするコーデックをDB７に要求する（ステップＳ１２）。DB７に着ドメインがサポートするコーデックの情報がない場合、DB７は、“対応なし”の情報（信号）をコーデックデータ処理部６に送る（ステップＳ１３）。
コーデックデータ処理部６は、Offer（AMR）の情報（信号）をそのまま発側IBCF３１に送る（ステップＳ１４）。
【００３９】
発側IBCF３１は、自身がサポートするコーデック“G.711μ-law”、“G.711A-law”をＳＤＰオファーのコーデック“AMR”に追加し、Offer（AMR、G.711μ-law、G.711A-law）（セッション開始要求）の信号を着側IBCF３３に送る（ステップＳ１５）。
着側IBCF３３は、SDPオファーのコーデックリストにサポート外のコーデック“AMR”、“G.711μ-law”があるので、４８８（G.711A-law）の応答信号を発側IBCF３１に送る（ステップＳ１６）。４８８（G.711A-law）における“４８８”はエラーコードであり、“G.711A-law”は着側IBCF３３（着網２３）がサポートしているコーデックである。
【００４０】
発側IBCF３１は、４８８（G.711A-law）の信号をコーデックデータ処理部６に送る（ステップＳ１７）。
コーデックデータ処理部６は、発端末５１が発呼している着端末５３の着網２３のドメイン（着ドメイン）と、着網２３のドメイン（着側IBCF３３）がサポートするコーデック“G.711A-law”とをDB７に登録する（ステップＳ１８）。対応関係が登録されたDB７は、登録したことを示す登録対応の応答の情報（信号）をコーデックデータ処理部６に返す（ステップＳ１９）。
【００４１】
続いて、発側IBCF３１は、４８８（G.711A-law）の応答信号を基に、４８８（G.711A-law）に含まれるコーデックの全てをコーデックリストに含めて再オファーする。つまり、発側IBCF３１は、Offer（G.711A-law）（セッション開始要求）の信号を着側IBCF３３に送る（ステップＳ２０）。着側IBCF３３は、Offer（G.711A-law）（セッション開始要求）の信号を着端末５３に送る（ステップＳ２１）。
【００４２】
着端末５３は、コーデック“G.711A-law”をサポートしているので、通話OKを表わすAnswer（G.711A-law）の応答信号を着側IBCF３３に送る（ステップＳ２２）。着側IBCF３３は、Answer（G.711A-law）の応答信号を発側IBCF３１に送る（ステップＳ２３）。
発側IBCF３１は、発端末５１がサポートするコーデック“AMR”を設定したAnswer（AMR）の応答信号を発端末５１に送る（ステップＳ２４）。
【００４３】
以上の呼制御処理を経て、ステップＳ２５において、発端末５１で利用者が話すと、通話の音声は、発端末５１で“AMR”に符号化され、発端末５１から発側IBCF３１に送られる。“AMR”を受けた発側IBCF３１のオファー送信部３１１は、TrGW４１に“AMR”を“G.711A-law”にコーデック変換するように、指令を出す。TrGW４１では、“AMR”形式の信号を“G.711A-law”形式の信号にコーデック変換し、この“G.711A-law”の情報（信号）を着端末５３に送る。送られた“G.711A-law”形式の信号は、着端末５３で、復号化され音声とされる。これにより、発端末５１で話された音声を着端末５３で聴くことができる。逆も同様にして、着端末５３で話された音声を発端末５１で聴くことができる。
【００４４】
＜呼制御処理システムの実施形態１の具体例＞
次に、図２の呼制御処理システムの動作の具体例を、呼制御プロトコルであるSIP（Session Initiation Protocol）を使用して行う場合を例に挙げて説明する。
図３、図４は、実施形態１の呼制御処理システムの具体例を示すシーケンス図である。
発端末５１は、イニシャルINVITE（x）（セッション開始要求）の信号を発側IBCF３１に送る（図３のステップＳ３０）。ここでxは、codec_xを示す。
なお、INVITE（x）とは具体的には、下記である。
【００４５】
「  INVITE sip:alice@xxx.co.uk SIP/2.0
(SIP以下略)
m=audio 10000 RTP/AVP 96
a=rtpmap:96 codec_x
(SDP以下略)  」
なお、SDPとは、セッションの招待（INVITE）などを必要とするマルチメディアセッションを開始するために、必要な情報を記述するためのプレゼンテーション層に属するプロトコルである。
【００４６】
発側IBCF３１は、INVITE（x）の信号をコーデックデータ処理部６に送り（ステップＳ３１）、発側IBCF３１は、上述の初期オファーコーデックのcodec_xを記憶部（メモリ）に保存する（ステップＳ３２）。
コーデックデータ処理部６は、発端末５１の初期オファーコーデックのcodec_xを、記憶部（メモリ）に保存する（ステップＳ３３）。
【００４７】
コーデックデータ処理部６は、イニシャルINVITEの要求URl（Uniform Resource Locator）の“alice@xxx.co.uk”に設定された着ドメインがサポートするコーデックを、DB７に要求する（ステップＳ３４）。
DB７は、着ドメインがサポートするコーデックが記憶されてないので、「該当データなし」の情報（信号）をコーデックデータ処理部６に返答する（ステップＳ３５）。コーデックデータ処理部６は、イニシャルINVITEのサポートコーデックを空行で上書きして（ステップＳ３６）、発側IBCF３１に送信する（ステップＳ３７）。ステップＳ３７の送信内容は、具体的には下記である。
【００４８】
「  INVITE sip:alice@xxx.co.uk SIP/2.0
(SIP以下略)
m=audio 10000 RTP/AVP
(SDP以下略)   」
【００４９】
発側IBCF３１は、コーデックデータ処理部６から返されたオファーコーデック（着ドメインがサポートするコーデック）が“空行”なので、発端末５１が設定した初期オファーコーデックcodec_xを再設定する（ステップＳ３８）。そして、発側IBCF３１は、INVITE（x）の信号を着側IBCF３３に送る（ステップＳ３９）。
【００５０】
着側IBCF３３は、発側IBCF３１からのオファーにサポートしてないコーデックcodec_xが含まれているため、４８８（d，c，b，a）の信号を発側IBCF３１に送る（ステップＳ４０）。“４８８”はエラーコードであり、“d，c，b，a”は着側IBCF３３がサポートしているコーデックcodec_d，codec_c，codec_b，codec_aを示す。ステップＳ４０の送信内容は具体的には下記である。
【００５１】
「  SIP/2.0 488 Not Acceptable Here
(SIP以下略)
m=audio 10000 RTP/AVP 96 97 98 99
a=rtpmap:96 codec_d
a=rtpmap:97 codec_c
a=rtpmap:98 codec_b
a=rtpmap:99 codec_a   」
【００５２】
発側IBCF３１は、４８８（a，b，c，d）の信号をコーデックデータ処理部６に送る（ステップＳ４１）。コーデックデータ処理部６は、着ドメイン（着側IBCF３３のドメイン）“xxx.co.uk”の情報と、着ドメイン“xxx.co.uk”がサポートするコーデックcodec_d，codec_c，codec_b，codec_aの情報とをDB７に登録する（ステップＳ４２）。DB７は、登録が完了したら、“登録完了”の信号をコーデックデータ処理部６に送る（ステップＳ４３）。
【００５３】
ステップＳ４１、ステップＳ４２、ステップＳ４３は、着ドメインがサポートするコーデック登録処理であり、実施タイミングは、ステップＳ４０の後であれば、任意のタイミングで行える。
発側IBCF３１は、着ドメイン“xxx.co.uk”のコーデックとして、初期のオファーコーデックcodec_xではないコーデックのcodec_d，codec_c，codec_b，codec_aが含まれているため、初期のオファーコーデックのcodec_xと、codec_d，codec_c，codec_b，codec_aとがトランスコーデックが可能であれば、着側IBCF３３へのオファーコーデックとする。
【００５４】
ここでTrGW４１は、codec_dとcodec_xとの間のトランスコーデックに対応していないために、codec_dを着側IBCF３３へのオファーコーデックから除外する。また、codec_xは、着側IBCF３３がサポートしていないため、着側IBCF３３へのオファーコーデックから除外する。こうして、発側IBCF３１は、着ドメイン“xxx.co.uk”のコーデックとして、codec_xに変換可能なcodec_c，codec_b，codec_aに絞り込む（図４のステップＳ４４）。
そして、発側IBCF３１は、INVITE（c，b，a）の信号を着側IBCF３３に送る（ステップＳ４５）。INVITE（c，b，a）の情報は、具体的には下記である。
【００５５】
「  INVITE sip:alice@xxx.co.uk SIP/2.0
(SIP以下略)
m=audio 10000 RTP/AVP 96 97 98
a=rtpmap:96 codec_c
a=rtpmap:97 codec_b
a=rtpmap:98 codec_a
(SDP以下略)  」
【００５６】
着側IBCF３３は、INVITE（c，b，a）の信号を着端末５３に送る（ステップＳ４６）。
着端末５３は、着信したことを知らせる暫定応答の“１８０Trying”の信号を着側IBCF３３に返す（ステップＳ４７）。“１８０”はリクエストを受信して、その処理の実行中を表す。
【００５７】
着側IBCF３３は、暫定応答の“１８０Trying”の信号を発側IBCF３１に送り（ステップＳ４８）、発側IBCF３１は、暫定応答の“１８０Trying”の信号を発端末５１に送る（ステップＳ４９）。発端末５１では、暫定応答の“１８０Trying”の情報が届くと保留音を発する。
【００５８】
着端末５３は、codec_a，codec_b，codec_cに対応している。着端末５３がオフフックされると、対応しているコーデックのうち最も優先順位の高いcodec_cを選択してアンサーを返す。つまり、着端末５３は、リクエストの成功を示す“２００OK（c）”の信号を着側IBCF３３に返す（ステップＳ５０）。“２００”は成功応答を示す。２００OK（c）は具体的には下記である。
【００５９】
「  SIP/2.0 200 OK
(SIP以下略)
m=audio 10000 RTP/AVP 96
a=rtpmap:96 codec_c
(SDP以下略) 」
着側IBCF３３は、この“２００OK（c）”の信号を発側IBCF３１に転送する（ステップＳ５１）。着側IBCF３３は、初期オファーコーデックでないアンサーコーデックのcodec_cが返されたため、発端末５１へのアンサーコーデックは初期オファーコーデックのcodec_xとし、“２００OK（x）”の信号を発端末５１に送る（ステップＳ５２）。２００OK（x）は具体的には下記である。
【００６０】
「  SIP/2.0 200 OK
(SIP以下略)
m=audio 10000 RTP/AVP 96
a=rtpmap:97 codec_x
(SDP以下略)  」
【００６１】
発側IBCF３１では、TrGW４１によるcodec_xとcodec_cとの間のトランスコーディングの制御を設定する（ステップＳ５３）。
【００６２】
発端末５１は、セッション確立の確認を表わす“ACK”の信号を発側IBCF３１に送る（ステップＳ５４）。発側IBCF３１は、“ACK”の信号を着側IBCF３３に送り（ステップＳ５６）、着側IBCF３３は、セッション確立の確認を表わす“ACK”の信号を着端末５３に送る（ステップＳ５６）。
【００６３】
以上の呼制御処理を経て、ステップＳ５７での通話が行われる。
ステップＳ５７では、利用者の発端末５１での通話の音声は、codec_xの情報に圧縮される。発側IBCF３１は、TrGW４１にコーデック変換を指令し、TrGW４１は、codec_xの情報をcodec_cの情報に変換する。そして、変換後のcodec_cの情報（信号）が、着端末５３に送られる。着端末５３では、codec_cの情報（信号）を音声に復号化して、着端末５３で音声を聴くことができる。
【００６４】
実施形態１の構成によれば、呼制御において、着網のドメインと、着網がサポートするコーデックがDB７に登録できる。従って、DB７の情報を用いれば、一度接続された回線間の呼損の発生を回避することができる。
また、エラーコードに付されるコーデックを用いて呼の再接続を行うので、呼損の発生を抑えて呼接続を行うことができる。
【００６５】
＜＜実施形態２＞＞
＜呼制御処理システムの実施形態２の動作概要＞
次に、呼制御処理システムの実施形態２の動作の概要について説明する。この実施形態２は、上記した実施形態１の後、再び発端末５１から着端末５３に発呼した場合を示している。
図５は、呼制御処理システムの実施形態２の動作を示すシーケンス図である。
利用者が発端末５１から着端末５３に発呼すると、発端末５１は、Offer（AMR）（セッション開始要求）の信号を発側IBCF３１に送る（図５のステップＳ１０）。“AMR”は発端末５１がサポートする音声の圧縮形式である。ステップＳ１０は、圧縮形式“AMR”をサポートする発端末５１から、通話の申出を受けることを意味する。
【００６６】
発側IBCF３１は、Offer（AMR）の信号をコーデックデータ処理部６に送る（ステップＳ１１）。詳細には、発端末５１からのOffer（AMR）コマンドの情報には、相手先の着端末５３のドメイン情報が含まれている。発側IBCF３１は、着ドメイン（着網２３のドメイン）の情報（信号）をコーデックデータ処理部６に送る。コーデックデータ処理部６は、こうして、Offer（AMR）の情報（信号）から着端末５３のドメイン（着ドメイン）の情報を取得する。例えば、着ドメインを“zzz.co.uk”とする。
【００６７】
そして、コーデックデータ処理部６では、着ドメインがサポートするコーデックをDB７に要求する（ステップＳ１２）。ここでDB７には、図１（ｂ）に示すように、着ドメイン“zzz.co.uk”がサポートするコーデック“G.711A-law”が記憶されている。
そこで、DB７は、着ドメイン“zzz.co.uk”がサポートするコーデック“G.711A-law”の情報（信号）をコーデックデータ処理部６に送る（ステップＳ１３ａ）。コーデックデータ処理部６は、Offer（G.711A-law）の信号を発側IBCF３１に送る（ステップＳ１４ａ）。
【００６８】
ここで、発側IBCF３１は、SDPオファーのコーデックリストに、着ドメインがサポートするコーディク“G.711A-law”のみを設定する。
そこで、発側IBCF３１は、“G.711A-law”のみが設定されるOffer（G.711A-law）の信号を着側IBCF３３に送る（ステップＳ２０）。着側IBCF３３は、Offer（G.711A-law）（セッション開始要求）の信号を着端末５３に送る（ステップＳ２１）。
【００６９】
着端末５３は、コーデック“G.711A-law”をサポートしているので、通話OKを示すAnswer（G.711A-law）（応答コマンド）の信号を着側IBCF３３に送る（ステップＳ２２）。着側IBCF３３はAnswer（G.711A-law）の信号を発端末５１に送る（ステップＳ２４）。
【００７０】
以上の呼制御処理を経て、ステップＳ２５において、発端末５１で利用者が通話すると、通話の音声は、発端末５１で“AMR”に符号化され、発端末５１から発側IBCF３１に送られる。“AMR”の情報（信号）を受けた発側IBCF３１は、TrGW４１に“AMR”をコーデック変換するように、指令を出す。TrGW４１では、“AMR”を“G.711A-law”にコーデック変換する。そして、発側IBCF３１は、“G.711A-law”の信号を着側IBCF３３に送る。送られた“G.711A-law”の情報（信号）は、着端末５３に送信され、この着端末５３にて“G.711A-law”の情報（信号）が復号化される。これにより、着端末５３において、発端末５１で話された音声を聴くことができる。逆も同様にして、着端末５３で話された音声を発端末５１で聴くことができる。
【００７１】
＜呼制御処理システムの実施形態２の具体例＞
次に、図２の呼制御処理システムの実施形態２の動作の具体例を、呼制御プロトコルであるSIP（Session Initiation Protocol）を使用して行う場合を例に挙げて説明する。
図６は、呼制御処理システムの具体例を示す実施形態２のシーケンス図である。
発端末５１は、イニシャルINVITE（x）（セッション開始要求）の信号を発側IBCF３１に送る（図６のステップＳ３０）。xは、codec_xを示す。
なお、INVITE（x）とは具体的には、下記である。
【００７２】
「  INVITE sip:alice@xxx.co.uk SIP/2.0
(SIP以下略)
m=audio 10000 RTP/AVP 96
a=rtpmap:96 codec_x
(SDP以下略)   」
【００７３】
発側IBCF３１は、INVITE（x）の信号をコーデックデータ処理部６に送る（ステップＳ３１）。発側IBCF３１は、発端末５１からの初期オファーコーデックcodec_xを記憶部（メモリ）に保存する（ステップＳ３２）。
コーデックデータ処理部６は、INVITE（x）における初期オファーコーデックcodec_xを記憶部（メモリ）に保存する（ステップＳ３３）。コーデックデータ処理部６は、イニシャルINVITE（x）の要求URLの“alice@xxx.co.uk”に設定された着ドメイン“xxx.co.uk”を抽出する。そして、コーデックデータ処理部６は、DB７に着ドメイン“xxx.co.uk”がサポートするコーデックを要求する（ステップＳ３４）。
【００７４】
DB７は、xxx.co.uk”がサポートするコーデックcodec_a，codec_b，codec_c，codec_dの情報（信号）をコーデックデータ処理部６に返信する（ステップＳ３５ａ）。ステップＳ３５ａでは、DB７は、サポートするコーデックを利用帯域が低い順に並べ替えて返信する（ステップＳ３５ａ）。なお、利用帯域が高い順に並べ替えて返信してもよい。
【００７５】
コーデックデータ処理部６は、保存した初期オファーコーデックcodec_xが、DB７から抽出したサポートコーデックにある場合は、オファーコーデックに「追加」して発側IBCF３１に送信する。一方、初期オファーコーデックであるcodec_xが、DB７から抽出したサポートコーデックにない場合は、サポートコーデックで「上書き」して発側IBCF３１に送信する。ここで、コーデックの順序は利用帯域が高い順に設定する。
【００７６】
このケースでは、コーデックデータ処理部６は、初期オファーコーデックのcodec_xは、DB７から抽出したサポートするコーデックcodec_a，codec_b，codec_c，codec_dに含まれないので、オファーコーデックcodec_xはcodec_a，codec_b，codec_c，codec_dで上書きする（ステップＳ３６ａ）。
コーデックデータ処理部６は、INVITE（d,c,b,a）の信号を発側IBCF３１に送る（ステップＳ３７ａ）。ステップＳ３７ａのINVITE（d,c,b,a）は、具体的には下記である。
【００７７】
「  INVITE sip:alice@xxx.co.uk SIP/2.0
(SIP以下略)
m=audio 10000 RTP/AVP 96 97 98 99
a=rtpmap:96 codec_d
a=rtpmap:97 codec_c
a=rtpmap:98 codec_b
a=rtpmap:99 codec_a
(SDP以下略)   」
【００７８】
コーデックの順序は上の行ほど優先順位が高くなり、アンサーを返す端末の着端末５３は、上の行から自身が対応するコーデックを一つ選ぶ。そのため、通常は広帯域・高品質のコーデックが上に書かれる。ステップＳ３７ａでは、codec_d，codec_c，codec_b，codec_aの順番となる。
【００７９】
発側IBCF３１は、初期オファーコーデックのcodec_xにないサポートコーデック（codec_d，codec_c，codec_b，codec_a）が含まれており、初期オファーコーデックとそれらのコーデックが、TrGW４１でトランスコーディング可能であれば、着側IBCF３３へのオファーコーデックとする。ここでは、codec_dとcodec_x間のトランスコーディングには対応していないため除外して追加する。つまり、発側IBCF３１は、着側IBCF３３へのオファーコーデックを、codec_xに変換可能なものに絞り込む（ステップＳ３８）。
なお、図６のステップＳ４５〜ステップＳ５７は、実施形態１の図４のステップＳ４５〜ステップＳ５７と同様であるから、詳細な説明は省略する。
【００８０】
実施形態２の構成によれば、DB７を参照して、着ドメインがサポートするコーデックを取得して呼接続するので、呼損になることなく呼接続できる。
また、DB７から着ドメインがサポートするコーデックを取得して呼接続することにより、呼のやり取りの回数を減じることができ、短時間で呼接続することができる。
加えて、DB７を参照して、着ドメインがサポートするコーデックを取得して呼接続するので、エラーレスポンス処理による接続遅延を短縮できる。
従って、ネットワーク負荷を軽減することができる。
【００８１】
＜＜変形例１＞＞
変形例１は、実施形態１，２で説明した構成を規格RFC3261での呼制御に用いた場合である。
図７は、変形例１の規格RFC3261での呼制御のパターンを示す図である。
変形例１の規格RFC3261では、図７に示すように、発端末５１は、コーデックを含むInitialのINVITEの情報（信号）で着端末５３にSDPオファーする（図７のステップＳ６０の太線）。着端末５３は、発端末５１に暫定応答“１ｘｘ”の情報（信号）を送る（ステップＳ６１）。ここで“ｘ”は、任意の数字を示している。
【００８２】
着端末５３は、発端末５１に“２００”（リクエストの成功）の情報（信号）のSDPアンサーを送る（図７のステップＳ６２の太線）。発端末５１は、着端末５３に“ACK”（セッション確立の確認）の情報（信号）を送る（ステップＳ６３）。
上述の図７のステップＳ６０〜Ｓ６２間のリクエストとレスポンスにおいて、着端末５３から返されたコーデックを用いて、前記で説明した実施形態１，２の構成を適用できる。
【００８３】
＜＜変形例２＞＞
変形例２は、実施形態１，２で説明した構成を、規格RFC3262の100relオプション対応の規格の呼制御に用いた場合である。
図８は、変形例２の規格100rel(RFC3262)での呼制御のパターンを示す図である。
変形例２では、図８に示すように、発端末５１は、InitialのINVITE（使用したいコーデックを含む）の情報（信号）で着端末５３にSDPオファーする（図８のステップＳ７０の太線）。
【００８４】
着端末５３は、発端末５１に、暫定応答“１ｘｘ”のSDPアンサーを送る（ステップＳ７１）。
着端末５３と発端末５１との間で、ステップＳ７２〜７４のやり取りを経て、発端末５１は、着端末５３に“ACK”（セッション確立の確認）の情報（信号）を送る（ステップＳ７５）。
上述の図８のステップＳ７０，Ｓ７１間のリクエストとレスポンスにおいて、着端末５３から返されたコーデックを用いて、前記で説明した実施形態１，２の構成を適用できる。
【００８５】
＜＜変形例３＞＞
変形例３は、実施形態１，２で説明した構成を、規格RFC3312/4032のPreconditionオプション対応の規格の呼制御に用いた場合である。
図９は、変形例３の規格Precondition(RFC3312/4032)での呼制御のパターンを示す図である。
【００８６】
変形例３の規格Precondition(RFC3312/4032)では、図９に示すように、発端末５１は、使用したいコーデックを含むInitialのINVITEの情報（信号）で着端末５３にSDPオファーする（図９のステップＳ８０の太線）。着端末５３は、発端末５１に、暫定応答“１xx”の情報（信号）のSDPアンサーを送る（ステップＳ８１の太線）。
そして、着端末５３と発端末５１との間で、PRACK（暫定応答に対する確認）（ステップＳ８２）、２００（PRACK）（暫定応答成功）（ステップＳ８３）を行う。
【００８７】
その後、発端末５１は、着端末５３に、UPDATE（セッションの変更）の情報（信号）のSDPオファーを送る（図９のステップＳ８４の太線）。着端末５３は、発端末５１に、２００（UPDATE）（セッションの変更の成功）の情報（信号）のSDPアンサーを送る（図９のステップＳ８５の太線）。
そして、着端末５３は、発端末５１に、２００（INV）（INVITEの成功）の情報（信号）を送り（ステップＳ８６）、発端末５１は、着端末５３に、ACK”（セッション確立の確認）を送る（ステップＳ８７）。
【００８８】
上述の図９のステップＳ８０，Ｓ８１間のリクエストとレスポンスと、ステップＳ８４，Ｓ８５間のリクエストとレスポンスとで着端末５３から返されたコーデックを用いて、前記した実施形態１，２の構成を適用できる。
変形例１〜３でも、実施形態１，２と同様な効果を奏する。
【００８９】
＜＜その他の実施形態＞＞
（１）  上記実施形態１，２では、呼制御の一例として、SIPを例示して説明したが、他の呼制御プロトコルで本発明を構成してももよい。
【００９０】
（２）  上記実施形態１，２では、IBCFを用いた場合を例示したが、P-CSCF（Proxy-Call Session Control Function）等の他のSession Control Functionを用いて行ってもよい。
【００９１】
（３）  上記実施形態１，２では、日本国内の電話網と外国の電話網との通話の場合を例示したが、日本国内の電話網間の通話や同じ外国の電話網間の通話、異なる外国間の電話網間の通話に本発明を適用することも可能である。
【００９２】
（４）  上記実施形態１，２では、着側ドメインからの応答に含まれる着側ドメインのサポートコーデックを取得したならば、着側ドメインとサポートコーデックとの対応をDB７に記録する場合を説明したが、予め着側ドメインとサポートコーデックとの対応をDB７に記録する構成としてもよい。
【００９３】
（５）  上記実施形態１，２では、記憶手段として、DB７を例示したが、記憶手段であればよく、テーブル、一時ファイル等のデータベース以外の記憶手段を適用してもよい。
【００９４】
（６）  発端末５１として携帯電話、ＰＤＡ等の携帯端末を例示したが、固定電話でもよい。また、着端末５３として固定電話を例示したが、携帯電話、ＰＤＡ等の携帯端末でもよい。つまり、発端末５１、着端末５３は、携帯端末、固定電話等、通話が可能な端末ならば限定されない。
【００９５】
（７）  上記実施形態１，２、変形例１〜３では、様々な構成を説明を説明したが、説明した構成の一部を抜き出して実現してもよいし、説明した各構成を適宜、組み合わせて構成してもよい。
【００９６】
（８）  上記実施形態１，２、変形例１〜３で説明した構成は、特許請求の範囲に記載した構成の一例を説明したものであり、特許請求の範囲に記載した範囲内で様々な具体的形態が可能である。
【符号の説明】
【００９７】
６      コーデックデータ処理部  （コーデックデータ処理手段）
７      データベース  （記憶手段）
２２    中継網
２３    着網
４１    TrGW  （コーデック変換手段）
５１    発端末
３１１  オファー送信部  （オファー送信手段）
３１２  コーデック取得部  （コーデック取得手段）
Ｓ      呼制御処理システム
【図１】
2016149671.tif 000003
【図２】
2016149671.tif 000004
【図３】
2016149671.tif 000005
【図４】
2016149671.tif 000006
【図５】
2016149671.tif 000007
【図６】
2016149671.tif 000008
【図７】
2016149671.tif 000009
【図８】
2016149671.tif 000010
【図９】
2016149671.tif 000011
【図１０】
2016149671.tif 000012
【図１１】
2016149671.tif 000013
【図１２】
2016149671.tif 000014