(57)【要約】【課題】セッション要求先端末がPrecondition非対応であっても、セッション確立におけるアーリーメディアのメディアクリッピングを生じないようにする方法等を提供する。【解決手段】セッション要求元となる第１の端末と、セッション要求先となる第２の端末と通信可能な、ＩＭＳのＳＩＰサーバであって、第１の端末からセッション開始要求を受信した際に、第１の端末に対してリソース確保を完了させる第１のステップと、第１の端末からのセッション開始要求を第２の端末へ送信し、第２の端末に対してリソース確保を完了させ、その応答を第１の端末へ送信する第２のステップと、第２の端末からアーリーメディア(early media)を受信し、そのアーリーメディアを第１の端末へ転送する第３のステップとを有する。【選択図】図２
2015162827.tif 000002
【特許請求の範囲】
【請求項１】
ＩＰベースのマルチメディアネットワークを介して、セッション要求元となる第１の端末と、セッション要求先となる第２の端末と通信可能なＳＩＰ(Session Initiation Protocol)サーバのセッション接続方法において、
第１の端末からセッション開始要求を受信した際に、第１の端末に対してリソース確保を完了させる第１のステップと、
第１の端末からのセッション開始要求を第２の端末へ送信し、第２の端末に対してリソース確保を完了させ、その応答を第１の端末へ送信する第２のステップと、
第２の端末からアーリーメディア(early media)を受信し、該アーリーメディアを第１の端末へ転送する第３のステップと
を有することを特徴とするＳＩＰサーバのセッション接続方法。
【請求項２】
第１のステップについて、ＳＩＰサーバが、
第１の端末からセッション開始要求を受信し、
リソース確保を要求する暫定応答を第１の端末へ返信し、
リソース確保が完了した第１の端末から、リソース確保完了通知を受信し、
成功応答を第１の端末へ返信する
ことを特徴とする請求項１に記載のＳＩＰサーバのセッション接続方法。
【請求項３】
第２のステップについて、ＳＩＰサーバが、
第１の端末からの前記セッション開始要求を第２の端末へ送信し、
リソース確保が完了した第２の端末からアーリーメディア提供通知の暫定応答を受信し、
前記暫定応答を第１の端末へ送信する
ことを特徴とする請求項１又は２に記載のＳＩＰサーバのセッション接続方法。
【請求項４】
第１の端末は、ＳＩＰサーバとの間で、アーリーダイアログシーケンスの要求／応答のＳＤＰオファー／アンサーに記述されるPrecondition制御に対応のものであり、
第２の端末は、ＳＩＰサーバとの間で、アーリーダイアログシーケンスの要求／応答のＳＤＰオファー／アンサーに記述されるPrecondition制御に非対応のものである
ことを特徴とする請求項１から３のいずれか１項に記載のＳＩＰサーバのセッション接続方法。
【請求項５】
第２のステップについて、ＳＩＰサーバから第２の端末へ送信する前記セッション開始要求には、
要求元の第１の端末がリソース確保完了を表すPreconditionパラメータと、
要求元の第１の端末がアーリーメディアの受信可能を表すDirectionパラメータと
を含むことを特徴とする請求項１から４のいずれか１項に記載のＳＩＰサーバのセッション接続方法。
【請求項６】
ＳＩＰサーバは、第２の端末がPrecondition制御に対応／非対応かを予め記憶し又は問い合わせ、
第１のステップについて、第２の端末がPrecondition制御に非対応である場合にのみ、第２のステップから第３のステップを実行する
ことを特徴とする請求項１から５のいずれか１項に記載のＳＩＰサーバのセッション接続方法。
【請求項７】
前記ＳＩＰサーバは、
ＣＳＣＦ(Call Session Control Function)と通信するアプリケーションサーバ(Application Server)、又は、
第１の端末側のＣＳＣＦと第２の端末側のＣＳＣＦとの間に配置されたＩＢＣＦ(Interconnection Border Control Function)
であることを特徴とする請求項１から６のいずれか１項に記載のＳＩＰサーバのセッション接続方法。
【請求項８】
ＩＰベースのマルチメディアネットワークを介して、セッション要求元となる第１の端末と、セッション要求先となる第２の端末と通信可能なＳＩＰサーバにおいて、
第１の端末からセッション開始要求を受信した際に、第１の端末に対してリソース確保を完了させる要求元リソース確保制御手段と、
第１の端末からのセッション開始要求を第２の端末へ送信し、第２の端末に対してリソース確保を完了させ、その応答を第１の端末へ送信する要求先リソース確保制御手段と、
第２の端末からアーリーメディアを受信し、該アーリーメディアを第１の端末へ転送するアーリーメディア転送手段と
を有することを特徴とするＳＩＰサーバ。
【請求項９】
ＩＰベースのマルチメディアネットワークを介して、セッション要求元となる第１の端末と、セッション要求先となる第２の端末と通信可能なＳＩＰサーバに搭載されたコンピュータを機能させるプログラムであって、
第１の端末からセッション開始要求を受信した際に、第１の端末に対してリソース確保を完了させる要求元リソース確保制御手段と、
第１の端末からのセッション開始要求を第２の端末へ送信し、第２の端末に対してリソース確保を完了させ、その応答を第１の端末へ送信する要求先リソース確保制御手段と、
第２の端末からアーリーメディアを受信し、該アーリーメディアを第１の端末へ転送するアーリーメディア転送手段と
してコンピュータを機能させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＩＭＳ(IP Multimedia Subsystem)におけるメディア制御の技術に関する。
【背景技術】
【０００２】
ＩＭＳは、ＩＰ(Internet Protocol)ベースのマルチメディア通信サービスを提供するものであって、３ＧＰＰ(3rd Generation Partnership Project)国際標準として規定されている（例えば非特許文献１参照）。ＩＭＳとは、アクセスネットワークに依存することなく、ＩＰパケットのトランスポートを制御するコアネットワークである。ＩＰ−ＣＡＮ(IP-Connectivity Access Network)と称される複数のアクセスネットワークが、シームレスに収容される。ＩＭＳによれば、異なるアクセスネットワークを介して、共通のマルチメディア通信サービス（例えばＩＰ電話、テレビ電話、ＩＭ(Instant Message)等）を提供することができる。
【０００３】
ＩＭＳは、主にセッション制御機能（ＣＳＣＦ(Call Session Control Function)）と共に、アプリケーションサービス制御機能（ＡＳ(Application Server）やユーザ情報蓄積機能（ＨＳＳ(Home Subscriber Server)）を搭載する。ＣＳＣＦは、サービス制御ネットワークの制御の核であるセッションを制御する機能であり、ユーザ端末（ＵＡ(User Agent)）間の通信セッションの設定及び解放を実現する。また、ＣＳＣＦは、ＳＩＰ（Session Initiation Protocol：セッション制御プロトコルである）やＳＤＰ（Session Description Protocol：セッション記述プロトコル）によってメッセージを交換する。ＣＳＣＦは、具体的には、Ｐ−ＣＳＣＦ（Proxy-CSCF）、Ｓ−ＣＳＣＦ（Serving-CSCF）、Ｉ−ＣＳＣＦ（Interrogating-CSCF）の３つの機能要素に分類される。また、ＣＳＣＦは、接続されるセッションのサービス条件に応じて、アプリケーションサーバを選択的に利用する。
【０００４】
ＩＭＳは、例えばＩＢＣＦ(Interconnection Border Control Function)を設置することによって、２つの異なるＩＰネットワーク（ＩＭＳやＮＧＮ(Next Generation Network)等）間を接続することができる。ＩＢＣＦは、ネットワーク毎に異なる独自のＳＩＰパラメータやＳＤＰのメディア情報に対して、プロトコル変換も実行する。
【０００５】
従来、セッション確立中に、アナウンスメントを提供する方式が規定されている（例えば非特許文献２参照）。この方式によれば、ＳＩＰシーケンスの中で、セッション開始要求（INVITE）の送信開始から、最終の成功応答（200OK）までのセッション確立中の状態を、「アーリーダイアログ」と定義する。アーリーダイアログで提供されるアナウンスメント等のメディアを、「アーリーメディア(Early Media)」と称する。アーリーメディアは、例えばＰＳＴＮ（Public Switched Telephone Network：公衆電話回線網）について、呼接続の前に、発信側に聞こえる呼び出しトーンとしても用いられる。
【０００６】
ここで、セッション要求元端末がメディアを聴取するためのリソース（通信路）を確保できていない状態（リソース未確保）のときに、セッション要求先端末がアーリーメディアを流し始めることが想定される。この場合、セッション要求元端末は、リソース確保が完了した時点でいきなり、アーリーメディアの途中から聞こえることになる。このように、メディアの先頭が聞こえない問題は、「メディアクリッピング」と称される。
【０００７】
このような問題を解決するために、ＳＩＰにおけるPrecondition制御の方式が規定されている（例えば非特許文献３参照）。この技術によれば、セッション要求元端末が、セッション開始要求を送信した時にリソースを確保できていなくても、そのリソース確保が完了した後、セッション要求先端末からアーリーメディアを受信できるように制御される。
【０００８】
Precondition制御の方式は、セッション要求元端末とセッション要求先端末との間で、リソース確保状態のパラメータを、ＳＤＰを用いて相互に交換するものである。端末間で、相手方のリソース確保の完了が確認できた段階で、アーリーメディアの送信が開始される。
【０００９】
更に、Precondition制御に対する対応／非対応は、セッション確立手順の中で、ＳＩＰ／ＳＤＰに設定すべきパラメータとして規定されている（例えば非特許文献４参照）。この規定によれば、Precondition制御「非対応」の場合、セッション確立手順について、ＳＤＰのDirectionパラメータに従って、メディアクリッピングを発生させることなくアーリーメディアを送信することができる。
【先行技術文献】
【非特許文献】
【００１０】
【非特許文献１】3GPP TS 23.228  「IP Multimedia Subsystem (IMS); Stage 2」
【非特許文献２】3GPP TS 24.628  「Common Basic Communication procedures using IP Multimedia (IM) Core Network (CN) subsystem; Protocol specification」
【非特許文献３】RFC 3312  「Integration of Resource Management and Session Initiation Protocol (SIP)」
【非特許文献４】3GPP TS 24.229  「IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3」
【発明の概要】
【発明が解決しようとする課題】
【００１１】
しかしながら、セッション要求元端末がPrecondition制御「対応」であり、セッション要求先端末がPrecondition制御「非対応」である場合、非特許文献４に記載の技術を用いても、セッション確立におけるアーリーメディアのメディアクリッピングが生じる可能性がある。
【００１２】
この従来技術によれば、Precondition制御「対応」のセッション要求元端末が、Precondition制御「非対応」のセッション要求先端末に対してセッション開始要求を送信した場合、Preconditionを使用することなくセッションを確立することとなる。ここで、以下の３つの条件がある。
（条件１）セッション要求元端末は、「セッション開始要求」をセッション要求先端末へ送信する。このセッション開始要求のＳＤＰオファーは、以下のように設定される。
Directionパラメータ＝メディアの送受信無し(a=inactive)
（条件２）これに対し、セッション要求先端末は、ＳＤＰアンサーを含む「暫定応答」を返信する。このとき、セッション要求先端末は、アーリーメディアの送信可能であっても、先のDirectionパラメータに従って、アーリーメディアの送信を待機する。
（条件３）ＳＤＰネゴシエーションの成立後、セッション要求元端末とセッション要求先端末とはそれぞれ、リソース確保を実行する。その後、セッション要求元端末は、リソース確保が完了したタイミングで、「情報更新要求（UPDATE）」をセッション要求先端末へ送信する。ここで、情報更新要求は、以下のように設定される。
Directionパラメータ＝メディアの送受信可能(a=sendrecv）
これに対し、情報更新要求を受信したセッション要求先端末は、成功応答を返信すると共に、待機していたアーリーメディアの送信を開始する。
【００１３】
このような端末間のシーケンスのみで、メディアクリッピングを発生すること無く、アーリーメディアの送信を開始できるように思える。勿論、条件１及び２については規定通りの必須の動作であるが、条件３については、セッション要求元端末及びセッション要求先端末それぞれが、情報更新要求を送受信する機能を別途実装する必要がある。
【００１４】
非特許公報４によれば、条件３の「情報更新要求」についてはオプション機能であって、その機能を搭載していないセッション要求元端末及びセッション要求先端末では、実現することができない。また、このオプション機能によれば、セッション要求元端末が、セッション開始要求を送信し、セッション要求元端末が最終「成功応答」を返信した後、セッション要求元端末が「情報更新要求」を送信する動作となる。しかしながら、情報更新要求が送信される前に、最終「成功応答」が送信されているために、実質的にアーリーメディアではないという問題がある。また、セッション要求元端末は、最終「成功応答」を受信した後、「情報更新要求」を受信するまで待機する必要がある。セッション要求先端末の動作によっては、セッション確立が、遅延したり、接続できなかったりすることとなる。即ち、条件３のオプション機能を前提として、アーリーメディアのメディアクリッピングを生じないようにすることはできない。
【００１５】
そこで、本発明は、セッション要求元端末がPrecondition制御「対応」であるにも拘わらず、セッション要求先端末がPrecondition制御「非対応」であっても、セッション確立におけるアーリーメディアのメディアクリッピングを生じないようにするセッション制御方法、ＳＩＰサーバ及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１６】
本発明によれば、ＩＰベースのマルチメディアネットワークを介して、セッション要求元となる第１の端末と、セッション要求先となる第２の端末と通信可能なＳＩＰサーバのセッション接続方法において、
第１の端末からセッション開始要求を受信した際に、第１の端末に対してリソース確保を完了させる第１のステップと、
第１の端末からのセッション開始要求を第２の端末へ送信し、第２の端末に対してリソース確保を完了させ、その応答を第１の端末へ送信する第２のステップと、
第２の端末からアーリーメディア(early media)を受信し、該アーリーメディアを第１の端末へ転送する第３のステップと
を有することを特徴とする。
【００１７】
本発明のＳＩＰサーバのセッション接続方法における他の実施形態によれば、
第１のステップについて、ＳＩＰサーバが、
第１の端末からセッション開始要求を受信し、
リソース確保を要求する暫定応答を第１の端末へ返信し、
リソース確保が完了した第１の端末から、リソース確保完了通知を受信し、
成功応答を第１の端末へ返信することも好ましい。
【００１８】
本発明のＳＩＰサーバのセッション接続方法における他の実施形態によれば、
第２のステップについて、ＳＩＰサーバが、
第１の端末からのセッション開始要求を第２の端末へ送信し、
リソース確保が完了した第２の端末からアーリーメディア提供通知の暫定応答を受信し、
暫定応答を第１の端末へ送信することも好ましい。
【００１９】
本発明のＳＩＰサーバのセッション接続方法における他の実施形態によれば、
第１の端末は、ＳＩＰサーバとの間で、アーリーダイアログシーケンスの要求／応答のＳＤＰオファー／アンサーに記述されるPrecondition制御に対応のものであり、
第２の端末は、ＳＩＰサーバとの間で、アーリーダイアログシーケンスの要求／応答のＳＤＰオファー／アンサーに記述されるPrecondition制御に非対応のものである
ことも好ましい。
【００２０】
本発明のＳＩＰサーバのセッション接続方法における他の実施形態によれば、
第２のステップについて、ＳＩＰサーバから第２の端末へ送信するセッション開始要求には、
要求元の第１の端末がリソース確保完了を表すPreconditionパラメータと、
要求元の第１の端末がアーリーメディアの受信可能を表すDirectionパラメータと
を含むことも好ましい。
【００２１】
本発明のＳＩＰサーバのセッション接続方法における他の実施形態によれば、
ＳＩＰサーバは、第２の端末がPrecondition制御に対応／非対応かを予め記憶し又は問い合わせ、
第１のステップについて、第２の端末がPrecondition制御に非対応である場合にのみ、第２のステップから第３のステップを実行することも好ましい。
【００２２】
本発明のＳＩＰサーバのセッション接続方法における他の実施形態によれば、
ＳＩＰサーバは、
ＣＳＣＦと通信するアプリケーションサーバ(Application Server)、又は、
第１の端末側のＣＳＣＦと第２の端末側のＣＳＣＦとの間に配置されたＩＢＣＦ(Interconnection Border Control Function)であることも好ましい。
【００２３】
本発明によれば、ＩＰベースのマルチメディアネットワークを介して、セッション要求元となる第１の端末と、セッション要求先となる第２の端末と通信可能なＳＩＰサーバにおいて、
第１の端末からセッション開始要求を受信した際に、第１の端末に対してリソース確保を完了させる要求元リソース確保制御手段と、
第１の端末からのセッション開始要求を第２の端末へ送信し、第２の端末に対してリソース確保を完了させ、その応答を第１の端末へ送信する要求先リソース確保制御手段と、
第２の端末からアーリーメディアを受信し、該アーリーメディアを第１の端末へ転送するアーリーメディア転送手段と
を有することを特徴とする。
【００２４】
本発明によれば、ＩＰベースのマルチメディアネットワークを介して、セッション要求元となる第１の端末と、セッション要求先となる第２の端末と通信可能なＳＩＰサーバに搭載されたコンピュータを機能させるプログラムであって、
第１の端末からセッション開始要求を受信した際に、第１の端末に対してリソース確保を完了させる要求元リソース確保制御手段と、
第１の端末からのセッション開始要求を第２の端末へ送信し、第２の端末に対してリソース確保を完了させ、その応答を第１の端末へ送信する要求先リソース確保制御手段と、
第２の端末からアーリーメディアを受信し、該アーリーメディアを第１の端末へ転送するアーリーメディア転送手段と
してコンピュータを機能させることを特徴とする。
【発明の効果】
【００２５】
本発明のセッション制御方法、ＳＩＰサーバ及びプログラムによれば、セッション要求元端末がPrecondition制御「対応」であるにも拘わらず、セッション要求先端末がPrecondition制御「非対応」であっても、セッション確立におけるアーリーメディアのメディアクリッピングを生じないようにすることができる。
【図面の簡単な説明】
【００２６】
【図１】本発明におけるシステム構成図である。
【図２】本発明におけるシーケンス図である。
【図３】本発明におけるアプリケーションサーバの機能構成図である。
【図４】ＳＩＰサーバが、セッション要求先端末へPrecondition制御の対応可否を問い合わせるシーケンス図である。
【発明を実施するための形態】
【００２７】
以下、本発明の実施の形態について、図面を用いて詳細に説明する。
【００２８】
図１は、本発明におけるシステム構成図である。
【００２９】
図１によれば、セッション要求元端末２１と、セッション要求先端末２２との間は、ＩＰベースのマルチメディアネットワークを介して接続されている。このようなネットワークは、具体的にはＩＭＳ（広義にＮＧＮ(Next Generation Network)も含む）であって、複数のＳＩＰサーバによって構成されている。要求元ネットワークと要求先ネットワークとは、ＩＭＳを介することによって、異なる事業者に運用されるものであってもよい。同一事業者のＩＭＳ間であれば、ＳＩＰ／ＳＤＰについてプロトコル変換も必要なく、直接的にＩ−ＣＳＣＦを介して接続することができる。また、異なる事業者ネットワーク間であれば、ＩＢＣＦを介して、ＳＩＰ／ＳＤＰについてプロトコル変換を実行することができる。
【００３０】
本発明のＳＩＰサーバの機能は、例えば以下のサーバに搭載される。
・アプリケーションサーバ(Application Server)
（特にＳ−ＣＳＣＦと通信する）
・ＩＢＣＦ(Interconnection Border Control Function)
（異なる通信事業者のＩＭＳ間に配置される）
アーリーメディアの送信の有無は、セッション要求先のＩＭＳの事業者の運用意志に依存すると考えられる。そのために、アプリケーションサーバは、アーリーメディアを送信したい側、即ち、セッション要求先のＩＭＳに配置するのが好ましい。
また、ＩＢＣＦは、プロトコル変換用のトランスコーディング機能を既に搭載しているために、異なる事業者のＩＭＳ間におけるアーリーメディアのメディア変換にも適する。
【００３１】
図１によれば、端末は、ＳＩＰサーバとの間で、アーリーダイアログシーケンスの要求／応答のＳＤＰオファー／アンサーに記述されるPrecondition制御について、以下のように対応／非対応の関係にあるとする。
・セッション要求元端末２１＝Precondition制御「対応」
・セッション要求先端末２２＝Precondition制御「非対応」
【００３２】
図２は、本発明におけるシーケンス図である。
【００３３】
図２によれば、アプリケーションサーバ１は、セッション要求元端末２１に対するリソース確保（第１のステップ）と、セッション要求先端末２２に対するリソース確保（第２のステップ）とを独立に完了させた後、アーリーメディアの送信が開始される（第３のステップ）ように制御する。即ち、アプリケーションサーバ１が、セッション要求元端末２１との間でPrecondition制御のセッション開始シーケンスを一度終端し、その後、セッション要求元端末２１との間でセッション開始シーケンスを実行する。
【００３４】
［ステップ１］アプリケーションサーバ１は、セッション要求元端末２１からセッション開始要求を受信した際に、セッション要求元端末２１に対してリソース確保を完了させる。
【００３５】
（Ｓ１１）端末２１は、端末２２に対する通話発信のような呼接続操作が実行されたとする。このとき、端末２１は、ＩＭＳへ向けて、端末２２とセッションを接続するべく「セッション開始要求」を送信する。このセッション開始要求のＳＤＰオファーは、以下のような情報を含む
・Preconditionパラメータ＝リソース未確保状態
・端末２１がサポートするメディア情報
セッション開始要求は、ＣＳＣＦ群を経由して、アプリケーションサーバ１へ転送される。セッション要求元端末２１からアプリケーションサーバ１までの転送経路は、ＩＭＳの既存の経路制御に基づく。
【００３６】
（Ｓ１２）アプリケーションサーバ１は、セッション開始要求を受信し、セッション要求元端末２１が「リソース未確保状態」にあることを認識する。その上で、アプリケーションサーバ１は、リソース確保を要求する「暫定応答」を、セッション要求元端末２１へ返信する。暫定応答のＳＤＰアンサーは、以下のような情報を含む。
・Preconditionパラメータ＝リソース確保通知の要求
・アプリケーションサーバ１がサポートするメディア情報
ここでは、ＳＤＰオファーとＳＤＰアンサーとのネゴシエーションによって、メディア情報が交換される。
【００３７】
（Ｓ１３）これに対し、セッション要求元端末２１は、ＳＤＰネゴシエーションのメディア情報に基づくリソースを確保する。
【００３８】
（Ｓ１４）セッション要求元端末２１は、リソース確保が完了した際、「リソース確保完了通知」を、アプリケーションサーバ１へ送信する。リソース確保完了通知のＳＤＰオファーは、以下のような情報を含む。
・Preconditionパラメータ＝リソース確保完了
【００３９】
（Ｓ１５）アプリケーションサーバ１は、セッション要求元端末２１からリソース確保完了通知を受信し、それに対する「成功応答」を、セッション要求元端末２１へ返信する。成功応答のＳＤＰアンサーは、以下のような情報を含む。
・Preconditionパラメータ＝端末２１との間でリソース確保完了
これによって、アプリケーションサーバ１は、セッション要求元端末２１との間で、交換したメディア情報に基づくリソース確保を完了させる。
【００４０】
［ステップ２］アプリケーションサーバ１は、セッション要求元端末２１からのセッション開始要求をセッション要求先端末２２へ送信し、セッション要求先端末２２に対してリソース確保を完了させ、その応答をセッション要求元端末２１へ送信する。
【００４１】
（Ｓ２１）次に、アプリケーションサーバ１は、「セッション開始要求」を、セッション要求先端末２２へ送信する。セッション開始要求のＳＤＰオファーは、以下の情報を含む。
Preconditionパラメータ＝ローカル側のリソース確保済み
Directionパラメータ＝メディア送受信可能(a=active)
アプリケーションサーバがサポートしているメディア情報
【００４２】
これに対し、セッション要求先端末２２は、自らがPrecondition制御「非対応」である場合、ＳＤＰオファーに含まれるPreconditionパラメータは読み飛ばす。また、セッション要求先端末２２は、Directionパラメータによってメディア送受信可能と判断する。
【００４３】
（Ｓ２２）セッション要求先端末２２は、アーリーメディアを送信するために、「暫定応答」を、アプリケーションサーバ１へ送信する。暫定応答のＳＤＰアンサーは、以下の情報を含む。
・アーリーメディア提供通知
・端末２２がサポートするメディア情報
【００４４】
（Ｓ２３）アプリケーションサーバ１は、セッション要求先端末２２から暫定応答を受信し、更に「暫定応答」をセッション要求元端末２１へ送信する。この「暫定応答」からは、ＳＤＰ情報を削除して、以下の情報を含む。
・アーリーメディア提供通知
【００４５】
（Ｓ２４）セッション要求先端末２２は、Ｓ２３によって暫定応答を送信した後、アプリケーションサーバ１との間で、交換したメディア情報に基づくリソースを確保する。
【００４６】
［ステップＳ３］セッション要求元端末２２は、リソース確保が完了した後、アーリーメディアの送信を開始する。
アプリケーションサーバ１は、セッション要求先端末２２から受信したアーリーメディアを、セッション要求元端末２１へ転送する。
これによって、セッション要求元端末２１は、セッション確立シーケンスの中のアーリーダイアログの中で、例えば呼び出しトーンのようなアーリーメディアを再生することができる。
【００４７】
尚、アプリケーションサーバ１は、セッション要求元端末２１のメディア情報と、セッション要求先端末２２のメディア情報とが異なる場合、アーリーメディアに対してメディア変換を実行する。
【００４８】
図３は、本発明におけるアプリケーションサーバの機能構成図である。
【００４９】
図３によれば、アプリケーションサーバ１は、要求元リソース確保制御部１１と、要求先リソース確保制御部１２と、アーリーメディア転送部１３とを有する。これら機能構成部は、サーバに搭載されたコンピュータを機能させるプログラムを実行することによって実現される。
【００５０】
［要求元リソース確保制御部１１]
要求元リソース確保制御部１１は、セッション要求元端末２１からセッション開始要求を受信した際に、そのセッション要求元端末２１に対してリソース確保を完了させる（前述した図２のステップ１（Ｓ１１〜Ｓ１５）参照）。
【００５１】
［要求先リソース確保制御部１２］
要求先リソース確保制御部１２は、セッション要求元端末２１からのセッション開始要求をセッション要求先端末２２へ送信し、そのセッション要求先端末２２に対してリソース確保を完了させ、その応答をセッション要求元端末２１へ送信する（前述した図２のステップ２（Ｓ２１〜Ｓ２４）参照）。
【００５２】
［アーリーメディア転送部１３］
アーリーメディア転送部１３は、セッション要求先端末２２からアーリーメディアを受信し、そのアーリーメディアをセッション要求元端末２１へ転送する（前述した図２のステップ３（Ｓ３）参照）。また、アーリーメディア転送部１３は、セッション要求元端末２１とセッション要求先端末２２との間で、アーリーメディアのメディア変換を実行するものであってもよい。
【００５３】
図４は、ＳＩＰサーバが、セッション要求先端末へPrecondition制御の対応可否を問い合わせるシーケンス図である。
【００５４】
図４（ａ）によれば、アプリケーションサーバ１は、セッション要求元端末２１からセッション開始要求を受信した際に、一度、セッション要求先端末２２へ、Precondition制御の「対応」／「非対応」を問い合わせるものであってもよい。アプリケーションサーバ１は、問合せ要求として、SIP OPTIONSを用いることができる。これに対し、セッション要求先端末２２は、Precondition制御の「対応」／「非対応」を含む200(Options)の問合せ応答を、アプリケーションサーバ１へ返信する。セッション要求先端末２２がPrecondition制御「非対応」である場合、図２に基づく次のシーケンス（Ｓ１３〜Ｓ３）を実行することができる。
【００５５】
一方で、図４（ｂ）によれば、アプリケーションサーバ１は、セッション要求先端末２２がPrecondition制御「対応」である場合、セッション要求元端末２１から受信した「セッション開始要求」のシグナリングをそのまま、セッション要求先端末２２へ送信するだけでよい。これに対し、セッション要求先端末２２は、アプリケーションサーバ１を介してセッション要求元端末２１へ向けて、暫定応答を返信する。次に、セッション要求元端末２１は、アプリケーションサーバ１を介してセッション要求先端末２２へ向けて、情報更新要求を送信する。その後、セッション要求先端末２２は、アプリケーションサーバ１を介してセッション要求元端末２１へ向けて、アーリーメディアの送信を開始する。
【００５６】
また、図４（ｃ）によれば、アプリケーションサーバ１がセッション要求先端末２２のPrecondition制御の「対応」／「非対応」を判定するものではなく、ＣＳＣＦによって判定する。ＣＳＣＦは、セッション開始要求のＳＤＰオファーにPreconditionパラメータが含まれていない場合、そのセッション開始要求をそのまま、セッション要求先端末２２へ送信すればよい。又は、セッション要求先端末２２がPrecondition制御「対応」である場合、そのセッション開始要求をそのまま、セッション要求先端末２２へ送信すればよい。これらの場合、アプリケーションサーバ１自体が、セッション開始要求等のアーリーダイアログを中継する必要もない。尚、それら判定をするＣＳＣＦとしては、Ｓ−ＣＳＣＦ，Ｉ−ＣＳＣＦ又はＢＧＣＦがある。これらＣＳＣＦは、セッション要求先端末におけるPrecondition制御情報を、過去の通信履歴から記憶しておくことができる。ＣＳＣＦによって、アプリケーションサーバを経由するか否かを判定することは、サーバの過負荷やシグナリングの遅延をできる限り回避するためにも有効である。
【００５７】
以上、詳細に説明したように、本発明のセッション制御方法、ＳＩＰサーバ及びプログラムによれば、セッション要求元端末がPrecondition制御「対応」であるにも拘わらず、セッション要求先端末がPrecondition制御「非対応」であっても、セッション確立におけるアーリーメディアのメディアクリッピングを生じないようにすることができる。
【００５８】
特に、本発明によれば、端末に特別な機能を搭載することなく、通信事業者がＩＭＳにアプリケーションサーバ（又はＩＢＣＦ）を設置するだけでよい。そのために、セッション要求先端末におけるPrecondition制御「対応／非対応」を認識する必要がない。即ち、端末から見て、ＩＭＳを介した既存シーケンスに変更を加える必要がない。また、異なる事業者に運用されるＩＭＳやＩＰネットワークに対しても、汎用的に用いることができる。
【００５９】
前述した本発明の種々の実施形態について、本発明の技術思想及び見地の範囲の種々の変更、修正及び省略は、当業者によれば容易に行うことができる。前述の説明はあくまで例であって、何ら制約しようとするものではない。本発明は、特許請求の範囲及びその均等物として限定するものにのみ制約される。
【符号の説明】
【００６０】
１  アプリケーションサーバ、ＩＢＣＦ
１１  要求元リソース確保制御部
１２  要求先リソース確保制御部
１３  アーリーメディア転送部
２１  セッション要求元端末
２２  セッション要求先端末
【図１】
2015162827.tif 000003
【図２】
2015162827.tif 000004
【図３】
2015162827.tif 000005
【図４】
2015162827.tif 000006