JP5639529B2 - 通信システム、および、その通信システムに用いられるセッション制御サーバ - Google Patents

Description

本発明は、通信システム、および、その通信システムに用いられるセッション制御サーバの技術に関する。

ユーザ端末間で通話するとき、その通信料金の負担をどのようにするのかは、ユーザにとって大きな関心事である。通信料金の課金対象は、一部の特殊な電話番号（フリーダイヤルやナビダイヤルなど）への発信を除き、一般的には全て発側となる。
よって、例えば、子供が親に電話をかけるときに、親が子供に通信料金を負担させたくないときには、親から子供へ電話をかけ直すことで、通信料金を親が負担するようにする。しかし、電話をかけ直すことは、回線を一旦切断して再接続するので、時間がかかってしまい不便である。

そこで、特許文献１には、通信中に発側から着側へ通信料金の負担要求を送信することで、電話をかけ直すことなく、通信料金の負担を変更する旨が記載されている。これにより、電話をかけ直す時間のロスを削減することができる。

特開平１１−８７１７号公報

インターネットの普及に伴い、ＩＰ（Internet Protocol）網上で、ＳＩＰ（Session Initiation Protocol）型通信を実現する通信システムも実現されている。この通信システムでは、ＩＰ網などで接続された端末間にＳＩＰのセッション（以下、単にセッションとする）を確立した後、そのセッションを介して通信を行う。

このとき、セッション内には通信を行うメディア種別（音声、映像、データなど）ごとのパス（メディアパス）を張る。つまり、１つのセッション内に、複数のメディアパスが確立されることもある（音声パスと映像パス、音声パスとデータパスなど）。そして、通信料金は、セッション内のメディアパスごとに行われた通信形態や通信時間から計算される。

ここで、特許文献１などの従来の課金管理システムでは、メディアパスごとの課金対象を指定する手段は、提供されていない。よって、従来のように、セッションごとに発側または着側に対して一律に課金することとしてしまうと、通信のメリットを享受する側に課金がなされないなどの不公平感が発生してしまう。例えば、データ転送サービスでは、そのデータを受信する側がメリットを享受する側になることが多い。

よって、さまざまな通信種別のメディアパスが通信サービスとして提供されていても、通信料金の負担を感じてしまうユーザからは、その通信サービスの利用を控えられてしまうことがあった。

そこで、本発明は、同じセッション内で複数の通信サービスを利用するとき、通信サービスごとにその課金対象を適切に指定させることを、主な目的とする。

前記課題を解決するために、本発明は、ネットワークを介して第１のユーザ端末と第２のユーザ端末との間でＳＩＰのセッションを確立し、そのセッション内に通信種別ごとの通信路であるメディアパスを追加する通信システムに用いられるセッション制御サーバであって、前記ユーザ端末間で通信されるＳＩＰ信号のうち、新たに追加する前記メディアパスとその課金対象とを対応づけた前記セッション情報が記載されている第１のＳＩＰ信号を前記第１のユーザ端末から受信して、前記第２のユーザ端末に対して中継し、その後、前記第１のＳＩＰ信号への応答であり、前記第１のＳＩＰ信号が示す課金内容に承認する旨の第２のＳＩＰ信号を前記第２のユーザ端末から受信すると、前記第２のＳＩＰ信号を前記第１のユーザ端末に対して中継するとともに、前記第２のＳＩＰ信号の受信時刻と、前記第１のＳＩＰ信号内の新たに追加する前記メディアパスとその課金対象とを含むＣＤＲ（Call Detail Record）を作成して、そのＣＤＲをもとに課金対象ごとの前記受信時刻からの通信料金を計算する課金サーバへＣＤＲを送信することを特徴とする。

これにより、同じネットワークに収容されるユーザ端末間によって適切に指定されたメディアパスごとの課金対象を、通信料金の計算に反映することができる。

