JPWO2015129181A1 - 音声通信端末、中間ノード、処理装置、接続方法およびプログラム - Google Patents

Abstract

音声通信端末間の接続方法であって、第１の音声通信端末（１００）は、音声コーデックの複数のモードを含む第１のカテゴリをＳＤＰオファーに記載して第２の音声通信端末（２００）に送信し、第２の音声通信端末は、ＳＤＰオファーに記載された第１のカテゴリの中から複数のモードを選択して第２のカテゴリとして、ＳＤＰアンサーに記載して、第１の音声通信端末に送信する。ＳＤＰオファーとＳＤＰアンサーの少なくとも１つには、第２のカテゴリに含まれる音声コーデックのモードのうち、最大の帯域幅もしくは最も優先度の高いモードの帯域幅の要求が記載される。

Description

本開示は、ＶｏＩＰ（Voice Over IP）等で用いられる音声通信端末、およびその接続方法に関し、音声コーデックのモードを切替える技術に関する。

３ＧＰＰなどの通信システム上で、通信端末（以下ＵＥ: User Equipment）がＩＰ(Internet Protocol)ベースの通信を行う際に呼制御が行われる。呼制御では、通信で使われるＩＰアドレスやポート番号の通信相手先との交換、通信で使う音声コーデックの取り決め（折衝（ネゴシエーション））、データが通る経路の確保などが行われる。３ＧＰＰでの呼制御はＩＭＳ(IP Multimedia Subsystem)で行われる。ＩＭＳ網は、呼制御のための情報管理及び呼制御のシグナリングメッセージ（ＳＩＰ：Session Initiation Protocol）のルーティング及び３ＧＰＰのレガシー網や３ＧＰＰ以外の網との相互接続を行うための網である。

図８は、３ＧＰＰのＩＭＳを使ったＶｏＩＰの通話が行われるまでの手順の一例を示すフローである。図８は、ＵＥ１００からＵＥ１０２に電話をかける場合のフロー例を示す。図８に示すように、SIP INVITEメッセージがＩＭＳ網経由でＵＥ１００からＵＥ１０２に送信され（ＳＴ１１）、SIP 183 Session ProgressメッセージがＩＭＳ網経由でＵＥ１０２からＵＥ１００へ送信される（ＳＴ１２）。このように、SIP INVITEメッセージ及びSIP 183 Session ProgressメッセージがＵＥ間でやりとりされ、通信に関するネゴシエーションが行われる。

SIP INVITEメッセージにはＳＤＰ（Session Description Protocol）オファーが付加されており、ＳＤＰオファーには、ＶｏＩＰ通信を行うために必要な情報、例えばサポートしている音声コーデックやそのペイロードフォーマット等に関する候補等が記述される。ＵＥ１０２は、ＳＴ１１でSIP INVITEメッセージを受け取ると、ＳＤＰオファーに記述された複数の候補の中から適当な音声コーデックなどのメディア情報を選択し、ＳＤＰアンサーに記述する。ＵＥ１０２は、ＳＴ１２においてＳＤＰアンサーをSIP 183 Session Progressメッセージに付加してＵＥ１００に送信する。

ＵＥ１０２で選択されたメディア情報はＩＭＳ網で解析され、解析結果に応じたリソースをこの通話セッションに割り当てる指示がＩＰコア網に出力される。要求リソースに応じた通信経路（ＧＰＲＳ (General Packet Radio Service) ）の場合には、ＰＤＰコンテクスト、ＥＰＳ(Evolved Packet System)の場合にはＥＰＳベアラ）が確立される。ＩＭＳ網からの指示に従って、ＩＰコア網及び無線アクセス網でのリソース割当処理が行われる（ＳＴ１３）。リソース割当処理が完了すると、ＵＥ１０２ではユーザの呼び出しが行われ（ＳＴ１４）、ユーザが応答するとＵＥ１００に200 OKメッセージが送信され（ＳＴ１５）、ＵＥ１００とＵＥ１０２との間で通話が開始される（ＳＴ１６）。

図９にＳＤＰオファー（SDP offer）及びＳＤＰアンサー（SDP answer）の一例を示す。図９では、ＳＤＰオファーによって、AMR-WB（Adaptive Multi Rate - Wide Band）bandwidth-efficiencyモード（のペイロードフォーマット）、AMR-WB octet-alignモード（のペイロードフォーマット）、AMR bandwidth-efficiencyモード、及び、AMR octet-alignモードの４モードがＵＥ１００においてオファーされ、AMR-WB bandwidth-efficiencyモードがＵＥ１０２において選択されている。

そして、通話途中で音声コーデックやモードを変更する場合には、再度ＩＭＳシグナリングメッセージ、つまりＳＤＰオファーおよびＳＤＰアンサーを交換し、再折衝を行う必要がある。

ここで、音声コーデックには複数のモードを持つものが存在する。３ＧＰＰで規格化が行われているＥＶＳ (Enhanced Voice Service)コーデックがその例である。非特許文献(S4-130778: EVS-4 Design Constraint)によると、ＥＶＳはAMR-WB互換モード（以下互換モード）の他、AMR-WB非互換モード（以下、非互換モード、又はネイティブモード）として、NB(Narrowband)モード、WB(Wideband)モード、SWB(Super Wideband)モード、FB(Full band)モードなどが存在する。

これらのモードは、セッション途中での切り替えが必要になる場合がある。例えば非特許文献１に記載のＳＲＶＣＣ(Single Radio Voice Communication Continuity)やＳＲＶＣＣ with ATCF enhancement などで通信中のＵＥの片方の音声コーデックが変わった場合である。ＳＲＶＣＣの場合について図１０を用いて説明する。

