(57)【要約】【課題】異種網間に配置されたＩＢＣＦが着側情報を要求する際に、呼識別情報をＴｒＧＷに通知でき、呼に関するログの確認時にＴｒＧＷのログから呼を識別する際に呼識別情報を利用でき、ログ確認作業を効率化できるようにしようとするものである。【解決手段】本発明は、それぞれ種類の異なる複数の通信網に接続してセッション制御を行うセッション制御手段と、複数の通信網に接続してパケット信号の転送制御を行う転送制御手段とを備え、セッション制御手段が、受信した呼接続要求に含まれる呼を識別する呼識別情報を含む着側情報要求メッセージを転送制御手段に与えるものであることを特徴とする通信システムである。【選択図】      図１
2015186249.tif 000002
【特許請求の範囲】
【請求項１】
それぞれ種類の異なる複数の通信網に接続してセッション制御を行うセッション制御手段と、
上記複数の通信網に接続してパケット信号の転送制御を行う転送制御手段と
を備え、
上記セッション制御手段が、受信した呼接続要求に含まれる呼を識別する呼識別情報を含む着側情報要求メッセージを上記転送制御手段に与えるものである
ことを特徴とする通信システム。
【請求項２】
上記着側情報要求メッセージがＭＥＧＡＣＯ  ａｄｄリクエストであり、上記ＭＥＧＡＣＯ  ａｄｄリクエストが、呼を識別するＳＩＰ  Ｃａｌｌ−ＩＤを含むことを特徴とする請求項１に記載の通信システム。
【請求項３】
上記着側情報要求メッセージがＭＥＧＡＣＯ  ａｄｄリクエストであり、上記ＭＥＧＡＣＯ  ａｄｄリクエストは、上記セッション制御手段が受信した呼接続要求に含まれる着側の情報を示すＳＩＰ−ＵＲＩ又はｔｅｌ−ＵＲＩを含むことを特徴とする請求項１又は２に記載の通信システム。
【請求項４】
上記着側情報要求メッセージがＭＥＧＡＣＯ  ａｄｄリクエストであり、上記ＭＥＧＡＣＯ  ａｄｄリクエストは、上記セッション制御手段が受信した呼接続要求に含まれる発側の情報を示すＳＩＰ−ＵＲＩ又はｔｅｌ−ＵＲＩを含むことを特徴とする請求項１〜３のいずれかに記載の通信システム。
【請求項５】
上記転送制御手段が、上記セッション制御手段から取得した、ＳＩＰ  Ｃａｌｌ−ＩＤ、着側の情報、発側の情報の一部又は全部の呼識別情報を含むログ情報を出力するものであることを特徴とする請求項２〜４のいずれかに記載の通信システム。
【請求項６】
上記転送制御手段が、ＳＩＰ  Ｃａｌｌ−ＩＤ、着側の情報、発側の情報の一部又は全部の呼識別情報と、ＲＴＰセッションの自律解放時のログ情報とを関連付けて出力するものであることを特徴とする請求項５に記載の通信システム。
【請求項７】
それぞれ種類の異なる複数の通信網に接続してセッション制御を行うセッション制御装置において、
受信した呼接続要求に含まれる呼識別情報を含む着側情報要求メッセージを、上記複数の通信網に接続してパケット信号の転送制御を行なう転送制御装置に与える制御手段を備えることを特徴とするセッション制御装置。
【請求項８】
それぞれ種類の異なる複数の通信網に接続してパケット信号の転送制御を行なう転送制御装置において、
上記複数の通信網に接続してセッション制御を行うセッション制御装置から、呼確立要求に含まれる呼識別情報を含む着側情報要求メッセージを取得して着側情報を含む応答メッセージを返信する制御手段を備えることを特徴とする転送制御装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信システム、セッション制御装置及び転送制御装置に関し、例えば、異種網の間に配置されるセッション制御装置及び転送制御装置及び通信システムに適用し得るものである。
【背景技術】
【０００２】
３ＧＰＰ（Third  Generation  Partnership  Project）では、ＩＭＳ（IP  Multimedia  Subsystem）網との網間の接続機能としてＢＣＦ（Border  Control  Function）の標準化技術を提案している。このＢＣＦは、ＩＢＣＦ（Interconnection  Border  Control  Function）及びＴｒＧＷ（Transition  Gateway）を有しており、ＩＢＣＦがシグナリング機能を担い、ＴｒＧＷがトランスポートに関わる網間接続機能を担っている。
【０００３】
例えば、ＩＰ電話システムにおいて、従来のＩＢＣＦ、ＴｒＧＷに関する規定技術は、３ＧＰＰの仕様３ＧＰＰ  ＴＳ  ２９．１６２に記載されており、ＩＢＣＦとＴｒＧＷと間のインタフェース技術については、３ＧＰＰの仕様３ＧＰＰ  ＴＳ  ２９．２３８に記載されている。
【０００４】
３ＧＰＰ  ＴＳ  ２９．２３８では、ＩＢＣＦとＴｒＧＷ間でＭＥＧＡＣＯ（Media  Gateway  Control  Protocol：ＩＴＵ−Ｔ勧告  Ｈ．２４８）を使用することが規定されており、ＩＢＣＦとＴｒＧＷと間のインタフェースで使用されるＭＥＧＡＣＯパッケージについて３ＧＰＰ  ＴＳ  ２９．２３８  ５．１４章に記載されている。
【０００５】
従来、ＩＢＣＦがｉｎｉｔｉａｌ  ＩＮＶＩＴＥを受信した場合の呼接続処理の動作フローを図２に示す。図２は、３ＧＰＰ  ＴＳ  ２９．１６２で定義されるものである。
【０００６】
図２において、ＩＢＣＦ９１がｉｎｉｔａｉｌ  ＩＮＶＩＴＥを発側網の対向ＳＩＰ装置から受信すると（Ｓ９１）、ＩＢＣＦ９１は、Ｈ．２４８  ａｄｄリクエストをＴｒＧＷ９２に送信する（Ｓ９２）。ここで、ａｄｄリクエストには、着側網に対するＲＴＰ（Real-time  Transport  Protocol）のアドレス・ＵＤＰポートの払い出しの要求が設定される（Ｌｏｃａｌ  Ａｄｄｒ＝Ｃｈｏｏｓｅ，  Ｌｏｃａｌ  Ｐｏｒｔ＝Ｃｈｏｏｓｅ）。
【０００７】
ａｄｄリクエストを受信したＴｒＧＷ９２は、着側網に対するＲＴＰのアドレス・ＵＤＰポートを払い出し（Ｓ９３）、ＴｒＧＷ９２は、ＲＴＰのアドレス・ＵＤＰポートをａｄｄレスポンスに設定してＩＢＣＦ９１に応答する（Ｓ９４）。
【０００８】
ＩＢＣＦ９１は、受信したａｄｄレスポンスに設定されたＲＴＰのアドレス・ＵＤＰポート番号をｉｎｉｔｉａｌ  ＩＮＶＩＴＥのＳＤＰ（Session  Description  Protocol）に設定し、着側網の対向ＳＩＰ装置へｉｎｉｔｉａｌ  ＩＮＶＩＴＥを送信する。
【０００９】
ここで、図２のＳ９２では、ＩＢＣＦ９１は、ａｄｄリクエストにＳＩＰダイアログや呼を識別するためのＣａｌｌ−ＩＤ、発信者電話番号・着信者電話番号を設定されず、Ｃａｌｌ−ＩＤ、発信者電話番号・着信者電話番号がＴｒＧＷ９２に通知されない。
【００１０】
一般に、ＣＤＲ（Call  Detail  Record）など呼に関するログを識別する際、ＳＩＰの場合はＩＥＴＦ  ＲＦＣ３２６１で定義されるＣａｌｌ−ＩＤの情報、あるいは、発信者電話番号・着信者電話番号を用いて識別する。例えば、ログがテキストファイルであるなら、発信者電話番号・着信者電話番号、又は、Ｃａｌｌ−ＩＤを用いてｇｒｅｐ（検索）するのが一般的である。特に、商用で利用されているシステムに何らかの問題が発生した場合、ログの解析が必要となったときには、発信者電話番号・着信者電話番号やＣａｌｌ−ＩＤに基づいて早期に呼に関連するログを抽出し、解析する即時性が求められる。
【先行技術文献】
【特許文献】
【００１１】
【特許文献１】特開２００６−１３５５２２号公報
【発明の概要】
【発明が解決しようとする課題】
【００１２】
ところで、ＩＢＣＦとＴｒＧＷとが物理的に別の装置である場合、それぞれの装置でログが出力されることになる。
【００１３】
しかしながら、上述したように、従来のＩＢＣＦは、呼を識別するためのＣａｌｌ−ＩＤや発信者電話番号・着信者電話番号をＴｒＧＷに通知していない。このため、ＴｒＧＷで出力される呼に関するログにはＣａｌｌ−ＩＤや発信者電話番号・着信者電話番号が設定されず、呼の情報としてＣａｌｌ−ＩＤ・発信者電話番号・着信者電話番号のみがわかっている状況でＴｒＧＷのログを解析する場合、手間がかかるという問題がある。
【００１４】
特に、ＭＥＧＡＣＯで定義されるＣｏｎｔｅｘｔ−ＩＤはＩＢＣＦとＴｒＧＷしか知らない情報である。ＩＢＣＦがＣｏｎｔｅｘｔ−ＩＤをログやＣＤＲに必ず出力するとは限らない。そのため、ＩＢＣＦがＣｏｎｔｅｘｔ−ＩＤをログやＣＤＲに出力していない場合、ＴｒＧＷのログとＳＩＰ（Session  Initiation  Protocol）のログを関連付ける情報がなくなり、解析が困難になる問題がある。
【００１５】
このように、ＩＢＣＦとＴｒＧＷとの呼に関するログをマッピングする場合、Ｃｏｎｔｅｘｔ−ＩＤなどの情報を用いる必要があり、ログ確認時にＣｏｎｔｅｘｔ−ＩＤと、Ｃａｌｌ−ＩＤ・発信者電話番号・着信者電話番号とのマッピングを行う等の手間がかかる問題がある。
【００１６】
そこで、本発明は、ＩＢＣＦが着側網のＲＴＰのアドレス、ＵＤＰポートをＴｒＧＷに要求する際に、呼を識別するためのＣａｌｌ−ＩＤ・発信者電話番号・着信者電話番号をＴｒＧＷに通知できるようにすると共に、呼に関するログの確認時にＴｒＧＷのログから呼を識別する際にＣａｌｌ−ＩＤ・発信者電話番号・着信者電話番号を利用でき、ログ確認作業を効率化できるようにしようとするものである。
【課題を解決するための手段】
【００１７】
かかる課題を解決するために、第１の本発明は、（１）それぞれ種類の異なる複数の通信網に接続してセッション制御を行うセッション制御手段と、（２）複数の通信網に接続してパケット信号の転送制御を行う転送制御手段とを備え、セッション制御手段が、受信した呼接続要求に含まれる呼を識別する呼識別情報を含む着側情報要求メッセージを転送制御手段に与えるものであることを特徴とする通信システムである。
【００１８】
第２の本発明は、それぞれ種類の異なる複数の通信網に接続してセッション制御を行うセッション制御装置において、受信した呼接続要求に含まれる呼識別情報を含む着側情報要求メッセージを、複数の通信網に接続してパケット信号の転送制御を行なう転送制御装置に与える制御手段を備えることを特徴とするセッション制御装置である。
【００１９】
第３の本発明は、それぞれ種類の異なる複数の通信網に接続してパケット信号の転送制御を行なう転送制御装置において、複数の通信網に接続してセッション制御を行うセッション制御装置から、呼確立要求に含まれる呼識別情報を含む着側情報要求メッセージを取得して着側情報を含む応答メッセージを返信する制御手段を備えることを特徴とする転送制御装置である。
【発明の効果】
【００２０】
本発明によれば、ＩＢＣＦが着側網のＲＴＰのアドレス、ＵＤＰポートをＴｒＧＷに要求する際に、呼を識別するためのＣａｌｌ−ＩＤ・発信者電話番号・着信者電話番号をＴｒＧＷに通知できると共に、呼に関するログの確認時にＴｒＧＷのログから呼を識別する際にＣａｌｌ−ＩＤ・発信者電話番号・着信者電話番号を利用でき、ログ確認作業の効率化を図ることができる。
【図面の簡単な説明】
【００２１】
【図１】実施形態に係る通信システムの構成及び通信装置の内部構成を示す構成図である。
【図２】従来のＩＢＣＦがｉｎｉｔｉａｌ  ＩＮＶＩＴＥを受信した場合の呼接続処理の動作を示すシーケンス図である。
【図３】実施形態に係るＭＥＧＡＣＯ  ａｄｄリクエストの拡張パッケージを説明する説明図である。
【図４】実施形態に係る通信システムにおける通信動作の概略を示すシーケンス図である。
【図５】実施形態に係る通信システムにおけるＩＢＣＦ、ＴｒＧＷの呼接続に関する信号フローを示すシーケンスである。
【図６】実施形態に係る呼開放時にＴｒＧＷがログに出力する項目例を説明する説明図である。
【発明を実施するための形態】
【００２２】
（Ａ）主たる実施形態
以下では、本発明の通信システム、セッション制御装置及び転送制御装置の実施形態を、図面を参照しながら詳細に説明する。
【００２３】
（Ａ−１）実施形態の構成
図１は、実施形態に係る通信システムの構成及び通信装置の内部構成を示す構成図である。
【００２４】
図１において、この実施形態に係る通信システムは、第１のネットワーク5及び第２のネットワーク６に接続する、セッション制御装置（以下、ＩＢＣＦとも呼ぶ。）１と、転送制御装置（以下、ＴｒＧＷとも呼ぶ。）２とを有する。
【００２５】
また、第１のネットワーク５にはＳＩＰ装置３−１及びＲＴＰ装置４−１が存在しており、第２のネットワークにはＳＩＰ装置３−２及びＲＴＰ装置４−２が存在している。
【００２６】
なお、第１のネットワーク５及び第２のネットワーク６は、通信プロトコルをＩＰ（インターネットプロトコル）とするＩＰネットワークとすることができる。第１のネットワーク５及び第２のネットワーク６は、例えばＩＰ電話システム等のＩＰマルチメディアのセッション管理としてＳＩＰを使用するものとする。
【００２７】
ＩＢＣＦ１及びＴｒＧＷ２は、第１のネットワーク５と第２のネットワーク６との間に配置され、ネットワーク間の接続処理を行うものである。ＩＢＣＦ１及びＴｒＧＷ２は、３ＧＰＰの仕様３ＧＰＰ  ＴＳ  ２９．１６２で規定されるＢＣＦを構成するものである。
【００２８】
３ＧＰＰの仕様３ＧＰＰ  ＴＳ  ２９．１６２の規定では、システムを構成する様々な機能が規定されており、１個の機能を１台の装置で実現するようにしても良いし、複数の機能を１台の物理的な装置で実現するようにしても良いし、又は、１個の機能を複数の装置で実現するようにしても良い。
【００２９】
この実施形態では、ＩＢＣＦ１とＴｒＧＷ２とがそれぞれ物理的に異なる装置である場合を例示する。
【００３０】
ＩＢＣＦ１は、ＳＩＰによるシグナリング処理を司るシグナリング装置である。ＩＢＣＦ１は、第１のネットワーク５上のＳＩＰ装置３−１と、第２のネットワーク６上のＳＩＰ装置３−２との間のＳＩＰ処理を制御する。
【００３１】
図１に示すように、ＩＢＣＦ１は、制御部１１、第１の網側インタフェース１２、第２の網側インタフェース１３、ＴｒＧＷ側インタフェース１４、記憶部１５を有する。
【００３２】
第１の網側インタフェース１２は、第１のネットワーク５との間でパケットの授受を行うインタフェースである。
【００３３】
第２の網側インタフェース１３は、第２のネットワーク６との間でパケットの授受を行うインタフェースである。
【００３４】
ＴｒＧＷ側インタフェース１４は、ＴｒＧＷ２との間で情報を授受するインタフェースである。ＴｒＧＷ側インタフェース１４は、３ＧＰＰ  ＴＳ  ２９．２３８に規定されており、ＭＥＧＡＣＯ（ＩＴＵ−Ｔ勧告  Ｈ．２４８）を用いるものである。ＴｒＧＷ側インタフェースで用いられるＭＥＧＡＣＯパッケージは３ＧＰＰ  ＴＳ  ２９．２３８  ５．１４章に定義されている技術を用いることができる。
【００３５】
記憶部１５は、制御部１１の制御により、呼に関する情報をログとして記憶するものである。
【００３６】
制御部１１は、ＳＩＰを用いたシグナリング処理を行うＩＢＣＦ１の機能を司るものである。制御部１１は、ＣＰＵ、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、入出力インタフェース等を有しており、ＣＰＵがＲＯＭに格納される処理プログラムを実行することによりＩＢＣＦ１の機能を実現するものである。
【００３７】
制御部１１は、種々の機能を実行するものであるが、主な機能として、ＳＩＰ処理機能１１ａ、メッセージ設定機能１１ｂ、ログ制御機能１１ｃ等を有する。
【００３８】
ＳＩＰ処理機能１１ａは、それぞれ対向するＳＩＰ装置３−１及びＳＩＰ装置３−２間でやり取りされるＳＩＰメッセージの授受を行うものである。
【００３９】
メッセージ設定機能１１ｂは、発側のＳＩＰ装置からｉｎｉｔｉａｌ  ＩＮＶＩＴＥを受信したときに、着側のＲＴＰのアドレス、ポート番号（例えばＵＤＰポート）を取得要求するために、ＴｒＧＷ２にＭＥＧＡＣＯ  ａｄｄリクエストを作成して送信するものである。
【００４０】
ここで、この実施形態では、呼を識別する呼識別情報をＴｒＧＷ２に通知するために、ＭＥＧＡＣＯ  ａｄｄリクエストに拡張パッケージを定義する。メッセージ設定機能１１ｂは、受信したｉｎｉｔｉａｌ  ＩＮＶＩＴＥに含まれている、発信者電話番号・着信者電話番号に相当する情報、Ｃａｌｌ−ＩＤを、拡張パッケージに設定する。
【００４１】
図３は、この実施形態に係るＭＥＧＡＣＯ  ａｄｄリクエストの拡張パッケージを説明する説明図である。なお、この実施形態に係る拡張パッケージの名称は、ＥｘｔｅｎｓｉｏｎＥｘａｍｐｌｅＰａｃｋａｇｅ（ｅｅｐ）とする。
【００４２】
図３に示すように、拡張パッケージは、着側に関する情報要素としてＣａｌｌｅＤ  Ｔｅｌｅｐｈｏｎｅ  Ｎｕｍｂｅｒ（ｃｄｔｎ）及びＣａｌｌｅＤ  Ｐｕｂｌｉｃ  Ｕｓｅｒ  ｉｄ（ｃｄｐｕ）、発側に関する情報要素としてＣａｌｌｉｎＧ  Ｔｅｌｅｐｈｏｎｅ  Ｎｕｍｂｅｒ（ｃｇｔｎ）及びＣａｌｌｉｎｇＧ  Ｐｕｂｌｉｃ  Ｕｓｅｒ  ｉｄ（ｃｇｐｕ）、ＳＩＰのＣａｌｌ−ＩＤを格納する領域としてＳｉｐ  Ｃａｌｌ  ＩＤ（ｓｃｉｄ）を定義する。
【００４３】
ここで、ＳＩＰには、発側・着側を識別するための情報としてＩＥＴＦ  ＲＦＣ３２６１で定義されるＳＩＰ−ＵＲＩと、ＩＥＴＦ  ＲＦＣ３９６６で定義されるｔｅｌ−ＵＲＩとが一般に使用される。
【００４４】
ｉｎｉｔｉａｌ  ＩＮＶＩＴＥのＲｅｑｕｅｓｔ−ＵＲＩには着側の情報が設定される。そのため、ＩＢＣＦ１が受信したｉｎｉｔｉａｌ  ＩＮＶＩＴＥのＲｅｑｕｅｓｔ−ＵＲＩにＳＩＰ−ＵＲＩが設定された場合、メッセージ設定機能１１ｂは、ａｄｄリクエストの拡張パケットのＣａｌｌｅＤ  Ｐｕｂｌｉｃ  Ｕｓｅｒ  ｉｄ（ｃｄｐｕ）にＳＩＰ−ＵＲＩを設定する。また、ＩＢＣＦ１が受信したｉｎｉｔｉａｌ  ＩＮＶＩＴＥのＲｅｑｕｅｓｔ−ＵＲＩにｔｅｌ−ＵＲＩが設定された場合、メッセージ設定機能１１ｂは、ａｄｄリクエストの拡張パッケージのＣａｌｌｉｎＧ  Ｔｅｌｅｐｈｏｎｅ  Ｎｕｍｂｅｒ（ｃｇｔｎ）にｔｅｌ−ＵＲＩを設定する。
【００４５】
また、同じくｉｎｉｔｉａｌ  ＩＮＶＩＴＥのＰ−Ａｓｓｅｒｔｅｄ  Ｉｄｅｎｔｉｔｙ（ＩＥＴＦ  ＲＦＣ  ３３２５で定義）ヘッダには発側の情報が設定される。そのため、ＩＢＣＦ１が受信したｉｎｉｔｉａｌ  ＩＮＶＩＴＥのＰ−Ａｓｓｅｒｔｅｄ  ＩｄｅｎｔｉｔｙにＳＩＰ−ＵＲＩが設定された場合、メッセージ設定機能１１ｂは、ａｄｄリクエストの拡張パッケージのＣａｌｌｉｎｇＧ  Ｐｕｂｌｉｃ  Ｕｓｅｒ  ｉｄ（ｃｇｐｕ）にＳＩＰ−ＵＲＩを設定する。また、ＩＢＣＦが受信したｉｎｉｔｉａｌ  ＩＮＶＩＴＥのＰ−Ａｓｓｅｒｔｅｄ  Ｉｄｅｎｔｉｔｙにｔｅｌ−ＵＲＩが設定された場合、メッセージ設定機能１１ｂは、ａｄｄリクエストの拡張パッケージのＣａｌｌｉｎＧ  Ｔｅｌｅｐｈｏｎｅ  Ｎｕｍｂｅｒ（ｃｇｔｎ）にｔｅｌ−ＵＲＩを設定する。
【００４６】
さらに、メッセージ設定機能１１ｂは、ＩＢＣＦ１が受信したｉｎｉｔｉａｌ  ＩＮＶＩＴＥのＣａｌｌ−Ｉｄを、ａｄｄリクエストの拡張パッケージのＳｉｐ  Ｃａｌｌ  ＩＤ（ｓｃｉｄ）に設定する。
【００４７】
ログ制御機能１１ｃは、呼に関するログ情報の記録、出力、解析等を制御するものである。ログ制御機能１１ｃは、既存技術を適用することができ、例えば、ＣＤＲ等の呼に関するログを識別する場合、ＩＦＴＦ  ＲＦＣ３２６１で定義されるＣａｌｌ−ＩＤの情報、発信者電話番号・着信者電話番号等の呼識別情報でログ管理を行う。
【００４８】
ＴｒＧＷ２は、網間のＲＴＰパケットの授受を行うＲＴＰ制御装置である。ＴｒＧＷ２は、第１のネットワーク５上のＲＴＰ装置４−１と、第２のネットワーク６上のＲＴＰ装置４−２との間のＲＴＰパケットの送受信を行う。
【００４９】
図１に示すように、ＴｒＧＷ２は、制御部２１、第１の網側インタフェース２２、第２の網側インタフェース２３、ＩＢＣＦ側インタフェース２４、記憶部２５を有する。
【００５０】
第１の網側インタフェース２２は、第１のネットワーク５との間でパケットの授受を行うインタフェースである。
【００５１】
第２の網側インタフェース２３は、第２のネットワーク６との間でパケットの授受を行うインタフェースである。
【００５２】
ＩＢＣＦ側インタフェース２４は、ＩＢＣＦ１との間で情報を授受するインタフェースである。ＩＢＣＦ側インタフェース２４は、３ＧＰＰ  ＴＳ  ２９．２３８に規定されており、ＭＥＧＡＣＯ（ＩＴＵ−Ｔ勧告  Ｈ．２４８）を用いるものである。ＩＢＣＦ側インタフェースで用いられるＭＥＧＡＣＯパッケージは３ＧＰＰ  ＴＳ  ２９．２３８  ５．１４章に定義されている技術を用いることができる。
【００５３】
記憶部２５は、制御部２１の制御により、呼に関する情報をログとして記憶するものである。
【００５４】
制御部２１は、授受するＲＴＰパケットに関する処理を行うＴｒＧＷ２の機能を司るものである。制御部２１は、ＣＰＵ、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、入出力インタフェース等を有しており、ＣＰＵがＲＯＭに格納される処理プログラムを実行することによりＴｒＧＷ２の機能を実現するものである。
【００５５】
制御部２１は、種々の機能を実行するものであるが、主な機能として、アドレス制御機能２１ａ、ログ制御機能２１ｂ、ＲＴＰパケット送受信量計測機能２１ｃ等を有する。
【００５６】
アドレス制御機能２１ａは、ＩＢＣＦ１からＭＥＧＡＣＯ  ａｄｄリクエストを受信すると、着側網に対するＲＴＰのアドレス、ポート番号を払い出し、その着側網のＲＴＰのアドレス、ポート番号を設定したＭＥＧＡＣＯ  ａｄｄレスポンスをＩＢＣＦ１に応答するものである。
【００５７】
ログ制御機能２１ｂは、ＩＢＣＦ１からＭＥＧＡＣＯ  ａｄｄリクエストに含まれている呼識別情報を取得し、その取得した呼識別情報を用いて呼に関する情報をログとして記録、出力、解析等を行うものである。なお、呼識別情報は、図３に例示したＭＥＧＡＣＯ  ａｄｄリクエストの拡張パッケージに設定される、発信者電話番号・着信電話番号に相当する情報、Ｃａｌｌ−ＩＤ等を含む情報である。
【００５８】
ＲＴＰパケット送受信量計測機能２１ｃは、送受信されるＲＴＰパケットの送信量及び又は受信量を計測するものである。なお、ＲＴＰパケット送受信量計測機能２１ｃは、ログ解析手段の一例であり、ログ解析手段としては他の機能を実行する手段を用いるようにしてもよい。
【００５９】
（Ａ−１）実施形態の構成
次に、この実施形態に係る通信システム１０における通信処理の動作を、図面を参照しながら詳細に説明する。
【００６０】
図４は、実施形態に係る通信システム１０における通信動作の概略を示すシーケンス図である。
【００６１】
図４において、ＩＢＣＦ１は、発側のＳＩＰ装置（ここでは、ＳＩＰ装置３−１とする。）から着側のＳＩＰ装置（ここでは、ＳＩＰ装置３−２とする。）ｉｎｉｔｉａｌ  ＩＮＶＩＴＥを受信する（Ｓ１）。
【００６２】
ＩＢＣＦ１において、制御部１１は、受信したｉｎｉｔｉａｌ  ＩＮＶＩＴＥのＲｅｑｕｅｓｔ−ＵＲＩに着側の情報として含まれている＜ｓｉｐ：ＡＡＡＡ…＠ｈｏｓｔｎａｍｅ．ｃｏｍ＞のうち、＠の前半部分に記載されている「ＡＡＡＡ…」を、ＭＥＧＡＣＯ  ａｄｄリクエストの拡張パッケージのｃｄｐｕに設定する。
【００６３】
また、制御部１１は、ｉｎｉｔｉａｌ  ＩＮＶＩＴＥのＰ−Ａｓｓｅｒｔｅｄ  Ｉｄｅｎｔｉｔｙに発側の情報として含まれている＜ｔｅｌ：ＢＢＢＢ…＞のうち、「ＢＢＢＢ…」を、ＭＥＧＡＣＯ  ａｄｄリクエストの拡張パッケージのｃｇｔｎに設定する。
【００６４】
さらに、制御部１１は、ｉｎｉｔｉａｌ  ＩＮＶＩＴＥのＣａｌｌ−ＩＤ「ＣＣＣＣ…」を、ＭＥＧＡＣＯ  ａｄｄリクエストの拡張パッケージのｓｃｉｄに設定する。
【００６５】
上記のようにして、発信者電話番号・着信側電話番号、Ｃａｌｌ−ＩＤを設定したＭＥＧＡＣＯ  ａｄｄリクエストを、ＩＢＣＦ１はＴｒＧＷ２に送信する（Ｓ３）。
【００６６】
ＴｒＧＷ２では、ＴｒＧＷ１内部でログを出力する必要があるか否かを判断して、ログを出力する必要がある場合には、呼と関連する情報としてＣａｌｌ−ＩＤを出力する（Ｓ４）。
【００６７】
また、ＴｒＧＷ２では、ＩＢＣＦ１からのＭＥＧＡＣＯ  ａｄｄリクエストで指定された発信者電話番号・着信者電話番号に基づいて、ＲＴＣＰに関するポリシーを決定する（Ｓ５）。
【００６８】
さらに、ＴｒＧＷ２は、ＩＢＣＦ１からのａｄｄリクエストの内容に基づいて、着側網の情報として、ｔｅｒｍｉｎａｔｉｏｎＩＤ、ＲＴＰのアドレス（ローカルアドレス）、ポート番号（ＲＴＰローカルポート）を設定したＭＥＧＡＣＯ  ａｄｄレスポンスを、ＩＢＣＦ１に応答する（Ｓ６）。
【００６９】
そして、ＩＢＣＦ１は、受信したａｄｄレスポンスの着信網側のＲＴＰのアドレス、ポート番号を、ｉｎｉｔｉａｌ  ＩＮＶＩＴＥのＳＤＰに設定して、着側のＳＩＰ装置３−２に送信する（Ｓ７）。
【００７０】
図５は、実施形態に係る通信システム１０におけるＩＢＣＦ１、ＴｒＧＷ２の呼接続に関する信号フローを示すシーケンスである。
【００７１】
ＩＢＣＦ１は、発側のＳＩＰ装置３−２からｉｎｉｔｉａｌ  ＩＮＶＩＴＥを受信すると（Ｓ１０１）、ＭＥＧＡＣＯ  ａｄｄリクエストをＴｒＧＷ２へ送信する（Ｓ１０２）。
【００７２】
ここで、ＩＢＣＦ１は、受信したｉｎｉｔａｉｌ  ＩＮＶＩＴＥのＲｅｑｕｅｓｔ−ＵＲＩの情報をａｄｄリクエストのＣａｌｌｅＤ  Ｔｅｌｅｐｈｏｎｅ  Ｎｕｍｂｅｒ（ｃｄｔｎ）又はＣａｌｌｅＤ  Ｐｕｂｌｉｃ  Ｕｓｅｒ  ｉｄ（ｃｄｐｕ）に設定し、ｉｎｉｔａｉｌ  ＩＮＶＩＴＥのＰ−Ａｓｓｅｒｔｅｄ  Ｉｄｅｎｔｉｔｙヘッダの情報をＣａｌｌｉｎＧ  Ｔｅｌｅｐｈｏｎｅ  Ｎｕｍｂｅｒ（ｃｇｔｎ）又はＣａｌｌｉｎｇＧ  Ｐｕｂｌｉｃ  Ｕｓｅｒ  ｉｄ（ｃｇｐｕ）に設定し、ＳＩＰ  Ｃａｌｌ−ＩＤヘッダの情報をＭＥＧＡＣＯ  ａｄｄリクエストのＳｉｐ  Ｃａｌｌ  ＩＤ（ｓｃｉｄ）に設定する。
【００７３】
なお、ｉｎｉｔｉａｌ  ＩＮＶＩＴＥにＰ−Ａｓｓｅｔｅｄ  Ｉｄｅｎｔｉｔｙが付与されていなかった場合、ＩＢＣＦ１はａｄｄリクエストのＣａｌｌｉｎＧ  Ｔｅｌｅｐｈｏｎｅ  Ｎｕｍｂｅｒ（ｃｇｔｎ）・ＣａｌｌｉｎｇＧ  Ｐｕｂｌｉｃ  Ｕｓｅｒ  ｉｄ（ｃｇｐｕ）の設定は行わないようにしても良い。
【００７４】
ＴｒＧＷ２は、ＭＥＧＡＣＯ  ａｄｄリクエストを受信すると、ａｄｄリクエストに含まれる着側の情報（ＣａｌｌｅＤ  Ｔｅｌｅｐｈｏｎｅ  Ｎｕｍｂｅｒ（ｃｄｔｎ）またはＣａｌｌｅＤ  Ｐｕｂｌｉｃ  Ｕｓｅｒ  ｉｄ（ｃｄｐｕ））、発側の情報（ＣａｌｌｉｎＧ  Ｔｅｌｅｐｈｏｎｅ  Ｎｕｍｂｅｒ（ｃｇｔｎ）またはＣａｌｌｉｎｇＧ  Ｐｕｂｌｉｃ  Ｕｓｅｒ  ｉｄ（ｃｇｐｕ））、Ｓｉｐ  Ｃａｌｌ  ＩＤ（ｓｃｉｄ）を蓄積し、着側網に対するＴｒＧＷ２側のＲＴＰアドレス、ＵＤＰポート番号を払い出し（Ｓ１０３）、ＭＥＧＡＣＯ  ａｄｄレスポンスを返却する（Ｓ１０４）。
【００７５】
Ｓ１０３で、ＴｒＧＷ２が蓄積した着側の情報（着信者電話番号に相当する情報）、発側の情報（発信者電話番号に相当する情報）、Ｃａｌｌ−ＩＤは、ＴｒＧＷ１においてログ出力が行なわれるまで保持される。
【００７６】
ＭＥＧＡＣＯ  ａｄｄレスポンスを受信したＩＢＣＦ１は、払いだされたＲＴＰアドレス、ＵＤＰポート番号をｉｎｉｔｉａｌ  ＩＮＶＩＴＥのＳＤＰへ設定し、着側のＳＩＰ装置３−２へ送信する（Ｓ１０５）。
【００７７】
Ｓ１０６では、着側で呼び出し（Ｒｉｎｇｉｎｇ）が開始されたことを示すｉｎｉｔｉａｌ  ＩＮＶＩＴＥの１８０暫定応答がＳＩＰ装置３−２からＩＢＣＦ１に返信される。
【００７８】
ＩＢＣＦ１は、ｉｎｉｔｉａｌ  ＩＮＶＩＴＥの１８０暫定応答を受信すると、ＳＤＰが含まれていないためＴｒＧＷへのアクセスなしに発側のＳＩＰ装置３−１に１８０暫定応答を送信する（Ｓ１０７）。
【００７９】
Ｓ１０８で、ＩＢＣＦ１が、着側のＳＩＰ装置３−２から、ｉｎｉｔｉａｌ  ＩＮＶＩＴＥに対する２００  ＯＫをＩＢＣＦ１を受信すると、ＩＢＣＦ１は受信した２００  ＯＫのＳＤＰに付与されている着側のＲＴＰアドレス、ＵＤＰポート番号をＭＥＧＡＣＯ  ｍｏｄｉｆｙリクエストに設定して、ＴｒＧＷ２に送信する（Ｓ１０９）。
【００８０】
ｍｏｄｉｆｙ  リクエストを受信したＴｒＧＷ２は、ｍｏｄｉｆｙレスポンスをＩＢＣＦ１へ返却し（Ｓ１１０）、着側のＴｅｒｍｉｎａｔｉｏｎを確立する。
【００８１】
ここで、ＭＥＧＡＣＯの基本的な概念として、ＩＴＵ−Ｔ勧告  Ｈ．２４８．１  ６章に記載があるようにＣｏｎｔｅｘｔ、Ｔｅｒｍｉｎａｔｉｏｎがあり、ＩＢＣＦ１はＴｅｒｍｉｎａｔｉｏｎを発側、着側それぞれで確立する必要がある。発側と着側のＴｅｒｍｉｎａｔｉｏｎはＣｏｎｔｅｘｔで関連付けられる。図５の例では、着側Ｔｅｒｍｉｎａｔｉｏｎの識別子は「Ｔ１」、発側Ｔｅｒｍｉｎａｔｉｏｎの識別子は「Ｔ２」としており、「Ｔ１」と「Ｔ２」を関連付けるＣｏｎｔｅｘｔの識別子を「Ｃ１」としている。
【００８２】
続けて、ＩＢＣＦ１は、発側Ｔｅｒｍｉｎａｔｉｏｎを確立するために、発側のＲＴＰアドレス・ＵＤＰポート番号と、発側網に対するＴｒＧＷ１側のＲＴＰのアドレス・ＵＤＰポートの払い出しの要求を設定したａｄｄリクエストを、ＴｒＧＷ１に送信する（Ｓ１１１）。
【００８３】
ＴｒＧＷ１は、Ｓ１１１のａｄｄリクエストを受信すると、発側に対するＴｒＧＷ側のＲＴＰアドレス・ＵＤＰポートを払い出し、ａｄｄレスポンスに設定して、ＩＢＣＦ１へ送信する（Ｓ１１２）。
【００８４】
ＩＢＣＦ１は、ＴｒＧＷ２からａｄｄレスポンスを受信すると、ｉｎｉｔｉａｌ  ＩＮＶＩＴＥに対する２００  ＯＫ応答を発側のＳＩＰ装置３−１へ送信し（Ｓ１１３）、ＩＢＣＦ１で呼が確立され、ＲＴＰセッションがＴｒＧＷ２で確立され、通話が開始される。
【００８５】
通話終了時、ＩＢＣＦ１は、発側のＳＩＰ装置３−１若しくは着側のＳＩＰ装置３−２からＢＹＥを受信する（Ｓ１１４）。なお、図５では、ＢＩＣＦ１が着側のＳＩＰ装置３−２からＢＹＥを受信した場合の例示している。
【００８６】
ＢＹＥを受信したＩＢＣＦ１は、まず着側Ｔｅｒｍｉｎａｔｉｏｎを解放するために、ＭＥＧＡＣＯ  ｓｕｂｔｒｕｃｔリクエストを送信する（Ｓ１１５）。ｓｕｂｔｒｕｃｔリクエストを受信したＴｒＧＷ２は、着側Ｔｅｒｍｉｎａｔｉｏｎを解放し、ｓｕｂｔｒｕｃｔレスポンスをＩＢＣＦ１へ送信する（Ｓ１１６）。
【００８７】
続けて、ＩＢＣＦ１は、発側Ｔｅｒｍｉｎａｔｉｏｎを解放するために、ＭＥＧＡＣＯ  ｓｕｂｔｒｕｃｔリクエストをＴｒＧＷ２に送信する（Ｓ１１７）。
【００８８】
ｓｕｂｔｒｕｃｔリクエストを受信したＴｒＧＷ２は、発側Ｔｅｒｍｉｎａｔｉｏｎを解放し、ｓｕｂｔｒｕｃｔレスポンスをＩＢＣＦ１へ送信する（Ｓ１１８）。Ｔｅｒｍｉｎａｔｉｏｎの解放が完了したＩＢＣＦ１は、発側のＳＩＰ装置３−１にＢＹＥを転送する（Ｓ１１９）。
【００８９】
一方、発側・着側Ｔｅｒｍｉｎａｔｉｏｎの両方の解放が完了したＴｒＧＷ２は、呼に関する情報をログに出力する（Ｓ１２０）。
【００９０】
図６は、実施形態に係る呼開放時にＴｒＧＷ１がログに出力する項目例を説明する説明図である。
【００９１】
図６に例示するログに出力する項目は、「項番１」〜「項番２１」の２１個の項目を有する。具体的には、「ＳＩＰ  Ｃａｌｌ−ＩＤ」、「着信先情報」、「発信者情報」、「Ｃｏｎｔｅｘｔ−ＩＤ」、「Ｃｏｎｔｅｘｔ解放要因」等を含む。
【００９２】
ここで、ＴｒＧＷ２は、図５のＳ１０２のａｄｄリクエストで受信し、蓄積していた着側に関する情報、発側に関する情報、ＳＩＰ  Ｃａｌｌ−ＩＤをログの項目に出力する。ログに着側に関する情報、発側に関する情報、ＳＩＰ  Ｃａｌｌ−ＩＤを出力することで、呼に関する発側電話番号、または着側電話番号、またはＳＩＰ  Ｃａｌｌ−ＩＤが分かれば、それに関連付けられるログ情報を容易に抽出可能となる。
【００９３】
また、さらに、図６の「項番２１」にはＴｒＧＷ２が内部エラーなど自律的にＲＴＰセッションを解放した場合に解析に必要な情報を出力するフィールドとして「Ｃｏｎｔｅｘ解放要因」を用意しておく。ＴｒＧＷ２が自律でＲＴＰセッションを開放した場合、図６の「項番２１」に自律で解放した旨を示す情報を出力することで、ログからＴｒＧＷ２側が自律解放した呼のＣａｌｌ−ＩＤ、発信者電話番号・着信者電話番号がわかり、ＴｒＧＷ２の自律解放によるサービス影響を受けた呼やエンドユーザを容易に特定できる。
【００９４】
（Ａ−３）実施形態の効果
以上のように、この実施形態によれば、ＭＥＧＡＣＯ  ａｄｄリクエストに図４に示すＳＩＰ装置が呼を識別するため情報と同じ情報を付与し、ＴｒＧＷがログに図４に示す情報を出力することで、従来技術で説明した、ＴｒＧＷのログを解析するには手間がかかるという問題、ＩＢＣＦがＣｏｎｔｅｘｔ−ＩＤをログやＣＤＲに出力していない場合はＴｒＧＷのログとＳＩＰのログを関連付ける情報がなくなり、解析が困難になる問題を解決できる。
【００９５】
また、この実施形態によれば、図６に例示した呼を特定する情報とＴｒＧＷがＲＴＰセッション自律解放したことを示す情報を関連付けておくことで、ＴｒＧＷがＲＴＰセッションの自律解放時にサービス影響を受けた呼、エンドユーザを容易に特定できるという効果がある。
【００９６】
（Ｂ）他の実施形態
上述した実施形態においても種々の変形実施形態を言及したが、本発明は、以下の変形実施形態にも適用可能である。
【００９７】
本発明の要点はＩＢＣＦがＭＥＧＡＣＯ  ａｄｄリクエストに図３に示すような発側の情報、着側の情報、ＳＩＰ  Ｃａｌｌ−ＩＤを設定することである。
【００９８】
上述した実施形態では、図５でｉｎｉｔｉａｌ  ＩＮＶＩＴＥに対する２００  ＯＫにＳＤＰアンサーが付与される例となっていたが、ｉｎｉｔｉａｌ  ＩＮＶＩＴＥに対する１ｘｘ暫定応答にＳＤＰアンサーが付与されるケースでも適用できる。
【００９９】
また、上述した実施形態では、図５において、着側のＳＩＰ装置からＢＹＥで切断されていたが、発側のＳＩＰ装置からのＢＹＥもしくはＣＡＮＣＥＬによる切断のケースでも適用可能である。
【符号の説明】
【０１００】
１０…通信システム、１…シグナリング装置（ＩＢＣＦ）、２…ＲＴＰ制御装置（ＴｒＧＷ）、１１…制御部、１２…第１の網側インタフェース、１３…第２の網側インタフェース、１４…ＴｒＧＷ側インタフェース、１５…記憶部、２１…制御部、２２…第１の網側インタフェース、２３…第２の網側インタフェース、２４…ＴｒＧＷ側インタフェース、２５…記憶部、３−１及び３−２…ＳＩＰ装置、４−１及び４−２…ＲＴＰ装置、５…第１のネットワーク、６…第２のネットワーク。
【図１】
2015186249.tif 000003
【図２】
2015186249.tif 000004
【図３】
2015186249.tif 000005
【図４】
2015186249.tif 000006
【図５】
2015186249.tif 000007
【図６】
2015186249.tif 000008