本発明は、ネットワークを介して第１のユーザ端末と第２のユーザ端末との間でＳＩＰのセッションを確立し、そのセッション内に通信種別ごとの通信路であるメディアパスを追加する通信システムに用いられるセッション制御サーバであって、前記セッション制御サーバが、収容される前記ネットワークごとに配置されており、前記ユーザ端末間で通信されるＳＩＰ信号のうち、新たに追加する前記メディアパスとその課金対象とを対応づけた前記セッション情報が記載されている第１のＳＩＰ信号を前記第１のユーザ端末、または、自身が収容される前記ネットワークとは別の前記ネットワークの前記セッション制御サーバから受信して、前記第２のユーザ端末、または、自身が収容される前記ネットワークとは別の前記ネットワークの前記セッション制御サーバに対して中継し、その後、前記第１のＳＩＰ信号への応答であり、前記第１のＳＩＰ信号が示す課金内容に承認する旨の第２のＳＩＰ信号を前記第２のユーザ端末、または、自身が収容される前記ネットワークとは別の前記ネットワークの前記セッション制御サーバから受信すると、前記第２のＳＩＰ信号を前記第１のユーザ端末、または、自身が収容される前記ネットワークとは別の前記ネットワークの前記セッション制御サーバに対して中継するとともに、前記第２のＳＩＰ信号の受信時刻と、前記第１のＳＩＰ信号内の新たに追加する前記メディアパスとその課金対象とを含むＣＤＲを作成して、自身が収容される前記ネットワークに接続されており、前記ＣＤＲをもとに課金対象ごとの前記受信時刻からの通信料金を計算する課金サーバへＣＤＲを送信することを特徴とする。

これにより、複数のネットワークそれぞれに収容されるユーザ端末間によって適切に指定されたメディアパスごとの課金対象を、通信料金の計算に反映することができる。

本発明によれば、同じセッション内で複数の通信サービスを利用するとき、通信サービスごとにその課金対象を適切に指定させることができる。

本発明の一実施形態に関する１つの網に収容されるユーザ端末間での通信を行うための通信システムを示す構成図である。 本発明の一実施形態に関する図１の通信システムにおける処理（前半部）を示すフローチャートである。 本発明の一実施形態に関する図１の通信システムにおける処理（後半部）を示すフローチャートである。 本発明の一実施形態に関する複数の網にまたがったユーザ端末間での通信を行うための通信システムを示す構成図である。 本発明の一実施形態に関する図４の通信システムにおける処理（前半部）を示すフローチャートである。 本発明の一実施形態に関する図４の通信システムにおける処理（後半部）を示すフローチャートである。

以下、本発明の一実施形態について、図面を参照して詳細に説明する。

図１（ａ）は、１つの網に収容されるユーザ端末間での通信を行うための通信システムを示す構成図である。通信システムは、課金サーバ１と、セッション制御サーバ２と、ユーザ端末３（ユーザ端末３ａ、ユーザ端末３ｂ）とがネットワーク９で接続されて構成される。
これらの通信システムを構成する各装置は、ＣＰＵ（Central Processing Unit）とメモリとハードディスク（記憶手段）とネットワークインタフェースを有するコンピュータとして構成され、このコンピュータは、ＣＰＵが、メモリ上に読み込んだプログラムを実行することにより、各処理部を動作させる。
ネットワーク９は、ＳＩＰ（Session Initiation Protocol）網であり、ＳＩＰのセッションを確立するための制御信号の通信をユーザ端末３間で行う制御プレーンと、確立されたセッション上でのユーザ端末３間のユーザデータの通信を行うデータプレーンとをそれぞれ構成する。

図１（ｂ）は、セッションとメディアパスとの関係を示す。なお、セッションとメディアパスとの対応関係は、ＳＩＰメッセージ内のセッションＩＤ（Call-ID）と、そのＳＩＰメッセージに含まれるＳＤＰ（Session Description Protocol）内のメディアパス情報（ＲＦＣ４５６６にて規定される「m=行」）により、対応づけられる。
ユーザ端末３は、他の端末とセッションを確立して通信を開始するとともに、確立されたセッションにメディアパスを追加する。ここで、１つのセッションの中に、複数（例えば２つ）のメディアパスを対応づけることができる。
例えば、ユーザ端末３ａは、ユーザ端末３ｂとの間に音声通話を行うための第１のメディアパスを含むＳＩＰセッションを確立する。その後、ユーザ端末３ａは、ユーザ端末３ｂとの間の通話において、データ転送が必要である旨の操作指示を受けると、既に確立されているＳＩＰセッションに対して、第２のメディアパスであるデータパスを追加する。