例えばＥＶＳのＳＷＢモードを使ってＵＥ１００およびＵＥ１０２の２つの端末が通信している途中に、ＵＥ１００がＬＴＥのカバーエリア（ＰＳ）を外れ回線交換網（ＣＳ）にＳＲＶＣＣハンドオーバしたとする。ＥＶＳは回線交換網ではサポートされていないため、ＵＥ１００の使用する音声コーデックが回線交換網サポートのもの（例えばAMRやAMR-WB）に変更になる。この時ＩＭＳのセッション再折衝を行いＵＥ１０２側の音声コーデックもAMRやAMR-WBに変更するか、又はセッション再折衝を行わず、中間のゲートウェイでトランスコーディングを行う必要がある（特許文献１、２）。トランスコーディングを行う場合、両方の端末の帯域幅が揃っていることが品質上望ましい。よって例えばＵＥ１００の音声コーデックがAMRに切り替わった場合には、ＵＥ１０２側をＥＶＳのＮＢモードに、ＵＥ１００の音声コーデックがAMR-WBに切り替わった場合には、ＵＥ１０２側をＥＶＳのＷＢモード又はAMR-WB互換モードに、セッション再折衝無しに切り替えるのが望ましい。

次に、モード切替方法について説明する。これらモードをセッション中に、ＩＭＳシグナリングメッセージによる再折衝なしに切り替えるための一つの方法として、ＲＴＰペイロードの中にモードに関する全ての情報を含ませておく方法がある。

図１１は、ＲＴＰパケットの構成を示す図である。ＲＴＰパケットは、ＩＰヘッダ、ＵＤＰヘッダ、ＲＴＰヘッダ、ＲＴＰペイロードからなる。ＲＴＰペイロードとはＲＴＰパケットが運ぶデータ部分（ペイロード）である。つまり、上記方法によれば、ＲＴＰペイロードの内容を確認することにより、モードの情報を得ることができる。

しかし、非特許文献２では、ＲＴＰペイロードに情報を持たせる代わりに、ＲＴＰヘッダに情報を持たせる方法を提案している。つまり図１１のように、まず、AMR-WB非互換モードのNB、WB、SWB、及びAMR-WB互換モードにそれぞれ別々のペイロードタイプ(ＰＴ)番号（９７，９８，９９，１００）を割り当ててＳＤＰオファーに記述する。次に、ＳＤＰアンサーで全てのモードをグループとして選択する。そして、モードを切り替える必要が生じたときは、切り替え先のモードに対応するペイロードタイプ番号をＲＴＰヘッダのペイロードタイプ(ＰＴ)フィールドに記述する事によりモードを切り替える。この方法をペイロードタイプ切替(PT switching)と呼ぶ事にする。

特開２０１３−１２８５５号公報 特開２０１３−１２８５６号公報

3GPP TS 23.216 V12.0.0 "Single Radio Voice Call Continuity (SRVCC)" AHEVS-272 3GPPSA4-EVS SWG Conference Call #29（August 29 2013） RFC 3388 Grouping of Media Lines in SDP (December 2002) 3GPP TS 23.237 V12.5.0 "IP Multimedia Subsystem (IMS) Service Continuity"

しかし、ペイロードタイプ切替にあたり、モードによってサンプリングレートが異なる場合、ＲＴＰヘッダのタイムスタンプの増え方がモードによってバラバラになってしまう。この結果、ＲＴＣＰ（Real Time Control Protocol）などを用いた再生制御がうまく行えない等の問題がある。

本開示では、音声コーデックのモード切替をスムーズに行うことにより、通話の中断がなく通話品質が高い音声通信端末等を提供する。具体的には、サンプリングレートや要求帯域幅の異なる複数のモードを含むコーデックであっても、従来の再生制御や帯域確保（帯域予約）手法を用いることができる音声コーデックのモード切替方法や音声通信端末等を提供する。

本開示の音声通信端末間の接続方法では、第１の音声通信端末が、音声コーデックの複数のモードを含む第１のカテゴリをＳＤＰオファーに記載して第２の音声通信端末に送信し、第２の音声通信端末が、ＳＤＰオファーに記載された第１のカテゴリの中から複数のモードを選択して第２のカテゴリとして、ＳＤＰアンサーに記載して、第１の音声通信端末に送信する。ＳＤＰオファーとＳＤＰアンサーの少なくとも１つには、第２のカテゴリに含まれる音声コーデックのモードの中で最大の帯域幅もしくは最も優先度の高いモードの帯域幅の要求が記載される。

本開示の音声通信端末等では、音声コーデックのモード切替をスムーズに行うことができるので、通話の中断がなく、通話品質を高くすることができる。具体的には、本開示の音声コーデックのモード切替方法や音声通信端末等によれば、サンプリングレートや要求帯域幅の異なる複数のモードを含むコーデックであっても、従来の再生制御や帯域確保（帯域予約）手法を用いることができる。

