"端末と前記端末の通信相手である相手端末との間の通信開始時に、前記相手端末から通知された複数のコーデックモード候補の中から選択したコーデックモードを前記相手端末に送信する端末であって、前記相手端末が現在接続しているアクセス網の特性に関する第1の情報を受信する受信手段と、前記第1の情報と、自機が現在接続しているアクセス網の特性に関する第2の情報とを比較し、自機と前記相手端末との間の通信形態を判断する判断手段と、前記判断手段で判断された前記通信形態に基づいて、前記複数のコーデックモード候補の中から、前記相手端末との通信で使用するコーデックモードを選択する選択手段と、を具備する端末。前記判断手段は、前記通信形態が、同一の基地局、複数の基地局、又は、複数の基地局及びVPNVirtualPrivateNetworkバックボーンで構成される通信網で接続された第1の通信形態、IPコア網を介した異なる基地局に接続された第2の通信形態、及び、前記第1の通信形態及び前記第2の通信形態のそれぞれと異なる第3の通信形態のいずれであるかを判断し、前記選択手段は、前記通信形態が前記第1の通信形態の場合に最も高品質なコーデックモードを選択し、前記通信形態が、前記第2の通信形態の場合、前記第3の通信形態の場合よりも高品質なコーデックモードを選択する、請求項1記載の端末。前記第1の情報は、呼制御のための処理機能を有するネットワークノードを経由して前記相手端末から前記端末へ送信され、前記ネットワークノードは、前記第1の情報の妥当性を確認する、請求項1記載の端末。前記受信手段は、更に、前記ネットワークノードでの前記妥当性の確認結果を受信し、前記判断手段は、前記確認結果に基づいて、前記通信形態の判断を行うか否かを決定する、請求項3記載の端末。前記受信手段は、更に、前記相手端末のハンドオーバの可能性の有無を示す第3の情報を受信し、前記判断手段は、前記第1の情報、前記第2の情報、前記第3の情報、及び、自機のハンドオーバの可能性の有無を示す第4の情報に基づいて、前記通信形態を判断する、請求項1記載の端末。前記第3の情報及び前記第4の情報は、前記相手端末及び前記端末のそれぞれが、据え置き型の装置であるか否か、据え置き型のノードに接続されているか否か、又は、通信モードが電話会議モードに設定されているか否か、を示す、請求項5記載の端末。通信中の自機又は前記相手端末において、ハンドオーバの可能性が変化した場合、現在使用しているコーデックモードを変更する変更手段を、更に具備する、請求項5記載の端末。前記第1の情報及び前記第2の情報は、CSGIDClosedSubscriberGroupIdentifier、又は、基地局IDである、請求項1記載の端末。前記アクセス網の特性は、1端末あたりに割当可能な無線リソース量である、請求項1記載の端末。前記コーデックモードには、ビットレート及び処理遅延が含まれる、請求項1記載の端末。前記選択手段で選択された、前記相手端末との通信で使用するコーデックモードは、RTPRealtimeTransportProtocolペイロードを用いて通知される、請求項1記載の端末。前記RTPペイロードは、ヘッダ部とデータ部とから成り、前記ヘッダ部の長さは、相手端末との通信で使用するコーデックモードに応じて変更される、請求項11記載の端末。前記RTPペイロードは、ヘッダ部とデータ部とから成り、前記ヘッダ部は、全てのRTPペイロードにおいて常に設けられる第1のヘッダと、全てのRTPペイロードにおいて常に設けられるとは限らない第2のヘッダとを含む、請求項11記載の端末。前記第1のヘッダには、前記第2のヘッダが設けられるか否かを示すフィールドが含まれる、請求項13記載の端末。前記選択手段は、更に、前記複数のコーデックモード候補のうち、前記端末に対して通信又は通話サービスを提供するオペレータのポリシーの少なくとも一部に対応するコーデックモード候補の中から、前記相手端末との通信で使用するコーデックモードを選択する、請求項1記載の端末。前記相手端末から通知される前記複数のコーデックモード候補には、前記相手端末に対して通信又は通話サービスを提供するオペレータのポリシーの少なくとも一部に対応するコーデックモード候補が含まれる、請求項15記載の端末。前記ポリシーには、前記オペレータが優先的に使用する、コーデックの方式、コーデックビットレート、サンプリングレート、オーディオ帯域、処理遅延、チャンネル数、セッション途中でのビットレート及びチャンネル数の切り替えを許可するか否か、VariableBitRateVBRオペレーションを許可するか否か、又は、冗長フレームを許可するか否かが含まれる、請求項15記載の端末。前記RTPペイロードは、データ部と、全てのRTPペイロードにおいて常に設けられるとは限らない後続シグナリング部と、全てのRTPペイロードにおいて常に設けられる、前記後続シグナリング部の有無を示すフィールドと、を含み、前記コーデックモードは、前記後続シグナリング部を用いて通知される、請求項11記載の端末。前記RTPペイロードは、データ部と、全てのRTPペイロードにおいて常に設けられるとは限らないヘッダ部と、全てのRTPペイロードにおいて常に設けられる、前記ヘッダ部の有無を示すフィールドと、を含み、前記コーデックモードは、前記ヘッダ部を用いて通知される、請求項11記載の端末。前記相手端末が生成した前記複数のコーデックモード候補を含む第3の情報は、呼制御のための処理機能を有するネットワークノードを経由して前記端末へ送信され、前記ネットワークノードは、前記端末が現在接続しているアクセス網が前記ネットワークノードの配下である場合、前記第3の情報に示される前記複数のコーデックモード候補を変更し、前記選択手段は、変更後の前記第3の情報に含まれる前記複数のコーデックモード候補の中から、前記相手端末との通信で使用するコーデックモードを選択する、請求項1記載の端末。前記ネットワークノードは、更に、前記第3の情報を確認したか否かを示す確認情報を前記端末へ送信し、前記選択手段は、前記第3の情報を確認済みであることを前記確認情報が示す場合、変更後の前記第3の情報に含まれる前記複数のコーデックモード候補の中から、前記相手端末との通信で使用するコーデックモードを選択する、請求項20記載の端末。第1の端末と前記第1の端末の通信相手である第2の端末との間の通信開始時に、前記第1の端末が、前記第2の端末から通知された複数のコーデックモード候補の中から選択したコーデックモードを前記第2の端末に送信する通信システムにおいて、前記第2の端末が、前記第2の端末が現在接続しているアクセス網の特性に関する第1の情報を前記第1の端末に通知するステップと、前記第1の端末が、前記第1の情報を受信するステップと、前記第1の端末が、前記第1の情報と、前記第1の端末が現在接続しているアクセス網の特性に関する第2の情報とを比較し、前記第1の端末と前記第2の端末との間の通信形態を判断するステップと、前記第1の端末が、判断された前記通信形態に基づいて、前記複数のコーデックモード候補の中から、前記第2の端末との通信で使用するコーデックモードを選択するステップと、を具備するコーデックモード選択方法。上述した通話開始時のネゴシエーションでのコーデックモード選択は、データのやり取りが実際に行われるネットワークの状況とは独立に行われる。このため、通話開始時点、或いは、通話期間全体で使用されるコーデックモードとして、適切なコーデックモードが選択されない場合があるという課題がある。現在3GPPSA4で議論されているEVSEnhancedVoiceServicesでは、AMR及びAMR-WBに比べ、より高ビットレートのサポート、複数の処理遅延のサポート、2チャンネルステレオのサポート等が考えられている。このため、特にEVSでは、好適なコーデックモードの選択が求められる。上記課題に対して、UEが現在のAirInterfaceの帯域幅をサーバに通知し、AirInterfaceの帯域幅に基づいてサーバにビットレートを決定させる方法が提案されている例えば、特表2006-500808号公報を参照。また、UEが無線区間の状況をモニタリングし、無線区間の状況に応じて好適なデジッタバッファ長を調整する方法が提案されている例えば、米国特許出願公開第2006/0077994号明細書を参照。しかしながら、どちらの方法も、UEが無線の状態現在のAirInterfaceの帯域幅又は無線区間の状況をモニタリングする分、UEに負担がかかる。その上、上記方法では、エンドツーエンドでの通信状況UE間の通信経路の品質は考慮されていない。また、非特許文献2には、ネゴシエーション時に、通信状況に関わらず確実に通信可能なコーデックモードつまり、ネゴシエーション失敗が生じる可能性が低いコーデックモードを選択する方法が記載されている。そして、非特許文献2には、更に、ネゴシエーションで選択されたコーデックビットレートの範囲のうち、低いコーデックビットレートを用いて通話を開始する方法が記載されている。この方法では、通話開始後、エンドツーエンドのネットワークの通信状況UE間の通信経路の品質に応じて、選択されたコーデックビットレートの範囲内でコーデックビットレートを調整する。しかし、この方法では、通話開始時から適当なコーデックビットレート実際の通信状況に適したコーデックビットレートを設定できない上、通話期間全体において使用可能なコーデックビットレートの上限も限定されてしまう。一方、ネットワークノードが、ネットワークの通信状況UE間の通信経路の品質をUEにフィードバックし、UEがネットワークの通信状況に応じてコーデックモードを選択する方法も考えられる。しかし、この方法では、ネットワークのトラフィック量が増大し、ネットワークに負担がかかってしまう。本発明の目的は、ネットワーク及び端末UEに対する処理負荷を抑えつつ、端末間の通信経路の品質に応じたコーデックモードを通信の初期段階から選択することができる通信端末及びコーデックモード選択方法を提供することである。本発明の一態様に係る端末は、端末と前記端末の通信相手である相手端末との間の通信開始時に、前記相手端末から通知された複数のコーデックモード候補の中から選択したコーデックモードを前記相手端末に送信する端末であって、前記相手端末が現在接続しているアクセス網の特性に関する第1の情報を受信する受信手段と、前記第1の情報と、自機が現在接続しているアクセス網の特性に関する第2の情報とを比較し、自機と前記相手端末との間の通信形態を判断する判断手段と、前記判断手段で判断された前記通信形態に基づいて、前記複数のコーデックモード候補の中から、前記相手端末との通信で使用するコーデックモードを選択する選択手段と、を具備する構成を採る。本発明の一態様に係るコーデックモード選択方法は、第1の端末と前記第1の端末の通信相手である第2の端末との間の通信開始時に、前記第1の端末が、前記第2の端末から通知された複数のコーデックモード候補の中から選択したコーデックモードを前記第2の端末に送信する通信システムにおいて、前記第2の端末が、前記第2の端末が現在接続しているアクセス網の特性に関する第1の情報を前記第1の端末に通知するステップと、前記第1の端末が、前記第1の情報を受信するステップと、前記第1の端末が、前記第1の情報と、前記第1の端末が現在接続しているアクセス網の特性に関する第2の情報とを比較し、前記第1の端末と前記第2の端末との間の通信形態を判断するステップと、前記第1の端末が、判断された前記通信形態に基づいて、前記複数のコーデックモード候補の中から、前記第2の端末との通信で使用するコーデックモードを選択するステップと、を具備するようにした。本発明によれば、端末が保有している情報を折衝情報として用いることにより、ネットワーク及び端末の双方に処理負荷をかけることなく、端末間の通信経路の状況を判断し、適切なコーデックモードを選択できる。以下、本発明の各実施の形態について、図面を参照して詳細に説明する。図4は、本発明の各実施の形態に係るネットワーク構成と、端末の位置関係の一例を示す図である。なお、図4において、図1と同一構成である部分には同一の符号を付してその説明を省略する。HeNBHomeeNodeB400、402は、小型基地局ここではフェムト基地局とする。例えば、3GPPTS23830v900ArchitectureaspectsofHomeNodeBandHomeeNodeBを参照。以下同様であり、限られたユーザが保有するUEのみ各HeNBに接続可能であることを示すCSGIDClosedSubscriberGroupIdentifier。例えば、3GPPTS25401v900UTRANoveralldescriptionを参照を保持する。HeNB400は、無線アクセス網406を構成し、HeNB402は、無線アクセス網408を構成する。図4に示すネットワーク構成では、HeNB400、402は、同一のLocalGWGateway404に接続されている。よって、HeNB400及びHeNB402にそれぞれ接続されているUE同士UE100とUE102は、オペレータのIPコア網124を経由することなく、LocalGW404を経由してデータを送受信することができる。図4に示す無線アクセス網406、408には、限られたユーザのみが接続されるため、各無線アクセス網における1UEあたりに割当可能な無線リソースは大きい。このような構成は、例えば、HeNBを用いて企業内の専用電話網を構築する場合等に適用される。なお、図4では、LocalGW404がHeNB400、402から独立している例が挙げられているが、これに限定されない。その他の構成、例えばLocalGW404が各HeNB400、402にそれぞれ設置され、各HeNBに設置されたLocalGWが直接或いは他のノードを介して接続される構成が採用されてもよい。図5は、本発明の各実施の形態に係るネットワーク構成と、端末の位置関係の別の例を示す図である。なお、図5において、図1と同一構成である部分には同一の符号を付してその説明を省略する。HeNB500、502は、小型基地局フェムト基地局であり、HeNB500は、無線アクセス網506を構成し、HeNB502は、無線アクセス網508を構成する。図5に示すネットワーク構成では、HeNB500とHeNB502とがそれぞれ別々にオペレータのIPコア網124に接続されている。よって、HeNB500及びHeNB502にそれぞれ接続されているUE同士UE100とUE102は、オペレータのIPコア網124を経由してデータを送受信する。ただし、無線アクセス網506、508には、図4と同様、限られたユーザのみが接続されるため、各無線アクセス網における1UEあたりに割当可能な無線リソースは大きい。このような構成は、例えば、個人宅等にHeNBが設置されている場合等に適用される。以下の説明では、図4に示すUE100とUE102との間の通信形態各々が接続されたHeNB及びLocalGWを介した通信形態を、HeNBローカル網通信と呼ぶ。また、図5に示すUE100とUE102との間の通信形態各々が接続されたHeNB及びIPコア網を介した通信形態を、HeNBIPコア網通信と呼ぶ。ここで、図6を用いて、本発明の各実施の形態で用いるRTP関連用語を説明する。RTPパケットは、図6に示すように、RTPヘッダとRTPペイロードとから成る。RTPヘッダはIETFInternetEngineeringTaskForceのRFCRequestforComments3550に記載の通りであり、RTPペイロードの種類コーデックの種類等によらず共通である。RTPペイロードのフォーマットはRTPペイロードの種類により異なる。図6に示すように、RTPペイロードは、ヘッダ部とデータ部とから成るが、RTPペイロードの種類によってはヘッダ部が存在しない場合もある。RTPペイロードのヘッダ部には、音声及び動画等のエンコードされたデータのビット数を特定するための情報等が含まれる。RTPペイロードデータ部には、音声及び動画等のエンコードされたデータの他、このRTPペイロード長が1オクテット8ビットの倍数にならなかった場合に付加されるpadding等が含まれる。また、図6に示すように、RTPパケットが伝送される際、更に下位層のヘッダUDPUserDatagramProtocolヘッダ、IPヘッダ、及びIP以下の伝送路固有のヘッダが付加される。実施の形態1図7は、本実施の形態に係る端末UE100、102の構成を示すブロック図である。なお、説明が煩雑になることを避けるために、図7では、本発明と密接に関連する端末同士の通信に関するネゴシエーションに関わる主な構成部例えば、図2に示すST11~ST15に関わる構成部を示す。図7に示す端末UE100、102において、無線受信部600は、自機が発呼側の場合、通信相手である相手端末着呼側UEから通知されるシグナリングメッセージSIP183SessionProgressメッセージを受信する。そして、無線受信部600は、受信したシグナリングメッセージをモード決定部608に出力する。このシグナリングメッセージには、例えばSDPアンサー内に記述された、コーデックモードセットビットレート、処理遅延、チャンネル数等の組み合わせが含まれている。一方、無線受信部600は、自機が着呼側の場合、通信相手のUE発呼側から通知されるシグナリングメッセージSIPINVITEメッセージを受信する。そして、無線受信部600は、受信したシグナリングメッセージを情報比較部606及びモード決定部608に出力する。このシグナリングメッセージには、例えばSDPオファー内に記述された、コーデックモードセット候補ビットレート、処理遅延、チャンネル数等の組み合わせの候補、及び、通信相手のUEが現在接続している無線アクセス網の特性に関する情報が含まれている。無線送信部602は、シグナリング生成部610から出力されるシグナリングメッセージSIPINVITEメッセージ又はSIP183SessionProgressメッセージを通信相手のUEへ送信する。接続先判断部604は、自機が現在接続している無線アクセス網の特性を判断し、無線アクセス網の特性に関する情報を保持する。接続先判断部604は、無線アクセス網の特性に関する情報を、情報比較部606及びシグナリング生成部610に出力する。情報比較部606は、自機が着呼側の場合、自機が現在接続している無線アクセス網の特性に関する情報と、通信相手のUE発呼側が現在接続している無線アクセス網の特性に関する情報とを比較する。前者は、接続先判断部604から入力される情報であり、後者は、無線受信部600から入力される、シグナリングメッセージに含まれる情報である。具体的には、情報比較部606は、双方の無線アクセス網の特性に関する情報を比較して、自機と相手端末との間の通信形態を判断する。例えば、情報比較部606は、自機及び相手端末が、HeNBローカル網通信、HeNBIPコア網通信、及び異なる通信形態のうち、いずれであるかを判断する。ここで、HeNBローカル網通信とは、同一のHeNB、複数のHeNB、又は複数のHeNB及びVPNVirtualPrivateNetworkバックボーンで構成されるような通信網で接続された通信形態である。また、HeNBIPコア網通信とは、IPコア網124を介した異なるHeNBフェムト基地局に接続された通信形態である。そして、情報比較部606は、判断した通信形態をモード決定部608に出力する。モード決定部608は、自機が発呼側の場合、無線受信部600から入力されるシグナリングメッセージに含まれるSDPアンサーに記述されたコーデックモードセットを、自機と通信相手との間の通信で使用するコーデックモードセットに決定する。モード決定部608は、自機が着呼側の場合、無線受信部600から入力されるシグナリングメッセージに含まれるSDPオファーに記述されたコーデックモードセット候補の中から、自機と相手端末との通信で使用するコーデックモードセットを選択する。この選択は、情報比較部606から入力される通信形態に基づいて行われる。シグナリング生成部610は、自機が発呼側の場合、接続先判断部604から入力される、自機の接続先アクセス網の特性に関する情報を含むシグナリングメッセージを生成する。これにより、発呼側UEの接続先アクセス網の特性に関する情報は、着呼側UEに通知される。シグナリング生成部610は、自機が着呼側の場合、モード決定部608で決定されたコーデックモードセットを含むシグナリングメッセージを生成する。シグナリング生成部610は、生成したシグナリングメッセージを無線送信部602に出力する。次に、図7を用いて、本実施の形態に係る端末UE100及びUE102における処理について詳細に説明する。以下の説明では、図4又は図5において、現在、UE100がHeNB400又はHeNB500に接続され、UE102がHeNB402又は502に接続されており、UE100からUE102に対して電話をかけるとする。通話開始時点では、UE100発呼側UE及びUE102着呼側UEは、互いに通信相手がどこに位置しているのかに関する情報例えば、UEが接続されているセルHeNBを示すセル情報、及び、UEの位置を示す位置情報等を保持していない。UE100の接続先判断部604は、UE100が接続している無線アクセス網406又は506の特性を判断する。例えば、接続先判断部604は、UE100が現在接続しているHeNB400又は500のCSGIDに基づいて、UE100に割り当てられる無線リソース割当可能な無線リソース又は無線リソースの占有量の状況を判断する。例えば、接続先判断部604は、CSGIDがフェムト基地局を表している場合、当該フェムト基地局ではUE100に割当可能なリソースが大きいと判断する。また別の例としては、接続先判断部604は、UE100が現在接続している無線アクセス網が、3GPP等の携帯電話専用無線アクセス網以外の無線アクセス網、例えば無線LAN等で構成されたものであると判断する。この判断は、無線アクセス網の無線特性無線周波数帯またはシグナリング等などに基づいて行われる。この場合、通信データの送受信フォーマット一度に送られるフレームの個数、RTPペイロードフォーマット等は、3GPP等の携帯電話専用無線アクセス網用に制限されたフォーマットでなくてよい事などを判断する。UE100のシグナリング生成部610は、通信相手UE102に通知する情報が記述された、呼制御のためのシグナリングメッセージ例えば、SIPINVITEメッセージを生成する。例えば、接続先判断部604で無線アクセス網の特性が判断されると、シグナリング生成部610は、現在接続中の無線アクセス網がCSGIDを保持する場合、CSGIDを、SIPINVITEメッセージに含まれるSDPオファー内に記述する。又は、シグナリング生成部610は、SIPヘッダ例えばPAccessNetworkInfoheaderfieldに記述してもよい例えば、3GPPTS24229v1000SessionInitiationProtocolandSessionDescriptionProtocolを参照。また、無線アクセス網の特性に関する情報としては、CSGIDの代わりに、基地局ID例えば、3GPPTS25401v900UTRANoveralldescriptionを参照を用いてもよい。各UEでは、CSGID又は基地局ID無線アクセス網の特性に関する情報に基づいて、無線アクセス網の特性例えば、当該無線アクセス網における1UEあたりに割当可能な無線リソースが大きいか否かを特定することができる。例えば、各UEは、CSGID又は基地局IDに基づいて、当該無線アクセス網を構成する基地局がフェムト基地局である場合には、当該無線アクセス網における1UEあたりに割当可能な無線リソースが大きいと判断する。また、UE100のシグナリング生成部610は、通信相手UE102が接続している無線アクセス網408又は508の特性の全て又は一部の可能性を考慮したコーデックモードセットの候補を作成する。そして、UE100のシグナリング生成部610は、コーデックモードセットの候補をSDPオファー内に記述する。SDPオファーの記述の一例を図8に示す。例えば、UE100の接続先無線アクセス網のCSGIDがAlicefemtoである場合、図8に示すように、SDPオファー内には、例えばacsgAlicefemtoと記述される。なお、記述方法はこれに限らず別の記述方法でもよい。また、通信相手UE102の接続先無線アクセス網の特性の全て又は一部の可能性を考慮したコーデックモードのセット候補を記述する方法として、例えば各コーデックモードセットにそれぞれ対応付けられた数値のみを記述してもよい。この数値は、図8では0x00、0x01及び0x02としている。これにより、SDP内の記述量を削減することが可能となる。また、コーデックモードセットと数値との対応付けに限らず、記号又はその他の方法でコーデックモードセットを表してもよい。例えば、図8に示す数値番号0x00、0x01、0x02と、これら数値の表わす意味及びこれらに対応するコーデックモードセットとの対応関係を図9に示す。具体的には、図9に示す0x00は、例えば、後述する0x01及び0x02に対応する通信と異なる通信である通常通信を意味する。そして、図9に示す0x00は、ビットレートが6kbps前後、8kbps前後、12kbps前後であり、低いLow処理遅延であるコーデックモードセットに対応する。通常通信では、例えば、選択可能なビットレートのうち低いビットレートで通話を開始し、その後、UE間の通信経路の品質に応じてコーデックビットレートを選択する。図9に示す0x01は、IPコア網を経由した通信HeNBIPコア網通信。例えば、図5を参照個人宅を意味し、ビットレートが6kbps前後、8kbps前後、12kbps前後、24kbps前後であり、低いLow処理遅延であるコーデックモードセットに対応する。また、0x02は、LocalGWを経由した通信HeNBローカル網通信。例えば、図4を参照企業内電話網を意味し、ビットレートが6kbps前後、8kbps前後、12kbps前後、24kbps前後であり、高いHigh処理遅延であるコーデックモードセットに対応する。つまり、図9では、0x02が最も品質の良いコーデックを与えるコーデックモードセット高ビットレート,長遅延であり、続いて0x01、0x00の順に、品質を抑えたコーデックモードセット低ビットレート化,低遅延化となる。端末UE100、102には図9に示す対応付けが予め格納されていてもよい。UE100のシグナリング生成部610で生成されたシグナリングメッセージSIPINVITEメッセージは、無線送信部602を介して、IMS網126経由でUE102に送信される。一方、UE102の無線受信部600は、UE100から送信されたシグナリングメッセージSIPINVITEメッセージを受け取る。UE102の接続先判断部604は、UE100と同様に、UE102が接続している無線アクセス網408又は508の特性を判断する。UE102の情報比較部606は、受け取ったシグナリングメッセージに、通信相手UE100の接続先無線アクセス網無線アクセス網406又は506の特性に関する情報が記述されているかを確認する。情報比較部606は、無線アクセス網の特性に関する情報が記述されている場合、通信相手の無線アクセス網の特性と、自機の接続先無線アクセス網の特性とを比較する。そして、情報比較部606は、自機UE102と通信相手UE100との間の通信形態どのような通信が可能かを判断する。例えば、情報比較部606は、通信相手UE100の接続先無線アクセス網の特性に関する情報として送信されたCSGIDと、自機UE102の接続先無線アクセス網の特性に関する情報であるCSGIDとを比較する。そして、情報比較部606は、自機と通信相手とが同一企業内電話網のHeNBにそれぞれ接続されているのか、互いに個人宅のHeNBにそれぞれ接続されているのか、又は、どちらか一方又は双方が公衆の基地局eNBに接続されているのか、を判断する。又は、情報比較部606が、通信相手UE100及び自機UE102の接続先無線アクセス網の特性に関する情報を比較して、双方が物理的に近くに位置するか否か例えば、データ経路のホップ数が所定の閾値以下であるか否かを判断してもよい。UE102のモード決定部608は、情報比較部606での判断結果自機と通信相手との間の通信形態に基づいて、コーデックモードセットビットレート、処理遅延、チャンネル数等の組み合わせを決定する。本実施の形態における情報比較部606及びモード決定部608における処理の一例を図10に示す。図10は、情報比較部606及びモード決定部608における処理の流れを示すフロー図である。図10において、ST101では、情報比較部606は、自機の接続先がHeNBであるか否かを判断する。自機の接続先がHeNBではない場合ST101:NO、ST102では、モード決定部608は、通常通信0x00に対するコーデックモードセットを選択する。自機の接続先がHeNBである場合ST101:YES、ST103では、情報比較部606は、通信相手の接続先がHeNBであるか否かを判断する。通信相手の接続先がHeNBではない場合ST103:NO、ST104では、モード決定部608は、通常通信0x00に対応するコーデックモードセットを選択する。つまり、モード決定部608は、自機及び通信相手の何れか一方の接続先でもHeNBではない場合には、通常通信0x00に対応するコーデックモードセットを選択する。通信相手の接続先がHeNBである場合ST103:YES、ST105では、情報比較部606は、自機及び通信相手の互いの接続先が同一ローカル網内であるか否かを判断する。自機及び通信相手の互いの接続先が同一ローカル網内でない場合ST105:NO、ST106では、モード決定部608は、HeNBIPコア網通信0x01に対応するコーデックモードセットを選択する。自機及び通信相手の互いの接続先が同一ローカル網内である場合ST105:YES、ST107では、モード決定部608は、HeNBローカル網通信0x02に対応するコーデックモードセットを選択する。つまり、モード決定部608は、自機と通信相手との間の通信形態が、HeNBローカル網通信の場合に最も高品質なコーデックモードセットを選択する。また、モード決定部608は、上記通信形態が、HeNBIPコア網通信の場合、通常通信の場合よりも高品質なコーデックモードセットを選択する。このように、モード決定部608は、情報比較部606で自機と通信相手との間で良好な品質の通信経路を確保できるか否かの判断結果に基づいて、自機と通信相手との間の通信で使用するコーデックモード又はコーデックモードセットを判断する。すなわち、モード決定部608は、確保できると判断された場合例えば、図10に示すST101:YESかつST103:YES、使用するコーデックモード又はコーデックモードセットとして、高品質高ビットかつ長遅延であるコーデックモードセット0x01又は0x02を選択する。一方、モード決定部608は、確保できるか不明であると判断された場合例えば、図10に示すST101:NO又はST103:NO、使用するコーデックモード又はコーデックモードセットとして、通常のコーデックモードセットつまり、上述した、どのような通信状況でも通信可能なコーデックモードセットを選択する。UE102のシグナリング生成部610は、モード決定部608で選択されたコーデックモードセットを、呼制御のためのシグナリングメッセージ例えば、SIP183SessionProgressメッセージの一部、例えばSDPアンサーに記述する。この際、シグナリング生成部610は、UE102の接続先HeNB402又は502のCSGID又は基地局IDを、SDPアンサー又はSIPヘッダに記述してもよい。SDPアンサーの記述の一例を図11に示す。例えば、UE100の接続先無線アクセス網のCSGIDが図8に示すAlicefemtoであり、UE102の接続先無線アクセス網のCSGIDがBobfemtoであるとする図10のST101、ST103:YES。また、CSGIDBobfemtoの無線アクセス網とCSGIDAlicefemtoの無線アクセス網とが同一ローカル網内ではないとする図10のST105:NO。この場合、UE102の情報比較部606は、例えば、自機及び通信相手が互いに個人宅等に設置されているHeNBに接続されていると判断し、モード決定部608は、HeNBIPコア網通信0x01に対応するコーデックモードセットを選択する。よって、図11に示すSDPアンサーには、選択されたコーデックモードセットとして0x01が記述される。なお、図11に示すように、UE102の接続先無線アクセス網の特性に関する情報BobfemtoをSDPアンサーに記述してもよい。UE102のシグナリング生成部610で生成されたシグナリングメッセージ例えば、SIP183SessionProgressメッセージは、無線送信部602を介してIMS網126経由でUE100に送信される。UE100のモード決定部608は、無線受信部600を介して、UE102から送信されたシグナリングメッセージを受け取ると、SDPアンサーに記述されている内容に基づいて、コーデックモードセットを決定する。図11の一例では、UE100のモード決定部608は、HeNBIPコア網通信0x01に対応するコーデックモードセットを決定する。この際、UE100の通信相手UE102の接続先のCSGID又は基地局IDを、参照情報として用いてもよい。このように、本実施の形態では、UE間での通信開始時において、発呼側のUEは、自機の接続先無線アクセス網の特性に関する情報としてCSGID又は基地局IDを通信相手である相手端末着呼側UEに通知する。着呼側のUEは、通信相手である相手端末発呼側UEから通知された、相手端末発呼側の接続先無線アクセス網の特性に関する情報CSGID等と、自機の接続先無線アクセス網の特性に関する情報CSGID等とを比較する。そして、着呼側のUEは、自機と相手端末との間の通信形態を判断する。着呼側のUEは、UE間で良好な品質の通信経路を確実に確保できると判断できる場合、通信開始時のコーデックモードセットとして、より高品質かつ長遅延のコーデックモード又はコーデックモードセットを選択する。これは、例えば、通信形態が企業内電話網での通信、又は、個人宅での通信である場合である。これにより、各UEは、通信開始時通信の初期段階から、通信経路の品質に応じた適切なコーデックモードセットビットレート、処理遅延、チャンネル数等の組み合わせを選択することができる。なお、本実施の形態では、本発明を、コーデックモードセットの選択に適用した例を説明したが、これに限定されない。本発明に係る接続先の無線アクセス網の特性判断は、通信に必要な他の折衝、例えば通信データの送受信フォーマット一度に送られるフレームの個数、RTPペイロードフォーマット等を折衝する際の、送受信フォーマット選択に適用してもよい。また、本実施の形態では、各UEが保有している情報無線アクセス網の特性に関する情報を通信相手に通知するだけでよく、ネットワーク側及びUE側のいずれにおいても無線アクセス網の状況通信経路の品質をモニタリングする必要がない。よって、適切なコーデックモード又はコーデックモードセットの選択のためにネットワーク及びUEに掛かる負担を抑えることができる。よって、本実施の形態によれば、端末が保有している情報を折衝情報として用いる。これにより、ネットワーク及び端末UEの双方にビーコンあるいはシグナリング送受信等に伴う処理負荷をかけることなく、端末間の通信経路の状況を判断し、適切なコーデックモード又はコーデックモードセットを選択することができる。実施の形態2本実施の形態では、実施の形態1においてUEがシグナリングメッセージの一部に記述した、無線アクセス網の特性に関する情報を、IMS網のネットワークノードで確認する。このネットワークノードは、ネットワークを提供するオペレータ、つまり、呼制御のための処理機能を有するネットワークノードである。図12は、本実施の形態に係るネットワークノードの構成を示すブロック図である。図12に示すネットワークノードにおいて、受信部700は、UEからのシグナリングメッセージを受け取ると、シグナリングメッセージをシグナリング解析部704に出力する。送信部702は、シグナリング生成部708から入力されるシグナリングメッセージを、シグナリングメッセージの送信先UEに送信する。シグナリング解析部704は、受信部700から入力されるシグナリングメッセージに記述されている情報を解析し、確認が必要な情報を、適切な確認部に出力する。例えば、シグナリング解析部704は、シグナリングメッセージに記述された情報のうち、UEが現在接続されている無線アクセス網の特性に関する情報例えば、CSGID又は基地局ID等を、端末位置情報確認部706に渡す。端末位置情報確認部706は、シグナリングメッセージを送信したUEが現在接続されている無線アクセス網の特性に関する情報CSGID等。つまり、端末の位置情報が妥当であるか否か妥当性を確認する。このとき、端末位置情報確認部706は、このネットワークノード内に保持されている情報を用いて確認を行ってもよく、他のネットワークノード例えばMMEMobilityManagementEntity及びHSSHomeSubscriberServer等。3GPPTS23002v1000NetworkArchitectureを参照と連携して確認を行ってもよい。端末位置情報確認部706は、確認結果をシグナリング生成部708に出力する。シグナリング生成部708は、UEから送信されたシグナリングメッセージの中で修正が必要な記載内容の上書きを行う。例えば、端末位置情報確認部706において、無線アクセス網の特性に関する情報が妥当であると判断されたとする。この場合、シグナリング生成部708は、ネットワークエンティティによる妥当性確認済を示す情報を、フラグ、数値、及び、テキスト等の記載方法でシグナリングメッセージに追加してもよい。また、端末位置情報確認部706において、無線アクセス網の特性に関する情報が妥当ではないと判断された場合、シグナリング生成部708は、シグナリングメッセージから、無線アクセス網の特性に関する情報を削除してもよい。又は、シグナリング生成部708は、端末位置情報確認部706での確認結果を示す情報妥当性の確認結果をシグナリングメッセージに追加してもよい。修正されたシグナリングメッセージは、送信部702を介して、シグナリングメッセージの送信先に送信される。シグナリングメッセージを受け取ったUEは、例えば、ネットワークエンティティによる妥当性確認済であることを特定する。この場合、UEは、実施の形態1と同様にして、シグナリングメッセージに記述された通信相手の接続先無線アクセス網の特性に関する情報を用いて、通信相手との通信形態を判断する。一方、シグナリングメッセージを受け取ったUEは、例えば、ネットワークエンティティによる妥当性確認済であることを特定できなかったとする。この場合、UEは、通信相手の接続先無線アクセス網の特性に関する情報を用いた、通信相手との通信形態の判断を行わない。つまり、UEは、ネットワークノードでの妥当性の確認結果に基づいて、相手端末との通信形態の判断を行うか否かを決定すればよい。これにより、UEは、自機と相手端末との間の通信形態を正確に判断することが可能となる。つまり、自機と相手端末との間の通信形態判断の確実性を向上させることができる。よって、本実施の形態によれば、実施の形態1と比較して、端末間の通信経路の状況をより正確に判断することができ、適切なコーデックモード又はコーデックモードセットを選択できる。なお、本実施の形態において、ネットワークノードは、IMS網のエンティティP-CSCF及びS-CSCF等。3GPPTS23002v1000NetworkArchitectureを参照であってもよく、企業内の専用電話網を構築する場合に用いられるIP-PBXInternetProtocolPrivateBrancheXchange等でもよい。例えば、IMS網のエンティティの1つであるP-CSCF図4又は図5に示すP-CSCF108、116には、SDPの内容を確認し、書き換える機能が備えられている。よって、本実施の形態に係るネットワークノードとしてP-CSCFを用いると、SDPの確認機能を無線アクセス網の特性に関する情報の確認にも利用できるので、ネットワーク側の負担の増やすことなく、本実施の形態と同様の効果を得ることができる。また、本実施の形態では、ネットワークノードが妥当性確認済を示す情報をUEに通知する場合について説明したが、妥当性確認済を示す情報は、UEに通知されなくてもよい。例えば、上述したように、ネットワークノードは、妥当ではないと判断された無線アクセス網の特性に関する情報をシグナリングメッセージから削除する。この場合、シグナリングメッセージの送信先UEでは、誤った情報を用いて通信形態の判断を行うことがなくなる。よって、ネットワークノードが妥当性確認済を示す情報をUEに通知しない場合でも、本実施の形態と同様、端末間の通信形態判断の確実性を向上させることができる。例えば、ネットワークノードは、同一オペレータのIPコア網に接続されたUE同士の通信については上記妥当性確認済を示す情報を通知しなくてもよい。そして、その代わりに、ネットワークノードは、異なるオペレータのIPコア網にそれぞれ接続されたUE同士の通信については上記妥当性確認済を示す情報を通知してもよい。実施の形態3本実施の形態では、UEの接続先アクセス網の特性に関する情報に加え、UEのハンドオーバの可能性の有無を示す情報を用いて、コーデックモード又はコーデックモードセット選択が行われる。更に、本実施の形態では、通話途中でハンドオーバの可能性の有無に変更が生じた場合には、コーデックモード又はコーデックモードセットの変更が行われる。図13は、本実施の形態に係る端末UE100、102の構成を示すブロック図である。なお、図13において、図7と同一構成である部分には同一の符号を付してその説明を省略する。図13に示す端末は、図7に示す端末の構成部に加え、状態解析部812及びモード変更部814が追加される。図13に示す端末において、状態解析部812は、自機の種類及び状態等から、自機にハンドオーバの可能性があるか否かを解析判断する。例えば、UEが電話会議システム用の据え置き型端末である場合、状態解析部812は、自機のハンドオーバの可能性は低いと判断する。また、自機が小型のUEであっても据え置き型の機器、スピーカ及びマイクロフォン等に接続されている状態の場合、状態解析部812は、自機のハンドオーバの可能性は低いと判断する。あるいは、自機が電話会議モード設定部図示せずを具備し、ユーザにより明示的にUEのユーザインタフェースの操作により電話会議モードが選択された場合、状態解析部812は、自機のハンドオーバの可能性は低いと判断する。状態解析部812は、通信開始時の解析結果を示す情報を、シグナリング生成部610に出力する。これにより、当該解析結果自機のハンドオーバの可能性の有無を示す情報は、シグナリングメッセージに付加されて、通信相手に通知される。また、状態解析部812は、通信途中における自機の状態を解析し、通信途中において自機の状態が変化した場合、自機の状態の変化内容をモード変更部814に出力する。例えば、据え置き型の機器、スピーカ及びマイクロフォン等に接続されて通信しているUEが、これらの機器と非接続になった場合、状態解析部812は、自機とこれらの機器とが非接続になったことをモード変更部814に出力する。モード変更部814は、状態解析部812から入力される情報に基づいて、現在使用しているコーデックモード又はコーデックモードセットの変更を行う。なお、通信相手へのコーデックモード又はコーデックモードセット変更の要求は、呼制御のためのシグナリングメッセージを送信することで実施してもよい。また、かかる要求は、通信データのヘッダ例えばRTPヘッダ、RTPペイロードのヘッダ部、通信データの制御情報、又は、RTCPRTPControlProtocolにコーデックモード又はコーデックモードセットの変更内容を示す変更情報を追加することで実施してもよい。次に、図13を用いて、本実施の形態に係る端末UE100及びUE102における処理について詳細に説明する。以下の説明では、実施の形態1と同様、図4又は図5において、現在、UE100がHeNB400又はHeNB500に接続され、UE102がHeNB402又は502に接続されており、UE100からUE102に対して電話をかけるとする。UE100の状態解析部812は、自機の種類及び状態等から、自機にハンドオーバの可能性があるか否かを解析判断する。UE100のシグナリング生成部610は、解析結果を示す情報を、呼制御のためのシグナリングメッセージの一部、例えばSDPオファー又はSIPヘッダに記述する。また、シグナリング生成部610は、実施の形態1と同様、通信相手UE102の接続先無線アクセス網の特性を考慮したコーデックモード又はコーデックモードセットの候補を作成する。また、シグナリング生成部610は、実施の形態1と同様、通信相手UE102のハンドオーバの可能性等のUE102に関する各情報の全て又は一部の可能性を考慮したコーデックモード又はコーデックモードセットの候補を作成する。これらの情報を含むシグナリングメッセージSIPINVITEメッセージは、無線送信部602を介して通信相手UE102に送信される。SDPオファーの記述の一例を図14に示す。例えば、UE100の状態解析部812においてUE100のハンドオーバの可能性が低いと判断された場合、図14に示すように、SDPオファー内には、例えばahandoverlowと記述される。なお、ハンドオーバの可能性の有無をlow又はHighと記述する代わりに、数値又は記号等で示してもよい。例えば0x00をハンドオーバの可能性高いとし、0x01をハンドオーバの可能性低いとした場合には、ハンドオーバの可能性が低い状態は、ahandover0x01と記述される。記述方法は、これらに限らず、別の記述方法でもよい。次いで、本実施の形態における、コーデックモードセットUEのハンドオーバの可能性が低い場合のコーデックモードセットを含むと、コーデックモードセットを示す数値番号との対応関係を図15に示す。図15では、図9に示す対応関係0x00、0x01、0x02に加え、0x03が設定されている。図15に示す0x03は、電話会議通信を意味し、ビットレートが100kbps前後であり、高いHigh処理遅延であるコーデックモードセットに対応する。一方、UE102着呼側の情報比較部606は、端末状態UE100の状態解析部812での解析結果及び接続先無線アクセス網の特性に関する情報と、自機の端末状態UE102の状態解析部812での解析結果及び接続先無線アクセス網の特性に関する情報とを比較する。前者は、UE100から送信されたシグナリングメッセージSIPINVITEメッセージに含まれる情報である。具体的には、情報比較部606は、比較結果に基づいて、自機UE102と通信相手UE100との間の通信形態どのような通信が可能かを判断する。例えば、情報比較部606は、UE100、102が共にHeNBに接続され、かつ、ハンドオーバの可能性が無い場合には、固定電話のような通信高品質な通信が可能と判断する。UE102のモード決定部608は、情報比較部606での判断結果自機と通信相手との間の通信形態に基づいて、コーデックモードセットビットレート、処理遅延、チャンネル数等の組み合わせを決定する。本実施の形態における情報比較部606及びモード決定部608における処理の一例を図16に示す。図16は、情報比較部606及びモード決定部608における処理の流れを示すフロー図である。なお、図16において、図10と同一処理を行う部分には同一の符号を付してその説明を省略する。図16において、自機UE102及び通信相手UE100の互いの接続先が同一ローカル網内であるST105:YES。この場合、情報比較部606は、ST201において、自機のハンドオーバの可能性があるかを判断し、ST202において通信相手のハンドオーバの可能性があるかを判断する。自機のハンドオーバの可能性がある場合ST201:YES、又は、通信相手のハンドオーバの可能性がある場合ST202:YES、ST107では、モード決定部608は、HeNBローカル網通信0x02に対応するコーデックモードセットを選択する。一方、自機のハンドオーバの可能性が無くST201:NO、かつ、通信相手のハンドオーバの可能性が無い場合ST202:NO、ST203では、モード決定部608は、電話会議通信0x03に対応するコーデックモードセットを選択する。このように、モード決定部608は、情報比較部606で自機と通信相手との間で良好な品質の通信経路を確保できると判断されたか否か、及び、自機と通信相手との双方でハンドオーバの可能性が無いか否かに基づいて、自機と通信相手との間の通信で使用するコーデックモードセットを選択する。より具体的には、良好な品質の通信経路を確保できると判断され例えば、図16に示すST101:YESかつST103:YES、かつ、双方でハンドオーバの可能性が無い場合例えば、図16に示すST201:NOかつST202:NO、選択可能なコーデックモードセットのうち、最も高品質かつ長遅延であるコーデックモードセット0x03を選択する。UE102のシグナリング生成部610は、モード決定部608で選択されたコーデックモードセットを、呼制御のためのシグナリングメッセージ例えば、SIP183SessionProgressメッセージの一部、例えばSDPアンサーに記述する。この際、シグナリング生成部610は、UE102の接続先HeNB402又は502のCSGID又は基地局ID、及び、UE102のハンドオーバの可能性の有無を、SDPアンサー又はSIPヘッダに記述してもよい。SDPアンサーの記述の一例を図17に示す。例えば、UE100の接続先無線アクセス網のCSGIDが図14に示すPanasonicfemtoであり、UE102の接続先無線アクセス網のCSGIDがPanasonicfemtoであるとする図16のST101、ST103:YES。また、CSGIDPanasonicfemtoの無線アクセス網とCSGIDPanasonicfemtoの無線アクセス網とが同一ローカル網内であるとする図16のST105:YES。更に、UE100及びUE102の双方のハンドオーバの可能性が低いとする図16のST201、ST202:NO。この場合、UE102の情報比較部606は、UE100及びUE102が互いに同一企業内のローカル網のHeNBに接続され、かつ、UE100及びUE102が共にハンドオーバの可能性が無いと判断する。そして、モード決定部608は、電話会議通信0x03に対応するコーデックモードセットを選択する。よって、図17に示すSDPアンサーには、選択されたコーデックモードセットとして0x03が記述される。なお、図17に示すように、UE102の接続先無線アクセス網の特性に関する情報Panasonicfemto、及び、UE102のハンドオーバの可能性の有無handover:lowをSDPアンサーに記述してもよい。UE102のシグナリング生成部610で生成されたシグナリングメッセージ例えば、SIP183SessionProgressメッセージは、無線送信部602を介してIMS網126経由でUE100に送信される。UE100のモード決定部608は、無線受信部600を介して、UE102から送信されたシグナリングメッセージを受け取ると、SDPアンサーに記述されている内容に基づいて、コーデックモードセットを決定する。図17の一例では、UE100のモード決定部608は、電話会議通信0x03に対応するコーデックモードセットを決定する。この際、UE100の通信相手UE102の接続先のCSGID又は基地局ID、又は、ハンドオーバの可能性の有無を、参照情報として用いてもよい。また、通信途中でUE100又はUE102の状態が変化した場合、モード変更部814は、コーデックモードセットの変更を行ってもよい。例えば、現在のコーデックモードセットが電話会議通信0x03に対応するものであるとする。この場合、モード変更部814は、RTPペイロードのヘッダ部又は、RTCPフィードバックのコーデックモードリクエストフィールドに、変更後のコーデックモードセット例えばHeNB配下ローカル網通信0x02を記載する例えば、図18参照。そして、モード変更部814は、通信相手に変更を促すと同時に、自機のコーデックモード又はコーデックモードセットも変更する。また、変更先コーデックモードセットではなく、変更先ビットレート、遅延モード、チャンネル数等の個別のコーデックモードがコーデックモードリクエストフィールドに直接指定されてもよい。また、この変更先ビットレート、遅延モード、チャンネル数等は複数のコーデックモード又はコーデックモードセットを跨いでもよい。これにより、UEでは、無線アクセス網の特性のみでなく、ハンドオーバの可能性の有無を用いることで、実施の形態1と比較して、自機と通信相手である相手端末との間の通信形態をより細かく判断することが可能となる。よって、UEでは、判断された上記通信形態に応じて、より高品質なコーデックモード又はコーデックモードセットを選択することができる。更に、UEは、通信中の自機又は相手端末において、ハンドオーバの可能性が変化した場合、現在使用しているコーデックモード又はコーデックモードセットを変更する。すなわち、UEは、通信途中であっても、自機又は通信相手のいずれかの状態が変化した場合、つまり、自機と通信相手との間の通信形態が変化し得る場合には、当該変化に応じて、コーデックモード又はコーデックモードセットを変更する。これにより、UEでは、通信途中における通信形態の変化に応じた適切なコーデックモード又はコーデックモードセットを使用することができる。よって、本実施の形態によれば、実施の形態1と比較して、端末間の通信経路の状況をより細かく判断することができ、より適切なコーデックモード又はコーデックモードセットを選択できる。実施の形態4本実施の形態では、上記実施の形態1~3の例で挙げたコーデック方式のように、ビットレート等のコーデックモードの種類が多いコーデック方式の場合に推奨される、RTPペイロードフォーマットの一例を以下に示す。なお、本実施の形態におけるRTPペイロードフォーマット例は、上記実施の形態1~3に記載したネゴシエーション方法あるいはコーデックモード又はコーデックモードセットの選択が行われた場合に限定されるものではない。ここでは、コーデックの1つの方式又はモード、又は、通話等の1つのリアルタイムセッションの中で互いに切り替えて使うことのできる複数の方式又はモードにおけるビットレートとして、方式X仮にマルチレートコーデックとするでは12、24kbpsがサポートされているものとする。そして、方式Y仮にスケーラブルコーデックとするでは、かかるビットレートとして、基本部8、12、24kbps、第一拡張部4、12kbps、第二拡張部8kbpsがサポートされているものとする。ここで方式X、方式Yは異なるコーデックであってもよいし、単一のコーデックの中の異なるモードであってもよい。ここで、スケーラブルコーデックの第一拡張部及び第二拡張部としては、例えばSuperWideband拡張及びFullBand拡張であってもよく、又は、Enhance対応の拡張又はステレオ拡張等であってもよい。また、方式X及び方式Yの双方とも、遅延モードとしてはそれぞれ異なる遅延A及び遅延Bの両方、又はいずれか一方を持つとする。また、チャンネル数も1チャンネルモノ及び2チャンネルステレオの2つ、又は1チャンネルモノのみをサポートしているとする。図19は、本実施の形態におけるコーデックモード本例ではビットレート及びこの組み合わせの番号対応付けFrameTypeIndex及びRTPペイロードフォーマットを示す第1の例である。図19Aに示すように、ビットレートの全ての組み合わせに対して異なるFrameTypeIndexがそれぞれ割り当てられる。図19Bは、第1の例でのRTPペイロードフォーマットの一例である。図19Bに示すように、RTPペイロードのデータ部に加え、RTPペイロードのヘッダ部に、RTPペイロードの情報として、FrameTypeIndex及びQビットが付加される。ここで、RTPペイロードのデータ部は、1frame分のエンコードされたデータ及びRTPペイロード長を調整するために加えられるパディングビットpaddingbitを含む。RTPペイロードのヘッダ部に含まれるFrameTypeIndexは、図19Aのどの組み合わせが使われているかを示す。RTPペイロードのヘッダ部に含まれるQビットは、非特許文献1に記載のQビットと同等であり、FrameQualityのIndicatorである。遅延モードに関しては、RTPペイロードのヘッダ部に含ませても、含ませなくてもよい。遅延モードをRTPペイロードのヘッダ部に含ませる場合には、図19Aの表の中に遅延モードを含ませてFrameTypeIndexを割り当ててもよい。そして、RTPペイロードフォーマットの中に遅延モードを表すビット例えば遅延Aは0、遅延Bは1を含ませてもよい。図19Bに示すように、第1の例でのRTPペイロードフォーマットには、非特許文献1に記載されているCodecModeRequestのようなフィールドを持たない。このフィールドを持たないことによりRTPペイロードのサイズを抑えることができる。ただし、RTPペイロードのサイズに問題がない場合にはすなわち、RTPペイロードフォーマットに数ビットを付け加えても問題が無い場合には、CodecModeRequestのようなフィールドを含んでもよい。なお、CodecModeRequestのフィールドを持たない場合で、通信相手にコーデックモード又はコーデックモードセットの変更を求める際には、例えば、RTCPを用いてもよい。また、複数のフレーム1フレーム分のエンコードされたデータを同時に一つのIPパケットにして送ってもよい。この際、同時に送られている複数フレームのうち、どのフレームが最後のフレームかを識別するためのビットが、RTPペイロードのヘッダ部に含まれてもよい。またヘッダに含まれるビット及びフィールドは、本例に挙げられているものに限らない。また、本例では、図19Aに示すように方式X及び方式Yの各ビットレート、又はビットレートの組み合わせに対し一連のFrameTypeIndexを与え、方式X及び方式Yがあたかも同一のコーデック方式であるかのように扱うことのできる例を挙げた。しかし、方式X及び方式Yに対して、それぞれ別にFrameTypeIndex及びRTPペイロードフォーマットが与えられ、独立して利用されるものであってもよい。図20は、本実施の形態におけるコーデックモード本例ではビットレートの番号対応付けFrameTypeIndex及びRTPペイロードフォーマットを示す第2の例である。図20Aに示すように、ビットレートのみに対してFrameTypeIndexがそれぞれ割り当てられる。なお、図20Aに示すFrameTypeIndexはビットレートのみを指定し、どのコーデック又はコーデックの組み合わせが使われているかは記述しない。かかる組み合わせには、図19A第1の例の組み合わせのうち、それぞれのビットレートに当てはまるコーデックモードが全て該当する。例えば、図20Aにおいて、FrameTypeIndexの値が1ビットレート:12kbpsであったとする。この場合、フレームの内容は、図19Aの中のビットレートが12kbpsとなるコーデックに対応するFrameTypeIndex0方式Xの12kbps、3方式Yの12kbps又は5方式Yで基本部8kbps、及び第一拡張部4kbpsの組みあわせの可能性がある。ただし、図20Aが方式Yのコーデックのみに対応している場合には、FrameTypeIndex3方式Yの12kbps、又は、FrameTypeIndex5方式Yで基本部8kbps、及び第一拡張部4kbpsの2通りの可能性となる。これらのコーデック方式及びビットレートの組み合わせのうち、どの組み合わせを選ぶかはエンコーダが決定する。エンコーダが決定した組み合わせを表す情報は、エンコードされたデータの中に含まれていてもよい。図20Bは、第2の例でのRTPペイロードフォーマットの一例である。図20Bに示すように、RTPペイロードのデータ部に加え、RTPペイロードのヘッダ部に、RTPペイロードの情報として、FrameTypeIndex、Qビット、CodecModeRequest及びRビットが含まれる。RTPペイロードのデータ部は、1frame分のエンコードされたデータ及びRTPペイロード長を調整するために加えられるパディングビットpaddingbitを含む。RTPペイロードのヘッダ部のFrameTypeIndexは、図19Aのどのビットレートが使われているのかを示す。Qビットは非特許文献1に記載のQビットと同等である。CodecModeRequestは通信相手にコーデックモードビットレートの変更をリクエストするフィールドであり、図20BのFrameTypeIndexが使われる。CodecModeRequestを受け取った通信相手のエンコーダは指定されたビットレートを与えるコーデックの組み合わせのうち最適なものを選択しエンコードする。例えば、CodecModeRequestに示されるFrameTypeIndexの値が112kbpsであった場合、フレームの内容は、図19Aの中のFrameTypeIndex0、3又は5の組み合わせの可能性がある。ただし、図20Aが方式Yのコーデックのみに対応している場合には、FrameTypeIndex3方式Yの12kbps、又は、5方式Yで基本部8kbps、及び第一拡張部4kbpsの2通りの可能性となる。エンコーダはこれらのうち最適と判断した組み合わせを用いてエンコードを実行する。図20Bに示すRビットはCodecModeRequestで相手にリクエストしきれない要求を示すフィールドである。例えば、Rビットはチャンネル数の指定例えば、モノ=0、ステレオ=1又は遅延の指定例えば、遅延A=0、遅延B=1等を示す。Rビットは例えばチャンネル数と遅延両方を示すため、2ビットまたはそれ以上であってもよい。なお、このRビットは、通信中に遅延あるいはチャンネル数を切り替えない場合にはRTPペイロードのヘッダ部に存在しなくてもよい。また、遅延モードに関しては、図20Aの表の中に遅延モードも含ませてFrameTypeIndexを割り当ててもよい。例えば、FrameTypeIndex0から8までに割り当てられているビットレートに関しては遅延Aを割り当てる。更に、図20Aに示すFrameTypeIndexの値を31までに拡張して、FrameTypeIndex11から19までに割り当てられているビットレートに関しては遅延Bを割り当てる図示せず。また、図20Aの表の中に遅延モードを含ませない場合には、エンコード側自分側に対してRTPペイロードのヘッダ部の中に遅延モードを示すビットを含ませてもよい。また、エンコード側自分側のチャンネル数に関しても、遅延モードと同様に、図20Aの表の中にFrameTypeIndexの値を拡張して含ませてもよい。また、RTPペイロードのヘッダ部の中にチャンネル数の指定を示すビットを含ませてもよいし、エンコードされたデータそのものに含ませてもよい。第2の例のように、コーデックのビットレートだけを指定することにより、エンコード側で最適なエンコードを行うことができ、かつ、RTPペイロードのヘッダ部の中のFrameTypeIndex及びCodecModeRequestのビット数を少なくすることができる。また、RTPペイロードのヘッダ部にCodecModeRequestを含めることにより、通信相手に、コーデックモード又はコーデックモードセットの変更要求を迅速に送信することができる。ただし、通信相手に対する迅速なコーデックモード又はコーデックモードセット変更の要求が必要ない場合で、CodecModeRequest及びRビットが必要な場合には、これらをRTPペイロードのヘッダ部に含めず、RTCPに含めて相手に通知してもよい。また、複数のフレーム1フレーム分のエンコードされたデータを同時に一つのIPパケットにして送ってもよい。この際、同時に送られている複数フレームのうち、どのフレームが最後のフレームかを識別するためのビットがRTPペイロードのヘッダ部に含まれてもよい。また、RTPペイロードのヘッダ部に含まれるビット及びフィールドは、本例に挙げられているものに限らない。図21は、本実施の形態におけるコーデックモード本例ではビットレートとその種類の番号対応付けFrameTypeIndex及びRTPペイロードフォーマットを示す第3の例である。図21Aに示すように、マルチレートコーデック、スケーラブルコーデックの基本部、及び、スケーラブルコーデックの各拡張部のそれぞれに異なるFrameTypeIndexが割り当てられる。図21Bは、第3の例でのRTPペイロードフォーマットの一例である。第3の例では、図21に示すように、スケーラブルコーデックにおけるレイヤ基本部、第一拡張部、第二拡張部毎にRTPペイロードのヘッダ部がつけられる。図21Bにおいて、RTPペイロードのヘッダ部に含まれるCビットは後続する拡張部が存在するか否かを示す。このように、基本部と各拡張部は別々のIPパケットとして送られてもよい。これにより、ネットワーク又は無線アクセス区間等が混雑している場合、プライオリティの低い拡張部のIPパケットを破棄できるという利点がある。なお、各RTPペイロードのヘッダ部、又は基本部のRTPペイロードのヘッダ部のみに、CodecModeRequest及びQビットを付加してもよい。遅延モードの記述及び通信相手に対するコーデックモード又はコーデックモードセットの変更要求の方法に関しては、第1の例図19及び第2の例図20の場合と同様である。また、複数のフレームを同時に一つのIPパケットにして送ってもよい。この際、同時に送られている複数フレームのうち、どのフレームが最後のフレームかを識別するためのビットが、RTPペイロードのヘッダ部に含まれてもよい。また、RTPペイロードのヘッダ部に含まれるビット及びフィールドは、本例に挙げられているものに限らない。また、本例では、図21Aに示すように方式X例えばマルチレートコーデック及び方式Y例えばスケーラブルコーデックの各ビットレート、又はビットレートの種類に対して、一連のFrameTypeIndexを与える例を挙げた。すなわち、方式X及び方式Yがあたかも同一のコーデック方式であるかのように扱うことのできる例を挙げた。しかし、方式X及び方式Yに対して、それぞれ別にFrameTypeIndex及びペイロードフォーマットが与えられ、独立して利用されるものであってもよい。尚、本実施の形態において、Qビットが含まれる例を示したが、Qビットは無くてもよい。実施の形態5本実施の形態では、RTPペイロード長が複数の固定長に限定される場合で、かつ、一つのビットレート若しくはその周辺のビットレートを表す組み合わせが複数存在し得る場合における、好ましいRTPペイロードフォーマット及びその処理方法に関する。これは、例えば実施の形態4で説明した方式Yの場合である。RTPペイロード長が複数の固定長に限定される例としては、携帯電話網の無線区間のように、伝送ブロックサイズが決められている場合がある。図22は、本実施の形態におけるコーデックモードの番号対応付けFrameTypeIndex及びRTPペイロードフォーマットを示す第1の例である。第1の例では、グロスビットレートGrossBitrateに対して番号対応付けFrameTypeIndexとの対応付けが行われる。ここでは、グロスビットレートは、RTPペイロード長を1秒あたりのキロビット数kbps:kilobitpersecondに変換したものとする。グロスビットレートに対する番号対応付けの例を図22Aに示す。また、第1の例では、RTPペイロードのヘッダ部に含む情報又は情報の一部例えばCodecModeRequestフィールドを、通話開始時のネゴシエーションSDPオファー及びアンサーによって選択してもよい。この時、実施の形態1及び3でコーデックモード又はコーデックモードセット使用されるビットレートの範囲、遅延モード等が選択される際に、この選択されたコーデックモード又はコーデックモードセットに合わせて、RTPペイロードのヘッダ部に含まれる情報又は情報の一部が選択されてもよい。例えば、図9及び図15に記載の通常通信等、利用されるビットレートの範囲が低い場合には、RTPペイロードのヘッダ部の比率を小さく抑えるために、CodecModeRequestフィールドをRTPペイロードのヘッダ部に含めないという選択が行われる。図22Bは、通話開始時のネゴシエーション、又は、サービスオペレータ等のポリシー等によって予めCodecModeRequestフィールドをRTPペイロードのヘッダ部に含めないと決定された際の、RTPペイロードフォーマットの一例を示す。また図22Cは、通話開始時のネゴシエーション、又は、サービスオペレータ等のポリシー等によって予めCodecModeRequestフィールドをRTPペイロードのヘッダ部に含めると決定された際の、RTPペイロードフォーマットの一例を示す。図22B及び図22Cにおいて、RTPペイロードのヘッダ部に含まれるQビットは、非特許文献1に記載のQビットと同等であり、FrameQualityのIndicatorである。エンコーダ側は、FrameTypeIndexと、RTPペイロードのヘッダ部の長さより決定されるRTPペイロードのデータ部の長さに応じたビットレートと、その組み合わせを、対応するコーデック方式がサポートするビットレート及びその組み合わせの中から決定する。ここで、RTPペイロードのヘッダ部の長さは、通話開始時のネゴシエーション又はサービスオペレータ等のポリシー等によって予め決められたものである。エンコーダが決定した組み合わせを表す情報は、エンコードされたデータの中に含まれていてもよい。なお、サービスオペレータ等のポリシー等により、通信開始から終了までコーデックビットレートの変更が行われない場合には、RTPペイロードのヘッダ部にFrameTypeIndexを含まなくてもよい。この場合の一定のビットレートは、通話開始時のネゴシエーションによって決められてもよいし、サービスオペレータ等のポリシー等によって予め決められていてもよい。図23は、RTPペイロードのヘッダ部に含まれる情報が通予め定められていた場合における、コーデックモードの番号対応付けFrameTypeIndex及びRTPペイロードフォーマットの例を示す本実施の形態の第2の例とする。これは、つまり、本実施の形態の第1の例図22のようにRTPペイロードのヘッダ部に含まれる情報が通信開始時のネゴシエーションによって決定されるのではなく、RTPペイロードのヘッダ部の長さが予め決められていた場合である。本例では、図23Aに示すように、RTPペイロードのデータ部の長さを1秒あたりのキロビット数kbps:kilobitpersecondに変換して得られるビットレートに対し、番号対応付けFrameTypeIndexとの対応付けが行われる。本例では、20ミリ秒につき1frame分のエンコードされたデータがRTPパケットとなる。すなわち、1秒間に50個のRTPパケットが発生する。また、RTPペイロードのヘッダ部の長さは、図22Aに示すグロスビットレートが72kbps、8kbps、96kbpsの場合は5ビットとし、グロスビットレートが132kbps、164kbps、244kbpsの場合は8ビットとしている。なお、1秒あたりのRTPパケットの数、ペイロードのヘッダ部の長さ、及び、グロスビットレートとヘッダ部の長さとの対応付けはこれらに限らない。図23B及び図23Cは、CodecModeRequestフィールドを含む場合、及び、含まない場合のRTPペイロードフォーマットの例をそれぞれ示す。本例では、RTPペイロードのヘッダ部に含まれ得る情報である、FrameTypeIndexフィールドを4ビットとし、Qビットフィールドを1ビットとし、CodecModeRequestフィールドを3ビットとした場合の例を示す。FrameTypeIndexフィールドには、図23Aの中で該当するFrameTypeIndexが入る。Qビットフィールドは非特許文献1に記載のQビットと同等である。また、CodecModeRequestフィールドには図23AのFrameTypeIndexのうち0~5すなわち、通信相手へのビットレート変更を要求するのに必要な情報のみが入る。また、CodecModeRequestフィールドには、通信相手のエンコーダに対するビットレート変更が無いことを示す値として6あるいは7を使用してもよい。なお、本例のRTPペイロードのヘッダ部の各フィールド長あるいは該当する値は、これに限らなくてもよいし、本例のRTPペイロードのヘッダ部に含まれる情報フィールドもこれに限らない。本実施の形態の第1の例図22、第2の例図23では、グロスビットレートあるいはグロスビットレートに応じたRTPペイロードのデータ部の長さだけをFrameTypeIndexとして指定する、このようにすることにより、エンコード側でRTPペイロードのデータ部の長さに応じた最適なエンコードを行うことができ、かつ、RTPペイロードのヘッダ部の中のFrameTypeIndexのビット数を少なくすることができる。また、RTPペイロードのヘッダ部の長さを調整可能にする。このようにすることにより、伝送路の特性等によって決められるビットレートの範囲実施の形態1~3のコーデックモード又はコーデックモードセット等に応じてRTPペイロードのデータ部の長さを決定し、好適なエンコードを行うことができる。なお、CodecModeRequestフィールドをRTPペイロードのヘッダ部に含めない場合で、通信相手側エンコーダへのビットレートの変更通知が必要な場合には、RTCPにより変更通知が行われる。実施の形態6本実施の形態では、各UEに対して通信/通話サービスを提供するオペレータのポリシーをコーデックモード又はコーデックモードセット選択に使用する方法について説明する。オペレータのポリシーとしては、例えば、優先して使用されるコーデックコーデックの方式、優先して使用されるコーデックビットレート、優先して使用されるサンプリングレート、優先して使用されるオーディオ帯域例えば、NB,WB,SWB,FB、優先して使用される処理遅延、及び、優先して使用されるチャンネル数等が挙げられる。また、オペレータのポリシーとしては、他にも、例えば、セッション途中でのビットレート又はチャンネル数の切り替えを許可するか否か、SourceControlledVariableBitRateVBRオペレーション例えば、3GPP2CS0052AVersion10SourceControlledVariableRateMultimodeWidebandSpeechCodecを参照を許可するか否か、回線交換網へのハンドオーバ例えば、3GPPTS23216v960SingleRadioVoiceCallContinuityStage2を参照を許可するか否か、及び、非特許文献2に記載のような冗長フレームを許可するか否か等が挙げられる。UEは、これらオペレータのポリシーの全て又は一部を、通話開始前、すなわち、図2に示すST11の処理が行われる前までに取得し、取得したポシリーに基づいてSDPオファーを生成する。ポリシー全て、又は一部の取得方法として、例えば、オペレータのネットワークからUEに送られてくるシグナリングにポリシー全て、又は一部が含まれるようにし、かかるシグナリングから取得する手法を採用してもよい。このシグナリングは、例えば、SIBSystemInformationBlock。例えば、3GPPTS36331v1000EvolvedUniversalTerrestrialRadioAccessRadioResourceControlProtocolspecificationを参照であってもよい。また、このシグナリングは、例えば、RRCRadioResourceControlコネクション確立の際のシグナリング例えば、3GPPTS36331v1000EvolvedUniversalTerrestrialRadioAccessRadioResourceControlProtocolspecificationに記載のRRCConnectionSetupであってもよい。また、ポリシーは、例えば、Registerに対する応答メッセージ200OK等のIMSのSIPシグナリング例えば3GPPTS23228v1031IPMultimediaSubsystemStage2を参照と一緒に送られてきてもよい。また、ポリシー、例えば、P-CSCF検索の応答メッセージに含まれていてもよい。ポリシーが応答メッセージを使ってUEに送られてくる場合、UEからの要求メッセージ例えば3GPPTS36331v1000EvolvedUniversalTerrestrialRadioAccessRadioResourceControlProtocolspecificationに記載のRRCConnectionRequest、又は、3GPPTS23228v1031IPMultimediaSubsystemStage2に記載のRegisterに、オペレータのポリシーを応答メッセージで受け取る能力のあることを示すパラメータを付加してもよい。また、ポリシーの他の取得方法として、UEは、UEがローカルに保持するポリシーに関する情報の中から、オペレータのネットワークからUEに送られてくる情報に基づいて、オペレータのポリシー全て、又は一部を決定してもよい。例えば、UEは、オペレータ毎のポリシー全て、又は一部をローカルに保持しており、或るオペレータのネットワークに接続した際に当該オペレータに関する情報オペレータ情報を取得し、ローカルに保持しているデータベースの中から該当するオペレータのポリシー全て、又は一部を選択する。UEがオペレータのネットワークに接続した際に取得するオペレータ情報は、例えば、CellID例えば、3GPPTS23003v1000Numberingaddressingandidentificationを参照から取得される。また、ポリシーの他の取得方法として、UEがオペレータのネットワークに接続した際に送られてくる、ユーザ毎に通話用に許されるQoS情報例えば、3GPPTS23401v1021EvolvedUniversalTerrestrialRadioAccessNetworkaccessを参照に基づいて、UEが、通話に優先して使われるコーデックビットレート等を選択してもよい。次に、オペレータから取得されたポリシーに基づくSDPの生成方法の例を示す。図24は発呼側UEが接続するオペレータオペレータAのポリシー図24A、及び、発呼側UEにおけるSDPオファー生成例図24Bを示す。また、図25は着呼側UEが接続するオペレータオペレータBのポリシー図25A、及び、着呼側UEにおけるSDPアンサー生成例図25Bを示す。なお、図24及び図25において、ポリシー又はSDPに記述されない項目、値等に関しては、例えば非特許文献2に記載された各方式のデフォルトが適応される。また、図24及び図25に示すポリシー及びSDPの記述方法は一例であり、他の記述方法であってもよい。例えば、図24Aに示すように、オペレータAのポリシーには、コーデック:方式1、オーディオ帯域:SWB、ビットレート:[12kbps,24kbps]及びVBR:可VBRを許可というポリシー以下、ポリシーA1と呼ぶが含まれる。また、オペレータAのポリシーには、コーデック:方式1、オーディオ帯域:WB、ビットレート:[12kbps,24kbps]及びVBR:可VBRを許可というポリシー以下、ポリシーA2と呼ぶが含まれる。更に、オペレータAのポリシーには、コーデック:方式2、オーディオ帯域:NB、ビットレート:[8kbps,12kbps]及びVBR:不可VBRを許可しないというポリシー以下、ポリシーA3と呼ぶが含まれる。そこで、発呼側UEは、発呼側UEに対して通信又は通話サービスを提供するオペレータのポリシーここでは、図24Aに示すオペレータAのポリシーの少なくとも一部に対応するコーデックモード又はコーデックモードセットの候補を含むSDPオファーを作成する。例えば、図24Bに示すように、発呼側UEは、図24Aに示すポリシーA1の一部である、コーデック:方式1、オーディオ帯域:SWB、ビットレート:{1224}kbpsに対応するコーデックモードセットの候補を選択する。具体的には、図24Bに示す、コーデック:方式1、オーディオ帯域:SWB、ビットレート:[12kbps,24kbps]であって、VBR:有可、又はVBR:無不可となる2つのコーデックモードセットの候補artpmap97及び98が作成される。同様に、図24Bに示すように、発呼側UEは、図24Aに示すポリシーA2の一部である、コーデック:方式1、オーディオ帯域:WB、ビットレート:{1224}kbpsに対応するコーデックモードセットの候補を選択する。具体的には、図24Bに示す、コーデック:方式1、オーディオ帯域:WB、ビットレート:[12kbps,24kbps]であって、VBR:有可、又はVBR:無不可となる2つのコーデックモードセットの候補artpmap99及び100が作成される。同様に、図24Bに示すように、発呼側UEは、図24Aに示すポリシーA3の全てである、コーデック:方式2、オーディオ帯域:NB、ビットレート:[8kbps,12kbps]及びVBR:無不可に対応するコーデックモードセットの候補artpmap101を作成する。図24Bに示すように、発呼側UEから着呼側UEへ通知されるSDPオファーに含まれる複数のコーデックモード又はコーデックモードセットの候補には、発呼側UEに対して通信又は通話サービスを提供するオペレータのポリシーの少なくとも一部に対応するコーデックモード又はコーデックモードセットの候補が含まれる。一方、図25Aに示すように、オペレータBのポリシーには、コーデック:方式1、オーディオ帯域:WB、ビットレート:12kbps及びVBR:不可VBRを許可しないというポリシー以下、ポリシーB1と呼ぶが含まれる。また、オペレータBのポリシーには、コーデック:方式2、オーディオ帯域:NB、ビットレート:12kbps、及びVBR:不可VBRを許可しないというポリシー以下、ポリシーB2と呼ぶが含まれる。そこで、着呼側UEは、発呼側UEから通知された図24Bに示すSDPオファーに含まれるコーデックモードセットの候補のうち、図25Aに示すオペレータBのポリシーの少なくとも一部に対応するコーデックモードセットの候補の中から、発呼側UEとの通信で使用するコーデックモードセットを選択する。具体的には、図25Bでは、着呼側UEは、図25Aに示すポリシーB1の全てに対応するコーデックモードセットの候補コーデック:方式1、オーディオ帯域:WB、ビットレート:12kbps、及び、VBR:無不可を、発呼側UEとの通信で使用するコーデックモードセットとして選択する。なお、本実施の形態におけるコーデックモード又はコーデックモードセット選択方法は、実施の形態1~3に示すコーデックモード又はコーデックモードセット選択方法と連動して用いられてもよい。こうすることで、本実施の形態によれば、発呼側UEはSDPオファーに記述するコーデックモード又はコーデックモードセット等を当該UEが接続しているオペレータのポリシーに応じて限定することができる。更に、着呼側UEは、発呼側UEとの通信で使用するコーデックモード又はコーデックモードセットとして選択するコーデックモード又はコーデックモードセット等を当該UEが接続しているオペレータのポリシーに応じて限定することができる。これにより、発呼側UEと着呼側UEとの間における複雑なSDP折衝を回避することができる。また、オペレータはポリシーに基づいたサービスコーデックをUEに選択させることができる。実施の形態7本実施の形態では、実施の形態1~3で用いたネットワーク構成とは異なるネットワーク構成例を用いた場合におけるコーデックモード又はコーデックモードセット選択方法について説明する。図26は本実施の形態に係るネットワーク構成と、UE端末の位置関係の一例を示す図である。なお、図26において、UE100、UE102、IPコア網124及びIMS網126は図1と同じであるので同一の符号を付してその説明を省略する。図26に示すAP2600及びAP2602はアクセスポイントAccessPointであり、無線アクセス網2606及び無線アクセス網2608をそれぞれ構成する。例えば、AP2600及び2602は、Wi-Fi又はWiMAX等のアクセスポイントであってもよく、図1に示すHeNBであってもよい。IP-PBX2604は、AP2600及びAP2602と接続しており、例えば企業等の組織内LANにおいて、IP電話による企業内電話網を実現する装置呼制御のための処理機能を有するネットワークノードである。例えば、IP-PBX2604は、オペレータのIMS網との接続機能、又は、オペレータのIMS網の機能の一部を有する例えば、3GPPTS22809v100FeasibilityStudyonSupportfor3GPPVoiceInterworkingwithEnterpriseIPPBXを参照。また、IP-PBX2604は、インターネットプロバイダのブロードバンド網等の外部IP網2610を通じてオペレータのIMS網126内に存在するサ-バ2612と接続している。また、IP-PBX2604は、外部IP網2610とのゲートウェイ機能又はIMSシグナリングを終端する機能図示せず等を合わせて有してもよい。サーバ2612は、例えば、図1に示すS-CSCF100等のCSCF、ASApplicationServer。例えば、3GPPTS23228v1031IPMultimediaSubsystemStage2に記載、または、その両方であってもよく、これらCSCFあるいはASと、IPPBX2604とを繋ぐ装置であってもよい。AP2614は、IPコア網124に接続しているアクセスポイントである。AP2614は、基地局eNBまたはHeNBであってもよい。また、AP2614は、Wi-Fi又はWiMAX等のアクセスポイントであってもよい例えば、3GPPTS23402v1021Architectureenhancementsfornon3GPPaccessesを参照。図26では、UE100は、無線アクセス網2606内でAP2600に接続している。このとき、例えば、UE100の接続先判断部604図7は、自機の接続先無線アクセス網2606が企業等の組織内LANを構成する無線アクセス網であると判断したとする。なお、AP2600がHeNBである場合、接続先判断部604は、実施の形態1と同様、CSGID等を用いて接続先を判断してもよい。また、AP2600がWi-Fi等の無線LANのアクセスポイントである場合、接続先判断部604は、SSIDServiceSetIdentifier等を用いて接続先を判断してもよい。本実施の形態では、UE100発呼側がUE102着呼側に対し発呼する場合、実施の形態1~3と同様にして、UE100が接続先判断部604図7、図13の判断に従ってSDPオファーの中に記述するコーデックモード又はコーデックモードセットを選択してもよい。また、UE100でコーデックモード又はコーデックモードセットを選択せずにIP-PBX2604でコーデックモード又はコーデックモードセットを選択してもよい。図27は、本実施の形態に係るIP-PBX2604の構成を示すブロック図である。図27に示すIP-PBX2604において、受信部2700は、発呼側UEここではUE100からのシグナリングメッセージを受け取ると、シグナリングメッセージをシグナリングインタセプト部2704に出力する。送信部2702は、シグナリング生成部2710から入力されるシグナリングメッセージを、シグナリングメッセージの送信先UE着呼側UE。ここではUE102に送信する。シグナリングインタセプト部2704は、受信部2700から入力されるシグナリングメッセージが自機宛IP-PBX2604のIPアドレス宛てでない場合でも、当該シグナリングメッセージを一旦インタセプトinterceptする。シグナリングインタセプト部2704は、インタセプトしたシグナリングメッセージをシグナリング解析部2706に出力する。シグナリング解析部2706は、入力されたシグナリングメッセージに記述されている情報を解析し、確認が必要な情報を、適切な確認部に出力する。例えば、シグナリング解析部2706は、着呼側UEUE102が現在接続されている無線アクセス網がIP-PBX2604の配下であるか否かを特定するために、シグナリングメッセージに記述された情報のうち、発呼先情報を、端末位置情報確認部2708に渡す。端末位置情報確認部2708は、着呼側UEUE102が現在接続されている無線アクセス網がIP-PBX2604の配下であるか否か例えば、同一企業内電話網に接続されているか否かを確認する。この確認は、シグナリング解析部2706から受け取った発呼先情報に基づいて行われる。このとき、端末位置情報確認部2708は、IP-PBX2604内のUE102の登録情報等を用いて確認を行ってもよいし、サーバ2612を通じてIMS網126に存在するUE102の登録情報等の全て又は一部を用いて確認を行ってもよい。または、端末位置情報確認部2708は、これら双方の情報を用いて確認を行ってもよい。端末位置情報確認部2708は、確認結果をシグナリング生成部2710に出力する。シグナリング生成部2710は、発呼側UEUE100から送信されたシグナリングメッセージの中で修正が必要な記載内容の上書き又は新規作成を行う。例えば、端末位置情報確認部2708において、着呼側UEUE102が同一企業内電話網ここではIP-PBX2604配下に存在すると判断されたとする。この場合、シグナリング生成部2710は、シグナリングメッセージ内のSDPオファーの記述内容について、同一企業内電話網内の通話に用いられるコーデックモード又はコーデックモードセット等を含むように新規記述又は上書きする。この際、シグナリング生成部2710は、IP-PBX2604によるSDPオファーの確認済を示す情報を、フラグ、数値及びテキスト等の記載方法でシグナリングメッセージに追加してもよい。また、端末位置情報確認部2708において、着呼側UEUE102が例えば同一企業内電話網ここではIP-PBX2604配下の外部に存在すると判断されたとする。この場合にも、シグナリング生成部2710は、シグナリングメッセージ内のSDPオファーの記述内容について、通常の通話に用いられるコーデックモード又はコーデックモードセット等を含むように新規記述又は上書きしてもよい。この際、シグナリング生成部2710は、IP-PBX2604によるSDPオファーの確認済を示す情報を、フラグ、数値及びテキスト等の記載方法でシグナリングメッセージに追加してもよい。新規作成又は修正されたシグナリングメッセージは、送信部2702を介して、シグナリングメッセージの送信先UE102に送信される。シグナリングメッセージを受け取った着呼側UEUE102は、自機の接続先無線アクセス網が企業等の組織内LANを構成する無線アクセス網であると判断し、かつ受け取ったシグナリングメッセージ内のSDPオファーがIP-PBXによる確認済であることを特定したとする。この場合、着呼側UEUE102は、SDPオファーIP-PBX2604で上書き又は新規作成されたSDPオファーを参照して、同一企業内電話網内の通話に用いられるコーデックモード又はコーデックモードセット等を選択する。この際、実施の形態3と同様にして、着呼側UEUE102は、ハンドオーバの可能性の有無なども用いてコーデックモード又はコーデックモードセットを選択してもよい。一方、着呼側UEUE102は、自機の接続先無線アクセス網が企業等の組織内LANを構成する無線アクセス網であると判断したが、受け取ったシグナリングメッセージ内のSDPオファーがIP-PBXによる確認済であることを特定できなかったとする。この場合、着呼側UEUE102は、SDPオファーに記述されたコーデックモード又はコーデックモードセットの候補の中から、通常の通信又は通常の通話に用いられるコーデックモード又はコーデックモードセット等を選択してもよい。また、着呼側UEUE102の接続先が企業等の組織内LANを構成する無線アクセス網の外部であった場合、着呼側UEUE102では、実施の形態1~3と同様のコーデックモード又はコーデックモードセット選択方法が適用される。そして、着呼側UEUE102は、選択したコーデックモード又はコーデックモードセットを含むSDPアンサーを生成し、発呼側UEUE100へ送信する。このようにして、本実施の形態では、IP-PBX2604は、着呼側UEが現在接続している無線アクセス網がIP-PBX2604配下である場合、発呼側UEから通知されたSDPオファーに示される複数のコーデックモード又はコーデックモードセット候補を変更新規作成又は上書きして、新たなSDPオファーを生成する。そして、着呼側UEは、IP-PBX2604で変更された変更後のSDPオファーに含まれる複数のコーデックモード又はコーデックモードセット候補の中から、発呼側UEとの通信で使用するコーデックモード又はコーデックモードセットを選択する。これにより、着呼側UEが現在接続している無線アクセス網がIP-PBX2604配下である場合には、SDPオファー内に記述されるコーデックモード又はコーデックモードセットの候補等を、IP-PBX2604配下に存在するUEに対して適切なコーデックモード又はコーデックモードセット例えば、同一企業内電話網内の通話に用いられるコーデックモード又はコーデックモードセット等に限定することができる。これにより、発呼側UEと着呼側UEとの間における複雑なSDP折衝を回避することができる。更に、IP-PBX2604は、SDPオファーを確認したか否か確認済みであるか否かを示す情報を着呼側UEへ送信する。そして、着呼側UEは、IP-PBX2604によりSDPオファーの確認済みであることを特定した場合には、IP-PBX2604で変更された変更後のSDPオファーに含まれる複数のコーデックモード又はコーデックモードセット候補の中から、発呼側UEとの通信で使用するコーデックモード又はコーデックモードセットを選択する。これにより、UEがIP-PBX2604の配下同一企業内電話網に存在するか否かが正確に判断される。そして、例えば、UEがIP-PBX2604の配下同一企業内電話網に存在する場合、UEは、同一企業内電話網内の通話に用いられるコーデックモード又はコーデックモードセット等に限定してコーデックモード又はコーデックモードセットを選択することができる。また、例えば、UEがIP-PBX2604の配下同一企業内電話網に存在しない場合、UEは、通常の通信通常の通話に用いられるコーデックモード又はコーデックモードセット等に限定してコーデックモード又はコーデックモードセットを選択することもできる。こうすることで、本実施の形態では、同一企業内電話網に存在するUEが正確に判断され、UEは好適なコーデックモード又はコーデックモードセット等を選択することができる。なお、本実施の形態では、発呼側UEからのSDPオファーに関してIP-PBX2604で新規記述又は上書きを行う場合について説明した。しかし、本実施の形態において、UE102が同一企業内電話網ここではIP-PBX2604配下に存在していた場合、着呼側UEからのSDPアンサーに関しても、前述のようにIP-PBX2604で新規記述又は上書きしてもよい。また、UE100、UE102、及び、IP-PBX2604でSDPオファー又はSDPアンサーが新規作成又は上書きされる場合に、実施の形態6と同様にして、オペレータのポリシーが使われてもよい。実施の形態8本実施の形態では、実施の形態4及び5に示したRTPペイロードフォーマットに関し、全てのRTPパケットのRTPペイロードヘッダ部、又はデータ部の一部に含める必要のないフィールドの与え方について説明する。例えば、実施の形態4及び5に示したコーデックモードリクエストCodecModeRequestのフィールド、又は、モノ/ステレオの切り替えチャンネル数の指定及び遅延モードの切り替え遅延の指定等を通信相手に要求するフィールド等がある。これらは、要求が発生した場合のみ、RTPペイロードヘッダ部、又はデータ部の一部に含めればよい。なお、非特許文献3または非特許文献4に記載のSID、NoData、speechlostが、図19~図23などに記載のFrameTypeIndexの一部等として、RTPペイロードヘッダ部に含まれない場合もある。この場合、これらSID、NoData、speechlostなどを送る要求が発生した場合にのみ、当該要求を、RTPペイロードヘッダ部、又はデータ部の一部に含めればよい。図23Aに示すFrameTypeIndexを利用した場合のRTPペイロードフォーマットの一例を図28に示す。図23AのFrameTypeIndexには上述のSIDは含まれていないが、ここでは、例えばFrameTypeIndexの8としてSIDが設定されていたとする。図28Aは、上記フィールドCodecModeRequestフィールド、又は、モノ/ステレオの切り替え、遅延モードの切り替え等を通信相手に要求するフィールドが存在しない場合のRTPペイロードフォーマットの一例を示す。図28Bは、上記フィールドが存在する場合のRTPペイロードフォーマットの一例を示す。ここで、図28Aに示すRTPペイロードのヘッダ部は例えば1オクテット等の固定長である。図28Aに示すヘッダ部の中には、固定長の後続ヘッダ部の有無を示すフィールド、その他のフィールド、FrameTypeIndexが含まれる。なお、ここでヘッダ部、後続ヘッダ部とは、RTPペイロードデータ部の一部と解釈してもよい。図28Aに示す後続ヘッダ部の有無を示すフィールドには、図28Aに示す固定長のヘッダ部の後に、別の固定長ヘッダ部が続くか否かを示す情報が、例えばフラグ又は数値等の形で入る。図28Aでは、後続する別のヘッダ部は存在しないので、後続ヘッダ部の有無を示すフィールドには、後続する別のヘッダ部が存在しないことを示す情報が入る。図28Aに示すその他のフィールドには、後続ヘッダ部の有無を示すフィールド及びFrameTypeIndexの両方以外の他のフィールドが含まれる。図28Aに示すFrameTypeIndexには、例えば図23Aに示すFrameTypeIndexが入る。図28Aに示すRTPペイロードのデータ部には、例えば、実施の形態5で示したように、エンコーダ側により選択された、適切なビットレート及び組み合わせ、組み合わせ情報等が入る。一方、図28Bに示す後続ヘッダ部の有無を示すフィールドには、図28Bに示す固定長のヘッダ部の後に、別の固定長ヘッダ部後続ヘッダが存在することを示す情報が入る。図28Bに示すその他のフィールド及びFrameTypeIndexは図28Aと同等である。図28Bに示す後続ヘッダは例えば1オクテット等の固定長である。図28Bに示す後続ヘッダには、後続ヘッダの種類、後続ヘッダの内容、及びその他のフィールドが含まれる。図28Bに示す後続ヘッダの種類には、当該後続ヘッダが何を示すものであるのか、を示す情報が、例えばフラグ又は数値等で示される。例えば、後続ヘッダの種類は、CodecModeRequest、モノ/ステレオ等のチャンネル数の切替要求、又は、遅延モードの切替要求を示してもよく、パケットロス隠蔽のための冗長データを示してもよい。図28Bに示す後続ヘッダの内容には、後続ヘッダの種類に示される種類に応じた内容が入る。例えば、後続ヘッダの種類がCodecModeRequestである場合には、通信相手に要求するコーデックビットレートを示す値例えば図23Aに示すFrameTypeIndex等が入る。また、後続ヘッダの種類がモノ/ステレオ等のチャンネル数の切替要求又は遅延モードの切替要求等である場合には、要求している切り替え先の情報例えば、モノへの切り替えを示す情報、又は遅延Aへの切り替えを示す情報等が入る。また、後続ヘッダの種類が冗長データである場合、冗長データのデータ長等が入る。なお、図28Bに示す後続ヘッダの種類により上記後続ヘッダの内容が一意に決定できる場合には、後続ヘッダはなくてもよい。また、図28Bに示す後続ヘッダの種類のフィールドは固定長であるが、後続ヘッダの内容のフィールド長は、後続ヘッダの種類によって異なる値をとってもよい。図28Bに示すその他のフィールドには、後続ヘッダの種類及び後続ヘッダの内容の両方以外の他のフィールドが入るが、必要無い場合は無くてもよい。図28Bに示すRTPペイロードのデータ部には、例えば実施の形態5で示したように、エンコーダ側により選択された、適切なビットレート及び組み合わせ、組み合わせ情報等が入る。また、データ部には、後続ヘッダの種類が冗長パケットであった場合には、冗長パケットも入る。この場合、エンコーダは、主データとして、データ部の長さから冗長パケットの長さを引いた長さに収まる適切なビットレート及び組み合わせを選択しビットストリームを生成する。このように、本実施の形態の第1の例では、ヘッダ部とデータ部とから成るRTPペイロードにおいて、ヘッダ部は、全てのRTPペイロードにおいて常に設けられるヘッダ部と、全てのRTPペイロードにおいて常に設けられるとは限らないヘッダ部図28Bに示す後続ヘッダ部とを含む。また、図28A及び図28Bに示すように、全てのRTPペイロードにおいて常に設けられるヘッダ部には、後続ヘッダ部が設けられるか否かを示すフィールド後続ヘッダ部の有無を示すフィールドが含まれる。なお、本実施の形態におけるRTPペイロードフォーマットは、別の構成を取り得る。図29は、本実施の形態におけるRTPペイロードフォーマットの第2の例を示す。本例では、特にRTPペイロードで運ぶ必要のある全ての情報が、RTPペイロードのデータ部の一部として運ばれる事を想定し、エンコードされたデータ以外の情報をシグナリング又はシグナリング部と呼ぶ。また本例では、コーデックのビットレートを示す情報FrameTypeIndex等は、RTPペイロードに明示的に含まない事を想定する。図29Aは、後続シグナリング部の有無を示すフィールドのみが、シグナリング部として存在する場合の、RTPペイロードフォーマットの一例を示す。図29Bは、後続シグナリング部の有無を示すフィールド及び後続シグナリング部が存在する場合の、RTPペイロードフォーマットの一例を示す。ここで、図29Aに示すRTPペイロードの、最上位ビットからの固定長例えば1ビット等には、後続シグナリング部の有無を示すフィールドが含まれる。なお、ここで最上位ビットからの固定長、後続シグナリング部とは、上述のようにRTPペイロードデータ部の一部であってもよいし、RTPペイロードのヘッダ部であってもよい。図29Aに示す後続シグナリング部の有無を示すフィールドには、このフィールドの後に、別のシグナリング部が続くか否かを示す情報が、例えばフラグ又は数値等の形で入る。例えば、このフィールドが1ビットである場合、このフィールドに0が入れば、後続するシグナリングは存在せず、1が入れば、後続するシグナリング部が存在する。図29Aでは、後続する別のシグナリング部は存在しないので、後続シグナリング部の有無を示すフィールドには、後続する別のシグナリング部が存在しないことを示す情報つまり本例では0が入る。一方、図29Bに示す後続シグナリング部の有無を示すフィールドには、図29Bに示す固定長のシグナリング部の後に、別の固定長、又は可変長のシグナリング部後続シグナリングが存在することを示す情報つまり本例では1が入る。図29Bに示す後続シグナリング部は、固定長又は可変長であり、後続シグナリングの種類及び後続シグナリングの内容フィールドを含む。図29Bに示す後続シグナリングの種類では、当該後続シグナリングが何を示すものであるのか、を示す情報が、例えばフラグ又は数値等で示される。例えば、後続シグナリングの種類は、CodecModeRequestコーデックビットレートの切替要求、チャンネル数の切替要求、帯域幅の切替要求などを示してもよく、また、パケットロス隠蔽のための冗長データの存在を示してもよい。また、後続シグナリングの種類は、SID、NoData、図19~図23などに記載のSpeechlostを示してもよい。図29Bに示す後続シグナリングの内容には、後続シグナリングの種類に示される種類に応じた内容が入る。例えば、後続シグナリングの種類がCodecModeRequestのコーデックビットレート切替要求である場合には、通信相手に要求するコーデックビットレートを示す値例えば、図23Aに示すFrameTypeIndex等が入る。また、後続シグナリングの種類がCodecModeRequestのチャンネル数切替要求である場合には、後続シグナリングの内容には、要求している切替先の情報例えば、モノへの切り替えを示す情報、ステレオへの切替を示す情報等が入る。また、後続シグナリングの種類が冗長データの存在である場合、後続シグナリングの内容には、冗長データのデータ長等が入る。なお、後続シグナリングの内容が可変長である場合は、後続シグナリングの種類に示される種類に応じて、その長さは変わる。なお、図29Bに示す後続シグナリングの種類により上記後続シグナリングの内容が一意に決定できる場合、又は、後続シグナリングの内容の決定が必要無い場合、後続シグナリングの内容はなくてもよい。これは、例えば、後続シグナリングの種類が、SID、NoData、あるいは、図19~図23などに記載のspeechlostを示す場合である。また、図29Bに示す後続シグナリングの種類のフィールドは固定長であるのに対し、後続シグナリングの内容のフィールド長は、後続シグナリングの種類によって異なる値をとってもよい。後続シグナリングの内容が後続シグナリングの種類によって異なる値をとる場合には、後続シグナリングそのものが可変長となる。また、RTPペイロードフォーマットは、図29Bにおいて、後続シグナリングの種類及び後続シグナリングの内容の後に、後続シグナリング部の有無を示すフィールドが設けられてもよい。そして、RTPペイロードフォーマットは、更に別の後続シグナリングの種類、後続シグナリングの内容、後続シグナリング部の有無を示すフィールドを続けてもよい図示せず。図29Bに示すRTPペイロードのデータ部には、例えば実施の形態5で示したように、エンコーダ側により選択された、適切なビットレート及び組み合わせ、組み合わせ情報等が入ってもよい。また、データ部には、後続シグナリングの種類が冗長パケットであった場合には、冗長パケットも入る。この場合、エンコーダは、データ部の長さから冗長パケットの長さを引いた長さに収まる適切なビットレート及び組み合わせを選択して、主データとして、ビットストリームを生成する。また、後続シグナリングの種類がSIDであった場合は、RTPペイロードのデータ部には、SIDの際に生成されるデータが含まれる。これに対し、後続シグナリングの種類がNoDataあるいは、図19~図23などに記載のspeechlostであった場合には、RTPペイロードのデータ部には、データは含まれないデータ部自体が存在しなくてもよい。本例では、コーデックのビットレートを示す情報FrameTypeIndexなどがRTPペイロードに明示的に含まない事を想定した。この場合、受信側でRTPペイロード長を算出IPヘッダまたはUDPヘッダに含まれるデータ長情報より、RTPペイロード長を算出、又はRTPペイロード長自体を計測し、そこから図29のシグナリング部の長さを取り除く事により、コーデックビットレートが計算される。また、図29の例では後続シグナリング部の有無を示すフィールドが最上位ビットからの固定長としてRTPペイロードの先頭に入る例を示したが、このフィールドは、RTPペイロードのどこに例えばRTPペイロードの最後に含まれてもよい。この場合、後続シグナリング部の有無を示すフィールドは、後続のシグナリング部の有無を示すという意味ではなく、RTPペイロードの先頭にシグナリング部があるかどうかを示すという意味となる。このように、本実施の形態の第2の例では、RTPペイロードは、データ部と、これに含まれるシグナリング部から成る。そして、かかるRTPペイロードにおいて、シグナリング部は、全てのRTPペイロードにおいて常に設けられる後続シグナリング部の有無を示すフィールドと、全てのRTPペイロードにおいて常に設けられるとは限らないシグナリング部図29Bに示す後続シグナリングとを含む。図30は、本実施の形態におけるRTPペイロードフォーマットの第3の例を示す。本例では、RTPペイロードの最上位ビットからの固定長に、ヘッダ部が存在するか否かを示すフィールドを設ける事により、RTPペイロードにヘッダ部が存在するか否かを切り替える。これにより、全てのRTPパケットのRTPペイロードに含める必要のないフィールドシグナリングが発生する場合には、このRTPペイロードのヘッダ部を利用し、このヘッダ部に情報シグナリングを含める。図30Aは、ヘッダ部の有無を示すフィールドのみが、シグナリング部として存在する場合の、RTPペイロードフォーマットの一例を示す。図30Bは、ヘッダ部が存在する場合の、RTPペイロードフォーマットの一例を示す。ここで、図30Aに示すRTPペイロードの最上位ビットからの固定長例えば1ビット等には、ヘッダ部の有無を示すフィールドが含まれる。図30Aに示すヘッダ部の有無を示すフィールドには、このRTPペイロードにヘッダ部が存在するか否か示す情報が、例えばフラグ又は数値等の形で入る。例えば、このフィールドが1ビットである場合、このフィールドに0が入ればヘッダ部は存在せず、1が入ればヘッダ部が存在する。図30Aでは、ヘッダ部は存在しないので、ヘッダ部の有無を示すフィールドには、ヘッダが存在しない事ことを示す情報つまり本例では0が入る。なお、図30Aのように、ヘッダ部の有無を示すフィールドが、ヘッダが存在しない事ことを示す場合には、このヘッダ部の有無を示すフィールドは、RTPペイロードのデータ部の一部とする。一方、図30Bに示すヘッダ部の有無を示すフィールドには、図30Bに示すヘッダ部が存在することを示す情報つまり本例では1が入る。ヘッダ部が存在する場合、図30B、図30C、図30Dに示すように、ヘッダ部は基本ヘッダと拡張ヘッダから成る。ヘッダ部が存在する場合、基本ヘッダは必ず存在するが、拡張ヘッダは、基本ヘッダの情報の内容によって、存在しない場合もある。図30Cに、基本ヘッダの一例を示す。本例では、ヘッダ部が存在する場合に、ヘッダ部の有無を示すフィールドが基本ヘッダの一部として含まれる例を示すが、このフィールドは、ヘッダ部の一部とせずに、データ部の一部としてもよい。すなわち、ヘッダ部の有無を示すフィールドは、基本ヘッダに含まれていなくてもよい。基本ヘッダは固定長であり、基本ヘッダの残りには、例えばmonomultiフィールド、FrameTypeフィールド、及び後続ヘッダ有無フィールドが含まれる。monomultiフィールドには、例えばこのRTPペイロードが運んでいるデータが、モノ1チャンネルなのか、ステレオなどのマルチチャンネルなのかを示す情報が、例えばフラグ又は数値等の形で入る。例えば、このフィールドが1ビットである場合、このフィールドに0が入ればモノを示し、1が入ればマルチチャンネルを示す。FrameTypeフィールドには、例えば前述のmonomultiフィールドがモノを表す場合、図19~図23などに記載のFrameTypeIndexのように、コーデックビットレートの情報、前述のSID、NoDataといった情報が含まれる。また上述のmonomultiフィールドがマルチチャンネルを表す場合、FrameTypeには、例えば、マルチチャンネルの情報、ビットレートなどが含まれる。マルチチャンネルの情報とは、すなわち、チャンネル数またはマルチチャンネル用エンコード方式例えば2チャンネルの場合、右と左とを別々にエンコードする方式か、2チャンネル拡張部を付ける方式か、などを示す情報である。後続ヘッダ有無フィールドには、例えば基本ヘッダの後に、拡張ヘッダが存在するか否かの情報が、例えばフラグ又は数値等の形で入る。例えば、このフィールドが1ビットである場合、このフィールドに0が入れば後続ヘッダは存在しない事を示し、1が入れば後続ヘッダが存在する事を示す。基本ヘッダは、固定長であるが、monomultiフィールドの示す内容、つまり、モノかマルチチャンネルかに応じて、その固定長の値が異なっていてもよい。図30Dに、後続ヘッダが存在する場合の、拡張ヘッダの一例を示す。拡張ヘッダは固定長であり、例えばヘッダタイプフィールド、情報フィールド、及び後続ヘッダ有無フィールドを含む。ヘッダタイプフィールドには、この拡張ヘッダのタイプを示す情報が、例えばフラグ又は数値等の形で入る。例えば、このフィールドが3ビットである場合、このフィールドに例えば000が入れば、拡張ヘッダのタイプが冗長データ情報であることを示す。ヘッダタイプフィールドに001が入れば、拡張ヘッダのタイプがCodecModeRequestであることを示す。ヘッダタイプフィールドに010が入れば、拡張ヘッダのタイプがCodecModeRequestであることを示す。ヘッダタイプフィールドに011が入れば、拡張ヘッダのタイプがCodecModeRequestであることを示す。情報フィールドには、ヘッダタイプの内容によって、異なる情報が入る。例えば上述のように、ヘッダタイプが冗長データ情報である場合、例えば情報フィールドには冗長データのビットレートを表すFrameTypeIndexが入る。これは、つまり、非特許文献2のように、一つのRTPパケットの中に複数のフレームのデータが入っている場合である。また、例えば上述のように、ヘッダタイプがCodecModeRequestである場合、情報フィールドには、相手端末に要求するコーデックビットレートを示すFrameTypeIndexが入る。また、例えば上述のように、ヘッダタイプがCodecModeRequestである場合、情報フィールドには、相手端末に要求するチャンネル数またはマルチチャンネル用エンコード方式が入る。また、例えば上述のように、ヘッダタイプがCodecModeRequestである場合、情報フィールドには、相手端末に要求するエンコーディング帯域を示す情報が入る。また、例えば、マルチチャンネルを示すフィールド及びマルチチャンネルの情報は、基本ヘッダではなく、拡張ヘッダに含めてもよい。また、逆に、CodecModeRequest及び冗長データを表すフィールド、及びその情報は、拡張ヘッダではなく、基本ヘッダに含んでもよい。後続ヘッダ有無フィールドには、例えば、この拡張ヘッダの後に、さらに拡張ヘッダが存在するか否かの情報が、フラグ又は数値等の形で入る。例えば、このフィールドが1ビットである場合、このフィールドに0が入れば、後続ヘッダは存在しない事を示し、1が入れば、後続ヘッダが存在する事を示す。なお、拡張ヘッダは、固定長であるが、ヘッダタイプフィールドの示す内容に応じて、その固定長の値が異なっていてもよい。拡張ヘッダのヘッダタイプが、例えば冗長データ情報またはマルチチャンネル情報である場合、図30Bに示すRTPペイロードのデータ部には、冗長データ、チャンネル数、マルチチャンネル用エンコード方式に合ったマルチチャンネルデータも含まれる。また、基本ヘッダのFrameTypeがNoData、あるいは、図19~図23などに記載のspeechlostなどであった場合には、RTPペイロードのデータ部は無くてもよい。また、図30の例ではヘッダ部の有無を示すフィールドが最上位ビットからの固定長としてRTPペイロードの先頭に入る例を示したが、このフィールドは、RTPペイロードのどこに例えばRTPペイロードの最後に含まれてもよい。このように、本実施の形態の第3の例では、ヘッダ部とデータ部とから成るRTPペイロードにおいて、ヘッダ部が存在しない場合図30Aと、ヘッダ部が存在する場合図30Bとを含む。また、図30A及び図30Bに示すように、全てのRTPペイロードにおいて常に、ヘッダ部が設けられるか否かを示すフィールドヘッダ部の有無を示すフィールドが含まれる。なお、実施の形態5で述べたように、伝送ブロックサイズ等が決められているために、RTPペイロード長、特に通常の音声等のデータを運ぶRTPペイロード長が、複数の固定長に限られる場合がある。このような場合、本実施の形態のように、通常の音声等のデータを運ぶRTPペイロードにCodecModeRequestを含めると、RTPペイロード長が、対応する伝送ブロックサイズより長くなる可能性がある。これを解決するため、端末は、データ部が存在しないRTPペイロード、又は、通常データを送る場合に比べてデータ部が短いRTPペイロードが送られるタイミングで、CodecModeRequestをこれらRTPペイロードに含めて送ってもよい。データ部が存在しない場合、又は通常データを送る場合に比べてデータ部が短い場合とは、例えば、SID、NoData、あるいは図19~図23に記載のspeechlostを用いる場合である。このように、本実施の形態によれば、RTPペイロードにおいて、必要な場合にのみ必要なフィールドを与えた上で、データ部の長さに収まる適切なビットレートとその組み合わせをエンコーダに選択させることができる。以上、本発明の各実施の形態について説明した。なお、FrameTypeIndexは用意されている全てのコーデックモードビットレートそのもの、又は、ビットレートの組み合わせを記述する必要はなく、コーデックモードの一部を定義してもよい。また、上記実施の形態では、実際のコーデックモード又はコーデックモードセットとコーデックモード又はコーデックモードセットを示す番号数値との対応付けが規定されている場合について説明した。そして、コーデックモード又はコーデックモードセットを示す番号数値がSDP図8及び図11に記述される場合について説明した。しかし、実際のコーデックモード又はコーデックモードセットがSDPに直接記述されてもよい。また、図8、図11、図14及び図17で記述されている方式1は、特定のコーデック名を表す。例えば、方式1はEVS、AMR又はAMR-WBでもよく、別のコーデックであってもよい。また、図8及び図14では、方式1のコーデックに関してのみオファーされている記述となっているが、他の方式方式2、方式3...に関しても同様に記述され、SDPオファーの中に含まれてもよい。また、或るコーデック内での異なる種別、チャンネル数モノ、ステレオ等は、コーデック名としてSDP内に記述されてもよく、図9及び図15に示すコーデックモードセットの対応付けの中で定義されてもよい。ここで、コーデック内での異なる種別とは、例えば、EVSの中の、AMR-WBインタオペラブルモード又はAMR-WB非インタオペラブルモード、オーディオ帯域NarrowBand、WideBand、SuperWideBand、FullBand等を含む。また、上記実施の形態では、無線アクセス網の特性に関する情報として、CSGID又は基地局IDを用いる場合について説明した。しかし、無線アクセス網の特性に関する情報としては、これらに限らず、例えば、UEが接続されているセルHeNBを示すセル情報、及び、UEの位置を示す位置情報等が挙げられる。また、上記実施の形態では、UE間の通信開始時のコーデックモード又はコーデックモードセットビットレート及び処理遅延を含むを選択する場合について説明したが、これに限られない。例えば、UEが有している能力例えば、ディスプレイの大きさ等を選択する場合についても上記実施の形態を適用することができる。また、上記実施の形態では、主に音声に関するコーデックを用いて説明した。しかし、これに限らず、音楽、音響、画像等に関しても、本発明は適用可能である。また、本発明は、上記実施の形態に限定されず、種々変更して実施することが可能である。また、上記実施の形態では、本発明をハードウェアで構成する場合を例にとって説明したが、本発明はハードウェアとの連携においてソフトウェアでも実現することも可能である。また、上記実施の形態の説明に用いた各機能ブロックは、典型的には集積回路であるLSIとして実現される。これらは個別に1チップ化されてもよいし、一部又は全てを含むように1チップ化されてもよい。ここでは、LSIとしたが、集積度の違いにより、IC、システムLSI、スーパーLSI、ウルトラLSIと呼称されることもある。また、集積回路化の手法はLSIに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。LSI製造後に、プログラムすることが可能なFPGAFieldProgrammableGateArray、LSI内部の回路セルの接続または設定を再構成可能なリコンフィギュラブルプロセッサを利用してもよい。さらには、半導体技術の進歩又は派生する別技術によりLSIに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。2010年11月10日出願の特願2010-252113の日本出願、2010年12月14日出願の特願2010-278222の日本出願、2011年4月6日出願の特願2011-84442の日本出願、及び2011年8月9日出願の特願2011-173910の日本出願に含まれる明細書、図面及び要約書の開示内容は、すべて本願に援用される。"