(57)【要約】【課題】アーリーメディアの後に通話メディアを提供するときに、通話メディア開通時の通信を安定させること。【解決手段】リソース確保装置８は、発端末１から着端末４へのセッション確立前に発端末１または着端末４に流すアーリーメディアと、発端末１から着端末４へのセッション確立後に発端末１と着端末４との間で通信される通話メディアとで、それぞれのメディアに要するリソース量を確保するときに、発端末１がＩＮＶＩＴＥ信号で提案したコーデックの候補リストから通話メディアを流すために用いられるコーデックを着端末４が決定する前に、その候補リストに含まれる各コーデックに要するリソース量のうちの最大のリソース量を、通話メディアに要するリソース量としてあらかじめ確保する。【選択図】図２
2017028591.tif 000002
【特許請求の範囲】
【請求項１】
発端末から着端末へのセッション確立前に前記発端末または前記着端末に流すアーリーメディアと、前記発端末から前記着端末へのセッション確立後に前記発端末と前記着端末との間で通信される通話メディアとで、それぞれのメディアに要するリソース量を確保するリソース確保装置であって、
前記それぞれのメディアを流すために用いられるコーデックの候補リストを前記発端末が前記着端末に提案すると、前記着端末が提案された前記候補リストから前記通話メディアを流すために用いられるコーデックを決定する前に、その候補リストに含まれる各コーデックに要するリソース量のうちの最大のリソース量を、前記通話メディアに要するリソース量としてあらかじめ確保することを特徴とする
リソース確保装置。
【請求項２】
前記リソース確保装置は、前記最大のリソース量から、既に確保されている前記アーリーメディアを流すために用いられるリソース量を減じたリソース量を、前記あらかじめ確保するリソース量とすることを特徴とする
請求項１に記載のリソース確保装置。
【請求項３】
前記リソース確保装置は、前記候補リストにおけるメディア種別ごとのコーデックに要するリソース量のうちの最大のリソース量を求め、その求めたリソース量の総和を、前記あらかじめ確保するリソース量とすることを特徴とする
請求項１に記載のリソース確保装置。
【請求項４】
リソース確保装置は、
発端末から着端末へのセッション確立前に前記発端末または前記着端末に流すアーリーメディアと、前記発端末から前記着端末へのセッション確立後に前記発端末と前記着端末との間で通信される通話メディアとで、それぞれのメディアに要するリソース量を確保する処理において、
前記それぞれのメディアを流すために用いられるコーデックの候補リストを前記発端末が前記着端末に提案すると、前記着端末が提案された前記候補リストから前記通話メディアを流すために用いられるコーデックを決定する前に、その候補リストに含まれる各コーデックに要するリソース量のうちの最大のリソース量を、前記通話メディアに要するリソース量としてあらかじめ確保することを特徴とする
リソース確保方法。
【請求項５】
前記リソース確保装置は、前記最大のリソース量から、既に確保されている前記アーリーメディアを流すために用いられるリソース量を減じたリソース量を、前記あらかじめ確保するリソース量とすることを特徴とする
請求項４に記載のリソース確保方法。
【請求項６】
前記リソース確保装置は、前記候補リストにおけるメディア種別ごとのコーデックに要するリソース量のうちの最大のリソース量を求め、その求めたリソース量の総和を、前記あらかじめ確保するリソース量とすることを特徴とする
請求項４に記載のリソース確保方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、リソース確保装置、および、リソース確保方法の技術に関する。
【背景技術】
【０００２】
発端末から着端末に通話などのセッションを確立するためのプロトコルとして、ＳＩＰ（Session Initiation Protocol）が提案されている。
非特許文献１には、ＳＩＰを用いたＩＰ（Internet Protocol）ネットワーク内の基本的な通信手順が記載されている。非特許文献１には、発端末および着端末というユーザ機器と、アプリケーションサーバとが実行するシグナリングフローも例示されている。
【０００３】
発端末から着端末に通話などのセッションを呼び出しているときに、その呼出中状態を発端末に知らせるために、発端末は呼出音を再生させる。この呼出音として、発端末に予め設定されている固定の呼出音を用いる代わりに、機械音声のガイダンスや好みの楽曲の再生音を用いるＣＡＴ（Customized Alerting Tone）が提案されている。
このＣＡＴは、通話セッションの確立前の暫定的なデータ転送で実現されるために、「アーリーメディア」と呼ばれる。一方、「通話メディア」とは、発端末と着端末との間のセッション確立後にend to endで疎通するメディアである。
非特許文献２には、ＣＡＴのアーリーメディアを通信するための具体的なシーケンスやメッセージの内容が記載されている。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】3GPP（3rd Generation Partnership Project）、"Common Basic Communication procedures using IP Multimedia (IM) Core Network (CN) subsystem; Protocol specification"、［online］、V12.3.0 (2014-03)、［平成27年7月21日検索］、インターネット〈URL：http://www.3gpp.org/dynareport/24628.htm〉
【非特許文献２】3GPP（3rd Generation Partnership Project）、"IP Multimedia Subsystem (IMS) Customized Alerting Tones (CAT); Protocol specification"、［online］、V12.3.0 (2014-03)、［平成27年7月21日検索］、インターネット〈URL：http://www.3gpp.org/dynareport/24182.htm〉
【発明の概要】
【発明が解決しようとする課題】
【０００５】
昨今、移動体のアクセスとしてＬＴＥ（Long Term Evolution）の導入が進んでおり、ＬＴＥ上での高品質な音声通信（VoLTE：Voice over LTE）の導入も進んでいる。ＶｏＬＴＥの音声通信の制御にはＳＩＰが利用される。さらに、標準化文書ＲＦＣ（Request for Comments）３３１２やＲＦＣ４０３２に示されるように、ＶｏＬＴＥでは、ＳＩＰの拡張機能であるプリコンディション拡張機能が利用される。
【０００６】
プリコンディション拡張機能では、通話メディアで使用されるコーデックをユーザ端末間で調整して決定した後に、そのコーデックに要するリソース量を確保する。そして、リソース量を確保した後に、通話メディアが開始される。これにより、余分なリソースを確保しなくて済むので、リソース量の節約ができる。
一方、プリコンディション拡張機能では、アーリーメディアに要するリソース量よりも通話メディアに要するリソース量のほうが多い場合、その不足分のリソース量を再度確保するために、そのリソース量を確保するまでに、通話メディアの開始が遅れたり、通話メディアの冒頭に話頭切れが発生したりしてしまう。
【０００７】
そこで、本発明は、アーリーメディアの後に通話メディアを提供するときに、通話メディア開通時の通信を安定させることを、主な課題とする。
【課題を解決するための手段】
【０００８】
前記課題を解決するために、本発明は、
発端末から着端末へのセッション確立前に前記発端末または前記着端末に流すアーリーメディアと、前記発端末から前記着端末へのセッション確立後に前記発端末と前記着端末との間で通信される通話メディアとで、それぞれのメディアに要するリソース量を確保するリソース確保装置であって、
前記それぞれのメディアを流すために用いられるコーデックの候補リストを前記発端末が前記着端末に提案すると、前記着端末が提案された前記候補リストから前記通話メディアを流すために用いられるコーデックを決定する前に、その候補リストに含まれる各コーデックに要するリソース量のうちの最大のリソース量を、前記通話メディアに要するリソース量としてあらかじめ確保することを特徴とする。
【０００９】
これにより、たとえ着端末が最高品質のコーデックを選択した場合でも、通話メディアに要するリソース量が不足しなくなる。さらに、着端末がコーデックを決定する前という早い段階であらかじめ充分なリソース量を確保することにより、セッション確立後すぐに通話メディアを開始できるため、話頭切れを解消できる。
【００１０】
本発明は、前記リソース確保装置が、前記最大のリソース量から、既に確保されている前記アーリーメディアを流すために用いられるリソース量を減じたリソース量を、前記あらかじめ確保するリソース量とすることを特徴とする。
【００１１】
これにより、アーリーメディア用のリソース量が既に確保されているが、通話メディア用のリソース量には不足する場合でも、あらかじめ充分なリソース量を確保することにより、話頭切れを解消できる。
【００１２】
本発明は、前記リソース確保装置が、前記候補リストにおけるメディア種別ごとのコーデックに要するリソース量のうちの最大のリソース量を求め、その求めたリソース量の総和を、前記あらかじめ確保するリソース量とすることを特徴とする。
【００１３】
これにより、１つのセッションで、映像メディアと音声メディアとを別々のコーデックで流すような複雑な場合でも、あらかじめ適切なリソース量を確保することにより、話頭切れを解消できる。
【発明の効果】
【００１４】
本発明によれば、アーリーメディアの後に通話メディアを提供するときに、通話メディア開通時の通信を安定させることができる。
【図面の簡単な説明】
【００１５】
【図１】図１（ａ）は、アーリーメディア用のパスの開通前の状態を示す。図１（ｂ）は、アーリーメディア用のパスの開通後の状態を示す。
【図２】図２（ａ）は、図１で説明したアーリーメディアパスを開通するときに実行される、プリコンディション拡張機能におけるリソース確保処理を示す。図２（ｂ）は、本実施形態におけるリソース確保処理を示す。
【図３】図２（ａ）におけるアーリーメディアの送信前処理を示すシーケンス図である。
【図４】図２（ａ）におけるアーリーメディアを送信して通話メディアを開始する処理を示すシーケンス図である。
【図５】図２（ｂ）におけるアーリーメディアの送信前処理を示すシーケンス図である。
【図６】図２（ｂ）におけるアーリーメディアを送信して通話メディアを開始する処理を示すシーケンス図である。
【図７】リソース確保システムでやりとりされるＳＩＰリクエスト／ＳＩＰレスポンスの概要を示すシーケンス図である。
【図８】図７の各メッセージと、ＳＩＰメッセージ種別との対応表である。
【発明を実施するための形態】
【００１６】
以下、本発明の一実施形態について、図面を参照して詳細に説明する。
【００１７】
図１（ａ）は、アーリーメディア用のパスの開通前の状態を示す。
発端末１は、これから通話（セッション）を開始したいユーザが操作する端末である。着端末４は、発端末１からの開始要求のあて先となるユーザが操作する端末である。中継装置２は、発端末１と着端末４との間でやりとりされる、ＳＩＰの各メッセージを転送する。
なお、図１（ａ）などの各図に示すリソース確保システムの各装置は、ＣＰＵ（Central Processing Unit）と、メモリと、ハードディスクなどの記憶手段（記憶部）と、ネットワークインタフェースとを有するコンピュータとして構成され、このコンピュータは、ＣＰＵが、メモリ上に読み込んだプログラム（アプリケーションや、その略のアプリとも呼ばれる）を実行することにより、後記する各処理部により構成される制御部（制御手段）を動作させる。
【００１８】
中継装置２は、例えば、ＳＩＰ−ＡＬＧ（Application Layer Gateway）を含むＭＧＷ（Media Gateway）として構成される。このＳＩＰ−ＡＬＧは、例えば、ＩＢＣＦ（Interconnection Border Control Function）、Ｐ−ＣＳＣＦ（Proxy-Call Session Control Function）またはＳ−ＣＳＣＦ（Serving-Call Session Control Function）として実現される。
【００１９】
以下が、ＳＩＰメッセージで使用される表現である。
「〜信号」の表現（ＩＮＶＩＴＥ信号、ＰＲＡＣＫ信号、ＵＰＤＡＴＥ信号、ＡＣＫ信号）は、それぞれＳＩＰのリクエストを示す。
「Ｎ応答（Ｎ＝３桁の数値）」の表現（１８０応答、１８３応答、２００応答）は、それぞれＳＩＰのレスポンスを示す。Ｎ＝１００番台は処理中の暫定応答であり、Ｎ＝２００番台は、処理が完了したことを示す最終回答である。
これらのＳＩＰのリクエスト／レスポンスの詳細は、ＲＦＣ３２６１として公開されている。また、各ＳＩＰメッセージには、そのＳＩＰメッセージで確立しようとする各メディア（アーリーメディア、通話メディア）についての説明が記述されたＳＤＰ（Session Description Protocol）が付加されていることもある。このＳＤＰの詳細は、ＲＦＣ４５６６として公開されている。
【００２０】
発端末１が作成したＩＮＶＩＴＥ信号（詳細は、図２）を受信した中継装置２は、そのＩＮＶＩＴＥ信号を着端末４に転送する。このＩＮＶＩＴＥ信号には、発端末１がアーリーメディアをサポートする旨の「P-Early-Media: supported」が含まれている。
このＩＮＶＩＴＥ信号を転送する初期状態では、着端末４から発端末１へ向かう方向（下り方向）のアーリーメディアパスを開通しないため、中継装置２は、下り方向のアーリーメディアのＲＴＰ（Real-time Transport Protocol）パケットを通過させない。なお、下り方向は、ＩＮＶＩＴＥ信号内のＳＤＰのc=行アドレスで指定される。
【００２１】
図１（ｂ）は、アーリーメディア用のパスの開通後の状態を示す。
着端末４は、ＩＮＶＩＴＥ信号への暫定応答として、処理中を示す１８３応答（詳細は、図２）を発端末１に送信する。ＲＦＣ５００９では、１８３応答などの暫定応答（１８ｘ応答：ｘ＝０〜９）にP-Early-Mediaヘッダフィールドを付与する旨が規定されている。
その１８３応答を受信した中継装置２は、１８３応答に含まれる「P-Early-Media: sendrecv」を参照し、上り（send）下り（recv）の両方向のアーリーメディアがサポートされていることを認識する。そして、中継装置２は、図１（ａ）で開通しなかったアーリーメディアパスを開通させることで、アーリーメディアのＲＴＰパケットを通過させる。
なお、アーリーメディアパスは、片方向のみの開通指定も可能であり、例えば、「sendrecv」の代わりに、上りのみ可（sendonly）、または、下りのみ可（recvonly）を用いてもよい。
これにより、セッション確立前の非課金状態あっても、アーリーメディアを介して発端末１や着端末４にガイダンスを流すなどの暫定的な通信を行うことができるので、ユーザ間の不正な通話を防ぎ、網で認可されたメディアのみ疎通させることができる。
【００２２】
図２（ａ）は、図１で説明したアーリーメディアパスを開通するときに実行される、プリコンディション拡張機能におけるリソース確保処理を示す。
この図２（ａ）のシステムでは、図１の発端末１、着端末４に加え、中継装置２であるＰ−ＣＳＣＦ９１ａと、課金制御ルールなどのポリシを決定するポリシ制御装置（ＰＣＲＦ：Policy and Charging Rule Function）９２と、メディアデータを転送するＳ／Ｐ−ＧＷ９３も含めて構成される。
なお、Ｓ／Ｐ−ＧＷ９３は、Ｓ−ＧＷ（Serving Gateway）およびＰ−ＧＷ（Packet data network Gateway）の総称である。
【００２３】
Ｐ−ＣＳＣＦ９１ａは、ＩＮＶＩＴＥ信号への１８３応答を受信すると（Ｓ１１）、Ｐ−ＣＳＣＦ９１ａに対して、Ｓ／Ｐ−ＧＷ９３が転送するアーリーメディア用のリソースの確保を指示する（Ｓ１２，破線矢印）。
発端末１は、Ｓ１２のリソース確保が完了するのを待ってから（換言すると、プリコンディション拡張機能に従って前準備が整うのを確認してから）、アーリーメディアの転送を指示するＵＰＤＡＴＥ信号を着端末４に向けて送信する（Ｓ１３）。
具体的には、発端末１は、着端末４から送信された１８０応答（図示省略）のＳＤＰのメッセージを参照することで、Ｓ１２で確保されたリソースを用いたアーリーメディアパス（ベアラ）が開通したことを確認できる。
【００２４】
図２（ｂ）は、本実施形態におけるリソース確保処理を示す。図２（ｂ）では、中継装置２としてＰ−ＣＳＣＦ９１ａの代わりに、Ｓ−ＣＳＣＦ９１ｂを用いている。
Ｓ１１，Ｓ１２は、図２（ａ）で説明したとおりである。これにより、アーリーメディア用のリソースが確保される。
Ｓ２１において、１８３応答を受信した発端末１は、発端末１−着端末４間の通話メディア用のリソースも前もって確保するように、ＰＣＲＦ９２からＳ／Ｐ−ＧＷ９３に指示する（Ｓ２２、破線矢印）。そして、発端末１は、Ｓ１３と同様に、ＵＰＤＡＴＥ信号をＳ−ＣＳＣＦ９１ｂに送信する（Ｓ２３）。
これにより、通話メディア用のリソースが早い段階（アーリーメディア送信前）で確保されるので、通話メディアの開始前に通話メディア用のリソース確保で待たされることが無くなり、早期に通話を開始できる。
【００２５】
以上、図２（ａ）で説明したリソース確保処理の詳細な具体例を図３、図４で説明し、図２（ｂ）で説明したリソース確保処理の詳細な具体例を図５、図６で説明することで、両方のリソース確保処理の違いをより明らかにする。
【００２６】
図３は、アーリーメディアの送信前処理を示すシーケンス図である。この図３および図４の各シーケンス図は、非特許文献２のＡ．５．３節を参考に作成したゲートウェイモデルのＣＡＴ提供時のシーケンス例である。
【００２７】
アプリケーションサーバ３は、発端末１と着端末４との間のセッション確立の調整役（Ｂ２ＢＵＡ：Back-to-Back User Agent）である。つまり、アプリケーションサーバ３が無いときには、ＳＩＰのリクエストの送信側（ＵＡＣ：User Agent Client）である発端末１が、ＳＩＰのリクエストの受信側（ＵＡＳ：User Agent Server）である着端末４と直接ＳＩＰのメッセージをやりとりする。
一方、アプリケーションサーバ３が存在するときには、発端末１にとってのＵＡＳは着端末４からアプリケーションサーバ３に代行され、着端末４にとってのＵＡＣは発端末１からアプリケーションサーバ３に代行される。
よって、図３以降の各シーケンス図において、発端末１と着端末４とでやりとりされるＳＩＰのメッセージが（遠回りであっても）アプリケーションサーバ３を経由するのは、アプリケーションサーバ３がＢ２ＢＵＡとして機能しているためである。
【００２８】
さらに、アプリケーションサーバ３は、ＣＡＴ−ＡＳ（Customized Alerting Tone−Application Server）として、ＣＡＴのアーリーメディア（専用呼出音）を発端末１に提供する。このアーリーメディアのコーデックには、例えば、狭帯域のＡＭＲ−ＮＢ（Adaptive Multi-Rate Narrowband）が使われる。一方、発端末１−着端末４間の通話メディアのコーデックには、例えば、ＡＭＲ−ＮＢより広帯域のＡＭＲ−ＷＢ（Adaptive Multi-Rate Wideband）が使われる。つまり、通話メディアはアーリーメディアよりも多くのリソース（帯域などの通信資源）を必要とする。
以下、図３のシーケンス図について、アーリーメディア用のリソースも、通話メディア用のリソースも確保していない初期状態から開始する。
【００２９】
Ｓ１１１として、発端末１は、着端末４との通話を要求する旨のＩＮＶＩＴＥ信号を、中継装置２を経由してアプリケーションサーバ３に送信する。このＩＮＶＩＴＥ信号には、発端末１がアーリーメディアに対応可能なことを示す「P-Early-Media:supported」のＳＩＰ行と、発端末１がサポートするコーデックのリストを示すＳＤＰが含まれる。現時点ではリソース確保前なので、ＳＤＰ内のコーデックは無効状態である。
【００３０】
Ｓ１１２として、アプリケーションサーバ３は、Ｓ１１１のＩＮＶＩＴＥ信号を受け、アーリーメディア（ＣＡＴ）のためのリソース確保（ＡＭＲ−ＮＢが要する分のリソース確保）を、リソースを管理する装置（ＰＣＲＦ９２）に指示する。
Ｓ１１３として、アプリケーションサーバ３は、Ｓ１１１のＩＮＶＩＴＥ信号を、中継装置２を経由して着端末４に転送する。
【００３１】
Ｓ１１４として、着端末４は、Ｓ１１３のＩＮＶＩＴＥ信号への応答として、そのＩＮＶＩＴＥ信号を処理中であることを示す１８３応答を、中継装置２を経由してアプリケーションサーバ３に送信する。１８３応答には、送受信可能なアーリーメディア用のパス開通を要求する旨の「P-Early-Media:sendrecv」のＳＩＰ行と、アーリーメディア用のコーデックの候補であるコーデックのリストを示すＳＤＰが含まれる。
Ｓ１１５として、アプリケーションサーバ３は、Ｓ１１４の１８３応答を、中継装置２を経由して発端末１に送信する。ここで、Ｓ１１５の１８３応答内のＳＤＰは、Ｓ１１４の１８３応答内のコーデックのリストから選択された、アーリーメディア用のコーデックへと置き換わる。
【００３２】
Ｓ１２１として、発端末１は、Ｓ１１５の１８３応答への返事であるＰＲＡＣＫ信号を、アプリケーションサーバ３を経由して着端末４に送信する。このＰＲＡＣＫ信号により着端末４は、１８３応答が発端末１に届いたことを知ることができるので、Ｓ１１４の１８３応答を繰り返し送信する必要がなくなる。
Ｓ１２２として、着端末４は、Ｓ１２１のＰＲＡＣＫ信号への応答である２００応答を、アプリケーションサーバ３を経由して発端末１に送信する。
【００３３】
Ｓ１２３として、発端末１は、Ｓ１１２のリソース確保処理が完了したことで、アーリーメディア（ＣＡＴ）用のリソースが利用可能であることを知る。この時点で、アーリーメディア用のコーデックは利用可能である。
Ｓ１３１として、発端末１は、アーリーメディア用のリソースが確保できたこと（Ｓ１２３）を伝えるためのＵＰＤＡＴＥ信号を、中継装置２を経由してアプリケーションサーバ３に送信する。
Ｓ１３２として、アプリケーションサーバ３は、Ｓ１３１のＵＰＤＡＴＥ信号を、中継装置２を経由して着端末４に転送する。
Ｓ１３３として、着端末４は、Ｓ１３２のＵＰＤＡＴＥ信号を受け、自身の呼出音を鳴らす。
【００３４】
Ｓ１３４として、着端末４は、Ｓ１３２のＵＰＤＡＴＥ信号への２００応答を、中継装置２を経由してアプリケーションサーバ３に送信する。２００応答内のＳＤＰには、ＳＩＰのセッション確立後に使用されるメディア（以下、通話メディア）のコーデックの種別ごとに、そのコーデックに要するリソース量の情報が含まれる。
つまり、着端末４は、Ｓ１１３のＩＮＶＩＴＥ信号で提案された発端末１が通話メディアで使用したいコーデックのリストから、自身が使用可能な（または使用を希望する）コーデックを選択して、その選択したコーデックをＳ１３４の２００応答を介して発端末１に向けて通知する。
【００３５】
Ｓ１３５として、アプリケーションサーバ３は、Ｓ１３４の２００応答を、中継装置２を経由して発端末１に送信する。
Ｓ１３６として、着端末４は、自身の呼び出し音を鳴らしている旨（Ringing）を示す１８０応答を、中継装置２を経由してアプリケーションサーバ３に送信する。
【００３６】
図４は、図３の処理の続きとして、アーリーメディアを送信して通話メディアを開始する処理を示すシーケンス図である。
Ｓ１６１として、アプリケーションサーバ３は、Ｓ１３６の１８０応答を受け、発端末１へのアーリーメディアであるＣＡＴ（Ｓ１６２）の開始をＳ／Ｐ−ＧＷ９３に指示する。
Ｓ１６３として、アプリケーションサーバ３は、Ｓ１１１のＩＮＶＩＴＥ信号への暫定応答であるＳ１３６の１８０応答を、中継装置２を経由して発端末１に送信する。
【００３７】
Ｓ１６４として、着端末４は、Ｓ１３３の呼出音への応答（受話器を取る、通話開始ボタンを押すなど）を検知する。
Ｓ１６５として、着端末４は、Ｓ１６４の応答を受けて最終的な応答信号である２００応答を、中継装置２を経由してアプリケーションサーバ３に送信する。
Ｓ１６６として、アプリケーションサーバ３は、Ｓ１６５の２００応答を受け、発端末１に呼び出し音を聞かせる必要がなくなったので、Ｓ１６２のアーリーメディア（ＣＡＴ）を終了する。
【００３８】
Ｓ１７１として、アプリケーションサーバ３は、アーリーメディアから通話メディアへの切替を促すＵＰＤＡＴＥ信号を、中継装置２を経由して発端末１に送信する。このＵＰＤＡＴＥ信号内のＳＤＰには、すでに受信したＳ１３４の２００応答に含まれていた、セッション確立後に使用されるコーデックが含まれる。
Ｓ１７２として、発端末１は、Ｓ１７１の２００応答で指定された通話メディアのコーデックに要するリソースが、Ｓ１２３で利用可能になったアーリーメディア用のリソースだけでは不足することを検知する。そこで、発端末１は、不足分のリソース（ＡＭＲ−ＷＢが要するリソースからＡＭＲ−ＮＢが要するリソースを減じた差分量）を新たに確保し、Ｓ１７３に処理を進める。この新たにリソースを確保する処理は、Ｓ１８１で実際に確保完了となる。
Ｓ１７３として、発端末１は、アーリーメディアから通話メディアへの切替に同意する旨の、Ｓ１７１のＵＰＤＡＴＥ信号への２００応答を、中継装置２を経由してアプリケーションサーバ３に送信する。
【００３９】
Ｓ１７４として、アプリケーションサーバ３は、Ｓ１１１のＩＮＶＩＴＥ信号への２００応答を、中継装置２を経由して発端末１に送信する。
Ｓ１７５として、発端末１は、Ｓ１７４の２００応答に対する最終回答であるＡＣＫ信号を、アプリケーションサーバ３を経由して着端末４に送信する。
【００４０】
Ｓ１８１として、発端末１は、Ｓ１７２のリソース確保が完了し、通話メディアが利用可能になる。この利用可能になるまでの期間には、リソース不足により通話メディア用のパス確立が安定しない（場合によっては、パスの疎通ができない）ので、話頭切れが発生してしまう。
Ｓ１８２として、発端末１は、Ｓ１８１で利用可能になった通話メディアを介して、着端末４との通話を行う。
【００４１】
以上説明したように、Ｓ１７２の段階でＡＭＲ−ＷＢが要するリソースを確保するのは、ＳＩＰプリコンディション拡張機能の技術思想によるものである。ＳＩＰプリコンディション拡張機能とは、所定の前提条件（precondition）を満たしてはじめて、セッション確立を行ってＳ１８２の通話メディアを利用可能にする機能である。
ＶｏＬＴＥ（Voice over Long Term Evolution）では、実際に必要となるまでは事前にリソースを割り当てないことで、通信資源を節約して利用効率を高める。よって、通話メディア用のコーデックが確定するという前提条件を満たす段階として、Ｓ１７１のＵＰＤＡＴＥ信号内のＳＤＰから通話メディア用のコーデックを参照できるタイミングで、発端末１は、通話メディア用のリソースを確保できる（Ｓ１７２）。
一方、Ｓ１８１で前記したように、ＳＩＰプリコンディション拡張機能による副作用として、話頭切れが発生してしまい、発端末１のユーザと、着端末４のユーザ双方に不便を強いてしまう。
【００４２】
図５は、本実施形態における、アーリーメディアの送信前処理を示すシーケンス図である。図５と図３とでは、大まかには同じ符号を用いた同じ処理が記載されている。以下、図３との違いに着目して図５の処理を説明する。
まず、発端末１は、Ｓ１１１のＩＮＶＩＴＥ信号を送信するときに、そのＩＮＶＩＴＥ信号のSDP offerのm=行に記載したコーデックのリスト、つまり、これからアーリーメディアや通話メディアで使用するものとして着端末４に対して提案したコーデックの候補を、自身の記憶手段に保持しておく（Ｓ１１１ａ）。
アプリケーションサーバ３は、Ｓ１１５で送信する１８３応答に対して、「sendrecv」または「sendonly」が設定されたP-Early-Mediaヘッダを設定（付加）する（Ｓ１１５ａ）。
【００４３】
発端末１は、このＳ１１５ａで付加されたP-Early-Mediaヘッダが１８３応答に含まれていたときに、Ｓ１１１ａで保持したコーデックの候補をもとに、アーリーメディアだけでなく通話メディアで必要なリソースを確保する（Ｓ１１６）。前記したように、Ｓ１１６のリソース確保の命令は、図２（ｂ）のＳ２２としてＰＣＲＦ９２に通知され、その結果としてリソースが利用可能になる（Ｓ１２３ａ）。
【００４４】
なお、Ｓ１１２でアーリーメディア用のリソース量を確保する処理を省略し、発端末１（リソース確保装置として動作）は、Ｓ１１６でアーリーメディア用のリソース量と、通話メディア用のリソース量とをまとめて１回で確保してもよい。
または、アプリケーションサーバ３（リソース確保装置として動作）は、Ｓ１１２でアーリーメディア用のリソース量を確保する処理において、アーリーメディア用のリソース量と、通話メディア用のリソース量とをまとめて１回で確保することで、Ｓ１１６の処理を省略してもよい。
【００４５】
以下が、Ｓ１１６で確保するリソース量の計算式の一例である。なお、コーデックごとのリソース量は、例えば、各SDP offerのm=行が示すコーデックについて、そのm=行の付近に記載された、最大帯域を示すSDPのb=AS行から特定できる。または、予めコーデックごとのリソース量を、管理者などが事前入力しておいてもよい。
【００４６】
（計算式１）各Ｓ１１１ａで保持した各コーデックが要するリソース量のうち、最大のリソース量（最大帯域など）をＳ１１６で確保する。
（計算式２）各Ｓ１１１ａで保持した各コーデックが要するリソース量のうち、最大のリソース量（最大帯域など）を求め、その最大のリソース量から、Ｓ１１２で既に確保したアーリーメディア用のリソース量を減じたリソース量（つまり、通話メディア用のリソース不足分）をＳ１１６で確保する。
（計算式３）各Ｓ１１１ａで保持した各コーデックが要するリソース量をあらかじめメディア種別ごと（映像ごと、音声ごと、文字ごとなど）に分類しておく。そして、メディア種別ごとの最大のリソース量（最大帯域など）を求め、その最大のリソース量の総和をＳ１１６で確保する。この（計算式３）は、１つのセッション（通話メディア）に対して、複数のメディア（映像メディア、音声メディア）が別々のコーデックで同時に利用される事象を反映したものである。
なお、（計算式１）〜（計算式３）で（最大の）リソース量が確保されるリソースとは、帯域などの通信資源の他にも、通信装置のＣＰＵ資源やメモリ資源などを確保対象としてもよい。
【００４７】
例えば、Ｓ１１１のＩＮＶＩＴＥ信号で、以下のコーデックが提案されていたとする。
アーリーメディア用のコーデック：1[Mbps]
通話メディア用の映像コーデック：10[Mbps] 20[Mbps] 50[Mbps]
通話メディア用の音声コーデック：2[Mbps] 5[Mbps]
以下のように、Ｓ１１６で確保するリソース量は、各計算式で異なる。
（計算式１）では、50[Mbps]
（計算式２）では、50-1=49[Mbps]
（計算式３）では、50+5=55[Mbps]
【００４８】
図６は、本実施形態における、アーリーメディアを送信して通話メディアを開始する処理を示すシーケンス図である。図６と図４とでは、大まかには同じ符号を用いた同じ処理が記載されている。以下、図４との違いに着目して図６の処理を説明する。
【００４９】
まず、Ｓ１７１のＵＰＤＡＴＥ信号を受信したときには、発端末１は、図４のＳ１７２のようなリソース不足は発生しないので、すぐにＳ１７３の２００応答を送信できる。これは、図５のＳ１２３ａで通話メディア用のリソースが既に確保されて利用可能になっているからである。
そして、発端末１は、Ｓ１７５のＡＣＫ信号を送信して、ＳＩＰのセッション確立処理を完了したときには、図４のＳ１８１のような話頭切れが発生することがないので、すぐにＳ１８２の通話メディアを開始することができ、ユーザエクスペリエンスが向上する。これも、図５のＳ１２３ａで通話メディア用のリソースが既に確保されて利用可能になっているからである。
【００５０】
図７は、リソース確保システムでやりとりされるＳＩＰリクエスト／ＳＩＰレスポンスの概要を示すシーケンス図である。
発側ＵＡＣ８１（発端末１）は、ＵＡＳ８２との間でＳＩＰメッセージをやりとりする。
着側ＵＡＳ８４は、ＵＡＣ８３との間でＳＩＰメッセージをやりとりする。
リソース確保装置８は、ＵＡＳ８２とＵＡＣ８３とを有するＢ２ＢＵＡ（Back-to-Back User Agent）として動作する。リソース確保装置８は、中継装置２、ＰＣＲＦ９２、または、発端末１−中継装置２間に設置されるＳＢＣ（Session Border Controller）である。
【００５１】
発側ＵＡＣ８１が生成する第１ＳＩＰリクエストへの応答として、着側ＵＡＳ８４（アプリケーションサーバ３）が生成し、リソース確保装置８が再構成する第２ＳＩＰレスポンスが送信される。
そして、リソース確保処理の後、発側ＵＡＣ８１が生成する第３ＳＩＰリクエストへの応答として、着側ＵＡＳ８４（アプリケーションサーバ３）が生成し、リソース確保装置８が再構成する第４ＳＩＰレスポンスが送信される。
さらに、着側ＵＡＳ８４（着端末４）が生成する第５ＳＩＰリクエストへの応答として、発側ＵＡＣ８１が生成する第６ＳＩＰレスポンスが送信される。
【００５２】
図８は、図７の各メッセージと、ＳＩＰメッセージ種別との対応表である。各ＳＩＰメッセージに含まれるＳＤＰの第１パターンまたは第２パターンのいずれかに従って、各メッセージ種別のＳＩＰメッセージ（図７の第１ＳＩＰリクエスト〜第６ＳＩＰレスポンス）が生成される。
【００５３】
なお、図８の表内の斜線（／）欄（第２パターンのUPDATEと200 OKの欄）は、ＳＩＰメッセージ自体が作成されないことを示す。また、図８の表内の横線（−）欄（100 Tryingの欄など）は、ＳＩＰメッセージは作成されるものの、そのＳＩＰメッセージにＳＤＰの設定が含まれていないことを示す。
例えば、図７の第３リクエストについて、第１パターンを採用するときにはＵＰＤＡＴＥ信号となり、第２パターンを採用するときにはＰＲＡＣＫ信号となる。
【００５４】
以上説明した本実施形態では、アーリーメディアより通話メディアの方がより多くのリソースを必要とする場合、図５のＳ１１４で示したように、ＩＮＶＩＴＥ信号への１８３応答（Ｓ１１５）を受信した発端末１が、アーリーメディアの開始前に、そのアーリーメディアに要するリソースだけでなく、通話メディアに要するリソースも前もって予約しておく（Ｓ１１６）。
しかし、発端末１が着端末４から通話メディアのコーデック（必要なリソース量）を知らされるタイミングは、Ｓ１１５よりもずっと後のＳ１７１（ＵＰＤＡＴＥ信号）である。
そこで、発端末１は、前記の（計算式１）〜（計算式３）で例示したように、Ｓ１１１ａで保持したコーデックの候補をもとに、必要なリソース量が最大（最悪）になってもいいように、多めのリソース量を予め確保しておく。これにより、Ｓ１８１の話頭切れを解消できる。
【符号の説明】
【００５５】
１      発端末
２      中継装置
３      アプリケーションサーバ
４      着端末
８      リソース確保装置
８１    発側ＵＡＣ
８２    ＵＡＳ
８３    ＵＡＣ
８４    着側ＵＡＳ
９１ａ  Ｐ−ＣＳＣＦ
９１ｂ  Ｓ−ＣＳＣＦ
９２    ＰＣＲＦ
９３    Ｓ／Ｐ−ＧＷ
【図１】
2017028591.tif 000003
【図２】
2017028591.tif 000004
【図３】
2017028591.tif 000005
【図４】
2017028591.tif 000006
【図５】
2017028591.tif 000007
【図６】
2017028591.tif 000008
【図７】
2017028591.tif 000009
【図８】
2017028591.tif 000010