本開示の実施形態１における音声通信端末の構成図 本開示の実施形態１におけるＳＤＰオファーを示す説明図 本開示の実施形態１におけるＳＤＰオファーを示す説明図 本開示の実施形態１におけるＳＤＰオファーを示す説明図 本開示の実施形態１におけるその他のＳＤＰオファーを示す説明図 本開示の実施形態１におけるＳＤＰアンサーを示す説明図 本開示の実施形態１におけるＳＤＰアンサーを示す説明図 本開示の実施形態１におけるＳＤＰアンサーを示す説明図 本開示の実施形態１における音声通信端末の動作を示す説明図 本開示の実施形態２におけるＳＤＰオファー示す説明図 本開示の実施形態２におけるＳＤＰオファー示す説明図 本開示の実施形態３における中間ノードの構成図 従来技術の呼制御方法を示す説明図 従来技術のＳＤＰオファー／アンサーを示す説明図 従来技術のハンドオーバを説明する説明図 従来技術のＲＴＰパケットの構成を示す説明図

以下、本開示の実施形態の構成および動作について、図面を参照して説明する。

なお、本明細書において、「第１のカテゴリ」とは、音声コーデックの複数のモードを含む集合であり、集合を代表する名称を記載する場合の他、集合の要素である音声コーデックや音声コーデックのモードを列挙して記載する場合も含まれる。

「第２のカテゴリ」とは、音声コーデックの複数のモードを含む集合であり、集合を代表する名称を記載する場合の他、集合の要素である音声コーデックや音声コーデックのモードを列挙して記載する場合も含まれる。第２のカテゴリに含まれる音声コーデックのモードの数は、第１のカテゴリに含まれる音声コーデックの数と同じ、もしくはそれより少ない。

「予め定められた」とは、予め特定のクロックレートが一意に定められている場合の他、クロックレートを決定する方法が一意に定められている場合も含む。

「着呼側音声通信端末から」とは、直接着呼側音声通信端末から受信する場合の他、１以上の中間ノードを経由して受信する場合も含む。中間ノードを経由する場合、中間ノードでＳＤＰアンサーが変更を受けているときは、当然変更後のＳＤＰアンサーが受信部で受信される。

「発呼側音声通信端末から」とは、直接発呼側音声通信端末から受信する場合の他、１以上の中間ノードを経由して受信する場合も含む。中間ノードを経由する場合、中間ノードでＳＤＰオファーが変更を受けているときは、当然変更後のＳＤＰオファーが受信部で受信される。

（本開示に至った経緯）
従来のペイロードタイプ切替にはいくつかの課題が存在する。

まず、モードによってサンプリングレートが異なる場合、ＲＴＰヘッダのタイムスタンプの増え方がモードによってバラバラになってしまう（課題１）。この結果、ＲＴＣＰ（Real Time Control Protocol）などを用いた再生制御がうまく行えない等の問題がある。

次に、またモードによって要求帯域（ビットレート）が違う場合（課題２）、ネットワーク側で要求される帯域を好適に確保できないという問題がある。

これらの課題を解決する方法として、各モードに対し別々のＥＰＳベアラを割り当て、別々にハンドリングする方法が考えられる。例えば、別々のＥＰＳベアラが割り当てられた複数の音声コーデックをグループ化し、１つのＥＴＰのフローとして取り扱う方法が、非特許文献３に開示されている。この方法は各音声コーデックに別々のポート番号を割り当てることにより、これらの音声コーデックのグループ関係を明示し、一つのＲＴＰセッションとして取り扱う方法である。しかし、非特許文献３ではグループ化される音声コーデックのサンプリングレートが同一である事が想定されており、上述の（課題１）は解決されない。さらに複数のベアラを張る方法は、中間ノードにおけるベアラの管理負荷がかかる上、モードが切り替わった際にそれまで使われていなかったモード用のベアラをアクティベートするためのシグナリングを走らせる必要があるというデメリットもある。

本開示では、音声コーデックのモード切替をスムーズに行うことにより、通話の中断がなく通話品質が高い音声通信端末等を提供する。具体的には、サンプリングレートや要求帯域幅の異なる複数のモードを含むコーデックであっても、従来の再生制御や帯域確保（帯域予約）手法を用いることができる音声コーデックのモード切替方法や音声通信端末等を提供する。

（実施形態１）
図１は、実施形態１にかかる音声通信端末の構成を示すブロック図である。図１の左側は、発呼側音声通信端末１００であり、図１の右側は着呼側音声通信端末２００である。発呼側音声通信端末１００は、ＳＤＰメッセージ生成部１０１、パケット生成部１０２、記憶部１０３、制御部１０４、送信部１０５、受信部１０６、判断部１０７により主に構成される。また、着呼側音声通信端末２００は、ＳＤＰメッセージ生成部２０１、パケット生成部２０２、記憶部２０３、制御部２０４、送信部２０５、受信部２０６、判断部２０７により主に構成される。

発呼側のＳＤＰメッセージ生成部１０１は、SIP INVITEメッセージ中のＳＤＰオファーを生成する。その際、判断部１０７は、ＳＤＰメッセージ生成部１０１がＳＤＰオファージを生成する際の要求帯域の判断を行う。図２Ａ、図２Ｂは、ＳＤＰメッセージ生成部１０１で生成されるＳＤＰオファーの例である。ＳＤＰオファーのメディア欄には、発呼側音声通信端末１００がサポートしている音声コーデックないし音声コーデックのモードが記載されている。図２Ａ、図２Ｂの場合、発呼側音声通信端末１００は、ＥＶＳのＡＭＲ―ＷＢ非互換モード（ＳＷＢ）、ＥＶＳのＡＭＲ―ＷＢ非互換モード（ＷＢ）、ＥＶＳのＡＭＲ―ＷＢ非互換モード（ＮＢ）、およびＥＶＳのＡＭＲ―ＷＢ互換モード（ＷＢ）の４つのモードをサポートしている。これら４つのモードで第１のカテゴリを構成する。ＥＶＳのＡＭＲ−ＷＢ互換モード（ＷＢ）が含まれているのは、ＳＤＰオファーを受信した着呼側音声通信端末２００がＥＶＳをサポートしておらず、レガシーのＡＭＲ−ＷＢのみをサポートしていた場合、ＡＭＲ−ＷＢの行（ペイロードタイプ１００）のみを選んで応答することができるようにするためである。