図１（ａ）に戻り、ユーザ端末３ａは、メディアパスの確立要求を送信する側の端末である。ユーザ端末３ａは、メディアごとに発側あるいは着側から課金対象を選択する課金選択部３１と、選択されたメディアごとの課金対象が記載されたメディアパスの確立あるいは変更・削除を行うＳＩＰ信号（INVITEやUPDATEなど）を送信するＳＩＰ送信部３２とを有する。

ユーザ端末３ｂは、メディアパスの確立要求を受信する側の端末である。ユーザ端末３ｂは、課金対象の選択されたメディアパスの確立を行うＳＩＰ信号を受信した後、そのメディアの課金対象を承認する課金承認部３４と、メディアパスの確立あるいは変更・削除を行うＳＩＰ信号に対する応答を返すＳＩＰ応答部３３とを有する。

なお、図１（ａ）においては、ユーザ端末３ａ内にＳＩＰ応答部３３と課金承認部３４とを図示することを省略したが、ユーザ端末３ａがメディアパスの確立要求を受信する側にもなりうるので、ユーザ端末３ａ内にＳＩＰ応答部３３と課金承認部３４とを有することとする。同様に、ユーザ端末３ｂも、課金選択部３１とＳＩＰ送信部３２とを有する。

セッション制御サーバ２は、ユーザ端末３間でやりとりされるＳＩＰ信号に関する各処理（中継処理など）を行い、そのＳＩＰ信号を参照して呼詳細情報であるＣＤＲ（Call Detail Record）を作成して、自装置内の記憶手段に記録する。作成される呼詳細情報には、受信したＳＩＰ信号内に記述されたメディアごとの課金対象が含まれる。セッション制御サーバ２は、さらに、作成した呼詳細情報を課金サーバ１に通知する。

課金サーバ１は、セッション制御サーバ２から受信した呼詳細情報をもとに、ユーザ端末３によるネットワーク９の通信料金をメディアパスごとに計算し、その計算結果をもとにユーザ端末３のユーザへ通信料金を課金する。

図２は、図１の通信システムにおける処理（前半部）を示すフローチャートである。この例では、２台の音声通信中のユーザ端末３間において、音声パスの課金対象をユーザ端末３ａとし、データパスの課金対象をユーザ端末３ｂとする例を示す。

表１は、図２および後記する図３の処理において生成される個々のＣＤＲの内容を示す。セッション制御サーバ２が生成するＣＤＲには、そのＣＤＲの生成処理の直前に受信した「200 OK」信号の受信時刻と、そのセッションに含まれるメディアパス（音声パス、データパス）ごとの課金対象とを含めて構成される。
表１の１行目のＣＤＲ１は、Ｓ１０５での「200 OK」信号の受信時刻「ｔ１」と、音声パス（audio）の課金対象がユーザＡ（ユーザ端末３ａのユーザ）であることが記載されている。
表１の２行目のＣＤＲ１は、Ｓ１１５での「200 OK」信号の受信時刻「ｔ２」と、音声パス（audio）の課金対象がユーザＡであることと、データパス（data）の課金対象がユーザＢ（ユーザ端末３ｂのユーザ）であることとが記載されている。
なお、表１の２行目のデータパスの「data」とはデータ通信の開始を示し、３行目のデータパスの「data port0」とはデータ通信の終了（dataのポート番号を０と指定）を示す。

図２のフローチャートを行う前準備として、ユーザ端末３ａとユーザ端末３ｂとの間に、セッションが確立されており、そのセッション内に１つの音声パスが含まれていることとする。

Ｓ１０１として、ユーザ端末３ａは、セッション開始時の音声パスの通話料金を選択する。ここでは、ユーザＡ（発側課金）とするため、INVITEのＳＤＰ内にメディアごとの課金対象を示す「ｄ＝課金対象」の行として、「d=A」を追加する。そして、ユーザ端末３ａは、Ｓ１０１で作成したINVITEを、セッション制御サーバ２経由で、ユーザ端末３ｂに通知する（Ｓ１０２，Ｓ１０３）。

