遠隔通信システムにおけるシグナリングポイント間で呼出し機能をネゴシエートする方法であって、発信シグナリングポイントから終端シグナリングポイントまたはシグナリング転送ポイントへ、機能選好または優先順位付き選好リストを呼出し制御レベルで送信するステップと、終端シグナリングポイントまたはシグナリング転送ポイントが発信シグナリングポイントにより送信された選好内容を受諾する場合、終端シグナリングポイントまたはシグナリング転送ポイントから発信シグナリングポイントへ機能受諾を呼出し制御レベルで返送するステップと、を含むことを特徴とする方法。終端シグナリングポイントまたはシグナリング転送ポイントが発信シグナリングポイントにより送信された機能選好または選好リストのいずれかを受諾しない場合は、受諾メッセージは返送されず、その場合は、デフォルト機能が両方のポイントにより想定されることを特徴とする請求項1に記載の方法。ネゴシエートする機能は通話コーデックに関することを特徴とする請求項1または2に記載の方法。ネゴシエートする機能はセキュリティに関することを特徴とする請求項1または2に記載の方法。ネゴシエーションを実行するために使用するプロトコルは、呼出し制御プロトコルであることを特徴とする請求項1乃至4の何れか1項に記載の方法。呼出し制御レベルとベアラ制御レベルは別々のプロトコルにより制御され、選択がベアラレベルに影響を与える場合は、シグナリングポイントはベアラ制御レベルに通知することで、呼出し制御レベルにおける機能の選択に応答することを特徴とする請求項1乃至5の何れか1項に記載の方法。シグナリングポイントまたはシグナリング転送ポイントは、ベアラ制御レベルで1つまたは複数のメディアゲートウェイと通信するメディアゲートウェイコントローラであることを特徴とする請求項1乃至6の何れか1項に記載の方法。終端シグナリングポイントまたはシグナリング転送ポイントで機能選好または優先順位付き選好リストを受信したとき、呼出し制御レベルはベアラ制御レベルとネゴシエーションを実行してベアラ制御レベルにおけるオプション可用性を決定することを特徴とする請求項1乃至7の何れか1項に記載の方法。前記ネゴシエーションは、呼出し制御レベルのメディアゲートウェイコントローラとベアラ制御レベルのメディアゲートウェイとの間で行われることを特徴とする請求項7に従属する場合の請求項8に記載の方法。優先順位付き選好リストが発信シグナリングポイントからメディアゲートウェイコントローラに送られるとき、コントローラはリストを修正して、対応するメディアゲートウェイがサポートしていないことが分かっている選好内容を削除し、メディアゲートウェイがその時点でサポートできる最高優先順位の選好内容を選択するメディアゲートウェイへ修正済みリストを送り、ゲートウェイはその選好内容に必要な資源を確保し、メディアゲートウェイコントローラに選好内容を通知することを特徴とする請求項9に記載の方法。遠隔通信システムにおいて別のシグナリングポイントと呼出し機能をネゴシエートするように配置したシグナリングポイントであって、機能選好または優先順位付き選好リストを終端シグナリングポイントまたはシグナリング転送ポイントへ、呼出し制御レベルで送信する手段と、終端シグナリングポイントまたはシグナリング転送ポイントが発信シグナリングポイントから送られた選好内容を受諾する場合に送信される機能受諾を、終端シグナリングポイントまたはシグナリング転送ポイントから呼出し制御レベルで受信する手段と、を備えることを特徴とするシグナリングポイント。遠隔通信システムのメディアゲートウェイコントローラであって、遠隔通信システムを介してセットアップする接続に関する機能選好または優先順位付き選好リストを、対等のメディアゲートウェイコントローラから受信する手段と、メディアゲートウェイコントローラと対応するメディアゲートウェイと通信し、メディアゲートウェイで受信した選好内容の可用性を決定する手段と、メディアゲートウェイにおいて決定された可用性に従い前記対等のメディアゲートウェイコントローラに機能選好受諾メッセージを返送する手段と、を備えることを特徴とするメディアゲートウェイコントローラ。遠隔通信システムのメディアゲートウェイであって、遠隔通信システムを介してセットアップする接続に関する機能選好または優先順位付き選好リストを、メディアゲートウェイコントローラから受信する手段と、メディアゲートウェイにおける選好内容の可用性により選好内容を選択する手段と、選択した選好内容を前記メディアゲートウェイコントローラへ送信する手段と、を備えることを特徴とするメディアゲートウェイ。別々の呼出し制御プロトコルとベアラ制御プロトコルとを使用する遠隔通信ネットワークにおいて、第1、第2、及び第3のノード間でプロトコルオプションをネゴシエートする方法であって、第1のノードがサポートするプロトコルオプションを指定する第1の呼出し制御メッセージを、第1のノードから第2のノードへ送信するステップと、第1及び第2のノードの両方がサポートするプロトコルオプションを指定する第2の呼出し制御メッセージを、第2のノードから第3のノードへ送信するステップと、第2の制御メッセージに指定したプロトコルオプションからプロトコルオプションを選択するステップと、を含むことを特徴とする方法。第2の制御メッセージに指定したプロトコルオプションからプロトコルオプションを選択する前記ステップは、第3のノードで実行されることを特徴とする請求項14に記載の方法。前記各呼出し制御メッセージは、指定した各プロトコルオプションに対応する選好レベルが含まれていることを特徴とする請求項14または15に記載の方法。第1のノードは発信ノードであることを特徴とする請求項14乃至16の何れか1項に記載の方法。第3のノードは終端ノードであることを特徴とする請求項14乃至17の何れか1項に記載の方法。第1のノードと第2のノードとの間のベアラレベルが前記選択するステップの影響を受けるかどうかを判別し、ベアラレベルが影響を受ける場合は、第1のノードと第2のノードとの間のベアラレベルのパラメータを修正する処置を実行するステップをさらに含むことを特徴とする請求項14乃至18の何れか1項に記載の方法。第2のノードと第3のノードとの間のベアラレベルが前記選択するステップの影響を受けるかどうかを判別し、ベアラレベルが影響を受ける場合は、第2のノードと第3のノードとの間のベアラレベルのパラメータを修正する処置を実行するステップをさらに含むことを特徴とする請求項14乃至19の何れか1項に記載の方法。呼出し制御プロトコルがトランスポート機構から独立している遠隔通信システムにおいて通話呼出し接続をセットアップする方法であって、システムの発信シグナリングポイントと第1の終端シグナリングポイントとの間の第1の通話コーデックをネゴシエートするステップと、前記第1の通話コーデックに従って、発信シグナリングポイントと前記第1の終端シグナリングポイントとの間でトランスポート機構を介して呼出し接続を確立するステップと、前記第1の終端シグナリングポイントと第2の新しい終端シグナリングポイントとの間で、その後、第2の異なった通話コーデックをネゴシエートするステップと、発信シグナリングポイントに第2の通話コーデックを通知するステップと、発信シグナリングポイントと前記第2の終端シグナリングポイントとの間で呼出し接続を確立するステップであって、前記第1の発信シグナリングポイントは中間シグナリングポイントとして動作し、前記第1の呼出し接続は前記第2の通話コーデックをサポートするために必要に応じて修正されるステップと、を含むことを特徴とする方法。前記第1の呼出し接続を修正し、新しいコーデックに従って元の終端シグナリングポイントと新しい終端シグナリングポイントとの間のトランスポート接続を、後で確立するステップを含むことを特徴とする請求項21に記載の方法。元の終端シグナリングポイントから発信シグナリングポイントへ適当な呼出し制御CCメッセージを送信することで、発信シグナリングポイントに第2の通話コーデックを通知するステップを含むことを特徴とする請求項21または22に記載の方法。呼出し制御プロトコルはトランスポート独立呼出し制御TICCプロトコルで、前記CCメッセージは修正.要求メッセージであることを特徴とする請求項23に記載の方法。呼出し制御プロトコルがトランスポート機構から独立している遠隔通信システムであって、システムの発信シグナリングポイントと第1の終端シグナリングポイントとの間で、第1の通話コーデックをネゴシエートする手段と、前記第1の通話コーデックに従って発信シグナリングポイントと前記第1の終端シグナリングポイントとの間で、トランスポート機構を介して呼出し接続を確立する手段と、前記第1の終端シグナリングポイントと第2の新しい終端シグナリングポイントとの間で、第2の異なった通話コーデックを、後でネゴシエートする手段と、発信シグナリングポイントに第2の通話コーデックを通知する手段と、発信シグナリングポイントと前記第2の終端シグナリングポイントとの間で呼出し接続を確立する手段であって、前記第1の発信シグナリングポイントは中間シグナリングポイントとして動作し、第1の呼出し接続は前記第2の通話コーデックをサポートするために必要に応じて修正される手段と、を備えることを特徴とするシステム。呼出し制御プロトコルがトランスポート機構から独立している遠隔通信ネットワークのシグナリングポイントであって、第1の終端シグナリングポイントと第1の通話コーデックをネゴシエートする処理手段と、前記第1の通話コーデックに従い、発信シグナリングポイントと前記第1の終端シグナリングポイントとの間でトランスポート機構を介して呼出し接続を確立する手段と、前記第1の終端シグナリングポイントと第2の新しい終端シグナリングポイントとの間でネゴシエートされた第2の通話コーデックの通知を受信する手段と、前記第2の通話コーデックをサポートするために、前記第1の呼出し接続を必要に応じ修正する手段と、を備えることを特徴とするシグナリングポイント。第1及び第2のモバイル電話ネットワーク間の呼出し接続をセットアップする方法であって、いずれかのネットワークはモバイルネットワークの無線アクセスネットワーク部分の外側に設置されたタンデムフリーオペレーションTFO装置を含み、呼出し制御プロトコルがベアラトランスポート機構から独立している方法であって、適当な通話コーデックを決定するために、片方のモバイルネットワークの前記TFO装置と他方のモバイルネットワークの対等TFO装置との間でネゴシエーションを実行するステップと、対応するTFO装置から呼出し制御CCメッセージを送信することで、前記無線アクセスネットワークに決定された通話コーデックを通知するステップと、を含むことを特徴とする方法。各モバイルネットワークは、モバイルネットワークの無線アクセスネットワーク部分の外側にタンデムフリーオペレーションTFO装置を含むことを特徴とする請求項27に記載の方法。2つのモバイル電話ネットワークは、PSTNを介してお互いに連結していることを特徴とする請求項27または28に記載の方法。前記ネゴシエーションはTFOプロトコルのコーデック不一致解決及び最適化手順を使用する方法であって、TFOメッセージは帯域内シグナリングを使用して送信することを特徴とする請求項27乃至29の何れか1項に記載の方法。無線アクセスネットワークの外側に設置する前記または各TFO装置は、モバイルネットワークと外部ネットワークとのインターフェースを提供するゲートウェイMSCGMSCに設置することを特徴とする請求項27乃至30の何れか1項に記載の方法。タンデムフリーオペレーションTFO装置が無線アクセスネットワーク部分の外側に設置するネットワークはユニバーサル移動通信方式UMTSネットワークであって、無線アクセスネットワークはUMTSターミナル地上無線接続ネットワークであることを特徴とする請求項27乃至31の何れか1項に記載の方法。第1と第2のモバイル電話ネットワーク間の呼出し接続をセットアップする装置であって、少なくともいずれかのネットワークはモバイルネットワークの無線アクセスネットワーク部分の外側に設置されたタンデムフリーオペレーションTFO装置を含み、呼出し制御プロトコルがベアラトランスポート機構から独立している装置であって、適当な通話コーデックを決定するために、片方のモバイルネットワークの前記TFO装置と他方のモバイルネットワークの対等TFO装置との間のネゴシエーションを実行する手段と、対応するTFO装置から呼出し制御CCメッセージを送信することで、前記無線アクセスネットワークに決定された通話コーデックを通知する手段と、を備えることを特徴とする装置。第1と第2のモバイル電話ネットワーク間の呼出し接続をセットアップする方法であって、各ネットワークはモバイルネットワークの無線アクセスネットワーク部分の外側に設置されたタンデムフリーオペレーションTFO装置を含み、呼出し制御プロトコルがベアラトランスポート機構から独立していて、両方のモバイルネットワークは公衆電話交換網PSTNを介して連結している方法であって、適当な通話コーデックを決定するために、それぞれ、第1及び第2のモバイルネットワークに加入している2つのモバイル端末間でネゴシエーションを実行するステップであって、そのネゴシエーションは無線アクセスネットワーク部分と各TFO装置間で交換される呼出し制御プロトコルシグナリングメッセージ及びTFO装置間で送信されるISUPメッセージを使用して実行するステップ、を含むことを特徴とする方法。発信モバイルネットワークで利用可能なコーデックリストをそのネットワークのTFO装置から対等のTFO装置へISUP初期アドレスメッセージIAMを使用して送信し、選択されたコーデックを後続ISUPメッセージで発信ネットワークへ返送することを特徴とする請求項34に記載の方法。第1と第2のモバイル電話ネットワーク間の呼出し接続をセットアップする装置であって、各ネットワークはモバイルネットワークの無線アクセスネットワーク部分の外側に設置されたタンデムフリーオペレーションTFO装置を含み、呼出し制御プロトコルがベアラトランスポート機構から独立していて、両方のモバイルネットワークは公衆電話交換網PSTNを介して連結されている装置であって、適当な通話コーデックを決定するために、それぞれ、第1及び第2のモバイルネットワークに加入している2つのモバイル端末間でネゴシエーションを実行する手段であって、そのネゴシエーションは無線アクセスネットワーク部分と各TFO装置間で交換される呼出し制御プロトコルシグナリングメッセージ及びTFO装置間で送信されるISUPメッセージを使用して実行する手段、を備えることを特徴とする装置。図1に、以下の説明でノードA及びノードCと呼ぶ2つのシグナリングポイントが含まれる遠隔通信ネットワークの一部を示す。これらのノードは電話交換局または交換機などで、同じネットワーク業者に属していても異なったネットワーク業者に属していてもよい。以下の例では、ノードAは呼出し側図示せずが接続している発信ノードを表し、ノードCは呼び出される側が接続している終端ノードを表している。各シグナリングポイントは、呼出し制御CC部分とベアラ制御BC部分とで構成されている。つまり、呼出し制御機能とベアラ制御機能が2つの異なったプロトコル層に分離されている。CC部分は呼出し制御レベルを形成していて、呼出し転送及び他のルーティングや制御機能などの機能の実行する。BC部分は、BC部分相互間のパイプを確立してその大きさを決定し、ユーザプレーンデータをトランスポートする。BCレベルについて説明すると、このレベルはIPネットワークなどのベアラネットワークにより構成される。図1には1つのベアラスイッチングポイントノードBしか示していないが、IPネットワークには1つまたは複数のベアラスイッチングポイントがある。IPネットワークの場合、これらのベアラスイッチングポイントはIPルータである。ベアラネットワークがATMネットワークまたはAAL2ネットワークの場合は、このベアラスイッチングポイントは、それぞれ、ATM交換機またはAAL2交換機になる。呼出し側が受話器を取るなどして呼出しを開始すると、発信シグナリングポイントであるノードAは、ソース呼出し側からCCレベルで情報を受け取る。この情報は、ベアラ資源要求を定義するものである。発信シグナリングポイントは、ソース情報またはシグナリングポイントとそのホームネットワークの機能のどちらかまたその両方を基に、終端シグナリングポイントであるノードCとネゴシエートする必要がある利用可能オプションリストを決定する。次に、ノードAは、利用可能オプションリストをメッセージに挿入し、具体的な機能をネゴシエートするCC部分に信号を送る図1のノードC。このメッセージは、各オプションの選好レベルを示している。ノードCは、リスト内の各オプションにノードAが指定した優先順位レベルを使用し、サポートしているオプション中で最も選好レベルが高いオプションを選択する。つまり、ノードCは、ノードAが高い選好度を示している別のオプションをリスト内でサポートしていても、最高選好オプション以外は選択しない。ノードCは、選択したオプションをノードAに送る。このネゴシエーションの結果がベアラ接続レベルに影響を与える場合は、ベアラレベルで適当な処置を実行し、ネゴシエーションの結果に適合するようにする。これは、BCプロトコルで行われる。これには、順方向ベアラ修正図2のケースAと逆方向ベアラ修正図2のケースBの2つのケースがある。上記の方法を使用してネゴシエートできる機能の例には、コーデック機能がある。一般的に、無線アクセスネットワークでは、通話はPCMにコード変換される。これは、従来の固定電話ネットワークで使用できる通話形式はこの形式だけであるからである。しかし、コード変換処理は通話品質を極端に低下させるため、一部のセルラー標準GSM、PDCなどでは、2つの互換性がある端末例えば、共通のコーデックで使用される2つのGSM端末間で接続が確立されたらコード変換を回避するための方法を仕様で決めている。現在の大部分のモバイル端末では幾つかのコーデックをサポートしているため、これらの方法でもコーデックネゴシエーションは可能になるが、以下に示す総称ネゴシエーション機構と比較すると幾つかの重大な欠陥がある。通話コーデックは、モバイル環境に密結合しているかPDCでは、コーデックネゴシエーションはMAPMobileApplicationPartプロトコルの1サービスである、またはハードウェア及び送信資源の使用を最適化していないGSMでは、コーデックネゴシエーションは、タンデムフリーオペレーションの一部である。コード変換が実際に行われるかどうかに関係なく、2つのコード変換装置TRAUと64Kbpsのチャネルとが常に通話接続用に割り振られている。現在、各種モバイル標準ではこの問題をさまざまな方法で処理していて、これまでのところ、これらの解決方法を調整する可能性はなかった。ネゴシエーションが必要な機能の別の例は、セキュリティ機能音声暗号化、データ暗号などである。現在、これは公衆遠隔通信ネットワークでは重大な関心事であり、近い将来さらに重要になる。しかし、望ましくない第3者からユーザのプレーン情報を保護する方法には幾つかある。複数の暗号アルゴリズムが存在していて、現在開発中のデータ暗号アルゴリズムおよび新しいアルゴリズムが次々に導入されている。したがって、公衆遠隔通信ネットワークにおいてセキュリティ機能をネゴシエートする方法は近い将来必要になり、この方法は本発明により提供される。上記の説明は、BCレベル及びCCレベルを一般的に言及したものである。図3は、CCレベルとBCレベルに分割された遠隔通信システムをさらに詳細に図示したものである。CCレベルは複数のメディアゲートウェイコントローラMGC_A、MGC_B、MGC_Cを含み、BCレベルは複数のメディアゲートウェイMG_1からMG_6を含んでいる。メディアゲートウェイの最初のペアMG_1、MG_6はAAL2ネットワークを介したベアラ接続であり、メディアゲートウェイの2番目のペアMG_2、MG_5はIPネットワークを介したベアラ接続である。メディアゲートウェイの3番目のペアMG_3、MG_4はSTMネットワークを介したベアラ接続である。図3から明らかなように、各メディアゲートウェイコントローラは、オープンインターフェースX-CP_1からX-CP_3を介して2つまたは3つのメディアゲートウェイを制御するように配置されている。上記ですでに説明したように、機能ネゴシエーションはCCレベル、つまり、メディアゲートウェイコントローラ間で行われる。さらに、X-CPは、メディアゲートウェイが制御側のメディアゲートウェイコントローラにメディアゲートウェイがサポートしている機能とオプションを通知する手段としても使用される例えば、機能=圧縮通話、オプション=コーデックリスト。また、メディアゲートウェイはX-CPを介してネゴシエーションに係わることができ、これにより、機能選択はゲートウェイに指定した機能だけでなく、これらの機能が現在使用できるかどうかにも依存するようになる。このように構成しておかないと、メディアゲートウェイコントローラがメディアゲートウェイのためにネゴシエートしたオプションをサポートするための資源をメディアゲートウェイが持っていない、という危険性がある。例えば、メディアゲートウェイコントローラが呼出しのためのインテリジェントネットワークINサービスを提供する必要がある場合で、且つ、このサービスが帯域内の告知情報を必要とする場合を考えてみる。メディアゲートウェイがサポートするコーデックの知識に従ってメディアゲートウェイコントローラが単独でコーデックを選択すると、メディアゲートウェイは、このコーデック用に現在TRAUを利用可能にしていないことがあり得る。したがって、メディアゲートウェイはこの接続を拒否し、呼出しは中止される。この問題の解決を説明するために、特定のネゴシエート可能な機能に関するオプションリストが含まれている接続セットアップメッセージを、メディアゲートウェイコントローラが対等のメディアゲートウェイコントローラから受信する場合を考えてみる。メッセージは、各オプションの選好レベルを示している。受信側のメディアゲートウェイコントローラは、受信したリストを読み取り、接続に選択されているメディアゲートウェイがサポートしていないことが分かっているオプションを、そのリストから削除する。次に、メディアゲートウェイコントローラは修正したオプションリストを、X-CPインターフェースを介してメディアゲートウェイに送信する。受信側のメディアゲートウェイは、最高優先順位で、且つ、ゲートウェイが現在サポートできるオプションを選択する。次に、メディアゲートウェイはこのオプションをサポートするために必要な資源を獲得し、メディアゲートウェイコントローラにX-CPインターフェースを介してそのオプションを送る。選択したオプションを受信すると、メディアゲートウェイコントローラは選択した内容を対等のメディアゲートウェイコントローラに上記のように送る。上記で説明した総称機能ネゴシエーションを、図4のフロー図でさらに詳しく説明する。多くの国では、業者はその国の関係当局から法的な目的で、呼出しを代行受信するように要求されている。合法な代行受信を使用可能にするために、業者は通常はネットワークにおける各呼出しについて、ユーザプレーンデータつまり、実際の通話、またはベアラレベルで行われる所謂パイプにより送信される他のデータにすべてアクセスすることを要求する。TICCを導入することで、ユーザプレーンデータは様々な技法ATM、IPなどを介してトランスポートできるようになり、これにより、暗号化ユーザプレーンデータのトランスポートも可能になる。したがって、合法代行受信ポイントでユーザプレーンデータのセキュリティ及びコーデック暗号化及び復号化特性を判別できないと、呼出しは正常に代行受信できない。したがって、業者は、呼出しの各BCセクション2つのBCノード間で使用しているコーデック及び暗号セキュリティアルゴリズムの知識が必要になる。一方、セキュリティアルゴリズムのコード変換及び変換処理は、呼出しのサービス品質を大幅に低下させ、余分な遅れを発生させる。したがって、各呼出しのエンドツーエンドで要求される変換ポイント数を減らしできれば回避する、セキュリティアルゴリズムポイントの変換を減少することが望ましい。この問題を解決する機構を、図5の動作シーケンスを参照して説明する。ノードAの呼出し制御部分図1を参照は、ノードBの呼出し制御部分にメッセージを送信する。このメッセージには、ノードAがサポートしているオプションのリストと各オプションの選好レベルとが含まれている。この機構はTICCで使用するのに特に適しているが、ネゴシエーション実行用に特別に適合された独立プロトコルでも使用できる。これは、図5で頭文字UPCNUserPartCapabilityNegotiationで示してある。次に、ノードBの呼出し制御側はノードCの呼出し制御側へメッセージを送る。これには、ノードAとノードBの両方がサポートしているオプションのリストと各オプションの選好レベルとが含まれている。ノードCは最高選好レベルのサポートオプションを選択し、選択したオプションが含まれたメッセージをノードBへ戻す。このメッセージを受け取ると、ノードBは選択オプションを指定したメッセージをノードAへ送る。次に、図5はケースAとケースBのラベルが付けられた2つの動作シーケンスを示す。ケースAでは、ベアラレベルが上記で説明した呼出し制御レベルのネゴシエーションにより影響を受けると、ノードAはベアラレベルで適当な処置を実行する。例えば、ノードAは選択したオプションをサポートするために必要なパイプのサイズを変更しなければならない場合がある。次に、BCメッセージがノードAからノードBへ送られ、どのパラメータが必要かを指定する。次にノードBは選択されたオプションを分析し、ベアラレベルがネゴシエーションにより影響を受けている場合は、ベアラレベルで適当な処置を実行する。次にBCメッセージはノードBからノードCへ送られ、ノードBとノードCの間でベアラレベルにどのパラメータが必要かを指定する。ケースBでは、ベアラレベルの動作シーケンスはノードCで始まり、ノードAで終わる。ノードCは選択されたオプションを分析し、ベアラレベルがネゴシエーションにより影響を受けている場合はベアラレベルで適当な処理を実行する。次に、BCメッセージがノードCからノードBへ送られ、必要なパラメータを指定する。ノードBは選択されたオプションを分析し、ベアラレベルがネゴシエーションにより影響を受けている場合はベアラレベルで適当な処理を実行する。次にBCメッセージがノードAからノードBへ送られ、必要なパラメータを指定する。ケースAとケースBは二者択一であるが、他のケースも考えられる。この点について、ノードAとノードB間のBCプロトコルはノードBとノードC間のプロトコルと異なっている可能性がある。例えば、プロトコルがそれぞれATM及びIPの場合もある。片方のノードペア間のベアラレベル接続パラメータを修正する必要があっても、他方のノードペア間では修正の必要がないこともある。上記のネゴシエーションは、呼出し確立時または呼出時に行うことができる。後者が該当するのは、例えば、ユーザが呼出し時に暗号の使用を開始しようとする場合である。この手順は、総称機能を変更する必要があるネットワーク内のポイント数を減らすことができる。特に、上記で指定した機構を使用し、複数CCセクションに渡るエンドツーエンド呼出しのコード変換ポイント数またはセキュリティアルゴリズムポイントの変換処理を最小限に抑えることができる。この解決方法は、1つまたは複数のネットワークに渡る呼出しに適用できる。GCN機構には、オプションリストおよびその選好レベルを開始CCノードに組み込ませ、発信ノードが示す選好レベルを使用して終端ノードにサポートオプションを選択させるという機能も含まれている。後述するネゴシエーション機構は、ネゴシエーションを2つのCCノード間で行う場合だけ有用である。提案した適合方法では、このGCN機構を複数のCCノードがネゴシエーションに介在する場合に拡張している。つまり、1つまたは複数の遠隔通信業者に属する複数のCCノードに呼出しがまたがる場合である。この適合方法には、以下の動作シーケンスが含まれる。1.開始CCノードは、サポートオプションのリストおよび各オプションに対応する選好レベルを送信する。2.中継CCノードは受信したオプションリストを分析し、サポートされていないオプションをそのリストから削除し、リストを次のノードへ転送する。3.終端CCノードは、受信したオプションリストおよび対応する優先順位を分析し、示されている最高優先順位のサポートオプションを選択する。合法代行受信の場合、呼出しを正常に代行受信できるように、合法代行受信ポイントつまり、代行受信が行われるノードでユーザプレーンデータのセキュリティ及びコーディング特性を受信できるようにしている。図1に示す提案された新しいアーキテクチャでは、呼出し制御プロトコルがトランスポート機構から独立している。この場合、TICCが呼出しにコーデックネゴシエーションを実行しないと、当該呼出しについてユーザプレーントランスポート接続を確立できない。その理由は、呼出しをサポートするのに必要なトランスポート資源量は、当該呼出しについて選択したコーデックつまり、コーデックネゴシエーション手順の結果に依存するからである。場合によっては、コーデックは最初に呼出しに選択されるが、環境の変化により、このコーデックを呼出しの後半のフェーズで新しいコーデックに変更しなければならない。この状況が発生する重要な2つの場合は、以下の通りである。1告知情報を行い、自動的にまたは呼び出した側からの入力に従って、呼び出された側へ呼出しを再転送するために行うインテリジェントネットワークINサービスとの対話。これは、告知情報を行うためには、第1のコーデックを選択する必要がある。後で、呼出しを相手側へ転送/再転送し、第2のコーデックを使用する。2これは所謂補足サービスであるCFNRCallForwardingonNoReply。第1のコーデックをA側とB側との間でネゴシエートした後、Bが事前定義された時間内に返答しないために呼出しをC側へ転送する。2番目のコーデックは、C側の要求に従って必要となる。上記の1及び2の場合及び関連する他の場合は、最初の選択されたコーデックによりトランスポート機構で呼出し接続を確立し、告知情報、信号音検査などを実行する必要がある。後でコーデックが変更されたら、呼出し接続を修正し、新しいコーデックをサポートしなければならないことがある。以下に、図6を参照し、TICCプロトコルを使用しているネットワークで使用され、且つ、通話呼出しのエンドツーエンド電話接続を確立できるシグナリングプロセスを説明する。ここでは、呼出しは発信シグナリングポイントであるノードAで生成され、最初に第1のノードであるノードBまたはシグナリングポイントへ転送される。この呼出しは、その後、別の終端シグナリングポイントであるノードCへ転送される。図示したプロセスは、特にINサービスの呼出しに関するもので、この場合は、呼出し側は最初にINネットワークノードに接続され、このノードでは事前記録メッセージを呼出し側へ再生した後に、呼出しを最終的な終端シグナリングポイントへ転送するものである。また、図示したプロセスはCFNRサービスに関連し、この場合は、最初の終端シグナリングポイントへ接続されている呼出し側が呼出しに返答しない場合、新しい終端シグナリングポイントへ呼出しを転送する。シグナリングシーケンスは、以下の順次ステップで構成される。1.ノードAはノードBへの呼出しを確立する。コーデックXをこの呼出しのために選択する。2.選択したコーデックに適切なトランスポート資源を有するトランスポート接続を、ノードAとノードBの間に設定する。3.ノードBは、呼出しをノードCへ転送/再転送する。ノードCはコーデックXをサポートせず、コーデックYを選択する。4.ノードBはノードAに対し、コーデックXからコーデックYへのこの呼出しに関するコーデック選択を修正するように要求する。5.ノードAとノードB間のトランスポート接続をコーデックYに合わせて、必要に応じ、修正する。図6は、トランスポート接続への修正が順方向に行われるケースと修正が逆方向に行われる代替ケースとを示している。6.コーデックYに適切なトランスポート接続を、ノードBとノードC間に確立する。7.TICCは、呼出し確立を完了するTICCACMTICCANM。TICCはISUPをベースにしているため、シグナリングメッセージ名はISUPから取られる。しかし、ISUPにはコーデックネゴシエーション手順またはコーデック修正手順が含まれていないため、コーデック修正機能を実行するために新しいTICCメッセージのペアTICC修正.要求/確認が必要になる。図6では、ノードAからノードBへのトランスポート接続について行われた修正だけが順方向または逆方向に行われることを示しているが、他のトランスポート接続修正も順方向または逆方向に行うことができる。また、トランスポート接続も順方向または逆方向に確立できる。上記で説明した機構を使用し、4つ以上のシグナリングポイントまたはノード間の通話呼出し接続を確立することができる。例えば、発信シグナリングポイントであるノードAと元の終端シグナリングポイントであるノードBとの間、または元の終端シグナリングポイントであるノードBと最終的な終端シグナリングポイントであるノードCとの間またはその両方に、1つまたは複数の中継ノードが存在してもよい。また、呼出しは、ノードCからさらに別のシグナリングポイントつまりノードDへ転送または中継することもできる。ただし、この場合はコーデックYがノードDに適当かどうかを判別するためのネゴシエーションが必要になり、適当でない場合は、ノードAとノードBとの間及びノードBとノードCとの間のトランスポート接続に修正が必要になることがある。このプロセスは、任意のノード数に拡張できる。従来の公衆電話交換網PSTNは、パルスコード変調PCMを使用して転送用通話データをデジタルにコード化する。一方、デジタルモバイル電話ネットワークは、CELP及び適応マルチレートAMRコーディングなどのさらに高度なコーディング技法を使用し、PCMより高度な圧縮率を達成している。多くのモバイルネットワークでは、通話のコーディング及びデコーディングはモバイル端末自身で行う。同じネットワークに登録されている2つのモバイル端末で呼出しを行う場合は、コード化された通話データをエンドツーエンドで送信することが可能である。モバイルネットワークに登録されているモバイル端末から外部ネットワークの加入者である端末へ呼出しが出された場合、コード化された通話データのエンドツーエンド伝送は、外部ネットワークの特性及び発信モバイルネットワークを外部ネットワークへ接続する中間ネットワークの特性によっては、不可能な場合がある勿論、これは呼出しが外部ネットワークで発信する場合も当てはまる。図7の遠隔通信システムを考えてみると、このシステムは2つの第3世代ユニバーサル移動通信方式UMTSネットワーク1と2とで構成されていて、これら2つのネットワークが従来のPSTN/ISDNネットワーク3により連結されている。UMTSネットワーク1と2は、それぞれ、UMTSターミナル地上無線接続ネットワークUTRAN4を含み、そのネットワークが無線ネットワークコントローラRNC5と無線基地局BTS6とで構成されている。UTRAN5は、モバイル端末図示せずと入力呼出し接続ならびに出力呼出し接続を転送するモバイル交換センタMSC7との間で、圧縮通話データを受け渡す。片方のUMTSネットワーク1の加入者から呼出しが発信され、別のUMTSネットワーク2の加入者へその呼出しが送られるものとする。呼出しは、UMTSネットワーク1と2の各中継ノード8いずれかはゲートウェイMSCGMSCを使用し、PSTN3を介して転送される。上記ですでに説明したように、PSTN3はPCMを使用して通話データを符号化する。PSTN3を介して転送される通話データは、当該ネットワークで理解できる形式であることが重要である。例えば、PSTN3が、通話呼出しに業者の告知情報を挿入したり音声プロンプトサービスなどを実行できるようにしたりするため、また、PSTN3の業者がセキュリティの目的などで呼出しを監視できるようにするために必要である。したがって、PSTN3にデータを渡す前に、UMTSネットワーク1と2のGMSC8で通話データをコード変換することが必要である。つまり、通話データは、モバイルネットワーク通話コーディング形式からPCMへ変換される。同様に、GMSC8で受信したPCMデータは、該当するモバイルネットワーク通話コーディング形式に変換する必要がある。コード変換を実行するとGMSC8において大量の処理資源を消費することになり、また、通話品質の低下も目立つ。これらの欠点を一部でも補うために、タンデムフリーオペレーションTFO装置をGMSC8における通話接続に導入できる。出力通話データはいままで通りPCMに変換されるが、各PCMサンプルの最下位ビットはTFO装置により盗聴される。これらの盗聴ビットが形成するチャネルの帯域幅は十分に大きくつまり8Kビット/秒元のコード化データを送信できる。終端UMTSネットワークのTFO装置はコード化データを組み立てて対応するUTRANへ送信するが、受信されたPCMデータは廃棄される業者の告知情報が追加されているなどして、PSTNによりそのデータが修正されていない限り。このようにして、TFOはPSTN3がPCMデータを利用できるようにするが、効果的にコード化された通話データのエンドツーエンド送信はいままで通り実行できる。PSTN/ISDN内の中間装置がPCMビットストリームを変更すると、TFO装置はその変更を検出し、TFO装置間でPCMコード化通話を受け渡すようにフォールバックする。つまり、それ以降は圧縮音声データを受け渡さない。モバイルネットワークが利用できる通話コーデックは、ネットワークの特性及び場合によってはネットワークを使用している端末の特性により異なる。エンドツーエンドで単一のコーデックを使用できるのは、2つのネットワークが両方とも同じコーデックを使用するときだけであることは明らかである。2つのモバイル通信ネットワークのGMSCが接続ネットワークのコーデック機能の情報を得ていると想定すると、それらGMSCネゴシエートして共通のコーデックの使用に合意することは可能である。実際、ETSI勧告GSM08.62バージョン7.0.0、リリース1998では、適当なプロトコルが提供されている。TFO装置がモバイルネットワークの境界部分、つまり、UTRANの外側に設置されている図7のような場合従来、TFO装置は無線アクセスネットワーク内に設置される、モバイルネットワークでTFOを実行しようとすると問題が発生する。現在のところ、このようなネットワークではTFO装置相互間及びTFO装置と無線アクセスネットワークとの間でネゴシエートされたコーデックに関する交換情報はない。図8は、2つのUMTSネットワークのGMSCがTFO装置9を組み込んでいる修正システムアーキテクチャを示している。一方、図9は各UMTSモバイル電話ネットワークにおける2つのノード間の呼出しセットアップに関するシグナリングを示している。ノード1とノード4はMSCを表し、2つの中間ノード2と3はGMSCを表している。UMTSネットワーク内における呼出しセットアップシグナリングは、呼出し制御例えばTICCレベルで行われる。この呼出しセットアップは、MSCから対応GMSCへ送られる初期アドレスメッセージIAMにより開始される。このIAMは総称機能ネゴシエーションGCN機構を使用し、呼出し接続のパラメータ数を決定する。特に、IAMには、発信UMTSネットワークがサポートするコーデックリストと選好コーデックとが含まれている。発信側GMSCは送信されたコーデックリストからコーデックを選択し、選択した内容をメッセージ選択されたコーデック1の形式でMSCへ返送する。その後、呼出し接続は、選択されたコーデックをサポートするために十分な帯域幅のベアラレベル例えばAAL2またはIPで確立される。エンドツーエンドコーデックネゴシエーションを実行できるようにするために、ISUPプロトコルにGCNを追加することが提案されている。このエンドツーエンドコーデックネゴシエーションを行うことで、両エンドポイントが同じコーデックタイプを利用する確率が高まる。両エンドポイントが同じ音声コード化アルゴリズムを使用していると、TFOはPCMネットワークを介して圧縮音声を渡すことができ、しかも、不要な変換処理による音声品質の低下を招くこともない。また、圧縮音声をサポートしている発信ネットワーク及び終端ネットワーク内のベアラ要件も低下するため例えば、AAL2またはIPベアラトランスポート、送信量も少なくて済む。図9は、2つのUMTSネットワーク間のシグナリングギャップを解消するためのGCN機能向上ISUPメッセージの使用を図示したものである。終端UMTSネットワークでは、GMSCからMSCへIAMがTICCを使用して送られる。この場合、MSCはコーデック1の使用を受諾し、その旨をTICCを使用してGMSCに再び返送する。その後、ベアラレベル接続は終端UMTSネットワークで確立される。PSTNは、コーデック受諾の旨を発信側のGMSCへ中継する。最初に提案されたコーデックが受諾されたため、発信UMTSネットワークにおいてベアラレベル接続を変更する必要はない。しかし、コーデックに変更があった場合は、その旨を発信側GMSCからMSCへ送信する必要がある。その結果、ベアラレベル接続を修正できるようになり、接続の帯域幅を拡張したりできる。図9では、ACMはアドレス完了メッセージAddressCompleteMessageを示し、ANMは応答メッセージAnswerMessageを示す。図10は、本発明の第2実施例を図示したものである。この解決方法は、TFOプロトコルに用意されているオプションのコーデック不一致解決及び最適化手順を利用し、互換性のないコーデックを検出する。TFOがコーデックの非互換性を検出すると、コーデック修正手順を開始して、端末が使用するコーデックを修正できる。TFOは、コーデック不一致を解決するための規則を指定するつまり、どのコーデックを選択するか。次に、TFOプロトコルはTICCシグナリングを開始し、呼出しで使用するコーデックを修正し、2つのエンド端末で互換性のあるコーデックを使用可能にする。発信UMTSネットワークが最初に示したコーデックから別のコーデックに変更する場合は、両方のUMTSネットワークで確立したベアラレベル接続を修正しなければならない場合がある。上記で述べた実施例は、中間PCMネットワークによる不要な通話コード変換を最小限に抑え、また、公衆遠隔通信ネットワークにおける特定の呼出しのサービスレベルをサポートするために、ユーザプレーン装置例えばコード変換装置またはユーザプレーン資源例えば帯域幅あるいはその両方の割当てを最適化する。既存のネットワーク及び新しいネットワークが通話経路における不要なコード変換を極力減らすためにPCMコード化音声だけをサポートする場合、コーデックタイプのネゴシエーションが必要になる。UMTS及びGSMの加入者通話品質は、TFOサポート機能を備えた既存のPCMコアネットワークを呼出しが通過する場合、必ずしも低下しない。TICCプロトコルにGCN機構を組み込むと、透過方式で行われることが多いAPMユーザ。当業者は、本発明の範囲から逸脱することなく、上記の実施例に各種変更を加えることができることは明らかである。