なお、図２Ｃのように、ＥＶＳのＡＭＲ−ＷＢ非互換モード（ＳＷＢ）、ＥＶＳのＡＭＲ−ＷＢ非互換モード（ＷＢ）、ＥＶＳのＡＭＲ−ＷＢ非互換モード（ＮＢ）をまとめて、例えばＥＶＳ／３２０００として一つの行に記載してもよい。このように、第１のカテゴリは、音声コーデックの複数のモードをまとめた集合を代表する名称を含んでいてもよいし、第１のカテゴリ自体を、複数のモードをまとめた集合を代表する名称としてもよい。

同じくＳＤＰオファーのメディア欄には、判断部１０７での要求帯域の判断に基づき、図２Ａのように、第１のカテゴリに含まれるモード、すなわち発呼側音声通信端末１００がサポートするモードが使用する最大の帯域幅の要求が記載されている。例えば、ＳＷＢおよびＷＢモードが最大８０ｋｂｐｓ、ＮＢモードおよびＡＭＲ−ＷＢ互換モード（ＷＢ）が最大３０ｋｂｐｓを要求する場合、ＳＤＰオファーに記載する帯域幅は８０ｋｂｐｓとする。

あるいは、ＳＤＰオファーのメディア欄には、判断部１０７での要求帯域の判断に基づき、図２Ｂのように、第１のカテゴリに含まれるモード、すなわち発呼側音声通信端末１００がサポートするモードのうち、最も優先度が高いモードの帯域幅の要求が記載される。例えば、ＮＢモードが最も優先度の高いモードであった場合には、ＳＤＰオファーに記載する帯域幅は３０ｋｂｐｓとなる。優先度は、予め音声通信端末で定められた順序などで判断することができる。この優先度順にＳＤＰオファーのメディア欄に記載してもよい。

なお、帯域幅を記載して帯域幅要求を行う場合、ＳＤＰオファーに記載せずに後述のＳＤＰアンサーに記載してもよい。あるいは、端末側ではＳＤＰには記載せず、代わりにベアラを張る中間ノードがＳＤＰの内容を確認し、ＳＤＰの内容に基づいて要求帯域幅を判断、決定し、要求帯域幅を割り当てるようにしてもよい。

なお、図３のように、音声コーデックのモードのグループ関係を明示的に記述してもよい。このように記載することで、通話開始時に張られるベアラの本数を１本とすることが明確になる。

着呼側のＳＤＰメッセージ生成部２０１は、発呼側のＳＤＰオファーに対応して、SIP 183 Session Progressメッセージの中のＳＤＰアンサーを生成する。図４Ａ、図４Ｂ、図４Ｃは、ＳＤＰメッセージ生成部２０１で生成されるＳＤＰアンサーの例である。ＳＤＰアンサーのメディア欄には、ＳＤＰオファーに記述された複数の音声コーデックないし音声コーデックのモードの候補の中から、着呼側音声通信端末２００がサポートしている音声コーデックないし音声コーデックのモードが記載されている。例えば、図４Ａの場合、着呼側音声通信端末２００は、４つのモード全てをサポートしている。これら４つのモードで第２のカテゴリを構成する。着呼側音声通信端末２００がＥＶＳをサポートしておらず、レガシーのＡＭＲ−ＷＢのみをサポートしていた場合、図４Ｂのように、ＥＶＳのＡＭＲ−ＷＢ互換モード（ＷＢ）であるＡＭＲ−ＷＢの行（ペイロードタイプ１００）のみを選んで記載される。

なお、第２のカテゴリも第１のカテゴリと同様、音声コーデックの複数のモードを記載したものに限らず、音声コーデックの複数のモードをまとめた集合を代表する名称を含んでいてもよいし、第２のカテゴリ自体を、複数のモードをまとめた集合を代表する名称としてもよい。

同じくＳＤＰアンサーのメディア欄には、帯域幅の要求が記載されている。この帯域幅の要求は、ＳＤＰオファーに帯域幅が記載されていた場合にはＳＤＰオファーからコピーしてもよいし、判断部２０７での要求帯域の判断に基づいて記載してもよい。図４Ａは、第２のカテゴリに含まれるモード、すなわち着呼側音声通信端末２００がサポートするモードが使用する最大の帯域幅の要求が記載されている例である。この例では、ＳＷＢおよびＷＢモードが要求する帯域幅である８０ｋｂｐｓが記載されている。図４Ｃは、第１のカテゴリに含まれるモード、すなわち着呼側音声通信端末２００がサポートするモードのうち、最も優先度が高いモードの帯域幅の要求が記載されている例である。この例では、ＮＢモードが最も優先度が高いモードである場合の３０ｋｂｐｓが記載されている。優先度は、ＳＤＰオファーのメディア欄に記載の順序や、予め音声通信端末で定められた順序などから判断できる。