Ｓ１０４として、ユーザ端末３ｂは、通知されたINVITEを参照して音声パスのユーザＡへの課金を承認する。この承認処理は、例えば、ユーザ端末３ｂの画面上に「承認しますか？」のメッセージをポップアップで表示するとともに、「ＯＫ」または「キャンセル」を選択するボタンを表示することで、行われる。
「ＯＫ」が押されたときには、承認可として、Ｓ１０５へ進む。
「キャンセル」が押されたときには、承認不可であるため、ＳＩＰセッション内にメディア追加が実施されず、ファイル転送は行われない。そして、ユーザ端末３ｂは、Ｓ１０５へは進まず、要求失敗（406 Not Acceptable）メッセージをユーザ端末３ａに返答する。この要求失敗を中継するセッション制御サーバ２は、ＣＤＲを発行しないことにより、追加されなかったメディアパスへの課金が行われないようにする。

Ｓ１０５，Ｓ１０７として、ユーザ端末３ｂはユーザ端末３ａへ応答を示す「200 OK」信号を送信し、セッション制御サーバ２では、その信号を中継するにあたり、表１の１行目で示したＣＤＲ１を作成し、課金サーバ１へ送信する（Ｓ１０６）。これにより、ユーザ端末３間での音声パスを介した音声通話が可能となる（Ｓ１０８）。なお、作成された各ＣＤＲは、それぞれ課金サーバ１へ送信されるので、以下では、その課金サーバ１への送信処理の記載を適宜省略する。

ユーザ端末３ａからユーザ端末３ｂに対しファイルを転送するために、確立済みのセッション内にデータパスを追加する。そのため、ユーザ端末３ａは、ファイル転送にかかる通信料金を着側課金（ユーザＢへの課金）とする旨を選択して（Ｓ１１１）、その結果を示すUPDATEをユーザ端末３ｂに送信する（Ｓ１１２，Ｓ１１３）。以下は、ＳＤＰの標準仕様（ＲＦＣ４５６６）に従った、UPDATE内のＳＤＰの記述例を示す。
（１行目）m=audio 12345 RTP/AVP 0
（２行目）d=A
（３行目）m=data 987654 RLUTE/UDP 0
（４行目）d=B
１行目に示す音声パスの課金対象として、２行目でユーザＡが指定されており、３行目に示すデータパスの課金対象として、４行目でユーザＢが指定されている。なお、ＲＦＣ４５６６において「d=」は未定義であるため、本実施形態のような新たな用途（メディアパスごとの課金対象の指定）として追加しても、既存のＳＤＰ処理との互換性は保たれる。一方、課金対象の格納先の行として、「d=」の代わりに、既存の定義された行（「a=」行や「i=」行など）を用いてもよい。

ユーザ端末３ｂは、受信したUPDATEに記載されている、データパスのユーザＢへの課金を承諾する（Ｓ１１４）。そして、ユーザ端末３ｂは、ユーザ端末３ａに対して、UPDATEに対する応答（200 OK）を送信する（Ｓ１１５，Ｓ１１７）。ここで、セッション制御サーバ２は、Ｓ１１５のUPDATEを受信すると、表１の２行目で示したＣＤＲ２を作成する（Ｓ１１６）。このように、既存のセッション上でUPDATEを用いることにより、セッションを一旦切断して再接続することなく、メディアパスごとの課金対象を選択することができる。

そして、ユーザ端末３ａとユーザ端末３ｂとの間で第１のメディアパスとしての音声パスによる音声通話（Ｓ１０８，Ｓ１２１）をユーザＡの課金として継続しつつ、第２のメディアパスとしてのデータパスによるデータ通信（Ｓ１２２）を課金Ｂとして開始することができる。

図３は、図１の通信システムにおける処理（後半部）を示すフローチャートである。

Ｓ１２２のファイル転送後、ユーザ端末３ａは、不要になったデータパスをセッションから削除する。そのため、ユーザ端末３ａは、データ終了を示すUPDATEをユーザ端末３ｂに送信する（Ｓ１３１，Ｓ１３２）。ユーザ端末３ｂは、Ｓ１３２のUPDATEに対する応答（200 OK）をユーザ端末３ａに返信する（Ｓ１３３，Ｓ１３５）。
セッション制御サーバ２では、Ｓ１３３の応答（200 OK）を受信すると、データパスが削除された旨を示すＣＤＲ３を作成する（Ｓ１３４）。これにより、セッション内には、音声パスを介した音声通話だけが継続される（Ｓ１４１）。

