知財求人 - 知財ポータルサイト「IP Force」
特許6593525アーリメディアサービス制御装置、アーリメディアサービス制御方法及びプログラム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】6593525
(24)【登録日】2019年10月4日
(45)【発行日】2019年10月23日
(54)【発明の名称】アーリメディアサービス制御装置、アーリメディアサービス制御方法及びプログラム
(51)【国際特許分類】
H04M 3/00 20060101AFI20191010BHJP
H04L 12/70 20130101ALI20191010BHJP
H04L 29/06 20060101ALI20191010BHJP
【ＦＩ】
H04M3/00 B
H04L12/70 A
H04L13/00 305B
【請求項の数】8
【全頁数】31
(21)【出願番号】特願2018-503061(P2018-503061)
(86)(22)【出願日】2017年2月21日
(86)【国際出願番号】JP2017006399
(87)【国際公開番号】WO2017150281
(87)【国際公開日】20170908
【審査請求日】2018年8月6日
(31)【優先権主張番号】特願2016-38277(P2016-38277)
(32)【優先日】2016年2月29日
(33)【優先権主張国】JP
(73)【特許権者】
【識別番号】000004237
【氏名又は名称】日本電気株式会社
(74)【代理人】
【識別番号】100109313
【弁理士】
【氏名又は名称】机 昌彦
(74)【代理人】
【識別番号】100124154
【弁理士】
【氏名又は名称】下坂 直樹
(72)【発明者】
【氏名】晒谷 光一
【審査官】
石井 則之
(56)【参考文献】
【文献】
特開２０１５−４３５１１（ＪＰ，Ａ）
【文献】
特開２０１５−１６２８２７（ＪＰ，Ａ）
【文献】
Qualcomm Incorporated，Interaction between early media generated by UE and P-Early-Media header field[online]， 3GPP TSG-CT WG1#94 C1-153455，２０１５年１０月 ３日
(58)【調査した分野】（Int.Cl.，ＤＢ名）
Ｈ０４Ｂ ７／２４−７／２６
Ｈ０４Ｌ １２／００−１２／２８
１２／４４−１２／９５５
１３／００−１３／１８
２９／００−２９／１２
Ｈ０４Ｍ ３／００
３／１６−３／２０
３／３８−３／５８
７／００−７／１６
１１／００−１１／１０
Ｈ０４Ｗ ４／００−９９／００
３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１−４
ＳＡ ＷＧ１−４
ＣＴ ＷＧ１、４
(57)【特許請求の範囲】
【請求項1】
通信手段と、
呼び出し中通知受信を要件の１つとしてアーリメディアのサービス実行を開始するアーリメディア方式のセッション開始要求発側端末装置が送信し前記通信手段が受信したセッション開始要求に含まれ、前記セッション開始要求発側端末装置のリソース予約状況を示すパラメータの値が、予約済みを示す値か否かを判定するリソース予約状況判定手段と、
前記リソース予約状況判定手段が、前記パラメータの値が予約済みを示す値であると判定した場合、当該パラメータの値をリソース未予約を示す値に書き換えるパラメータ値書換手段と、
前記リソース予約状況判定手段が、前記パラメータの値が予約済みを示す値であると判定した場合、前記パラメータ値書換手段がパラメータの値を書き換えたセッション開始要求をセッション開始要求着側ネットワークへ送信するよう前記通信手段を制御し、前記リソース予約状況判定手段が、前記パラメータの値が予約済みを示す値でないと判定した場合、前記セッション開始要求発側端末装置から受信したセッション開始要求をセッション開始要求着側ネットワークへ送信するよう前記通信手段を制御するセッション開始要求送信制御手段と、
前記通信手段が前記セッション開始要求着側ネットワークへ送信した前記セッション開始要求に対して送信され、セッション開始要求着側端末装置におけるリソース予約済みを示す応答を前記通信手段が受信した場合、前記呼び出し中通知を前記セッション開始要求発側端末装置へ送信するよう前記通信手段を制御する呼び出し中通知送信制御手段とを備えるアーリメディアサービス制御装置。
呼び出し中通知受信を要件の１つとしてアーリメディアのサービス実行を開始するアーリメディア方式のセッション開始要求発側端末装置が送信し前記通信手段が受信したセッション開始要求に含まれ、前記セッション開始要求発側端末装置のリソース予約状況を示すパラメータの値が、予約済みを示す値か否かを判定するリソース予約状況判定手段と、
前記リソース予約状況判定手段が、前記パラメータの値が予約済みを示す値であると判定した場合、当該パラメータの値をリソース未予約を示す値に書き換えるパラメータ値書換手段と、
前記リソース予約状況判定手段が、前記パラメータの値が予約済みを示す値であると判定した場合、前記パラメータ値書換手段がパラメータの値を書き換えたセッション開始要求をセッション開始要求着側ネットワークへ送信するよう前記通信手段を制御し、前記リソース予約状況判定手段が、前記パラメータの値が予約済みを示す値でないと判定した場合、前記セッション開始要求発側端末装置から受信したセッション開始要求をセッション開始要求着側ネットワークへ送信するよう前記通信手段を制御するセッション開始要求送信制御手段と、
前記通信手段が前記セッション開始要求着側ネットワークへ送信した前記セッション開始要求に対して送信され、セッション開始要求着側端末装置におけるリソース予約済みを示す応答を前記通信手段が受信した場合、前記呼び出し中通知を前記セッション開始要求発側端末装置へ送信するよう前記通信手段を制御する呼び出し中通知送信制御手段とを備えるアーリメディアサービス制御装置。
【請求項2】
セッション開始要求発側ネットワーク及びセッション開始要求発側端末装置、セッション開始要求着側ネットワーク及びセッション開始要求着側端末装置がいずれもリソース予約有無の通知の規定に対応しているか否かを前記通信手段の受信信号に基づいて判定するサポート判定手段と、
前記サポート判定手段が、セッション開始要求発側ネットワーク及びセッション開始要求発側端末装置、セッション開始要求着側ネットワーク及びセッション開始要求着側端末装置の少なくともいずれかがリソース予約有無の通知の規定に対応していないと判定した場合、セッション開始要求に対する応答にセッション開始要求着側ネットワークがアーリメディアに対応していることを示すアーリメディア対応情報が含まれるか否かを判定するアーリメディア対応判定手段と、
前記アーリメディア対応判定手段が、前記応答に前記アーリメディア対応情報が含まれると判定した後、前記セッション開始要求着側ネットワークからリクエスト正常処理完了を示す処理完了信号を前記通信手段が受信したか否かを判定する処理完了判定手段と、
前記処理完了判定手段が、前記処理完了信号を前記通信手段が受信したと判定した場合、呼び出し中通知受信を要件の１つとしてアーリメディアのサービス実行を開始するアーリメディア方式のセッション開始要求発側端末装置に前記呼び出し中通知を送信するよう前記通信手段を制御する呼び出し中通知送信制御手段とを備え、
前記リソース予約状況判定手段は、前記サポート判定手段が、セッション開始要求発側ネットワーク及びセッション開始要求発側端末装置、セッション開始要求着側ネットワーク及びセッション開始要求着側端末装置がいずれもリソース予約有無の通知の規定に対応していると判定した場合、前記セッション開始要求発側端末装置が送信し前記通信手段が受信したセッション開始要求に含まれ、前記セッション開始要求発側端末装置のリソース予約状況を示すパラメータの値が、予約済みを示す値か否かを判定する、
請求項１に記載のアーリメディアサービス制御装置。
前記サポート判定手段が、セッション開始要求発側ネットワーク及びセッション開始要求発側端末装置、セッション開始要求着側ネットワーク及びセッション開始要求着側端末装置の少なくともいずれかがリソース予約有無の通知の規定に対応していないと判定した場合、セッション開始要求に対する応答にセッション開始要求着側ネットワークがアーリメディアに対応していることを示すアーリメディア対応情報が含まれるか否かを判定するアーリメディア対応判定手段と、
前記アーリメディア対応判定手段が、前記応答に前記アーリメディア対応情報が含まれると判定した後、前記セッション開始要求着側ネットワークからリクエスト正常処理完了を示す処理完了信号を前記通信手段が受信したか否かを判定する処理完了判定手段と、
前記処理完了判定手段が、前記処理完了信号を前記通信手段が受信したと判定した場合、呼び出し中通知受信を要件の１つとしてアーリメディアのサービス実行を開始するアーリメディア方式のセッション開始要求発側端末装置に前記呼び出し中通知を送信するよう前記通信手段を制御する呼び出し中通知送信制御手段とを備え、
前記リソース予約状況判定手段は、前記サポート判定手段が、セッション開始要求発側ネットワーク及びセッション開始要求発側端末装置、セッション開始要求着側ネットワーク及びセッション開始要求着側端末装置がいずれもリソース予約有無の通知の規定に対応していると判定した場合、前記セッション開始要求発側端末装置が送信し前記通信手段が受信したセッション開始要求に含まれ、前記セッション開始要求発側端末装置のリソース予約状況を示すパラメータの値が、予約済みを示す値か否かを判定する、
請求項１に記載のアーリメディアサービス制御装置。
【請求項3】
通信手段と、
セッション開始要求に対する応答にセッション開始要求着側ネットワークがアーリメディアに対応していることを示すアーリメディア対応情報が含まれるか否かを判定するアーリメディア対応判定手段と、
前記アーリメディア対応判定手段が、前記応答に前記アーリメディア対応情報が含まれると判定した後、前記セッション開始要求着側ネットワークからリクエスト正常処理完了を示す処理完了信号を前記通信手段が受信したか否かを判定する処理完了判定手段と、
前記処理完了判定手段が、前記処理完了信号を前記通信手段が受信したと判定した場合、呼び出し中通知受信を要件の１つとしてアーリメディアのサービス実行を開始するアーリメディア方式のセッション開始要求発側端末装置に前記呼び出し中通知を送信するよう前記通信手段を制御する呼び出し中通知送信制御手段とを備えるアーリメディアサービス制御装置。
セッション開始要求に対する応答にセッション開始要求着側ネットワークがアーリメディアに対応していることを示すアーリメディア対応情報が含まれるか否かを判定するアーリメディア対応判定手段と、
前記アーリメディア対応判定手段が、前記応答に前記アーリメディア対応情報が含まれると判定した後、前記セッション開始要求着側ネットワークからリクエスト正常処理完了を示す処理完了信号を前記通信手段が受信したか否かを判定する処理完了判定手段と、
前記処理完了判定手段が、前記処理完了信号を前記通信手段が受信したと判定した場合、呼び出し中通知受信を要件の１つとしてアーリメディアのサービス実行を開始するアーリメディア方式のセッション開始要求発側端末装置に前記呼び出し中通知を送信するよう前記通信手段を制御する呼び出し中通知送信制御手段とを備えるアーリメディアサービス制御装置。
【請求項4】
通信手段を備えるアーリメディアサービス制御装置が、
呼び出し中通知受信を要件の１つとしてアーリメディアのサービス実行を開始するアーリメディア方式のセッション開始要求発側端末装置が送信し前記通信手段が受信したセッション開始要求に含まれ、前記セッション開始要求発側端末装置のリソース予約状況を示すパラメータの値が、予約済みを示す値か否かを判定し、
前記判定で、前記パラメータの値が予約済みを示す値であると判定した場合、当該パラメータの値をリソース未予約を示す値に書き換え、
前記判定で、前記パラメータの値が予約済みを示す値であると判定した場合、パラメータの値が書き換えられたセッション開始要求をセッション開始要求着側ネットワークへ送信するよう前記通信手段を制御し、前記判定で、前記パラメータの値が予約済みを示す値でないと判定した場合、前記セッション開始要求発側端末装置から受信したセッション開始要求をセッション開始要求着側ネットワークへ送信するよう前記通信手段を制御し、
前記セッション開始要求着側ネットワークへ送信した前記セッション開始要求に対して送信され、セッション開始要求着側端末装置におけるリソース予約済みを示す応答を受信した場合、前記呼び出し中通知を前記セッション開始要求発側端末装置へ送信するよう前記通信手段を制御する
アーリメディアサービス制御方法。
呼び出し中通知受信を要件の１つとしてアーリメディアのサービス実行を開始するアーリメディア方式のセッション開始要求発側端末装置が送信し前記通信手段が受信したセッション開始要求に含まれ、前記セッション開始要求発側端末装置のリソース予約状況を示すパラメータの値が、予約済みを示す値か否かを判定し、
前記判定で、前記パラメータの値が予約済みを示す値であると判定した場合、当該パラメータの値をリソース未予約を示す値に書き換え、
前記判定で、前記パラメータの値が予約済みを示す値であると判定した場合、パラメータの値が書き換えられたセッション開始要求をセッション開始要求着側ネットワークへ送信するよう前記通信手段を制御し、前記判定で、前記パラメータの値が予約済みを示す値でないと判定した場合、前記セッション開始要求発側端末装置から受信したセッション開始要求をセッション開始要求着側ネットワークへ送信するよう前記通信手段を制御し、
前記セッション開始要求着側ネットワークへ送信した前記セッション開始要求に対して送信され、セッション開始要求着側端末装置におけるリソース予約済みを示す応答を受信した場合、前記呼び出し中通知を前記セッション開始要求発側端末装置へ送信するよう前記通信手段を制御する
アーリメディアサービス制御方法。
【請求項5】
前記アーリメディアサービス制御装置が、
セッション開始要求発側ネットワーク及びセッション開始要求発側端末装置、セッション開始要求着側ネットワーク及びセッション開始要求着側端末装置がいずれもリソース予約有無の通知の規定に対応しているか否かを前記通信手段の受信信号に基づいて判定し、
前記通信手段の受信信号に基づく判定で、セッション開始要求発側ネットワーク及びセッション開始要求発側端末装置、セッション開始要求着側ネットワーク及びセッション開始要求着側端末装置の少なくともいずれかがリソース予約有無の通知の規定に対応していないと判定した場合、セッション開始要求に対する応答にセッション開始要求着側ネットワークがアーリメディアに対応していることを示すアーリメディア対応情報が含まれるか否かを判定し、
前記判定で、前記応答に前記アーリメディア対応情報が含まれると判定した後、前記セッション開始要求着側ネットワークからリクエスト正常処理完了を示す処理完了信号を前記通信手段が受信したか否かを判定し、
前記判定で、前記処理完了信号を前記通信手段が受信したと判定した場合、呼び出し中通知受信を要件の１つとしてアーリメディアのサービス実行を開始するアーリメディア方式のセッション開始要求発側端末装置に前記呼び出し中通知を送信するよう前記通信手段を制御し、
前記通信手段の受信信号に基づく判定で、セッション開始要求発側ネットワーク及びセッション開始要求発側端末装置、セッション開始要求着側ネットワーク及びセッション開始要求着側端末装置がいずれもリソース予約有無の通知の規定に対応していると判定した場合、前記セッション開始要求発側端末装置が送信し前記通信手段が受信したセッション開始要求に含まれ、前記セッション開始要求発側端末装置のリソース予約状況を示すパラメータの値が、予約済みを示す値か否かを判定する、
請求項４に記載のアーリメディアサービス制御方法。
セッション開始要求発側ネットワーク及びセッション開始要求発側端末装置、セッション開始要求着側ネットワーク及びセッション開始要求着側端末装置がいずれもリソース予約有無の通知の規定に対応しているか否かを前記通信手段の受信信号に基づいて判定し、
前記通信手段の受信信号に基づく判定で、セッション開始要求発側ネットワーク及びセッション開始要求発側端末装置、セッション開始要求着側ネットワーク及びセッション開始要求着側端末装置の少なくともいずれかがリソース予約有無の通知の規定に対応していないと判定した場合、セッション開始要求に対する応答にセッション開始要求着側ネットワークがアーリメディアに対応していることを示すアーリメディア対応情報が含まれるか否かを判定し、
前記判定で、前記応答に前記アーリメディア対応情報が含まれると判定した後、前記セッション開始要求着側ネットワークからリクエスト正常処理完了を示す処理完了信号を前記通信手段が受信したか否かを判定し、
前記判定で、前記処理完了信号を前記通信手段が受信したと判定した場合、呼び出し中通知受信を要件の１つとしてアーリメディアのサービス実行を開始するアーリメディア方式のセッション開始要求発側端末装置に前記呼び出し中通知を送信するよう前記通信手段を制御し、
前記通信手段の受信信号に基づく判定で、セッション開始要求発側ネットワーク及びセッション開始要求発側端末装置、セッション開始要求着側ネットワーク及びセッション開始要求着側端末装置がいずれもリソース予約有無の通知の規定に対応していると判定した場合、前記セッション開始要求発側端末装置が送信し前記通信手段が受信したセッション開始要求に含まれ、前記セッション開始要求発側端末装置のリソース予約状況を示すパラメータの値が、予約済みを示す値か否かを判定する、
請求項４に記載のアーリメディアサービス制御方法。
【請求項6】
通信手段を備えるアーリメディアサービス制御装置が、
セッション開始要求に対する応答にセッション開始要求着側ネットワークがアーリメディアに対応していることを示すアーリメディア対応情報が含まれるか否かを判定し、
前記判定で、前記応答に前記アーリメディア対応情報が含まれると判定した後、前記セッション開始要求着側ネットワークからリクエスト正常処理完了を示す処理完了信号を前記通信手段が受信したか否かを判定し、
前記判定で、前記処理完了信号を前記通信手段が受信したと判定した場合、呼び出し中通知受信を要件の１つとしてアーリメディアのサービス実行を開始するアーリメディア方式のセッション開始要求発側端末装置に前記呼び出し中通知を送信するよう前記通信手段を制御する
アーリメディアサービス制御方法。
セッション開始要求に対する応答にセッション開始要求着側ネットワークがアーリメディアに対応していることを示すアーリメディア対応情報が含まれるか否かを判定し、
前記判定で、前記応答に前記アーリメディア対応情報が含まれると判定した後、前記セッション開始要求着側ネットワークからリクエスト正常処理完了を示す処理完了信号を前記通信手段が受信したか否かを判定し、
前記判定で、前記処理完了信号を前記通信手段が受信したと判定した場合、呼び出し中通知受信を要件の１つとしてアーリメディアのサービス実行を開始するアーリメディア方式のセッション開始要求発側端末装置に前記呼び出し中通知を送信するよう前記通信手段を制御する
アーリメディアサービス制御方法。
【請求項7】
通信手段を備えるコンピュータに、
呼び出し中通知受信を要件の１つとしてアーリメディアのサービス実行を開始するアーリメディア方式のセッション開始要求発側端末装置が送信し前記通信手段が受信したセッション開始要求に含まれ、前記セッション開始要求発側端末装置のリソース予約状況を示すパラメータの値が、予約済みを示す値か否かを判定するリソース予約状況判定ステップと、
前記リソース予約状況判定ステップで、前記パラメータの値が予約済みを示す値であると判定した場合、当該パラメータの値をリソース未予約を示す値に書き換えるパラメータ値書換ステップと、
前記リソース予約状況判定ステップで、前記パラメータの値が予約済みを示す値であると判定した場合、前記パラメータ値書換ステップでパラメータの値を書き換えたセッション開始要求をセッション開始要求着側ネットワークへ送信するよう前記通信手段を制御し、前記リソース予約状況判定ステップで、前記パラメータの値が予約済みを示す値でないと判定した場合、前記セッション開始要求発側端末装置から受信したセッション開始要求をセッション開始要求着側ネットワークへ送信するよう前記通信手段を制御するセッション開始要求送信制御ステップと、
前記セッション開始要求着側ネットワークへ送信した前記セッション開始要求に対して送信され、セッション開始要求着側端末装置におけるリソース予約済みを示す応答を受信した場合、前記呼び出し中通知を前記セッション開始要求発側端末装置へ送信するよう前記通信手段を制御する呼び出し中通知送信制御ステップと
を実行させるためのプログラム。
呼び出し中通知受信を要件の１つとしてアーリメディアのサービス実行を開始するアーリメディア方式のセッション開始要求発側端末装置が送信し前記通信手段が受信したセッション開始要求に含まれ、前記セッション開始要求発側端末装置のリソース予約状況を示すパラメータの値が、予約済みを示す値か否かを判定するリソース予約状況判定ステップと、
前記リソース予約状況判定ステップで、前記パラメータの値が予約済みを示す値であると判定した場合、当該パラメータの値をリソース未予約を示す値に書き換えるパラメータ値書換ステップと、
前記リソース予約状況判定ステップで、前記パラメータの値が予約済みを示す値であると判定した場合、前記パラメータ値書換ステップでパラメータの値を書き換えたセッション開始要求をセッション開始要求着側ネットワークへ送信するよう前記通信手段を制御し、前記リソース予約状況判定ステップで、前記パラメータの値が予約済みを示す値でないと判定した場合、前記セッション開始要求発側端末装置から受信したセッション開始要求をセッション開始要求着側ネットワークへ送信するよう前記通信手段を制御するセッション開始要求送信制御ステップと、
前記セッション開始要求着側ネットワークへ送信した前記セッション開始要求に対して送信され、セッション開始要求着側端末装置におけるリソース予約済みを示す応答を受信した場合、前記呼び出し中通知を前記セッション開始要求発側端末装置へ送信するよう前記通信手段を制御する呼び出し中通知送信制御ステップと
を実行させるためのプログラム。
【請求項8】
通信手段を備えるコンピュータに、
セッション開始要求に対する応答にセッション開始要求着側ネットワークがアーリメディアに対応していることを示すアーリメディア対応情報が含まれるか否かを判定するアーリメディア対応判定ステップと、
前記アーリメディア対応判定ステップで、前記応答に前記アーリメディア対応情報が含まれると判定した後、前記セッション開始要求着側ネットワークからリクエスト正常処理完了を示す処理完了信号を前記通信手段が受信したか否かを判定する処理完了判定ステップと、
前記処理完了判定ステップで、前記処理完了信号を前記通信手段が受信したと判定した場合、呼び出し中通知受信を要件の１つとしてアーリメディアのサービス実行を開始するアーリメディア方式のセッション開始要求発側端末装置に前記呼び出し中通知を送信するよう前記通信手段を制御する呼び出し中通知送信制御ステップと
を実行させるためのプログラム。
セッション開始要求に対する応答にセッション開始要求着側ネットワークがアーリメディアに対応していることを示すアーリメディア対応情報が含まれるか否かを判定するアーリメディア対応判定ステップと、
前記アーリメディア対応判定ステップで、前記応答に前記アーリメディア対応情報が含まれると判定した後、前記セッション開始要求着側ネットワークからリクエスト正常処理完了を示す処理完了信号を前記通信手段が受信したか否かを判定する処理完了判定ステップと、
前記処理完了判定ステップで、前記処理完了信号を前記通信手段が受信したと判定した場合、呼び出し中通知受信を要件の１つとしてアーリメディアのサービス実行を開始するアーリメディア方式のセッション開始要求発側端末装置に前記呼び出し中通知を送信するよう前記通信手段を制御する呼び出し中通知送信制御ステップと
を実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、アーリメディアサービス制御装置、アーリメディアサービス制御方法及びプログラムに関する。【背景技術】
【0002】
ＩＭＳ（IP Multimedia Subsystem）の標準化団体であるGSMA/3GPP（ＧＳＭは登録商標）が、事業者間における通信ネットワークの相互接続の検討を進めている。ＩＭＳは、アクセスネットワークに依存することなく、ＩＰパケットのトランスポートを制御するコアネットワークの技術である。このＩＭＳに関連して幾つかの技術が提案されている。例えば、特許文献１には、ＴｒＧＷ（Transition Gateway）が出力するログにＣａｌｌ−ＩＤ・発信者電話番号・着信者電話番号を出力できるようにするための技術が記載されている。特許文献１に記載の通信システムでは、ＩＢＣＦ（Interconnection Border Control Function）がＴｒＧＷにＭＥＧＡＣＯ ａｄｄリクエストを送信する際に、これらの情報を含めて送信する。
【0003】
一方、アーリメディア（Early Media）の規定は3GPP TS 24.628 Section 4.2.2で定義されている。アーリメディアは、呼の確立前に端末間で通信を行う技術である。ＩＭＳあるいはその基となるＳＩＰ（Session Initiation Protocol）におけるアーリメディアに関連して幾つかの技術が提案されている。例えば、特許文献２には、セッション要求元端末がPrecondition制御に対応しているが、セッション要求先端末がPrecondition制御に対応していない場合に、アーリメディアのメディアクリッピングを生じないようにするための技術が記載されている。特許文献２に記載のＳＩＰサーバは、セッション開始要求元の第１の端末に対してリソース確保を完了させる。また、このＳＩＰサーバは、セッション開始要求先の第２の端末に対してリソース確保を完了させ、その応答を第１の端末に送信する。そして、ＳＩＰサーバは、第２の端末からアーリメディアを受信し、受信したアーリメディアを第１の端末へ転送する。
【0004】
また、特許文献３には、ＩＭＳにおいてＭＲＢＴ（Multimedia Ring Back Tone）サービス及びＭＣＩＤ（Multimedia Caller identification）サービスを適用できるようにするための技術が記載されている。特許文献３に記載の方法では、発呼側ＵＥがＭＣＩＤサービス加入者であり、かつ、着呼側ＵＥがＭＣＩＤアーリメディアをサポートすると判定した場合、ＭＣＩＤアーリメディアと着呼側ＵＥとをネゴシエーションし、ＭＣＩＤを着呼側ＵＥに再生する。一方、着呼側ＵＥがＭＲＢＴサービス加入者であり、かつ、発呼側ＵＥが前記ＭＲＢＴアーリメディアをサポートすると判定した場合、ＭＲＢＴアーリメディアと発呼側ＵＥとをネゴシエーションし、ＭＲＢＴを発呼側ＵＥに再生する。【0005】
また、特許文献４には、ＳＩＰ基盤のアーリメディアサービス提供方法が記載されている。特許文献４に記載の方法では、応用サーバは、発信端末のＳＤＰ（Session Description Protocol）情報が含まれた第１のＩＮＶＩＴＥメッセージを発信端末から受信する。この応用サーバは、Ｂ２ＢＵＡ（Back-to-back User Agent）モードで動作して第２のＩＮＶＩＴＥメッセージを着信端末へ転送する。また、応用サーバは、アーリメディアとして提供されるコンテンツのメディア情報をメディアサーバから獲得し、また、メディアサーバから発信端末にアーリメディアを伝達するためのアーリーセッションを設定する。メディアサーバは、アーリーセッションを通じて発信端末にアーリメディアを提供する。
応用サーバは、着信端末から着信端末のＳＤＰ情報が含まれた１８０リンギングメッセージを受信すると、発信端末と着信端末との間に正規セッション設定を準備する。さらに、応用サーバは、着信端末から２００ ＯＫメッセージを受信すると、メディアサーバへ中止命令を転送して、アーリメディア転送が終了するようにする。そして、応用サーバは、発信端末と着信端末との間に正規セッション設定を完了する。
【先行技術文献】
【特許文献】
【0006】
【特許文献1】特開２０１５−１８６２４９号公報
【特許文献2】特開２０１５−１６２８２７号公報
【特許文献3】特表２０１０−５２１１１０号公報
【特許文献4】特表２００９−５４０６５９号公報
【発明の概要】
【発明が解決しようとする課題】
【0007】
3GPP TS 24.628 Section 4.2.2では、アーリメディアの方式が複数示されている。ＩＭＳにおいて発呼側と着呼側とでアーリメディアの方式が異なる場合、アーリメディアによるサービス提供に支障が生じる可能性がある。これに対し、特許文献１〜４のいずれにも、発呼側と着呼側とでアーリメディアの方式が異なる場合に対する対応策は示されていない。【0008】
本発明は、上述の課題を解決することのできるアーリメディアサービス制御装置、アーリメディアサービス制御方法及びプログラムを提供することを目的としている。【課題を解決するための手段】
【0009】
本発明の第１の態様によれば、アーリメディアサービス制御装置は、通信部と、呼び出し中通知受信を要件の１つとしてアーリメディアのサービス実行を開始するアーリメディア方式のセッション開始要求発側端末装置が送信し前記通信部が受信したセッション開始要求に含まれ、前記セッション開始要求発側端末装置のリソース予約状況を示すパラメータの値が、予約済みを示す値か否かを判定するリソース予約状況判定部と、前記リソース予約状況判定部が、前記パラメータの値が予約済みを示す値であると判定した場合、当該パラメータの値をリソース未予約を示す値に書き換えるパラメータ値書換部と、前記リソース予約状況判定部が、前記パラメータの値が予約済みを示す値であると判定した場合、前記パラメータ値書換部がパラメータの値を書き換えたセッション開始要求をセッション開始要求着側ネットワークへ送信するよう前記通信部を制御し、前記リソース予約状況判定部が、前記パラメータの値が予約済みを示す値でないと判定した場合、前記セッション開始要求発側端末装置から受信したセッション開始要求をセッション開始要求着側ネットワークへ送信するよう前記通信部を制御するセッション開始要求送信制御部と、前記通信部が前記セッション開始要求着側ネットワークへ送信した前記セッション開始要求に対して送信され、セッション開始要求着側端末装置におけるリソース予約済みを示す応答を前記通信部が受信した場合、前記呼び出し中通知を前記セッション開始要求発側端末装置へ送信するよう前記通信部を制御する呼び出し中通知送信制御部と、を備える。【0010】
本発明の第２の態様によれば、アーリメディアサービス制御装置は、通信部と、セッション開始要求に対する応答にセッション開始要求着側ネットワークがアーリメディアに対応していることを示すアーリメディア対応情報が含まれるか否かを判定するアーリメディア対応判定部と、前記アーリメディア対応判定部が、前記応答に前記アーリメディア対応情報が含まれると判定した後、前記セッション開始要求着側ネットワークからリクエスト正常処理完了を示す処理完了信号を前記通信部が受信したか否かを判定する処理完了判定部と、前記処理完了判定部が、前記処理完了信号を前記通信部が受信したと判定した場合、呼び出し中通知受信を要件の１つとしてアーリメディアのサービス実行を開始するアーリメディア方式のセッション開始要求発側端末装置に前記呼び出し中通知を送信するよう前記通信部を制御する呼び出し中通知送信制御部と、を備える。【0011】
本発明の第３の態様によれば、アーリメディアサービス制御方法は、通信部を備えるアーリメディアサービス制御装置が、呼び出し中通知受信を要件の１つとしてアーリメディアのサービス実行を開始するアーリメディア方式のセッション開始要求発側端末装置が送信し前記通信部が受信したセッション開始要求に含まれ、前記セッション開始要求発側端末装置のリソース予約状況を示すパラメータの値が、予約済みを示す値か否かを判定するリソース予約状況判定ステップと、前記リソース予約状況判定ステップで、前記パラメータの値が予約済みを示す値であると判定した場合、当該パラメータの値をリソース未予約を示す値に書き換えるパラメータ値書換ステップと、前記リソース予約状況判定ステップで、前記パラメータの値が予約済みを示す値であると判定した場合、前記パラメータ値書換ステップでパラメータの値を書き換えたセッション開始要求をセッション開始要求着側ネットワークへ送信するよう前記通信部を制御し、前記リソース予約状況判定ステップで、前記パラメータの値が予約済みを示す値でないと判定した場合、前記セッション開始要求発側端末装置から受信したセッション開始要求をセッション開始要求着側ネットワークへ送信するよう前記通信部を制御するセッション開始要求送信制御ステップと、前記セッション開始要求着側ネットワークへ送信した前記セッション開始要求に対して送信され、セッション開始要求着側端末装置におけるリソース予約済みを示す応答を受信した場合、前記呼び出し中通知を前記セッション開始要求発側端末装置へ送信するよう前記通信部を制御する呼び出し中通知送信制御ステップと、を含む。【0012】
本発明の第４の態様によれば、アーリメディアサービス制御方法は、通信部を備えるアーリメディアサービス制御装置が、セッション開始要求に対する応答にセッション開始要求着側ネットワークがアーリメディアに対応していることを示すアーリメディア対応情報が含まれるか否かを判定するアーリメディア対応判定ステップと、前記アーリメディア対応判定ステップで、前記応答に前記アーリメディア対応情報が含まれると判定した後、前記セッション開始要求着側ネットワークからリクエスト正常処理完了を示す処理完了信号を前記通信部が受信したか否かを判定する処理完了判定ステップと、前記処理完了判定ステップで、前記処理完了信号を前記通信部が受信したと判定した場合、呼び出し中通知受信を要件の１つとしてアーリメディアのサービス実行を開始するアーリメディア方式のセッション開始要求発側端末装置に前記呼び出し中通知を送信するよう前記通信部を制御する呼び出し中通知送信制御ステップと、を含む。【0013】
本発明の第５の態様によれば、プログラムは、通信部を備えるコンピュータに、呼び出し中通知受信を要件の１つとしてアーリメディアのサービス実行を開始するアーリメディア方式のセッション開始要求発側端末装置が送信し前記通信部が受信したセッション開始要求に含まれ、前記セッション開始要求発側端末装置のリソース予約状況を示すパラメータの値が、予約済みを示す値か否かを判定するリソース予約状況判定ステップと、前記リソース予約状況判定ステップで、前記パラメータの値が予約済みを示す値であると判定した場合、当該パラメータの値をリソース未予約を示す値に書き換えるパラメータ値書換ステップと、前記リソース予約状況判定ステップで、前記パラメータの値が予約済みを示す値であると判定した場合、前記パラメータ値書換ステップでパラメータの値を書き換えたセッション開始要求をセッション開始要求着側ネットワークへ送信するよう前記通信部を制御し、前記リソース予約状況判定ステップで、前記パラメータの値が予約済みを示す値でないと判定した場合、前記セッション開始要求発側端末装置から受信したセッション開始要求をセッション開始要求着側ネットワークへ送信するよう前記通信部を制御するセッション開始要求送信制御ステップと、前記セッション開始要求着側ネットワークへ送信した前記セッション開始要求に対して送信され、セッション開始要求着側端末装置におけるリソース予約済みを示す応答を受信した場合、前記呼び出し中通知を前記セッション開始要求発側端末装置へ送信するよう前記通信部を制御する呼び出し中通知送信制御ステップと、を実行させるためのプログラムである。【0014】
本発明の第６の態様によれば、プログラムは、通信部を備えるコンピュータに、セッション開始要求に対する応答にセッション開始要求着側ネットワークがアーリメディアに対応していることを示すアーリメディア対応情報が含まれるか否かを判定するアーリメディア対応判定ステップと、前記アーリメディア対応判定ステップで、前記応答に前記アーリメディア対応情報が含まれると判定した後、前記セッション開始要求着側ネットワークからリクエスト正常処理完了を示す処理完了信号を前記通信部が受信したか否かを判定する処理完了判定ステップと、前記処理完了判定ステップで、前記処理完了信号を前記通信部が受信したと判定した場合、呼び出し中通知受信を要件の１つとしてアーリメディアのサービス実行を開始するアーリメディア方式のセッション開始要求発側端末装置に前記呼び出し中通知を送信するよう前記通信部を制御する呼び出し中通知送信制御ステップと、を実行させるためのプログラムである。【発明の効果】
【0015】
この発明によれば、ＩＭＳにおいて発呼側と着呼側とでアーリメディアの方式が異なる場合でも、アーリメディアによるサービスを提供することができる。【図面の簡単な説明】
【0016】
【図1】本発明の一実施形態に係るＩＭＳネットワークの機能構成を示す概略ブロック図である。
【図2】同実施形態に係る発側ＩＢＣＦの機能構成を示す概略ブロック図である。
【図3】同実施形態に係る発側ネットワーク側、着側ネットワーク側のいずれもPreconditionをサポートしている場合の、ＩＭＳネットワークの動作の第一の例を示す説明図である。
【図4】同実施形態に係る発側ネットワーク側、着側ネットワーク側のいずれもPreconditionをサポートしている場合の、ＩＭＳネットワークの動作の第一の例を示す説明図である。
【図5】同実施形態に係る発側ネットワーク側、着側ネットワーク側のいずれもPreconditionをサポートしている場合の、ＩＭＳネットワークの動作の第一の例を示す説明図である。
【図6】同実施形態に係る発側ネットワーク側、着側ネットワーク側のいずれもPreconditionをサポートしている場合の、ＩＭＳネットワークの動作の第二の例を示す説明図である。
【図7】同実施形態に係る発側ネットワーク側、着側ネットワーク側のいずれもPreconditionをサポートしている場合の、ＩＭＳネットワークの動作の第二の例を示す説明図である。
【図8】同実施形態に係る着側ネットワーク側がPreconditionをサポートしているが、発側ネットワーク側がPreconditionをサポートしていない場合の、ＩＭＳネットワークの動作の例を示す説明図である。
【図9】同実施形態に係る着側ネットワーク側がPreconditionをサポートしているが、発側ネットワーク側がPreconditionをサポートしていない場合の、ＩＭＳネットワークの動作の例を示す説明図である。
【図10】同実施形態に係る発側ネットワーク側がPreconditionをサポートしているが、着側ネットワーク側がPreconditionをサポートしていない場合の、ＩＭＳネットワークの動作の例を示す説明図である。
【図11】同実施形態に係る発側ネットワーク側がPreconditionをサポートしているが、着側ネットワーク側がPreconditionをサポートしていない場合の、ＩＭＳネットワークの動作の例を示す説明図である。
【図12】同実施形態に係る発側ＩＢＣＦが、第一の方法及び第二の方法のうちいずれを用いるかを決定する手順の例を示す説明図である。
【図13】本発明に係るアーリメディアサービス制御装置の最小構成の第一の例を示す説明図である。
【図14】本発明に係るアーリメディアサービス制御装置の最小構成の第二の例を示す説明図である。
【発明を実施するための形態】
【0017】
以下、本発明の実施形態を説明するが、以下の実施形態は請求の範囲にかかる発明を限定するものではない。また、実施形態の中で説明されている特徴の組み合わせの全てが発明の解決手段に必須であるとは限らない。まず、ＩＭＳ相互接続でアーリメディアの方式が異なる場合の問題点について説明する。
【0018】
アーリメディアを規定する3GPP TS 24.628 Section 4.2.2では、以下の３つの方式のいずれか１つをサポートすることが求められている。（１）RFC3960で定義されるGateway Model方式
（２）RFC5009で定義されるmultiple early dialog(= Forking model方式)
（３）「１８０Ｒｉｎｇｉｎｇ」を用いたAlert-Info header方式
【0019】
ＩＭＳによる事業者間相互接続を行う通信事業者がアーリメディアを提供する場合、特に、（１）のGateway Model方式、又は、（２）のForking Model方式のいずれか一方をサポートすることが考えられる。これら（１）のGateway Model方式、及び、（２）のForking Model方式について規定している3GPP TS 24.182では、異なるモデル間の連係を対象範囲外（out of scope）としている。すなわち、異なるモデルを採用している通信事業者間の相互接続は規定されておらず、この場合のアーリメディア提供の枠組みも示されていない。
さらに、（１）のGateway Model方式の特徴と、（２）のForking Model方式の特徴とを比較すると、特に以下の点で相違する。
【0020】
（１）Gateway Model方式Gateway Model方式では、シングルダイアログ(SDP_Offer/SDP_Anser)でＳＤＰ（Session Description Protocol）の交換を行う。また、「１８０Ｒｉｎｇｉｎｇ」を端末側に通知する。「１８０Ｒｉｎｇｉｎｇ」は、呼び出し中であることを通知するメソッドである。
（２）Forking Model方式
Forking Model方式では、マルチプルダイアログ(SDP_O/A Dialog1, SDP_O/A Dialog2)でＳＤＰの交換を行う。また、「１８０Ｒｉｎｇｉｎｇ」を発端末側に通知せずCAT-ASで終端する。
【0021】
この相違点がアーリメディアに及ぼす影響について検討する。Gateway Model方式とForking Model方式の組み合わせとして、
（Ａ）発側、着側共にGateway Model方式
（Ｂ）発側がGateway Model方式、かつ、着側がForking Model方式
（Ｃ）発側がForking Model方式、かつ、着側 がGateway Model方式
（Ｄ）発側、着側共にForking Model方式
の４通りが考えられる。これらのうち、（Ａ）発側、着側共にGateway Model方式の場合、及び、（Ｄ）発側、着側共にForking Model方式の場合は、発側と着側とで方式が同じなので、方式の相違に起因する問題は生じない。
また、（Ｃ）発側がForking Model方式、かつ、着側がGateway Model方式の場合、発側の端末装置はForking Model方式に基づくことで「１８０Ｒｉｎｇｉｎｇ」を必要としないため、「１８０Ｒｉｎｇｉｎｇ」着信の有無に起因する問題は生じない。
【0022】
一方、（Ｂ）発側がGateway Model方式、かつ、着側がForking Model方式の場合、着側のネットワークがサポートするForking Model方式では、上記のように「１８０Ｒｉｎｇｉｎｇ」がＣＡＴ−ＡＳで終端され、発側のネットワークに送信されない。これに対し、発側のネットワークがサポートするGateway Model方式では、発呼を行った端末装置が「１８０Ｒｉｎｇｉｎｇ」を受信した後にRBTを受信することになっている。
「１８０Ｒｉｎｇｉｎｇ」を受信していない状態でRBTを受信した場合の発端末の動作については規定されていない。従って、「１８０Ｒｉｎｇｉｎｇ」を受信していない状態でRBTを受信した場合に発端末がどのような動作を行うかは、発端末の実装に依存する。
このため、発側の端末装置に１８０Ｒｉｎｇｉｎｇが送信されないことに起因して、発側の端末装置がアーリメディアを正しく実行できない場合がある。
【0023】
また、端末装置に限らず発側のネットワーク内のノードについても、Gateway Model方式の規定に基づいて「１８０Ｒｉｎｇｉｎｇ」を必要とするノードが存在する可能性がある。例えば、「１８０Ｒｉｎｇｉｎｇ」が送信されないことで、発側のネットワーク内のノードが着側のネットワークからいつＲＢＴ（Ring Back Tone）が送信されるか分からない可能性がある。そこで、本実施形態では、異なるモデル同士（Gateway Model方式、及びForking Model方式）のＩＭＳ相互接続で、Gateway model方式を採用している側のネットワークの機器が、同一ネットワーク内からセッション要求を送信した端末装置に対して「１８０Ｒｉｎｇｉｎｇ」を送信する。
【0024】
図１は、本発明の一実施形態に係るＩＭＳネットワークの機能構成を示す概略ブロック図である。同図に示すように、ＩＭＳネットワーク１は、発側ネットワーク１００と、着側ネットワーク２００とを備える。発側ネットワーク１００は、発側Ｐ−ＣＳＣＦ１１１と、発側Ｓ−ＣＳＣＦ１１２と、発側ＩＢＣＦ１１３と、発側ＴｒＧＷ１１４とを備える。着側ネットワーク２００は、着側Ｐ−ＣＳＣＦ２１１と、着側Ｓ−ＣＳＣＦ２１２と、着側ＩＢＣＦ２１３と、着側ＴｒＧＷ２１４と、着側ＣＡＴ−ＡＳ２２１とを備える。発側ネットワーク１００には発側端末装置３１１が通信接続されている。また、着側ネットワーク２００には着側端末装置３２１が通信接続されている。ここでいう発側は、発呼する側（セッション要求を送信する側）である。着側は、着呼する側（セッション要求を受ける側）である。以下では、発側端末装置３１１が着側端末装置３２１に通信要求を送信する場合を例に説明する。
【0025】
なお、発側端末装置３１１は、発側ネットワーク１００に含まれていてもよいし、発側ネットワーク１００には含まれない装置として発側ネットワーク１００に通信接続していていてもよい。着側端末装置３２１は、着側ネットワーク２００に含まれていてもよいし、着側ネットワーク２００には含まれない装置として着側ネットワーク２００に通信接続していてもよい。【0026】
以下では、発側ネットワーク１００が発側端末装置３１１を含まず、着側ネットワーク２００が着側端末装置３２１を含まないものとして説明する。なお、発側ネットワーク１００と発側端末装置３１１とを総称して発側ネットワーク１００側と表記する。また、着側ネットワーク２００と着側端末装置３２１とを総称して着側ネットワーク２００側と表記する。【0027】
ＩＭＳネットワーク１は、発側端末装置３１１と着側端末装置３２１との間にセッション（呼）を確立して、発側端末装置３１１と着側端末装置３２１との通信を仲介する通信ネットワークである。発側ネットワーク１００は、Gateway Model方式にてアーリメディアサービスを提供するコアネットワーク（Core Network）である。
着側ネットワーク２００は、Forking Model方式にてアーリメディアサービスを提供するコアネットワークである。
発側ネットワーク１００と着側ネットワーク２００とはＩＭＳ接続されている。ここで、ＩＭＳ接続とは、ＩＭＳの規定に基づくコアネットワーク間通信接続である。
【0028】
発側端末装置３１１は、発側Ｐ−ＣＳＣＦ１１１に接続して通信を行う端末装置である。発側端末装置３１１は発側ネットワーク１００のアーリメディアサービス提供方式であるGateway Model方式に基づいて、ＲＢＴの受信の前に「１８０Ｒｉｎｇｉｎｇ」を受信することを必要としている。着側端末装置３２１は、着側Ｐ−ＣＳＣＦ２１１に接続して通信を行う端末装置である。着側端末装置３２１は着側ネットワーク２００のアーリメディアサービス提供方式であるForking Model方式に基づいてアーリメディアサービスの処理を行う。
【0029】
発側Ｐ−ＣＳＣＦ（Proxy Call/Session Control Function）１１１は、発側端末装置３１１など発側ネットワーク１００における端末装置のプロキシサーバとして機能するサーバ装置である。着側Ｐ−ＣＳＣＦ２１１は、着側端末装置３２１など着側ネットワーク２００における端末装置のプロキシサーバとして機能するサーバ装置である。
発側Ｓ−ＣＳＣＦ（Serving-Call Session Control Function）１１２及び着側Ｓ−ＣＳＣＦ２１２は、ＳＩＰサーバとして機能し、セッション制御を実行するサーバ装置である。
【0030】
発側ＩＢＣＦ（Interconnection Border Control Function）１１３及び着側ＩＢＣＦ２１３は、外部ネットワークとの境界に位置する。発側ＩＢＣＦ１１３及び着側ＩＢＣＦ２１３は、いずれも、外部ネットワークとのゲートウェイとして機能し、NAT（Network Address Translation、IPアドレスの変換）及びファイアウォール機能を提供するサーバ装置である。発側ＴｒＧＷ（Transition Gateway）１１４及び着側ＴｒＧＷ２１４は、いずれも、ＩＰｖ４とＩＰＶ６との変換などの変換を行うサーバ装置である。
着側ＣＡＴ−ＡＳ（Customized Alerting Tones-Application Server）２２１は、カスタマイズされた呼び出し音（ユーザの好みの呼び出し音）を提供するサーバ装置である。
【0031】
本実施形態では、発側ＩＢＣＦ１１３が発側端末装置３１１に「１８０Ｒｉｎｇｉｎｇ」を提供する場合を例に説明する。但し、発側端末装置３１１に「１８０Ｒｉｎｇｉｎｇ」を提供する装置は、発側ＩＢＣＦ１１３に限らず、各装置に対して矛盾を生じさせずに「１８０Ｒｉｎｇｉｎｇ」を提供できればよい。例えば、発側Ｐ−ＣＳＣＦ１１１が発側端末装置３１１に「１８０Ｒｉｎｇｉｎｇ」を提供するようにしてもよい。【0032】
図２は、発側ＩＢＣＦ１１３の機能構成を示す概略ブロック図である。同図に示すように発側ＩＢＣＦ１１３は、通信部４１０と、記憶部４５０と、制御部４６０とを備える。制御部４６０は、通信制御部４７１と、サポート判定部４８１と、リソース予約状況判定部４８２と、アーリメディア対応判定部４８３と、処理完了判定部４８４と、信号調整部４９１とを備える。通信制御部４７１は、セッション開始要求送信制御部４７２と、呼び出し中通知送信制御部４７３とを備える。信号調整部４９１は、パラメータ値書換部４９２を備える。
【0033】
通信部４１０は、通信制御部４７１の制御に従って、発側ネットワーク１００内の機器、発側ネットワーク１００外の機器それぞれと通信を行う。特に、通信部４１０は、発側端末装置３１１が着側ネットワーク２００側へ送信した信号を、発側Ｐ−ＣＳＣＦ１１１及び発側Ｓ−ＣＳＣＦ１１２を介して受信し、受信した信号、または、受信した信号に対して信号調整部４９１が加工した信号を着側ネットワーク２００側へ送信する。また、通信部４１０は、着側ネットワーク２００側から発側端末装置３１１宛ての信号を受信し、受信した信号、または、受信した信号に対して信号調整部４９１が加工した信号を、発側Ｓ−ＣＳＣＦ１１２及び発側Ｐ−ＣＳＣＦ１１１を介して発側端末装置３１１へ送信する。【0034】
記憶部４５０は、各種情報を記憶する。記憶部４５０は、発側ＩＢＣＦ１１３が備える記憶デバイスを用いて構成される。あるいは、記憶部４５０が外付けの記憶デバイスを用いて構成されていてもよい。制御部４６０は、発側ＩＢＣＦ１１３の各部を制御して各種処理を実行する。制御部４６０は、例えば、発側ＩＢＣＦ１１３が備えるＣＰＵ（Central Processing Unit、中央処理装置）が記憶部４５０からプログラムを読み出して実行することで構成される。
【0035】
通信制御部４７１は、通信部４１０を制御して通信を行わせる。セッション開始要求送信制御部４７２は、通信部４１０を制御して「ＩＮＶＩＴＥ」を送信させる。発側端末装置３１１が送信し通信部４１０が受信した「ＩＮＶＩＴＥ」に対してパラメータ値書換部４９２がパラメータの書換を行った場合、セッション開始要求送信制御部４７２は、パラメータ書換後の「ＩＮＶＩＴＥ」を送信させる。一方、パラメータ値書換部４９２がパラメータの書換を行っていない場合、セッション開始要求送信制御部４７２は、通信部４１０が受信した「ＩＮＶＩＴＥ」を送信させる。「ＩＮＶＩＴＥ」は、セッション開始要求の例に該当する。
呼び出し中通知送信制御部４７３は、通信部４１０を制御して「１８０Ｒｉｎｇｉｎｇ」を発側端末装置３１１へ送信させる。「１８０Ｒｉｎｇｉｎｇ」は、呼び出し中通知の例に該当する。
【0036】
サポート判定部４８１は、発側ネットワーク１００及び発側端末装置３１１、着側ネットワーク２００及び着側端末装置３２１共にPreconditionをサポートしているか否かを判定する。ここでいうPreconditionは、アーリメディアのためのリソースの予約（確保）の有無を他機器に通知するための規定である。Preconditionのサポートには、ネットワークによるサポートと、端末装置によるサポートとがある。本実施形態では、発側ネットワーク１００によるサポートと、着側ネットワーク２００によるサポートと、発側端末装置３１１によるサポートと、着側端末装置３２１によるサポートとがある。ネットワークがPreconditionをサポートするとは、ネットワークに含まれている各機器がPreconditionをサポートすること（すなわち、Preconditionの規定に適合していること）である。なお、ネットワークに含まれている機器のうちPreconditionに関与しない機器は、Preconditionをサポートしているものとして扱う。すなわち、Preconditionに関与しない機器がネットワーク中に含まれていても、ネットワークがPreconditionをサポートしていないことにはならない。
【0037】
以下では、ネットワークがPreconditionをサポートしていない場合、端末装置がPreconditionをサポートしていない場合のいずれも、ネットワーク側がPreconditionをサポートしていないと表記する。一方、ネットワークがPreconditionをサポートしており、かつ、端末装置がPreconditionをサポートしている場合、ネットワーク側がPreconditionをサポートしていると表記する。【0038】
ネットワークがPreconditionをサポートしていない場合、端末装置がPreconditionをサポートしていない場合のいずれも、ネットワークとしてPreconditionをサポートしていない動作となる。特に、本実施形態で、発側ネットワーク１００、着側ネットワーク２００、発側端末装置３１１、着側端末装置３２１のいずれがPreconditionをサポートしていない場合も、発側端末装置３１１のリソース予約状況を着側ネットワーク２００の機器に通知するという後述の処理を適用することができない。【0039】
発側ネットワーク１００側がPreconditionをサポートしていない場合、着側ネットワーク２００の機器及び着側端末装置３２１は、発側端末装置３１１が既にリソースを予約済みである前提で処理を行う。また、着側ネットワーク２００側がPreconditionをサポートしていない場合、発側ネットワーク１００の機器及び発側端末装置３１１は、着側端末装置３２１が既にリソースを予約済みである前提で処理を行う。【0040】
サポート判定部４８１は、発側ネットワーク１００側、着側ネットワーク２００側のそれぞれがPreconditionをサポートしているか否かを判定する。サポート判定部４８１は、発側ネットワーク１００側と着側ネットワーク２００側との間の通信信号のヘッダ又はパラメータ（ＳＤＰ等）を参照して当該判定を行う。【0041】
ここで、発側端末装置３１１は、「ＩＮＶＩＴＥ」のSupported Headerに「precondition」のパラメータを付与して、発側端末装置３１１自らの能力を通知する。また、「ＩＮＶＩＴＥ」を受信した着側端末装置３２１は、着側端末装置３２１自らがPreconditionをサポートしている場合は、応答信号にPreconditionのパラメータ（ＳＤＰ）を含めて送信する。一方、着側端末装置３２１自らがPreconditionをサポートしていない場合、着側端末装置３２１は、応答信号にＳＤＰを含めずに送信する。【0042】
そこで、発側ＩＢＣＦ１１３は、発側端末装置３１１が送信した「ＩＮＶＩＴＥ」のヘッダを参照して、発側ネットワーク１００側がPreconditionをサポートしているか否かを判定する。また、発側ＩＢＣＦ１１３は、着側端末装置３２１が送信した応答信号（例えば「１８３（Ｄ１）」応答）のパラメータ、又はヘッダを参照して、着側ネットワーク２００側がPreconditionをサポートしているか否かを判定する。【0043】
リソース予約状況判定部４８２は、発側端末装置３１１が送信し通信部４１０が受信した「ＩＮＶＩＴＥ」に含まれ発側端末装置３１１のリソース予約状況を示すパラメータ（ＳＤＰ）の値が、予約済みを示す値か否かを判定する。アーリメディア対応判定部４８３は、「ＩＮＶＩＴＥ」に対して着側ＣＡＴ−ＡＳ２２１が送信する「１８３（Ｄ１）」応答のP-Early-Media header fieldに「sendrecv」パラメータが設定されているか否かを判定する。「１８３」応答は、セッション開始要求に対する応答の例に該当する。「１８３（Ｄ１）」応答のP-Early-Media header fieldに「sendrecv」パラメータの設定は、セッション開始要求着側ネットワークがアーリメディアに対応していることを示すアーリメディア対応情報の例に該当する。
処理完了判定部４８４は、着側ネットワーク２００の着側ＣＡＴ−ＡＳ２２１が送信した「２００ＯＫ（ＰＲＡＣＫ）」を通信部４１０が受信したか否かを判定する。「２００ＯＫ（ＰＲＡＣＫ）」は、リクエスト正常処理完了を示す処理完了信号の例に該当する。
【0044】
信号調整部４９１は、通信部４１０が受信した信号に加工を加える。信号調整部４９１は、サポート判定部４８１の判定結果に応じて異なる処理を行う。発側ネットワーク１００側がPreconditionをサポートしている場合、かつ、発側端末装置３１１がリソースを予約済みの場合、発側ＩＢＣＦ１１３は、一旦、リソース未予約として着側ネットワーク２００側に通知を行う。これにより、発側ＩＢＣＦ１１３は、「１８ｘ（Ｄ２）」応答を受信し、「１８０Ｒｉｎｇｉｎｇ」に変換して発側端末装置３１１へ送信する。なお、「ｘ」は１文字の数字を示す。例えば、発側ＩＢＣＦ１１３は、「１８３（Ｄ２）」応答を受信する。【0045】
一方、発側ネットワーク１００側、着側ネットワーク２００側のうちいずれか一方、又は両方がPreconditionをサポートしていない場合、発側ＩＢＣＦ１１３は、発側端末装置３１１のリソース予約状況を未に変更して着側ネットワーク２００側に通知することができない。そこで、発側ＩＢＣＦ１１３は、着側ネットワーク２００側から受信する信号のヘッダを参照してアーリメディアサービス開始の条件が整っているか否かを判定する。【0046】
パラメータ値書換部４９２は、発側端末装置３１１が送信した「ＩＮＶＩＴＥ」のパラメータを書き換える。具体的には、パラメータ値書換部４９２は、発側端末装置３１１のリソース予約状況を示すパラメータ（ＳＤＰ）の値が、予約済みを示す値である場合に、未予約を示す値に書き換える。【0047】
ここで、図３〜図１１を参照して、信号調整部４９１が行う処理について説明する。なお、図３〜図１１では、発側端末装置３１１、着側端末装置３２１、及び、ＩＭＳネットワーク１の各部のうち発側ＩＢＣＦ１１３と、着側Ｓ−ＣＳＣＦ２１２と、着側ＣＡＴ−ＡＳ２２１とを記載し、他の各部については記載を省略する。【0048】
図３〜図５は、発側ネットワーク１００側、着側ネットワーク２００側のいずれもPreconditionをサポートしている場合の、ＩＭＳネットワーク１の動作の第一の例を示す説明図である。発側ネットワーク１００は、Gateway model方式を採用しており、着側ネットワーク２００は、Forking Model方式を採用している。同図では、発側端末装置３１１が「ＩＮＶＩＴＥ」を送信する際に、発側端末装置３１１、着側端末装置３２１のいずれも既にリソースを予約出来ている場合の例を示す。発側端末装置３１１は、シーケンスＳ１１１でリソースを予約済みである。また、着側端末装置３２１は、シーケンスＳ１１２でリソースを予約済みである。
【0049】
同図の処理で、発側端末装置３１１は「ＩＮＶＩＴＥ」を送信している（シーケンスＳ１２１）。この「ＩＮＶＩＴＥ」のパラメータ（Preconditionを示すＳＤＰ）のうち、「curr」は現在の状態を示し、「des」は、希望する状態（Preconditionが満たされるための条件）を示す。また、ＳＤＰ値の「sendrecv」は、送受信可能な状態を示し、「none」は、送受信不可能な状態を示す。あるいは、送受信の可否が不明な状態を示す。発側端末装置３１１は、リソースを予約済みなので、発側（「local」）の現在（「curr」）のＳＤＰの値を、「sendrecv」にしている。
なお、発側端末装置３１１が送信した信号では、「local」が発側端末装置３１１を示し、「remote」が着側端末装置３２１を示す。一方、着側端末装置３２１が送信した信号では、「local」が着側端末装置３２１を示し、「remote」が発側端末装置３１１を示す。
【0050】
発側端末装置３１１からの「ＩＮＶＩＴＥ」を通信部４１０が受信した発側ＩＢＣＦ１１３では、信号調整部４９１のパラメータ値書換部４９２がＳＤＰ値を書き換える（シーケンスＳ１２２）。信号調整部４９１は、発側の現在のＳＤＰの値を「sendrecv」から「none」に書き換えている。発側端末装置３１１がリソースを予約済みか否かにかかわらず、着側ネットワーク２００側に一旦リソース未予約を通知して、「１８０Ｒｉｎｇｉｎｇ」に相当する「１８ｘ（Ｄ２）」を取得する。【0051】
パラメータ値書換部４９２は、リソース予約状況判定部４８２の判定結果に基づいて、シーケンスＳ１２２でのＳＤＰ値の書換を行う。具体的には、リソース予約状況判定部４８２は、「ＩＮＶＩＴＥ」の発側（「local」）の現在（「curr」）のＳＤＰの値が、「sendrecv」か否かを判定することで、発側端末装置３１１がリソースを予約済みか否かを判定する。パラメータ値書換部４９２は、発側端末装置３１１がリソースを予約済みであるとリソース予約状況判定部４８２が判定した場合に、シーケンスＳ１２２でのＳＤＰ値の書換を行う。【0052】
通信部４１０は、信号調整部４９１がＳＤＰ値を書き換えた「ＩＮＶＩＴＥ」を着側ネットワーク２００側へ送信する（シーケンスＳ１２３）。通信部４１０は、通信制御部４７１のセッション開始要求送信制御部４７２の制御に従って、シーケンスＳ１２３での「ＩＮＶＩＴＥ」の送信を行う。シーケンスＳ１２３で「ＩＮＶＩＴＥ」を受信した着側ＣＡＴ−ＡＳ２２１は、ＣＡＴ（Customized alerting tones）のリソースを準備する（シーケンスＳ１３１）。これにより、着側ＣＡＴ−ＡＳ２２１は、カスタマイズされた着信音（例えば発呼者の好みの音楽など）を送信可能になっている。
【0053】
そして、着側ＣＡＴ−ＡＳ２２１は、着側Ｓ−ＣＳＣＦ２１２に「ＩＮＶＩＴＥ」を送信する（シーケンスＳ１３２）。なお、ＳＤＰの「Ｄ１」（Dialog1）は、発側端末装置３１１と着側ＣＡＴ−ＡＳ２２１との間のＳＤＰ交換（セッション確立）に関するダイアログであることを示す。着側Ｓ−ＣＳＣＦ２１２は、着側端末装置３２１に「ＩＮＶＩＴＥ」を送信する（シーケンスＳ１３３）。
【0054】
また、着側ＣＡＴ−ＡＳ２２１は、発側ネットワーク１００へ向けて「ＩＮＶＩＴＥ」に対する「１８３（Ｄ１）」応答（183 Session Progress）を送信する（シーケンスＳ１４１）。ここで、着側ＣＡＴ−ＡＳ２２１がシーケンスＳ１２３で受信した「ＩＮＶＩＴＥ」で、発側の現在の状態を示すＳＤＰ（「curr」、「local」）がリソース未予約（「none」）になっている。これに対応して、着側ＣＡＴ−ＡＳ２２１は、「１８３（Ｄ１）」応答のＳＤＰのうち発側の現在の状態を示す「curr」、「remote」のＳＤＰの値を「none」（リソース未予約を示す値）にしている。
【0055】
シーケンスＳ１４１で通信部４１０が「１８３（Ｄ１）」応答を受信した発側ネットワーク１００では、信号調整部４９１がＳＤＰ値を書き換える（シーケンスＳ１４２）。信号調整部４９１は、「１８３」応答のＳＤＰのうち、発側の現在の状態を示す「curr」、「remote」のＳＤＰの値を「sendrecv」（リソース予約済みを示す値）に書き換えている。シーケンスＳ１４２で発側ＩＢＣＦ１１３は、いわばシーケンスＳ１２２の場合と逆のパラメータ書換を行っている。シーケンスＳ１２２での書換に対して発側ネットワーク１００内での整合性をとるためである。【0056】
通信部４１０は、信号調整部４９１がＳＤＰ値を書き換えた「１８３」応答を発側端末装置３１１へ送信する（シーケンスＳ１４３）。なお、発側ＩＢＣＦが、Gateway model方式に基づいて「１８３」応答を書き換えることから、シーケンスＳ１４３での「１８３」応答には「Ｄ１」、「Ｄ２」の区別が示されていない。
【0057】
シーケンスＳ１４３で「１８３」応答を受信した発側端末装置３１１は、「ＰＲＡＣＫ」（Provisional Response Acknowledgement）を送信する（シーケンスＳ１５１）。「ＰＲＡＣＫ」は、暫定応答に対する送達確認である。発側端末装置３１１は、シーケンスＳ１４３で受信した「１８３」応答のＳＤＰでPreconditionが満たされたことを確認済みであるため、「ＰＲＡＣＫ」にＳＤＰを付与せずに送信する。【0058】
シーケンスＳ１５１で通信部４１０が「ＰＲＡＣＫ」を受信した発側ＩＢＣＦ１１３では、信号調整部４９１が、「ＰＲＡＣＫ」にＳＤＰを付与する（シーケンスＳ１５２）。特に、発側ＩＢＣＦ１１３は、発側がリソース未予約から予約済みに変わったように見せるために、発側の現在の状態を示す「curr」、「remote」のＳＤＰの値を「sendrecv」としている。
【0059】
但し、発側ＩＢＣＦ１１３が発側のリソース予約済みを着側ネットワーク２００側に通知する方法は、「ＰＲＡＣＫ」にＳＤＰを付与する方法に限らない。例えば、発側ＩＢＣＦ１１３が、「ＰＲＡＣＫ」にはＳＰＤを付与せず、着側からの「２００ＯＫ（ＰＲＡＣＫ）」を受信した後に、「ＵＰＤＡＴＥ」を送信するようにしてもよい。すなわち、発側ＩＢＣＦ１１３が、「ＰＲＡＣＫ」では発側ＩＢＣＦ１１３側のリソース予約済みを通知せず、リソース予約済み通知のための信号を別途送信するようにしてもよい通信部４１０は、信号調整部４９１がＳＤＰを付与した「ＰＲＡＣＫ」を着側ネットワーク２００側へ送信する（シーケンスＳ１５３）。
【0060】
シーケンスＳ１５２で「ＰＲＡＣＫ」を受信した着側ＣＡＴ−ＡＳ２２１は、「２００ＯＫ（ＰＲＡＣＫ）」を返信する（シーケンスＳ１６１）。「２００ＯＫ（ＰＲＡＣＫ）」は、リクエストが正常に処理されたことを示す応答である。着側ＣＡＴ−ＡＳ２２１は、シーケンスＳ１５３で受信した「ＰＲＡＣＫ」のＳＤＰに応じたＳＤＰを「２００ＯＫ（ＰＲＡＣＫ）」に付している。特に、着側ＣＡＴ−ＡＳ２２１は、「ＰＲＡＣＫ」の「curr」、「local」（発側の現在の状態を示すＳＤＰ）の値「sendrecv」に基づいて、「２００ＯＫ（ＰＲＡＣＫ）」の「curr」、「remote」のＳＤＰ（発側の現在の状態を示すＳＤＰ）の値を「sendrecv」にしている。このＳＤＰ値は、発側のリソース未予約から予約済みに変更されPreconditionが満たされたことを着側ＣＡＴ−ＡＳ２２１が把握した旨を示している。
【0061】
シーケンスＳ１６２で通信部４１０が「２００ＯＫ（ＰＲＡＣＫ）」を受信した発側ＩＢＣＦ１１３では、信号調整部４９１がＳＤＰを削除する（シーケンスＳ１６２）。信号調整部４９１は、いわば、シーケンスＳ１５２でＳＤＰを付与したのと逆の処理を行っている。シーケンスＳ１５２での処理に対して発側ネットワーク１００内での整合性をとるためである。通信部４１０は、信号調整部４９１がＳＤＰを削除した「２００ＯＫ（ＰＲＡＣＫ）」を発側端末装置３１１へ送信する（シーケンスＳ１６３）。
【0062】
また、シーケンスＳ１３３で「ＩＮＶＩＴＥ」を受信した着側端末装置３２１は、呼び出しを開始すると「１８０Ｒｉｎｇｉｎｇ」を送信する（シーケンスＳ１７１）。「１８０Ｒｉｎｇｉｎｇ」は、例えば呼び出し音を鳴らすなど呼び出し中であることを示す応答である。着側端末装置３２１は、シーケンスＳ１３３で受信した「ＩＮＶＩＴＥ」のＳＤＰに応じて、発側の現在の状態を示す「curr」、「remote」のＳＤＰの値を、リソース未予約を示す「none」にしている。
なお、ＳＤＰの「Ｄ２」（Dialog２）は、発側端末装置３１１と着側端末装置３２１との間のＳＤＰ交換（セッション確立）に関するＳＤＰであることを示す。
【0063】
シーケンスＳ１７１で「１８０Ｒｉｎｇｉｎｇ」を受信した着側Ｓ−ＣＳＣＦ２１２は、着側ＣＡＴ−ＡＳ２２１へ「１８０Ｒｉｎｇｉｎｇ」を送信する（シーケンスＳ１７２）。「１８０Ｒｉｎｇｉｎｇ」を受信した着側ＣＡＴ−ＡＳ２２１は、ＣＡＴメディアを開始する（シーケンスＳ１７３）。すなわち、着側ＣＡＴ−ＡＳ２２１は、カスタマイズされた着信音の送信処理を開始する。また、着側ＣＡＴ−ＡＳ２２１は、シーケンスＳ１７２で受信した「１８０Ｒｉｎｇｉｎｇ」のＳＤＰでPreconditionが満たされていないことから「１８３（Ｄ２）」応答を発側ネットワーク１００側へ送信する（シーケンスＳ１７４）。
【0064】
Forking Model 方式では、着側ＣＡＴ−ＡＳ２２１は、受信した「１８０Ｒｉｎｇｉｎｇ」を終端し、発側ネットワーク１００側へは送信しない。一方、発側ネットワーク１００が、一旦、発側ネットワーク１００側のリソース未予約で着側ネットワーク２００側に通知した後、発側ネットワーク１００側のリソース予約済で通知することで、着側ＣＡＴ−ＡＳ２２１は、「１８０Ｒｉｎｇｉｎｇ」に相当する「１８３（Ｄ２）」応答を発側ネットワーク１００側へ送信する。【0065】
シーケンスＳ１７４で通信部４１０が「１８３（Ｄ２）」を受信した発側ＩＢＣＦ１１３では、信号調整部４９１がメソッドを書き換える（シーケンスＳ１７５）。具体的には、発側ＩＢＣＦ１１３は、「１８３（Ｄ２）」応答から「１８０Ｒｉｎｇｉｎｇ」に書き換えている。上記のように、着側ネットワーク２００がForking Modelに対応していることから、着側ＣＡＴ−ＡＳ２２１が「１８０Ｒｉｎｇｉｎｇ」を終端し、発側ネットワーク１００側へは送信しない。一方、上記のように、着側ＣＡＴ−ＡＳ２２１は「１８０Ｒｉｎｇｉｎｇ」に相当する「１８３（Ｄ２）」応答を送信する。そこで、信号調整部４９１は、得られた「１８３（Ｄ２）」を、Gateway Model方式で必要とされている「１８０Ｒｉｎｇｉｎｇ」に書き換える。
【0066】
通信部４１０は、信号調整部４９１が「１８３（Ｄ２）」応答から書き換えた「１８０Ｒｉｎｇｉｎｇ」を発側端末装置３１１へ送信する（シーケンスＳ１７６）。通信部４１０は、通信制御部４７１の呼び出し中通知送信制御部４７３の制御に従って、シーケンスＳ１７６での「１８０Ｒｉｎｇｉｎｇ」の送信を行う。着側ＣＡＴ−ＡＳ２２１は、シーケンスＳ１７４で「１８０Ｒｉｎｇｉｎｇ」を送信した後、カスタマイズされた着信音（ＲＢＴ；Ring Back Tone）を送信する（シーケンスＳ１８１）。
その後の処理については、図示及び説明を省略する。
【0067】
図３〜５の例では、発側ネットワーク１００側がGateway Model方式を採用しているのに対し、着側ネットワーク２００側がForking Model方式を採用している。発側ネットワーク１００側が採用しているGateway Model方式では、「１８０Ｒｉｎｇｉｎｇ」が送信されることが前提となっており、「１８０Ｒｉｎｇｉｎｇ」が送信されずにＲＢＴが送信された場合の処理については規定されていない。従って、発側端末装置３１１が「１８０Ｒｉｎｇｉｎｇ」を受信せずにＲＢＴを受信した場合の処理は、発側端末装置３１１の実装に依存し、発側端末装置３１１が正常に動作しない可能性がある。【0068】
これに対し、発側ＩＢＣＦ１１３が、リソース予約済みの場合でもリソース未予約として「ＩＮＶＩＴＥ」を送信することで（シーケンスＳ１１３〜Ｓ１１４）、着側ネットワーク２００側から発側ネットワーク１００側へ「１８０Ｒｉｎｇｉｎｇ」が送信されるようにすることができる（シーケンスＳ１７１〜Ｓ１７６）。これにより、発側端末装置３１１は、「１８０Ｒｉｎｇｉｎｇ」を受信してからＲＢＴを受信することができ、発側端末装置３１１が、Gateway Model方式に従って正常に動作することが期待される。【0069】
なお、「ＩＮＶＩＴＥ」の送信時に着側端末装置３２１が未だリソースを予約していない点のみが図３〜図５の例と異なる場合、着側ネットワーク２００側の「Resource available」（図３ではシーケンスＳ１１２）の位置が「ＩＮＶＩＴＥ」よりも後ろになるのみで、動作自体は図３〜５の例の場合と同様である。【0070】
図６〜図７は、発側ネットワーク１００側、着側ネットワーク２００側のいずれもPreconditionをサポートしている場合の、ＩＭＳネットワーク１の動作の第二の例を示す説明図である。発側ネットワーク１００は、Gateway model方式を採用しており、着側ネットワーク２００は、Forking Model方式を採用している。同図では、発側端末装置３１１が「ＩＮＶＩＴＥ」を送信する際に、着側端末装置３２１は既にリソースを予約出来ているが、発側端末装置３１１はリソースを未予約である場合の例を示す。着側端末装置３２１は、シーケンスＳ２１１でリソースを予約済みである。
【0071】
同図の処理で、発側端末装置３１１は「ＩＮＶＩＴＥ」を送信している（シーケンスＳ２２１）。図６〜図７の例では、図３の場合と異なり、発側端末装置３１１は未だリソースを予約していない。このため、発側端末装置３１１は、「ＩＮＶＩＴＥ」の「curr」、「local」のＳＤＰ（発側の現在の状態を示すＳＤＰ）の値を「none」（リソース未予約を示す値）にしている。このため、図６では、図３のシーケンスＳ１２２の場合と異なり、発側ＩＢＣＦ１１３は、「ＩＮＶＩＴＥ」のＳＤＰ値を変更せずにそのまま着側ネットワーク２００側へ送信している。具体的には、リソース予約状況判定部４８２が、ＳＤＰ値を参照して、発側端末装置３１１がリソースを未予約であると判定する。この判定結果に応じて、通信制御部４７１のセッション開始要求送信制御部４７２が通信部４１０を制御して「ＩＮＶＩＴＥ」（ＳＤＰ値を書き換えていない「ＩＮＶＩＴＥ」）を着側ネットワーク２００側へ転送させている。【0072】
シーケンスＳ２３１〜Ｓ２３３は、図３のシーケンスＳ１３１〜Ｓ１３３の場合と同様である。また、図３の場合と同様、着側ＣＡＴ−ＡＳ２２１は発側ネットワーク１００側へ「１８３（Ｄ１）」応答を送信している（シーケンスＳ２４１）。図６では、図３の場合と異なり、着側ＣＡＴ−ＡＳ２２１が送信した「１８３（Ｄ１）」応答のＳＤＰの値（特に、「curr」、「remote」のＳＤＰの値「none」）が、現在の状態と整合している。このため、発側ＩＢＣＦ１１３は、「１８３（Ｄ１）」応答のＳＤＰを書き換えずにそのまま発側端末装置３１１へ送信している。具体的には、通信制御部４７１が通信部４１０を制御して、「１８３」応答を発側端末装置３１１へ転送させている。
【0073】
「１８３」応答を受信した発側端末装置３１１は、「ＰＲＡＣＫ」を着側ネットワーク２００側へ送信する（シーケンスＳ２４２）。ここでは、「１８３」応答から状態変化がないため、発側端末装置３１１は状態を示すＳＤＰを付さずに「ＰＲＡＣＫ」を送信している。この「ＰＲＡＣＫ」は発側ネットワーク１００及び着側ネットワーク２００の現在の状態に整合しているので、発側ＩＢＣＦ１１３は、「ＰＲＡＣＫ」をそのまま着側ネットワーク２００側へ送信している。具体的には、通信制御部４７１が通信部４１０を制御して「ＰＲＡＣＫ」を発側ネットワーク１００側へ送信させている。Preconditionが整っていないことから、着側ネットワーク２００側では着側ＣＡＴ−ＡＳ２２１が「ＰＲＡＣＫ」を終端して「２００ＯＫ（ＰＲＡＣＫ）」を応答している（シーケンスＳ２４３）。この「２００ＯＫ」についても発側ＩＢＣＦ１１３は、そのまま発側端末装置３１１へ送信している。具体的には、通信制御部４７１が通信部４１０を制御して「２００ＯＫ」を発側端末装置３１１へ送信させている。
【0074】
シーケンスＳ２５１〜Ｓ２５２は、図５のシーケンスＳ１７１〜Ｓ１７２と同様である。また、リソースを予約した発側端末装置３１１は（シーケンスＳ２６１）、「ＵＰＤＡＴＥ」を着側ネットワーク２００側へ送信する（シーケンスＳ２６２）。「ＵＰＤＡＴＥ」は、ＳＤＰの更新を通知するメソッドである。この「ＵＰＤＡＴＥ」についても発側ＩＢＣＦ１１３は、そのまま発側端末装置３１１へ送信している。具体的には、通信制御部４７１が通信部４１０を制御して「ＵＰＤＡＴＥ」を発側端末装置３１１へ送信させている。着側ＣＡＴ−ＡＳ２２１は、「ＵＰＤＡＴＥ」を参照することで、Preconditionが整ったことを検出することができる。
【0075】
シーケンスＳ２６２で「ＵＰＤＡＴＥ」を受信した着側ＣＡＴ−ＡＳ２２１は、「２００ＯＫ（ＵＰＤＡＴＥ）」を応答している（シーケンスＳ２６３）。この「２００ＯＫ」についても発側ＩＢＣＦ１１３は、そのまま発側端末装置３１１へ送信している。具体的には、通信制御部４７１が通信部４１０を制御して「２００ＯＫ」を発側端末装置３１１へ送信させている。【0076】
シーケンスＳ２７１〜Ｓ２７４は、図５のシーケンスＳ１７３〜Ｓ１７６と同様である。シーケンスＳ２８１は、図５のシーケンスＳ１８１と同様である。図７の場合も図５の場合と同様、発側端末装置３１１は、「１８０Ｒｉｎｇｉｎｇ」を受信した後、ＲＢＴを受信している。シーケンスＳ２８１より後の処理については、図示及び説明を省略する。
なお、「ＩＮＶＩＴＥ」の送信時に着側端末装置３２１が未だリソースを予約していない点のみが図６〜図７の例と異なる場合、着側ネットワーク２００側の「Resource available」（図６ではシーケンスS２１１）の位置が「ＩＮＶＩＴＥ」よりも後ろになるのみで、動作自体は図６〜図７の例の場合と同様である。
【0077】
図８〜図９は、着側ネットワーク２００がPreconditionをサポートしているが、発側ネットワーク１００がPreconditionをサポートしていない場合の、ＩＭＳネットワーク１の動作の例を示す説明図である。発側ネットワーク１００は、Gateway model方式を採用しており、着側ネットワーク２００は、Forking Model方式を採用している。同図では、発側端末装置３１１が「ＩＮＶＩＴＥ」を送信する際に、着側端末装置３２１がリソースを未予約である場合の例を示す。発側ネットワーク１００がPreconditionをサポートしていないことから、シーケンスＳ３１１に示されるように、発側端末装置３１１は、「ＩＮＶＩＴＥ」を送信する際には必ずリソースを使用可能になっている。
【0078】
同図の処理で、発側端末装置３１１は「ＩＮＶＩＴＥ」を送信している（シーケンスＳ３１２）。発側端末装置３１１がPreconditionに未対応である場合、「ＩＮＶＩＴＥ」にＳＤＰは付与されない。この場合、着側端末装置３２１がリソース予約を完了しているか否かにかかわらず、発側ネットワーク１００の各機器（特に発側端末装置３１１）は、着側端末装置３２１がリソース予約を完了している前提で動作する。シーケンスＳ３１３〜Ｓ３１５は、図３のシーケンスＳ１３１〜Ｓ１３３と同様である。
【0079】
シーケンスＳ３１５で「ＩＮＶＩＴＥ」を受信した着側端末装置３２１は、リソースを予約して（シーケンスＳ３１６）、呼び出しを開始すると、「１８０Ｒｉｎｇｉｎｇ」を送信する（シーケンスＳ３１７）。そして、着側Ｓ−ＣＳＣＦ２１２は、シーケンスＳ３１７で受信した「１８０Ｒｉｎｇｉｎｇ」を着側ＣＡＴ−ＡＳ２２１へ送信する（シーケンスＳ３１８）。
着側ＣＡＴ−ＡＳ２２１は、受信した「１８０Ｒｉｎｇｉｎｇ」を終端する。また、着側ＣＡＴ−ＡＳ２２１は、シーケンスＳ３１２で受信した「ＩＮＶＩＴＥ」に対応して「１８３（Ｄ１）」応答を送信する（シーケンスＳ３１９）。その際、着側ＣＡＴ−ＡＳ２２１は、「１８３（Ｄ１）」応答のP-Early-Media header fieldに「sendrecv」パラメータを設定して送信する。
【0080】
なお、Forking Model方式におけるDialog「Ｄ１」と「Ｄ２」とは、並列（Parallel）に実行される。従って、着側ＣＡＴ−ＡＳ２２１が「１８３（Ｄ１）」応答を送信するタイミングは、図８の例のタイミングに限らない。例えば、着側ＣＡＴ−ＡＳ２２１がシーケンスＳ３１８の「１８０Ｒｉｎｇｉｎｇ（Ｄ２）」を受信する前にシーケンスＳ３１９の「１８３（Ｄ１）」応答を送信することもあり得る。【0081】
通信部４１０が「１８３」応答を受信した発側ＩＢＣＦ１１３では、アーリメディア対応判定部４８３が、得られた「１８３」応答のP-Early-Media header fieldに「sendrecv」パラメータが設定されていることを検出する。発側ＩＢＣＦ１１３は、「１８３」応答自体はそのまま発側端末装置３１１へ送信する。具体的には、通信制御部４７１が通信部４１０を制御して「１８３」応答を発側端末装置３１１へ送信させる。「１８３」応答を受信した発側端末装置３１１は、「ＰＲＡＣＫ」を送信する（シーケンスＳ３２１）。発側ＩＢＣＦ１１３は、この「ＰＲＡＣＫ」をそのまま着側ネットワーク２００側へ送信する。具体的には、通信部４１０が「ＰＲＡＣＫ」を受信すると、通信制御部４７１が通信部４１０を制御して、この「ＰＲＡＣＫ」を着側ネットワーク２００側へ転送させる。
【0082】
シーケンスＳ３２１で「ＰＲＡＣＫ」を受信した着側ＣＡＴ−ＡＳ２２１は、ＣＡＴメディアを開始する（シーケンスＳ３２２）。すなわち、着側ＣＡＴ−ＡＳ２２１は、カスタマイズされた着信音の送信処理を開始する。また、着側ＣＡＴ−ＡＳ２２１は、発側ネットワーク１００側に対して「２００ＯＫ（ＰＲＡＣＫ）」を送信する（シーケンスＳ３２３）。通信部４１０が「２００ＯＫ（ＰＲＡＣＫ）」を受信した発側ＩＢＣＦ１１３では、処理完了判定部４８４が「２００ＯＫ（ＰＲＡＣＫ）」であることを確認する。そして、通信部４１０は、「２００ＯＫ（ＰＲＡＣＫ）」をそのまま発側端末装置３１１へ送信する（シーケンスＳ３２４）。具体的には、通信制御部４７１の呼び出し中通知送信制御部４７３が通信部４１０を制御して、この「２００ＯＫ（ＰＲＡＣＫ）」を発側端末装置３１１へ転送させる。
【0083】
また、「２００ＯＫ（ＰＲＡＣＫ）」を確認した呼び出し中通知送信制御部４７３は、「１８０Ｒｉｎｇｉｎｇ」を生成する。そして、通信部４１０が、呼び出し中通知送信制御部４７３が生成した「１８０Ｒｉｎｇｉｎｇ」を呼び出し中通知送信制御部４７３の制御に従って発側端末装置３１１へ送信する（シーケンスＳ３２５）。また、着側ＣＡＴ−ＡＳ２２１は、シーケンスＳ３２３で「２００ＯＫ（ＰＲＡＣＫ）」を送信した後、ＲＢＴを送信する（シーケンスＳ３３１）。
その後の処理については、図示及び説明を省略する。
【0084】
発側ネットワーク１００がPreconditionに対応していない場合、発側ネットワーク１００、着側ネットワーク２００共にPreconditionに対応している場合とは異なり、発側ネットワーク１００の側のリソース未予約をＳＤＰで着側ネットワーク２００側に通知することはできず、これによって「１８３（Ｄ２）」応答を得られない可能性がある。そこで、発側ＩＢＣＦ１１３は、着側ネットワーク２００側からの「１８３（Ｄ１）」応答のP-Early-Media header fieldの「sendrecv」パラメータを確認することで、後に着側ネットワーク２００側からＲＢＴが送信されることを確認しておく。そして、発側ＩＢＣＦ１１３は、準備完了を示す「２００ＯＫ（ＰＲＡＣＫ）」を検出すると、「１８０Ｒｉｎｇｉｎｇ」を生成して発側端末装置３１１へ送信する。これにより、発側端末装置３１１は、「１８０Ｒｉｎｇｉｎｇ」を受信してからＲＢＴを受信することができ、発側端末装置３１１が、Gateway Model方式に従って正常に動作することが期待される。【0085】
なお、図８〜図９を参照して説明した方法は、発側ネットワーク１００側がPreconditionに対応している場合にも適用できる。なお、「ＩＮＶＩＴＥ」の送信時に着側端末装置３２１が既にリソースを予約している点のみが図８〜図９の例と異なる場合、着側ネットワーク２００側の「Resource available」（図９ではシーケンスＳ３１６）の位置が「ＩＮＶＩＴＥ」よりも前になるのみで、動作自体は図８〜図９の例の場合と同様である。
【0086】
図１０〜図１１は、発側ネットワーク１００がPreconditionをサポートしているが、着側ネットワーク２００がPreconditionをサポートしていない場合の、ＩＭＳネットワーク１の動作の例を示す説明図である。発側ネットワーク１００は、Gateway model方式を採用しており、着側ネットワーク２００は、Forking Model方式を採用している。同図では、発側端末装置３１１が「ＩＮＶＩＴＥ」を送信する際に、発側端末装置３１１がリソースを未予約である場合の例を示す。着側ネットワーク２００がPreconditionをサポートしていないことから、シーケンスＳ４１１に示されるように、着側端末装置３２１は、「ＩＮＶＩＴＥ」を受信する際には必ずリソースを使用可能になっている。
【0087】
同図の処理で、発側端末装置３１１は「ＩＮＶＩＴＥ」を送信している（シーケンスＳ４２１）。発側端末装置３１１は、Preconditionに対応しているため、「ＩＮＶＩＴＥ」にPreconditionのＳＤＰを付して送信している。但し、着側ネットワーク２００側がPreconditionに未対応であるため、着側ネットワーク２００側の装置はPreconditionのＳＤＰを無視する。【0088】
シーケンスＳ４２１で「ＩＮＶＩＴＥ」を受信した着側ＣＡＴ−ＡＳ２２１は、ＣＡＴのリソースを準備する（シーケンスＳ４２２）。着側ＣＡＴ−ＡＳ２２１は、カスタマイズされた着信音を送信可能になっている。そして、着側ＣＡＴ−ＡＳ２２１は、着側Ｓ−ＣＳＣＦ２１２に「ＩＮＶＩＴＥ」を送信する（シーケンスＳ４２３）。着側Ｓ−ＣＳＣＦ２１２は、着側端末装置３２１に「ＩＮＶＩＴＥ」を送信する（シーケンスＳ４２４）。
【0089】
「ＩＮＶＩＴＥ」を受信した着側端末装置３２１は、呼び出しを開始すると「１８０Ｒｉｎｇｉｎｇ」を送信する（シーケンスＳ４２５）。シーケンスＳ４２５で「１８０Ｒｉｎｇｉｎｇ」を受信した着側Ｓ−ＣＳＣＦ２１２は、「１８０Ｒｉｎｇｉｎｇ」を着側ＣＡＴ−ＡＳ２２１に送信する（シーケンスＳ４２６）。
【0090】
着側ＣＡＴ−ＡＳ２２１は、受信した「１８０Ｒｉｎｇｉｎｇ」に対して「１８３（Ｄ１）」応答を送信する（シーケンスＳ４２７）。その際、着側ＣＡＴ−ＡＳ２２１は、「１８３（Ｄ１）」応答のP-Early-Media header fieldに「sendrecv」パラメータを設定して送信する。通信部４１０が「１８３」応答を受信した発側ＩＢＣＦ１１３では、アーリメディア対応判定部４８３が、得られた「１８３」応答のP-Early-Media header fieldに「sendrecv」パラメータが設定されていることを検出する。発側ＩＢＣＦ１１３は、「１８３」応答自体はそのまま発側端末装置３１１へ送信する。具体的には、通信制御部４７１が通信部４１０を制御して「１８３」応答を発側端末装置３１１へ送信させる。
【0091】
「１８３」応答を受信した発側端末装置３１１は、「ＰＲＡＣＫ」を送信する（シーケンスＳ４２８）。発側ＩＢＣＦ１１３は、この「ＰＲＡＣＫ」をそのまま着側ネットワーク２００側へ送信する。具体的には、通信部４１０が「ＰＲＡＣＫ」を受信すると、通信制御部４７１が通信部４１０を制御して、この「ＰＲＡＣＫ」を着側ネットワーク２００側へ転送させる。シーケンスＳ４２８で「ＰＲＡＣＫ」を受信した着側ＣＡＴ−ＡＳ２２１は、ＣＡＴメディアを開始する（シーケンスＳ４２９）。すなわち、着側ＣＡＴ−ＡＳ２２１は、カスタマイズされた着信音の送信処理を開始する。
【0092】
また、着側ＣＡＴ−ＡＳ２２１は、発側ネットワーク１００側に対して「２００ＯＫ（ＰＲＡＣＫ）」を送信する（シーケンスＳ４３１）。通信部４１０が「２００ＯＫ（ＰＲＡＣＫ）」を受信した発側ＩＢＣＦ１１３では、信号調整部４９１が「２００ＯＫ（ＰＲＡＣＫ）」であることを確認する。そして、発側ネットワーク１００は、「２００ＯＫ（ＰＲＡＣＫ）」をそのまま発側端末装置３１１へ送信する（シーケンスＳ４３２）。具体的には、通信制御部４７１が通信部４１０を制御して、この「２００ＯＫ（ＰＲＡＣＫ）」を発側端末装置３１１へ転送させる。また、発側端末装置３１１はリソースを予約している（シーケンスＳ４３３）。
【0093】
また、「２００ＯＫ（ＰＲＡＣＫ）」を確認した発側ＩＢＣＦ１１３は、「１８０Ｒｉｎｇｉｎｇ」を生成して発側端末装置３１１へ送信する（シーケンスＳ４３４）。具体的には、呼び出し中通知送信制御部４７３が、「１８０Ｒｉｎｇｉｎｇ」を生成する。そして、呼び出し中通知送信制御部４７３は、通信部４１０を制御して当該「１８０Ｒｉｎｇｉｎｇ」を発側端末装置３１１へ送信させる。着側ＣＡＴ−ＡＳ２２１は、シーケンスＳ４３１で「２００ＯＫ（ＰＲＡＣＫ）」を送信した後、ＲＢＴを送信する（シーケンスＳ４４１）。
その後の処理については、図示及び説明を省略する。
【0094】
着側ネットワーク２００がPreconditionに対応していない場合も、発側ネットワーク１００がpreconditionに対応していない図８〜図９の例の場合と同様、発側ネットワーク１００の側のリソース未予約をＳＤＰで着側ネットワーク２００側に通知することはできず、これによって「１８３（Ｄ２）」応答を得られない可能性がある。そこで、発側ＩＢＣＦ１１３は、着側ネットワーク２００側からの「１８３（Ｄ１）」応答のP-Early-Media header fieldの「sendrecv」パラメータの設定を確認することで、後に着側ネットワーク２００側からＲＢＴが送信されることを確認しておく。そして、発側ＩＢＣＦ１１３は、準備完了を示す「２００ＯＫ（ＰＲＡＣＫ）」を検出すると、「１８０Ｒｉｎｇｉｎｇ」を生成して発側端末装置３１１へ送信する。これにより、発側端末装置３１１は、「１８０Ｒｉｎｇｉｎｇ」を受信してからＲＢＴを受信することができ、発側端末装置３１１が、Gateway Model方式に従って正常に動作することが期待される。【0095】
なお、発側ＩＢＣＦ１１３が「１８０Ｒｉｎｇｉｎｇ」を生成して送信するタイミングは、図８〜図１１を参照して説明した「２００ＯＫ（ＰＲＡＣＫ）」を受信したタイミングに限らない。例えば、発側ＩＢＣＦ１１３が「１８ｘ（Ｄ１）」でP-Early-Media header fieldに「sendrecv」パラメータが設定された応答を受信したタイミングで「１８０Ｒｉｎｇｉｎｇ」を生成して発側端末装置３１１へ送信するようにしてもよい。【0096】
なお、図１０〜図１１を参照して説明した方法は、着側ネットワーク２００側がPreconditionに対応している場合にも適用できる。なお、「ＩＮＶＩＴＥ」の送信時に発側端末装置３１１が既にリソースを予約している点のみが図１０〜図１１の例と異なる場合、発側ネットワーク１００側の「Resource available」（図１１ではシーケンスＳ４３３）の位置が「ＩＮＶＩＴＥ」よりも前になるのみで、動作自体は図１０〜図１１の例の場合と同様である。
【0097】
なお、着側ネットワーク２００に加えて発側ネットワーク１００もPreconditionに対応していない場合、発側端末装置３１１は、「ＩＮＶＩＴＥ」送信前にリソースを使用可能な状態になっており、また、着側ネットワーク２００側も、発側ネットワーク１００側がリソースを使用可能であることを前提に動作する。従って、この場合のＩＭＳネットワーク１の動作としては、図１０〜図１１の例で「ＩＮＶＩＴＥ」の送信時に発側端末装置３１１が既にリソースを予約している場合と同様であり、ＩＭＳネットワーク１の動作の概要は、図１０〜図１１の例の場合と同様である。【0098】
発側ネットワーク１００側及び着側ネットワーク２００側のいずれもPreconditionに対応している場合は、図３〜図７を参照して説明した、発側ネットワーク１００側のリソース未予約をＳＤＰで通知する方法を用いることができる。以下、この方法を第一の方法と称する。一方、発側ネットワーク１００側及び着側ネットワーク２００側のうちいずれか一方又は両方がPreconditionに対応していない場合は、図８〜図１１を参照して説明した、「１８ｘ」応答のP-Early-Media header fieldの「sendrecv」パラメータの設定を検出する方法を用いることができる。以下、この方法を第二の方法と称する。
【0099】
例えば、発側ＩＢＣＦ１１３は、図１２に示す手順に基づいて第一の方法及び第二の方法のうち何れを用いるかを決定することができる。図１２は、発側ＩＢＣＦ１１３が、第一の方法及び第二の方法のうちいずれを用いるかを決定する手順の例を示す説明図である。
同図の処理にて、サポート判定部４８１は、発側ネットワーク１００側がPreconditionに対応しているか否かを判定する（ステップＳ５０１）。例えば、サポート判定部４８１は、上述したように発側端末装置３１１からの「ＩＮＶＩＴＥ」のヘッダを参照してステップＳ５０１での判定を行う。
【0100】
発側ネットワーク１００側が対応していると判定した場合（ステップＳ５０１：ＹＥＳ）、サポート判定部４８１は、着側ネットワーク２００側がPreconditionに対応しているか否かを判定する（ステップＳ５０２）。例えば、サポート判定部４８１は、上述したように着側ネットワーク２００側からの応答信号（例えば「１８３（Ｄ１）」応答）のパラメータを参照して、着側ネットワーク２００側がPreconditionをサポートしているか否かを判定する。【0101】
着側ネットワーク２００側が対応していると判定した場合（ステップＳ５０２：ＹＥＳ）、制御部４６０は、第一の方法を用いることに決定する（ステップＳ５１１）。ステップＳ５１１の後、図１２の処理を終了する。一方、ステップＳ５０１で、発側ネットワーク１００側がPreconditionに対応していないと判定した場合（ステップＳ５０１：ＮＯ）、制御部４６０は、第二の方法を用いることに決定する（ステップＳ５２１）。ステップＳ５２１の後、図１２の処理を終了する。
また、ステップＳ５０２で、着側ネットワーク２００側がPreconditionに対応していないと判定した場合（ステップＳ５０２：ＮＯ）も、ステップＳ５２１へ進む。
【0102】
以上のように、リソース予約状況判定部４８２は、発側端末装置３１１が送信し通信部４１０が受信した「ＩＮＶＩＴＥ」に含まれ、発側端末装置３１１のリソース予約状況を示すパラメータの値（ＳＤＰ値）が、予約済みを示す値か否かを判定する。リソース予約状況判定部４８２が、ＳＤＰ値が予約済みを示す値であると判定した場合、パラメータ値書換部４９２は、当該ＳＤＰ値を、リソース未予約を示す値に書き換える。リソース予約状況判定部４８２が、ＳＤＰ値が予約済みを示す値であると判定した場合、セッション開始要求送信制御部４７２は、パラメータ値書換部４９２がＳＤＰ値を書き換えた「ＩＮＶＩＴＥ」を着側ネットワーク２００へ送信するよう通信部４１０を制御する。一方、リソース予約状況判定部４８２が、ＳＤＰ値が予約済みを示す値でないと判定した場合、セッション開始要求送信制御部４７２は、発側端末装置３１１から受信した「ＩＮＶＩＴＥ」を着側ネットワーク２００へ送信するよう通信部４１０を制御する。
「ＩＮＶＩＴＥ」に対する「１８３（Ｄ２）」応答が着側端末装置におけるソース予約済みを示す場合、呼び出し中通知送信制御部は、「１８０Ｒｉｎｇｉｎｇ」を発側端末装置３１１へ送信するよう通信部４１０を制御する。
【0103】
これにより、発側端末装置３１１は、「１８０Ｒｉｎｇｉｎｇ」を受信してからＲＢＴを受信することができ、発側端末装置３１１が、Gateway Model方式に従って正常に動作することが期待される。従って、発側ＩＢＣＦ１１３によれば、ＩＭＳにおいて発呼側と着呼側とでアーリメディアの方式が異なる場合でも、アーリメディアによるサービスを提供することができる。【0104】
また、サポート判定部４８１は、発側ネットワーク１００及び発側端末装置３１１、着側ネットワーク２００及び着側端末装置３２１がいずれもPreconditionに対応しているか否かを通信部４１０の受信信号に基づいて判定する。サポート判定部４８１が、発側ネットワーク１００及び発側端末装置３１１、着側ネットワーク２００及び着側端末装置３２１の少なくともいずれかがPreconditionに対応していないと判定した場合、アーリメディア対応判定部４８３は、着側ネットワーク２００からの「１８３（Ｄ１）」応答のP-Early-Media header fieldに「sendrecv」パラメータが設定されているか否かを判定する。処理完了判定部４８４は、アーリメディア対応判定部が、「１８３（Ｄ１）」応答のP-Early-Media header fieldに「sendrecv」パラメータが設定されていると判定した後、着側ネットワーク２００から「２００ＯＫ（ＰＲＡＣＫ）」を通信部４１０が受信したか否かを判定する。
呼び出し中通知送信制御部４７３は、処理完了判定部４８４が、「２００ＯＫ（ＰＲＡＣＫ）」を通信部４１０が受信したと判定した場合、発側端末装置３１１へ「１８０Ｒｉｎｇｉｎｇ」を送信するよう通信部４１０を制御する。
また、リソース予約状況判定部４８２は、サポート判定部４８１が、発側ネットワーク１００及び発側端末装置３１１、着側ネットワーク２００及び着側端末装置３２１がいずれもPreconditionに対応していると判定した場合に、発側端末装置３１１が送信し通信部４１０が受信した「ＩＮＶＩＴＥ」に含まれ、発側端末装置３１１のリソース予約状況を示すパラメータの値（ＳＤＰ値）が、予約済みを示す値か否かを判定する。
【0105】
これにより、発側端末装置３１１は、発側ネットワーク１００及び発側端末装置３１１、着側ネットワーク２００及び着側端末装置３２１のいずれかがPreconditionに対応していない場合でも、「１８０Ｒｉｎｇｉｎｇ」を受信してからＲＢＴを受信することができ、発側端末装置３１１が、Gateway Model方式に従って正常に動作することが期待される。従って、発側ＩＢＣＦ１１３によれば、発側端末装置３１１は、ＩＭＳにおいて発呼側と着呼側とでアーリメディアの方式が異なり、かつ、発側ネットワーク１００及び発側端末装置３１１、着側ネットワーク２００及び着側端末装置３２１がいずれかがPreconditionに対応していない場合でも、アーリメディアによるサービスを提供することができる。【0106】
また、アーリメディア対応判定部４８３は、着側ネットワーク２００からの「１８３（Ｄ１）」応答のP-Early-Media header fieldに「sendrecv」パラメータが設定されているか否かを判定する。処理完了判定部４８４は、アーリメディア対応判定部が、「１８３（Ｄ１）」応答のP-Early-Media header fieldに「sendrecv」パラメータが設定されていると判定した後、着側ネットワーク２００から「２００ＯＫ（ＰＲＡＣＫ）」を通信部４１０が受信したか否かを判定する。呼び出し中通知送信制御部４７３は、処理完了判定部４８４が、「２００ＯＫ（ＰＲＡＣＫ）」を通信部４１０が受信したと判定した場合、発側端末装置３１１へ「１８０Ｒｉｎｇｉｎｇ」を送信するよう通信部４１０を制御する。
【0107】
これにより、発側端末装置３１１は、発側ネットワーク１００及び発側端末装置３１１、着側ネットワーク２００及び着側端末装置３２１のいずれかがPreconditionに対応していない場合でも、「１８０Ｒｉｎｇｉｎｇ」を受信してからＲＢＴを受信することができ、発側端末装置３１１が、Gateway Model方式に従って正常に動作することが期待される。従って、発側ＩＢＣＦ１１３によれば、発側端末装置３１１は、ＩＭＳにおいて発呼側と着呼側とでアーリメディアの方式が異なり、かつ、発側ネットワーク１００及び発側端末装置３１１、着側ネットワーク２００及び着側端末装置３２１がいずれかがPreconditionに対応していない場合でも、アーリメディアによるサービスを提供することができる。【0108】
次に、図１３及び図１４を参照して、本発明の最小構成について説明する。図１３は、本発明に係るアーリメディアサービス制御装置の最小構成の第一の例を示す説明図である。同図に示すアーリメディアサービス制御装置１０は、通信部１１と、リソース予約状況判定部１２と、パラメータ値書換部１３と、セッション開始要求送信制御部１４と、呼び出し中通知送信制御部１５とを備える。
【0109】
かかる構成にて、リソース予約状況判定部１２は、呼び出し中通知受信を要件の１つとしてアーリメディアのサービス実行を開始するアーリメディア方式のセッション開始要求発側端末装置が送信し通信部１１が受信したセッション開始要求に含まれ、セッション開始要求発側端末装置のリソース予約状況を示すパラメータの値が、予約済みを示す値か否かを判定する。また、パラメータ値書換部１３は、リソース予約状況判定部１２が、パラメータの値が予約済みを示す値であると判定した場合、当該パラメータの値をリソース未予約を示す値に書き換える。
また、セッション開始要求送信制御部１４は、リソース予約状況判定部１２が、パラメータの値が予約済みを示す値であると判定した場合、パラメータ値書換部１３がパラメータの値を書き換えたセッション開始要求をセッション開始要求着側ネットワークへ送信するよう通信部１１を制御し、リソース予約状況判定部１２が、パラメータの値が予約済みを示す値でないと判定した場合、セッション開始要求発側端末装置から受信したセッション開始要求をセッション開始要求着側ネットワークへ送信するよう通信部１１を制御する。
そして、呼び出し中通知送信制御部１５は、通信部１１がセッション開始要求着側ネットワークへ送信したセッション開始要求に対して送信され、セッション開始要求着側端末装置におけるリソース予約済みを示す応答を通信部１１が受信した場合、呼び出し中通知をセッション開始要求発側端末装置へ送信するよう通信部１１を制御する。
【0110】
これにより、セッション開始要求発側端末装置は、呼び出し中通知を受信してからアーリメディアサービスのメディア（データ）を受信することができる。これにより、セッション開始要求発側端末装置が、呼び出し中通知を受信してからアーリメディアサービスのメディアを受信する方式に従って正常に動作することが期待される。従って、アーリメディアサービス制御装置１０によれば、ＩＭＳにおいて発呼側と着呼側とでアーリメディアの方式が異なる場合でも、アーリメディアによるサービスを提供することができる。【0111】
図１４は、本発明に係るアーリメディアサービス制御装置の最小構成の第二の例を示す説明図である。同図に示すアーリメディアサービス制御装置２０は、通信部２１と、アーリメディア対応判定部２２と、処理完了判定部２３と、呼び出し中通知送信制御部２４と、を備える。かかる構成にて、アーリメディア対応判定部２２は、セッション開始要求に対する応答にセッション開始要求着側ネットワークがアーリメディアに対応していることを示すアーリメディア対応情報が含まれるか否かを判定する。
また、処理完了判定部２３は、アーリメディア対応判定部２２が、応答にアーリメディア対応情報が含まれると判定した後、セッション開始要求着側ネットワークからリクエスト正常処理完了を示す処理完了信号を通信部が受信したか否かを判定する。
そして、呼び出し中通知送信制御部２４は、処理完了判定部２３が、処理完了信号を通信部２１が受信したと判定した場合、呼び出し中通知受信を要件の１つとしてアーリメディアのサービス実行を開始するアーリメディア方式のセッション開始要求発側端末装置に呼び出し中通知を送信するよう通信部２１を制御する。
【0112】
これにより、セッション開始要求発側ネットワーク及びセッション開始要求発側端末装置、セッション開始要求着側ネットワーク及びセッション開始要求着側端末装置のいずれかがリソース予約通知の規定に対応していない場合でも、セッション開始要求発側端末装置は、呼び出し中通知を受信してからアーリメディアサービスのメディアを受信することができる。これにより、セッション開始要求発側端末装置が、呼び出し中通知を受信してからアーリメディアサービスのメディアを受信する方式に従って正常に動作することが期待される。従って、アーリメディアサービス制御装置１０によれば、ＩＭＳにおいて発呼側と着呼側とでアーリメディアの方式が異なり、かつ、セッション開始要求発側ネットワーク及びセッション開始要求発側端末装置、セッション開始要求着側ネットワーク及びセッション開始要求着側端末装置のいずれかがリソース予約通知の規定に対応していない場合でも、アーリメディアによるサービスを提供することができる。【0113】
なお、発側ＩＢＣＦ１１３の機能の全部または一部を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより各部の処理を行ってもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。また上記プログラムは、前述した機能の一部を実現するためのものであっても良く、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであっても良い。
【0114】
以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。以上、実施形態を参照して本願発明を説明したが、本願発明は上記実施形態に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。
この出願は、２０１６年２月２９日に出願された日本出願特願２０１６−０３８２７７を基礎とする優先権を主張し、その開示の全てをここに取り込む。
【符号の説明】
【0115】
１ ＩＭＳネットワーク１０、２０ アーリメディアサービス制御装置
１１、２１、４１０ 通信部
１２、４８２ リソース予約状況判定部
１３、４９２ パラメータ値書換部
１４、４７２ セッション開始要求送信制御部
１５、２４、４７３ 呼び出し中通知送信制御部
２２、４８３ アーリメディア対応判定部
２３、４８４ 処理完了判定部
１００ 発側ネットワーク
１１１ 発側Ｐ−ＣＳＣＦ
１１２ 発側Ｓ−ＣＳＣＦ
１１３ 発側ＩＢＣＦ
１１４ 発側ＴｒＧＷ
２００ 着側ネットワーク
２１１ 着側Ｐ−ＣＳＣＦ
２１２ 着側Ｓ−ＣＳＣＦ
２１３ 着側ＩＢＣＦ
２１４ 着側ＴｒＧＷ
２２１ 着側ＣＡＴ−ＡＳ
３１１ 発側端末装置
３２１ 着側端末装置
４５０ 記憶部
４６０ 制御部
４７１ 通信制御部
４８１ サポート判定部
４９１ 信号調整部