パケット生成部１０２は、ＳＤＰオファーおよびＳＤＰアンサーに従いネットワーク側でリソース割り当てが行われ、そしてユーザ呼び出しを経て通話が開始された後に、符号化された音声データを送信するためのパケットであるＲＴＰパケットを生成する。ＲＴＰパケットの構成は図１１の通りである。パケット生成部１０２は、記憶部１０３からクロックレートを読み出し、読み出したクロックレートを用いて、ＲＴＰパケット中にタイムスタンプを付与し、ＲＴＰパケットを生成する。あるいは、クロックレートを読み出すことに代えて、クロックレートを決定する方法を読み出し、かかる方法に従いクロックレートを決定し、決定したクロックレートを用いて、タイムスタンプを付与してもよい。クロックレートの決定は、判断部１０７が行う。記憶部１０３に記憶されているクロックレートないしクロックレートを決定する方法については、後述する。

また、パケット生成部１０２は、ハンドオーバ等により音声コーデックないし音声コーデックのモードを切り替える必要が生じた場合には、ＳＤＰオファー／アンサーでの再折衝を行わず、ＲＴＰヘッダのペイロードタイプフィールドに切り替え先の音声コーデックないし音声コーデックのモードに割り当てられたペイロードタイプ（ＰＴ）番号を指定することにより、音声コーデックないし音声コーデックのモードを切り替える（ペイロードタイプ切替）。ペイロードタイプ切替は、図１１で説明した従来技術と同様である。この場合において、切り替えに伴ってクロックレートが変更されることはない。また、ペイロードタイプ切替方式ではなく、ペイロードにモード情報が含まれている場合の切替方式の場合にも、ＳＤＰオファー／アンサーでの再折衝を行わず、ペイロードに含まれているモード情報がモード切替に使われる。この場合においても、切り替えに伴ってクロックレートが変更されることはない。

パケット生成部２０２は、パケット生成部１０２と同じ構成を有している。

記憶部１０３は、第２のカテゴリに含まれる音声コーデックないし音声コーデックのモードに共通のクロックレート、またはクロックレートの決定方法を記憶している。例えば、第２のカテゴリに含まれる音声コーデックがＥＶＳの場合、ＡＭＲ−ＷＢ非互換モード（ＦＢ）のサンプリングレートである４８０００Ｈｚをクロックレートとして用いると定めることができる。さらに、このような一意の固定のクロックレートではなく、クロックレートの決定方法を定めてもよい。例えば、第２のカテゴリに含まれる音声コーデックのモードのうち最大のものとする決定方法を定めた場合、図４Ａの場合には３２０００Ｈｚとなる。ここで重要なのは、定められるクロックレートは、第２のカテゴリに含まれる音声コーデックないし音声コーデックのモードに共通のクロックレートであればよいということである。つまり、再折衝なしにモードを切り替える場合には第２のカテゴリに含まれるモード内での切り替えとなるが、このような切り替えの範囲でクロックレートが変わらない、すなわちタイムスタンプが切り替えの前後で変わらない，すなわち連続的にタイムスタンプの値を付与するようにすればよいからである。

記憶部２０３は、記憶部１０３と同じ構成を有している。

制御部１０４は、ＳＤＰメッセージ生成部１０１およびパケット生成部１０２の機能を実現する他、記憶部１０３に対する入出力や送信部１０５、受信部１０６の制御を行う。また、制御部１０４は、判断部１０７の機能を実現する。具体的には、判断部１０７は、記憶部１０３を参照してクロックレートを決定し、パケット生成部１０２に供給する。また、判断部１０７は、要求する帯域幅を決定し、ＳＤＰメッセージ生成部１０１へ供給する。制御部２０４も制御部１０４と同様の構成を有している。

送信部１０５は、ＳＤＰメッセージ生成部１０１で生成されたＳＤＰオファー、およびパケット生成部１０２で生成されたＲＴＰパケットを着呼側音声通信端末２００の受信部２０６に向けて送信し、受信部２０６はこれを受信する。

また、送信部２０５は、ＳＤＰメッセージ生成部２０１で生成されたＳＤＰアンサー、およびパケット生成部２０２で生成されたＲＴＰパケットを発呼側音声通信端末１００の受信部１０６に向けて送信し、受信部１０６はこれを受信する。

なお、ＳＤＰメッセージ生成部１０１、パケット生成部１０２および判断部１０７を含む制御部１０４、および、記憶部１０３で、発呼側処理装置を構成する。また、ＳＤＰメッセージ生成部２０１、パケット生成部２０２および判断部２０７を含む制御部２０４、および、記憶部２０３で、着呼側処理装置を構成する。発呼側処理装置および着呼側処理装置は、半導体素子などの部品レベルあるいはシステムボードなどの半完成品レベルの構成に対応する。

次に、発呼側音声通信端末１００および着呼側音声通信端末２００の動作を、図５を用いて説明する。図５は、本開示の発呼側音声通信端末１００および着呼側音声通信端末２００の動作（方法）を表す動作説明図である。

まず、発呼側音声通信端末１００はＳＤＰオファーを生成し、着呼側音声通信端末２００に向けて送信する（Ｓ１）。発呼側音声通信端末１００で帯域幅の要求を行う場合には、かかる要求をＳＤＰオファーに記載する。

着呼側音声通信端末２００は、発呼側音声通信端末１００から送信されたＳＤＰオファーを受信する（Ｓ２）。そして、ＳＤＰオファーに対応して、ＳＤＰアンサーを生成し、発呼側音声通信端末１００に向けて送信する（Ｓ３）。着呼側音声通信端末２００で帯域幅の要求を行う場合には、かかる要求をＳＤＰアンサーに記載する。