そして、音声通話を終了させるときには、ユーザ端末３ａは、音声終了を示すBYEをユーザ端末３ｂに送信する（Ｓ１５１，Ｓ１５２）。ユーザ端末３ｂは、Ｓ１５２のBYEに対する応答（200 OK）をユーザ端末３ａに返信する（Ｓ１５３，Ｓ１５５）。
セッション制御サーバ２では、Ｓ１５３の応答（200 OK）を受信すると、音声パスが削除された（つまり、セッションが終了した）旨を示すＣＤＲ４を作成する（Ｓ１５４）。

以上によりそれぞれ作成されたＣＤＲ１〜ＣＤＲ４は、セッション制御サーバ２から課金サーバ１に送信される。課金サーバ１は、受信した呼詳細情報（ＣＤＲ１〜ＣＤＲ４）をもとに、メディアパスごとの通信料金を計算する。通信料金は、例えば、メディアパスの使用期間（通信開始時刻から通信終了時刻まで）に比例した従量課金とする。
（ユーザＡの通信料金）：通話時間（ｔ４−ｔ１）×（単位時間あたりの通話料金）
（ユーザＢの通信料金）：データ通信時間（ｔ３−ｔ２）×（単位時間あたりの通信料金）

さらに、課金対象をどちらか片方に１００％負担させる代わりに、両方の課金対象それぞれについて、課金割合（例えば、７０％：３０％）を指定するとともに、その課金割合を前記した（通信時間）と（単位時間あたりの通信料金）との積にかけることによって、課金対象それぞれについての課金割合に応じた通信料金を計算してもよい。

図４は、複数の網にまたがったユーザ端末間での通信を行うための通信システムを示す構成図である。図１の通信システムと比較すると、課金サーバ１（課金サーバ１ａ，課金サーバ１ｂ）と、セッション制御サーバ２（セッション制御サーバ２ａ，セッション制御サーバ２ｂ）とが、それぞれ各ネットワーク９（ネットワーク９ａ，ネットワーク９ｂ）ごとに配備されている。

図５は、図４の通信システムにおける処理（前半部）を示すフローチャートである。

表２は、図５および後記する図６の処理において生成される個々のＣＤＲの内容を示す。表１のＣＤＲと比較すると、ネットワーク９ａ側と、ネットワーク９ｂ側とで、それぞれＣＤＲが個別に作成される。
セッション制御サーバ２ａは、ＣＤＲ１１〜ＣＤＲ１４を作成して、課金サーバ１ａに通知する。
セッション制御サーバ２ｂは、ＣＤＲ２１〜ＣＤＲ２４を作成して、課金サーバ１ｂに通知する。

図５のフローチャートを行う前準備として、ユーザ端末３ａとユーザ端末３ｂと間に、セッションが確立されており、そのセッション内に１つの音声パスが含まれていることとする。

Ｓ２００として、ユーザ端末３ａは、セッション開始時の音声パスの通話料金を選択する。ここでは、ユーザＡ（発側課金）とするため、INVITEのＳＤＰ内にメディアごとの課金対象を示す「ｄ＝課金対象」の行として、「d=A」を追加する。そして、ユーザ端末３ａは、Ｓ２０１で作成したINVITEを、セッション制御サーバ２経由で、ユーザ端末３ｂに通知する（Ｓ２０１〜Ｓ２０３）。
Ｓ２０４として、ユーザ端末３ｂは、通知されたINVITEを参照して音声パスのユーザＡへの課金を承認する（Ｓ１０４と同様）。
Ｓ２０５，Ｓ２０７，Ｓ２０９として、ユーザ端末３ｂはユーザ端末３ａへ応答を示す「200 OK」信号を送信する。
セッション制御サーバ２ｂでは、「200 OK」信号を中継するにあたり、表２の１行目で示したＣＤＲ２１を作成する（Ｓ２０６）。セッション制御サーバ２ａでは、「200 OK」信号を中継するにあたり、表２の２行目で示したＣＤＲ１１を作成する（Ｓ２０８）。これにより、ユーザ端末３間での音声パスを介した音声通話が可能となる（Ｓ２１１）。