発呼側音声通信端末１００は、着呼側音声通信端末２００から送信されたＳＤＰアンサーを受信する（Ｓ４）。

通話が開始されると、符号化された音声データを送信するため、発呼側音声通信端末１００および着呼側音声通信端末２００それぞれでＲＴＰパケットが生成される（Ｓ８）。この際、記憶部１０３、２０３からクロックレートを読み出し、制御部１０４中の判断部１０７、および制御部２０４中の判断部２０７でクロックレートを決定し、かかるクロックレートでタイムスタンプが付与される。

ハンドオーバ等の理由によりモード切替の必要が生じた場合、発呼側音声通信端末１００、または着呼側音声通信端末２００から、ペイロードタイプ（ＰＴ）番号を指定することにより音声コーデックないし音声コーデックのモードを切り替える（Ｓ９）。ペイロードタイプ切替方式ではなく、ペイロードにモード情報が含まれている場合、この情報によりモードを切り替える。

切替後、再び発呼側音声通信端末１００および着呼側音声通信端末２００それぞれでＲＴＰパケットが生成される（Ｓ１０）。この際、切り替え前と同じクロックレートでタイムスタンプが付与される。つまり、タイムスタンプの周期は切り替え前後で変化しない。なお、Ｓ１０で再度記憶部１０３、２０３からクロックレートを読み出してもよいし、記憶部１０３，２０３からの読み出しの動作なしに、切り替え前のクロックレートを引き続き用いるようにしてもよい。

以上、本実施形態によれば、音声コーデックのモード切替の前後でクロックレートが変化しない結果、タイムスタンプの周期がモード切替の前後で変化しないので、ＲＴＣＰ（Real Time Control Protocol）などを用いた再生制御を問題なく行うことができる。

また、本実施形態によれば、ネットワーク側で要求される帯域を好適に確保することが可能となる。

（実施形態２）
本実施形態では、発呼側音声通信端末１００が送信するＳＤＰオファーの他の例について説明する。

図２Ａで示されるところの実施形態１のＳＤＰオファーを着呼側音声通信端末２００に送信して折衝（ネゴシエーション）を行った場合を考える。ＳＤＰオファーを受け取った着呼側音声通信端末２００がＥＶＳをサポートしておらず、ＡＭＲ−ＷＢのみをサポートしている場合、図４ＢのようにＡＭＲ−ＷＢの行（ペイロードタイプ１００）のみを選んでＳＤＰアンサーを送信する。

しかし、図２Ａの場合、帯域幅を８０ｋｂｐｓと設定しているが、ＥＶＳのＡＭＲ−ＷＢ非互換モードでの符号化が行われない場合には、このような広い帯域幅を必要としない場合も多い。また、図３のように明示的にグループ化の記載をした場合、着呼側音声通信端末２００が図３のようなグループ化を行ったＳＤＰの表記方法に対応していないことから、ＡＭＲ−ＷＢの行（ペイロードタイプ１００）のみを選ぶことができない可能性がある。

そこで、本実施形態では、図６Ａのように第１番目のメディア行にはサポートする４つのモード全てを記載するとともに、第２番目のメディア行にＥＶＳのＡＭＲ−ＷＢ非互換モードのみを独立して取り出し記載する。なお、図６Ｂのように、第１番目のメディア行にグループ関係を表示してもよい。なお、図６Ａや図６Ｂのような記載を行ったとしても、着呼側音声通信端末２００においてＥＶＳが選ばれる場合には第２番目のメディア行はＳＤＰアンサーで削除され、着呼側音声通信端末２００においてＡＭＲ−ＷＢが選ばれる場合には第１番目のメディア行はＳＤＰアンサーで削除されるので、通話に用いられるベアラは単一となる。

このように、ＥＶＳのＡＭＲ−ＷＢ非互換モードのみを取り出して別のメディア行に記載することにより、ＥＶＳのＡＭＲ−ＷＢ非互換モードに必要、かつ適切な帯域幅を独自に設定することができる。

なお、本実施形態の別の実施態様として、発呼側音声通信端末１００は実施形態１と同様の図２ＡのＳＤＰオファーを送信し、これに応答する着呼側音声通信端末２００、あるいは中間のネットワークノード側で、要求帯域の値を変更して記載してもよい。

なお、本実施の形態１及び２の音声通信端末１００及び２００の機能は、ＭＧＭ(media gateway)やＳＲＶＣＣ with ATCF enhancementのＡＴＣＦやＡＴＧＷなどの、ＳＤＰメッセージや音声データをアンカーするノードに実装されていてもよい。

（実施形態３）
本実施形態では、実施形態１、２で記載した発呼側音声通信端末１００や着呼側音声通信端末２００の間に位置する中間ノード３００について説明する。

図７は、ＳＤＰオファーやＳＤＰアンサーの内容を確認する、Ｐ−ＣＳＣＦなどの中間ノードの構成を示すブロック図である。中間ノード３００は、受信部３０１、判断部３０２、情報生成部３０３、送信部３０４より構成される。

中間ノード３００は、代表的にはＰ−ＣＳＣＦ（Proxy Call Session Control Function）が該当するが、その他のＳＤＰメッセージを転送するノードでも実現可能である。

受信部３０１は、発呼側音声通信端末１００や着呼側音声通信端末２００から、ＳＤＰメッセージ、すなわちＳＤＰオファーやＳＤＰアンサーを受け取る。

判断部３０２は、QoS(Quality of Service)設定を行うネットワークノードへ要求する帯域幅を判断する。この帯域は、オペレータによりあらかじめ定められたものであってもよいし、受信部３０１より受け取ったＳＤＰオファーやＳＤＰアンサーの中身に基づいたものであってもよい。例えば、ＳＤＰオファーやＳＤＰアンサーに明示的に帯域幅が記載されていた場合には、この帯域幅に従う。ＳＤＰオファーやＳＤＰアンサーに明示的に帯域幅が記載されていない場合、メディア欄などの他の情報から要求帯域幅を判断する。例えば複数モードがサポートされているコーデックの場合、サポートされているモードの最大の帯域幅でもよいし、最も優先度の高いモードの帯域幅であってもよい。

情報生成部３０３は、判断部３０２により判断された要求帯域を、QoS(Quality of Service)設定を行うネットワークノードへ通知するための情報を生成する。

送信部３０４は、情報生成部３０２で生成された情報をネットワークノードへ送信する。また、受け取ったＳＤＰメッセージを発呼側音声通信端末１００や着呼側音声通信端末２００に転送する。

なお、判断部３０２で行われる判断、又は情報生成部３０３で作成される情報には、要求帯域だけではなく、他のポリシーや課金情報などが含まれてもよい。またQoS(Quality of Service)設定を行うネットワークノードとは、例えば、3GPPネットワーク上のPCRF(Policy and Charging Rules Function)などを指す。なお、判断部３０２での判断や，情報生成部３０３での情報生成は、単一のネットワークノードで完結せず、他のノードとの連携により行われてもよい。

（総括）
以上、実施形態１および２で本開示の音声通信端末を説明し、実施形態３で本開示の中間ノードを説明した。本開示の音声通信端末および本開示の中間ノードは、専用に設計されたハードウェアとしてだけでなく、汎用のハードウェアに本開示の動作（方法）を実行するプログラムをインストールしてプロセッサで実行することにより実現する場合も含む。汎用のハードウェアたる電子計算機として、例えばパーソナルコンピュータ、スマートフォンなどの各種携帯情報端末などが挙げられる。

本開示にかかる音声通信端末は、音声信号を扱う場合の他、音楽信号を扱う場合も含まれる。そして、音声信号や音楽信号の記録、伝送、再生に関係する機器に応用が可能である。

１００ 発呼側音声通信端末
２００ 着呼側音声通信端末
１０１，２０１ ＳＤＰメッセージ生成部
１０２，２０２ パケット生成部
１０３，２０３ 記憶部
１０４，２０４ 制御部
１０５，２０５ 送信部
１０６，２０６ 受信部
１０７，２０７ 判断部
３００ 中間ノード

Claims (11)

1. 音声通信端末間の接続方法であって、
   第１の音声通信端末で、音声コーデックの複数のモードを含む第１のカテゴリをＳＤＰ（Session Description Protocol）オファーに記載して、第２の音声通信端末に送信し、
   前記第２の音声通信端末で、前記ＳＤＰオファーに記載された前記第１のカテゴリの中から複数のモードを選択して第２のカテゴリとしてＳＤＰアンサーに記載して、前記第１の音声通信端末に送信し、
   単一のベアラで前記第１の音声通信端末および前記第２の音声通信端末を接続し、
   前記ＳＤＰオファーまたは前記ＳＤＰアンサーの少なくとも１つに、前記第２のカテゴリに含まれる前記音声コーデックの前記モードの中で最大の帯域幅もしくは最も優先度の高いモードの帯域幅の要求が記載される、
   接続方法。
2. 音声通信端末間の接続方法であって、
   第１の音声通信端末で、音声コーデックの複数のモードを含む第１のカテゴリをＳＤＰ（Session Description Protocol）オファーに記載して、第２の音声通信端末に送信し、
   前記第２の音声通信端末で、前記ＳＤＰオファーに記載された前記第１のカテゴリの中から複数のモードを選択して第２のカテゴリとしてＳＤＰアンサーに記載して、前記第１の音声通信端末に送信し、
   単一のベアラで前記第１の音声通信端末および前記第２の音声通信端末を接続し、
   前記第１の音声通信端末および前記第２の音声通信端末の間に位置する中間ノードにおいて、受信した前記ＳＤＰオファーまたは前記ＳＤＰアンサーを参照して、前記第２のカテゴリに含まれる前記音声コーデックの前記モードの中で最大の帯域幅もしくは最も優先度の高いモードの帯域幅の要求を行う、
   接続方法。
3. ＳＩＰ（Session Initiation Protocol）メッセージに付加されるＳＤＰオファーおよびＳＤＰアンサーを交換して着呼側音声通信端末との間で接続を行う発呼側の音声通信端末であって、
   前記音声コーデックの複数のモードを含む第１のカテゴリを記載した前記ＳＤＰオファーを生成するＳＤＰメッセージ生成部と、
   前記ＳＤＰオファーを前記着呼側音声通信端末に送信する送信部と、
   前記着呼側音声通信端末から、前記ＳＤＰオファーに対応する前記ＳＤＰアンサーであって、前記ＳＤＰオファーに記載した前記第１のカテゴリの中から複数のモードが選択されて第２のカテゴリとして記載されるとともに、前記第２のカテゴリに含まれる前記音声コーデックの前記モードの中で最大の帯域幅もしくは最も優先度の高いモードの帯域幅の要求が記載された前記ＳＤＰアンサーを受信する受信部と、を有し
   単一のベアラで前記着呼側音声通信端末と接続を行う、
   音声通信端末。