ユーザ端末３ａからユーザ端末３ｂに対しファイルを転送するために、確立済みのセッション内にデータパスを追加する。そのため、ユーザ端末３ｂは、ファイル転送にかかる通信料金をユーザＢの課金とする旨を選択して（Ｓ２２０）、その結果を示すUPDATE（内容は、Ｓ１１２で送信されるものと同様）をユーザ端末３ａに送信する（Ｓ２２１〜Ｓ２２３）。

ユーザ端末３ａは、受信したUPDATEに記載されている、ユーザＢへの課金を承諾する（Ｓ２２４）。そして、ユーザ端末３ａは、ユーザ端末３ｂに対して、UPDATEに対する応答（200 OK）を送信する（Ｓ２２５，Ｓ２２７，Ｓ２２９）。
ここで、セッション制御サーバ２ａは、Ｓ２２５のUPDATEを受信すると、表２の３行目で示したＣＤＲ１２を作成する（Ｓ２２６）。セッション制御サーバ２ｂは、Ｓ２２７のUPDATEを受信すると、表２の４行目で示したＣＤＲ２２を作成する（Ｓ２２８）。

そして、ユーザ端末３ａとユーザ端末３ｂとの間で第１のメディアパスとしての音声パスによる音声通話（Ｓ２１１，Ｓ２３１）をユーザＡの課金として継続しつつ、第２のメディアパスとしてのデータパスによるデータ通信（Ｓ２３２）をユーザＢの課金として開始することができる。

図６は、図４の通信システムにおける処理（後半部）を示すフローチャートである。

Ｓ２３２のファイル転送後、ユーザ端末３ｂは、不要になったデータパスをセッションから削除する。そのため、ユーザ端末３ｂは、データ終了を示すUPDATEをユーザ端末３ａに送信する（Ｓ２４１〜Ｓ２４３）。ユーザ端末３ａは、Ｓ２４３のUPDATEに対する応答（200 OK）をユーザ端末３ｂに返信する（Ｓ２４４，Ｓ２４６，Ｓ２４８）。
セッション制御サーバ２ａは、Ｓ２４４の応答（200 OK）を受信すると、データパスが削除された旨を示すＣＤＲ１３を作成する（Ｓ２４５）。セッション制御サーバ２ｂは、Ｓ２４６の応答（200 OK）を受信すると、データパスが削除された旨を示すＣＤＲ２３を作成する（Ｓ２４７）。
これにより、セッション内には、音声パスを介した音声通話だけが継続される（Ｓ２５１）。

そして、音声通話を終了させるときには、ユーザ端末３ｂは、音声終了を示すBYEをユーザ端末３ａに送信する（Ｓ２６１〜Ｓ２６３）。ユーザ端末３ａは、Ｓ２６３のBYEに対する応答（200 OK）をユーザ端末３ｂに返信する（Ｓ２６４，Ｓ２６６，Ｓ２６８）。
セッション制御サーバ２ａは、Ｓ２６４の応答（200 OK）を受信すると、音声パスが削除された（つまり、セッションが終了した）旨を示すＣＤＲ１４を作成する（Ｓ２６５）。セッション制御サーバ２ｂは、Ｓ２６６の応答（200 OK）を受信すると、Ｓ２６５と同様に、ＣＤＲ２４を作成する（Ｓ２６７）。

課金サーバ１ａは、セッション制御サーバ２ａからＣＤＲ１１〜ＣＤＲ１４を受信すると、例えば以下の計算式により、通信料金を計算する。
（ユーザＡの通信料金）：通話時間（ｔ１４−ｔ１１）×（ネットワーク９ａでの単位時間あたりの通話料金）
（ユーザＢの通信料金）：課金なし

課金サーバ１ｂは、セッション制御サーバ２ｂからＣＤＲ２１〜ＣＤＲ２４を受信すると、例えば以下の計算式により、通信料金を計算する。
（ユーザＡの通信料金）：課金なし
（ユーザＢの通信料金）：データ通信時間（ｔ２３−ｔ２２）×（ネットワーク９ｂでの単位時間あたりの通信料金）