4. ＳＩＰ（Session Initiation Protocol）メッセージに付加されるＳＤＰオファーおよびＳＤＰアンサーを交換して発呼側音声通信端末との間で接続を行う着呼側の音声通信端末であって、
   前記発呼側音声通信端末から、前記音声コーデックの複数のモードを含む第１のカテゴリが記載された前記ＳＤＰオファーを受信する受信部と、
   前記ＳＤＰオファーに対応する前記ＳＤＰアンサーであって、前記ＳＤＰオファーに記載された前記第１のカテゴリの中から複数のモードを選択して第２のカテゴリとして記載するとともに、前記第２のカテゴリに含まれる前記音声コーデックの前記モードの中で最大の帯域幅もしくは最も優先度の高いモードの帯域幅の要求を記載した前記ＳＤＰアンサーを生成するＳＤＰメッセージ生成部と、
   前記ＳＤＰアンサーを前記発呼側音声通信端末に送信する送信部と、を有し、
   単一のベアラで前記着呼側音声通信端末と接続を行う、
   音声通信端末。
5. ＳＩＰ（Session Initiation Protocol）メッセージに付加されるＳＤＰオファーおよびＳＤＰアンサーを交換して着呼側音声通信端末との間で接続を行う発呼側音声通信端末で用いられる発呼側の処理装置であって、
   前記音声コーデックの複数のモードを含む第１のカテゴリを記載した前記ＳＤＰオファーを生成し、前記発呼側音声通信端末の送信部へ供給するＳＤＰメッセージ生成部と、
   前記ＳＤＰオファーに記載した前記第１のカテゴリの中から複数のモードが選択されて第２のカテゴリとして記載されるとともに、前記第２のカテゴリに含まれる前記音声コーデックの前記モードの中で最大の帯域幅もしくは最も優先度の高いモードの帯域幅の要求が記載された前記ＳＤＰアンサーの受信処理を行なう制御部と、を有し
   単一のベアラで前記着呼側音声通信端末と接続を行う、
   発呼側処理装置。
6. ＳＩＰメッセージに付加されるＳＤＰオファーおよびＳＤＰアンサーを交換して発呼側音声通信端末との間で接続を行う着呼側音声通信端末で用いられる着呼側処理装置であって、
   前記発呼側音声通信端末から送信された、前記音声コーデックの複数のモードを含む第１のカテゴリが記載された前記ＳＤＰオファーの受信処理を行なう制御部と、
   前記ＳＤＰオファーに記載された前記第１のカテゴリの中から複数のモードを選択して第２のカテゴリとして記載するとともに、前記第２のカテゴリに含まれる前記音声コーデックの前記モードの中で最大の帯域幅もしくは最も優先度の高いモードの帯域幅の要求を記載した前記ＳＤＰアンサーを生成するＳＤＰメッセージ生成部と、を有し、
   単一のベアラで前記着呼側音声通信端末と接続を行う、
   着呼側処理装置。
7. ＳＩＰメッセージに付加されるＳＤＰオファーおよびＳＤＰアンサーを交換して第１の音声通信端末および第２の音声通信端末との間で接続サービスを行う中間ノードであって、
   前記第１の音声通信端末で生成され、音声コーデックの複数のモードを含む第１のカテゴリが記載されたＳＤＰオファーと、前記第２の音声通信端末で生成され、前記ＳＤＰオファーに記載された前記第１のカテゴリの中から複数のモードが選択され第２のカテゴリとして記載された前記ＳＤＰアンサーとを受信する受信部と、
   受信した前記ＳＤＰオファーまたは前記ＳＤＰアンサーを参照して、前記第２のカテゴリに含まれる前記音声コーデックの前記モードの中で最大の帯域幅もしくは最も優先度の高いモードの帯域幅を判断する判断部と、
   前記判断部の判断結果を生成する情報生成部と、
   前記判断結果をネットワークノードに送信する送信部と、
   を有する中間ノード。
8. 着呼側音声通信端末との間で接続を行う発呼側音声通信端末の接続方法であって、
   音声コーデックの複数のモードを含む第１のカテゴリを記載したＳＤＰオファーを生成し、
   前記ＳＤＰオファーを前記着呼側音声通信端末に送信し、
   前記着呼側音声通信端末から、前記ＳＤＰオファーに記載した前記第１のカテゴリの中から複数のモードが選択されて第２のカテゴリとして記載されるとともに、前記第２のカテゴリに含まれる前記音声コーデックの前記モードの中で、最大の帯域幅もしくは最も優先度の高いモードの帯域幅の要求が記載されたＳＤＰアンサーを受信し、
   単一のベアラで前記着呼側音声通信端末と接続を行う、
   接続方法。
9. 発呼側音声通信端末との間で接続を行う着呼側音声通信端末の接続方法であって、
   前記発呼側音声通信端末から、音声コーデックの複数のモードを含む第１のカテゴリが記載された前記ＳＤＰオファーを受信し、
   前記ＳＤＰオファーに記載された前記第１のカテゴリの中から複数のモードを選択して第２のカテゴリとして記載するとともに、前記第２のカテゴリに含まれる前記音声コーデックの前記モードの中で最大の帯域幅もしくは最も優先度の高いモードの帯域幅の要求を記載したＳＤＰアンサーを生成し、
   前記ＳＤＰアンサーを前記発呼側音声通信端末に送信し、
   単一のベアラで前記着呼側音声通信端末と接続を行う、
   接続方法。
10. 請求項８記載の接続方法をプロセッサで実行するためのプログラム。
11. 請求項９記載の接続方法をプロセッサで実行するためのプログラム。

Images