以上説明した本実施形態によれば、新たなメディアパスを利用して通信したいユーザは、メディアパスごとに課金対象を指定するＳＩＰ信号を送信することにより、既存のセッションに設定されている課金対象に影響されず、メディアパスごとに課金対象を設定することができる。
例えば、ユーザ端末３ａからユーザ端末３ｂへの発呼によって、ユーザＡの課金による音声通話が開始された後でも、その音声通話を中断することなく、ユーザＢの課金によるデータ通信をセッションに追加することができる。

これにより、メディアパスを介して行われる通信サービスごとにその課金対象を設定して通信相手に承認させることができるので、音声通信より通信料金が比較的高額なデータ転送を実施することに抵抗感が減り、ユーザが音声通信サービスに加えデータ通信サービスを手軽に利用できる。

１（１ａ，１ｂ） 課金サーバ
２（２ａ，２ｂ） セッション制御サーバ
３（３ａ，３ｂ） ユーザ端末
９（９ａ，９ｂ） ネットワーク
３１ 課金選択部
３２ ＳＩＰ送信部
３３ ＳＩＰ応答部
３４ 課金承認部

Claims (4)

1. ネットワークを介して第１のユーザ端末と第２のユーザ端末との間でＳＩＰ（Session Initiation Protocol）のセッションを確立し、そのセッション内に通信種別ごとの通信路であるメディアパスを追加する通信システムに用いられるセッション制御サーバであって、
   前記ユーザ端末間で通信されるＳＩＰ信号のうち、新たに追加する前記メディアパスとその課金対象とを対応づけた前記セッション情報が記載されている第１のＳＩＰ信号を前記第１のユーザ端末から受信して、前記第２のユーザ端末に対して中継し、その後、
   前記第１のＳＩＰ信号への応答であり、前記第１のＳＩＰ信号が示す課金内容に承認する旨の第２のＳＩＰ信号を前記第２のユーザ端末から受信すると、前記第２のＳＩＰ信号を前記第１のユーザ端末に対して中継するとともに、前記第２のＳＩＰ信号の受信時刻と、前記第１のＳＩＰ信号内の新たに追加する前記メディアパスとその課金対象とを含むＣＤＲ（Call Detail Record）を作成して、そのＣＤＲをもとに課金対象ごとの前記受信時刻からの通信料金を計算する課金サーバへＣＤＲを送信することを特徴とする
   セッション制御サーバ。
2. ネットワークを介して第１のユーザ端末と第２のユーザ端末との間でＳＩＰ（Session Initiation Protocol）のセッションを確立し、そのセッション内に通信種別ごとの通信路であるメディアパスを追加する通信システムに用いられるセッション制御サーバであって、
   前記セッション制御サーバは、収容される前記ネットワークごとに配置されており、
   前記ユーザ端末間で通信されるＳＩＰ信号のうち、新たに追加する前記メディアパスとその課金対象とを対応づけた前記セッション情報が記載されている第１のＳＩＰ信号を前記第１のユーザ端末、または、自身が収容される前記ネットワークとは別の前記ネットワークの前記セッション制御サーバから受信して、前記第２のユーザ端末、または、自身が収容される前記ネットワークとは別の前記ネットワークの前記セッション制御サーバに対して中継し、その後、
   前記第１のＳＩＰ信号への応答であり、前記第１のＳＩＰ信号が示す課金内容に承認する旨の第２のＳＩＰ信号を前記第２のユーザ端末、または、自身が収容される前記ネットワークとは別の前記ネットワークの前記セッション制御サーバから受信すると、前記第２のＳＩＰ信号を前記第１のユーザ端末、または、自身が収容される前記ネットワークとは別の前記ネットワークの前記セッション制御サーバに対して中継するとともに、前記第２のＳＩＰ信号の受信時刻と、前記第１のＳＩＰ信号内の新たに追加する前記メディアパスとその課金対象とを含むＣＤＲ（Call Detail Record）を作成して、自身が収容される前記ネットワークに接続されており、前記ＣＤＲをもとに課金対象ごとの前記受信時刻からの通信料金を計算する課金サーバへＣＤＲを送信することを特徴とする
   セッション制御サーバ。
3. 前記第１のユーザ端末と、前記第２のユーザ端末と、請求項１に記載のセッション制御サーバとを有することを特徴とする通信システム。
4. 前記第１のユーザ端末と、前記第２のユーザ端末と、請求項２に記載のセッション制御サーバとを有することを特徴とする通信システム。

Images