"パケット交換網により音声呼と非音声呼の両方を処理する第1事業者網と、回線交換網とパケット交換網の2網を組み合わせて音声呼と非音声呼を処理する第2事業者網とを相互接続した相互接続網におけるネットワーク制御方法であって、前記第1事業者網に備えられたセッション処理装置が、当該第1事業者網に接続されたユーザ装置から呼接続要求を受信したときに、当該呼接続要求の宛先を判定する判定ステップと、前記呼接続要求が前記第2事業者網宛である場合に、前記セッション処理装置は、記憶手段に格納されたポリシを取得し、当該ポリシに基づいて、前記呼接続要求に係る呼種別を決定し、決定した呼種別に応じた経路で前記呼接続要求の転送を行う経路制御ステップとを備えたことを特徴とするネットワーク制御方法。前記経路制御ステップにおいて、前記セッション処理装置は、前記ポリシに基づいて、前記呼接続要求が、音声呼要求と非音声呼要求とが重畳されたものであると判定した場合に、当該呼接続要求を音声呼接続要求と非音声呼接続要求に分割し、それぞれに応じた経路で当該音声呼接続要求、及び当該非音声呼接続要求の転送を行うことを特徴とする請求項1に記載のネットワーク制御方法。前記第1事業者網に接続された第1ユーザ装置と、前記第2事業者網に接続された第2ユーザ装置との間で音声呼又は非音声呼のいずれかが確立している状態において、前記セッション処理装置が、前記第2ユーザ装置から前記第1ユーザ装置宛に、音声呼又は非音声呼の確立していないもう一方の呼に係る呼接続要求を受信した場合に、当該呼接続要求を、前記確立済みの呼に集約した呼制御信号を生成し、前記第1ユーザ装置宛に転送する呼集約ステップを更に備えることを特徴とする請求項1又は2にネットワーク制御方法。パケット交換網により音声呼と非音声呼の両方を処理する第1事業者網と、回線交換網とパケット交換網の2網を組み合わせて音声呼と非音声呼を処理する第2事業者網とを相互接続した相互接続網におけるネットワーク制御方法であって、前記第2事業者網のパケット交換網に備えられたセッション処理装置が、前記第1事業者網から呼接続要求を受信したときに、記憶手段に格納されたポリシを取得し、当該ポリシに基づいて、前記呼接続要求に係る呼種別を決定し、決定した呼種別に応じた経路で前記呼接続要求の転送を行う経路制御ステップを備えたことを特徴とするネットワーク制御方法。前記経路制御ステップにおいて、前記セッション処理装置は、前記ポリシに基づいて、前記呼接続要求が、音声呼要求と非音声呼要求とが重畳されたものであると判定した場合に、当該呼接続要求を音声呼接続要求と非音声呼接続要求に分割し、それぞれに応じた経路で当該音声呼接続要求、及び当該非音声呼接続要求の転送を行うことを特徴とする請求項4に記載のネットワーク制御方法。前記第1事業者網に接続された第1ユーザ装置と、前記第2事業者網に接続された第2ユーザ装置との間で音声呼又は非音声呼のいずれかが確立している状態において、前記セッション処理装置が、前記第2ユーザ装置から前記第1ユーザ装置宛に、音声呼又は非音声呼の確立していないもう一方の呼に係る呼接続要求を受信した場合に、当該呼接続要求を、前記確立済みの呼に集約した呼制御信号を生成し、前記第1ユーザ装置宛に転送する呼集約ステップを更に備えることを特徴とする請求項4又は5に記載のネットワーク制御方法。前記ポリシを格納する記憶手段は、前記セッション処理装置と通信網を介して接続されたデータベース装置であることを特徴とする請求項1ないし6のうちいずれか1項に記載のネットワーク制御方法。パケット交換網により音声呼と非音声呼の両方を処理する第1事業者網と、回線交換網とパケット交換網の2網を組み合わせて音声呼と非音声呼を処理する第2事業者網とを相互接続した相互接続網における前記第1事業者網に備えられるセッション処理装置であって、前記第1事業者網に接続されたユーザ装置から呼接続要求を受信したときに、当該呼接続要求の宛先を判定する判定手段と、前記呼接続要求が前記第2事業者網宛である場合に、記憶手段に格納されたポリシを取得し、当該ポリシに基づいて、前記呼接続要求に係る呼種別を決定し、決定した呼種別に応じた経路で前記呼接続要求の転送を行う経路制御手段とを備えたことを特徴とするセッション処理装置。パケット交換網により音声呼と非音声呼の両方を処理する第1事業者網と、回線交換網とパケット交換網の2網を組み合わせて音声呼と非音声呼を処理する第2事業者網とを相互接続した相互接続網における前記第2事業者網のパケット交換網に備えられるセッション処理装置であって、前記第1事業者網から呼接続要求を受信したときに、記憶手段に格納されたポリシを取得し、当該ポリシに基づいて、前記呼接続要求に係る呼種別を決定し、決定した呼種別に応じた経路で前記呼接続要求の転送を行う経路制御手段を備えたことを特徴とするセッション処理装置。非特許文献2におけるSIPASは、事業者Aまたは事業者Bいずれかに配備され、該事業者のSCSCFにおけるiFC処理に基づき転送された呼を受信する。SIPASが処理した音声呼、非音声呼は、ともに、一旦SCSCFに戻され、SCSCFにおいて通常のIMSにおける電話番号から予め決められた規則に従い接続先を判断する宛先解決処理および経路決定処理にかけられ、その結果として、音声呼はSIPASが指定したゲートウェイに経路決定され、非音声呼は宛先解決によって導かれる後位のIMS装置例:PCSCFなどに転送されることになる。非特許文献2のSIPASによって実行される、呼の種別に応じた経路制御の処理は、着信側網である事業者BのSIPASで行われる場合、音声呼を提供しないIMSにおいて、網間の関門装置に相当し他網からの着信時に必ず呼処理を担うICSCF、ないしはIBCFだけでなく、SCSCF、SIPASまでもが、IMSでは提供しないはずの音声呼について処理を行う必要が生じ、設備利用が非効率化する、一旦IMS設備で音声呼を処理し、あらためて回線交換網へ転送するため、音声呼の接続遅延が増加する、といった問題が生じる。事業者Bでは、IMSのみを運用する事業者Aから、本来は直接回線交換網で受けるべき音声呼を、相互接続合意上の理由等によりIMSで着信した場合に、一早く回線交換網に音声呼を転送し、IMSにおいて不要な音声呼処理を継続しないようにすることが望ましい。また、発信側網である事業者Aで呼の種別に応じた経路制御の処理が行われる場合、SIPASでの宛先解決とSCSCFでの宛先解決が2回重複して行われることとなり、機能配備設備が冗長化する問題がある。事業者A内では、自網内に閉じる呼についてはASによる呼種識別経路制御の処理は不要であり、SCSCFによる通常の宛先解決処理のみで接続が可能である。また、事業者Bに向かう呼については、反対に、ASにより既に経路決定までが行われた呼についてSCSCFが重複した宛先解決を行うこととなる。本発明は上記の点に鑑みてなされたものであり、パケット交換網により音声呼と非音声呼の両方を処理する第1事業者網と、回線交換網とパケット交換網の2網を組み合わせて音声呼と非音声呼を処理する第2事業者網とを相互接続した相互接続網において、設備利用を冗長化させることなく、更に、呼の接続遅延を増加させることなく、接続するSIP呼の種別に応じた適切な接続先を選択し、転送を行うためのネットワーク制御技術を提供することを目的とする。上記の課題を解決するために、本発明は、パケット交換網により音声呼と非音声呼の両方を処理する第1事業者網と、回線交換網とパケット交換網の2網を組み合わせて音声呼と非音声呼を処理する第2事業者網とを相互接続した相互接続網におけるネットワーク制御方法であって、前記第1事業者網に備えられたセッション処理装置が、当該第1事業者網に接続されたユーザ装置から呼接続要求を受信したときに、当該呼接続要求の宛先を判定する判定ステップと、前記呼接続要求が前記第2事業者網宛である場合に、前記セッション処理装置は、記憶手段に格納されたポリシを取得し、当該ポリシに基づいて、前記呼接続要求に係る呼種別を決定し、決定した呼種別に応じた経路で前記呼接続要求の転送を行う経路制御ステップとを備えたことを特徴とするネットワーク制御方法として構成される。前記経路制御ステップにおいて、前記セッション処理装置は、前記ポリシに基づいて、前記呼接続要求が、音声呼要求と非音声呼要求とが重畳されたものであると判定した場合に、当該呼接続要求を音声呼接続要求と非音声呼接続要求に分割し、それぞれに応じた経路で当該音声呼接続要求、及び当該非音声呼接続要求の転送を行うこととしてもよい。また、前記第1事業者網に接続された第1ユーザ装置と、前記第2事業者網に接続された第2ユーザ装置との間で音声呼又は非音声呼のいずれかが確立している状態において、前記セッション処理装置が、前記第2ユーザ装置から前記第1ユーザ装置宛に、音声呼又は非音声呼の確立していないもう一方の呼に係る呼接続要求を受信した場合に、当該呼接続要求を、前記確立済みの呼に集約した呼制御信号を生成し、前記第1ユーザ装置宛に転送する呼集約ステップを更に備えることとしてもよい。また、本発明は、パケット交換網により音声呼と非音声呼の両方を処理する第1事業者網と、回線交換網とパケット交換網の2網を組み合わせて音声呼と非音声呼を処理する第2事業者網とを相互接続した相互接続網におけるネットワーク制御方法であって、前記第2事業者網のパケット交換網に備えられたセッション処理装置が、前記第1事業者網から呼接続要求を受信したときに、記憶手段に格納されたポリシを取得し、当該ポリシに基づいて、前記呼接続要求に係る呼種別を決定し、決定した呼種別に応じた経路で前記呼接続要求の転送を行う経路制御ステップを備えたことを特徴とするネットワーク制御方法として構成することもできる。前記経路制御ステップにおいて、前記セッション処理装置は、前記ポリシに基づいて、前記呼接続要求が、音声呼要求と非音声呼要求とが重畳されたものであると判定した場合に、当該呼接続要求を音声呼接続要求と非音声呼接続要求に分割し、それぞれに応じた経路で当該音声呼接続要求、及び当該非音声呼接続要求の転送を行うようにしてもよい。また、前記第1事業者網に接続された第1ユーザ装置と、前記第2事業者網に接続された第2ユーザ装置との間で音声呼又は非音声呼のいずれかが確立している状態において、前記セッション処理装置が、前記第2ユーザ装置から前記第1ユーザ装置宛に、音声呼又は非音声呼の確立していないもう一方の呼に係る呼接続要求を受信した場合に、当該呼接続要求を、前記確立済みの呼に集約した呼制御信号を生成し、前記第1ユーザ装置宛に転送する呼集約ステップを更に備えることとしてもよい。また、本発明は、上記各ネットワーク制御方法におけるセッション処理装置の処理手順を実行する手段を備えたセッション処理装置として構成することもできる。本発明によれば、パケット交換網により音声呼と非音声呼の両方を処理する第1事業者網と、回線交換網とパケット交換網の2網を組み合わせて音声呼と非音声呼を処理する第2事業者網とを相互接続した相互接続網において、設備利用を冗長化させることなく、更に、呼の接続遅延を増加させることなく、接続するSIP呼の種別に応じた適切な接続先を選択し、転送を行うためのネットワーク制御技術を提供することができる。すなわち、本発明の一実施形態に係る技術によれば、IMSにおいて、呼種識別を要する特殊な経路決定の実行を、通常の経路決定のみで十分なSIP呼の処理から分離させることで、装置の処理負荷軽減、接続遅延低減等を可能にしている。これにより、ユーザはより優れた品質の通信サービスを享受することができるようになる。また、IMSにおける設備の利用効率が向上し、設備コストを低減させることができる。更に、音声呼と非音声呼の重畳分離を網構成に応じて適切に制御することが可能となる。以下、図面を参照して本発明の実施例を説明する。システム構成図1に、本発明の実施の形態におけるシステムの全体構成を示す。本実施の形態では、音声呼と非音声呼の両方を処理する事業者AのIMSベースのパケット交換網IMSベースのパケット交換網を単にIMS網とも呼ぶと、回線交換網CS網B200とIMSベースのパケット交換網B200を組み合わせて音声呼と非音声呼を処理する事業者Bの網とが相互接続された構成を有する。また、事業者AのIMS網にはユーザUEが接続されている。事業者AのIMS網において図示されているポリシDB以外の各装置は、その名称に対応するIMSの規定に準拠した機能を少なくとも含む装置である。例えば、図1におけるSCSCFは、IMSで規定されたSCSCFの機能を含むSIP処理装置である。本実施の形態では、図1において網掛けで示した装置が、本発明に係る機能を備えている。すなわち、SCSCF、ICSCF、IBCFは本発明に係る機能を有するSIP処理装置である。本実施の形態では、これらをIMS装置とも呼ぶ。また、セッション処理装置と呼んでもよい。ポリシDBは、呼接続の経路決定、呼種識別のポリシを格納するデータベース装置である。ポリシDBは、単独のデータベース装置としてIMS網上に備えてもよいし、IMSを構成しているSIP処理装置内例えば、IMS装置内に備えることとしてもよい。事業者BにおけるIMS網図1では、事業者Aから見て他IMSと記載は、基本的に事業者AのIMS網と同様の装置構成を有し、SCSCF、ICSCF、IBCFが本発明に係る機能を有し、ポリシDBを備える。なお、本実施の形態の説明では、事業者Aの装置には、Aから始まる参照符号を付し、事業者Bの対応する装置には、Bから始まる同じ番号の参照符号を付すものとする。図2に、IMS装置具体的には、SCSCF,ICSCF,又はIBCFの機能構成図を示す。図2に示すように、IMS装置は、SIP制御部1、DB処理部2、通信制御部3、及びソケット部4を備える。ソケット部4及び通信制御部3は、IMS装置が、他の装置例えば、図示されたポリシDBや他のIMS装置と通信網を介して通信を行うための機能部である。SIP制御部1は、SIPのヘッダボディ処理、トランザクション管理、ダイアログ管理、セッションタイマ管理等を行う機能部であり、IMSにおける通常のSIP処理のほか、DB処理部2を介してSIP処理ポリシを取得し、ポリシに応じたSIP処理を実行する。ポリシに応じたSIP処理については、後の動作説明のところで詳細に説明する。DB処理部2は、SIPの呼種識別経路決定呼分割に必要なSIP処理ポリシを取得するために、ポリシDBにアクセスする機能部である。IMS装置は、コンピュータに、本実施の形態で説明する処理内容を記述したプログラムを実行させることにより実現可能である。すなわち、IMS装置において、各部が有する機能は、当該装置を構成するコンピュータに内蔵されるCPUやメモリなどのハードウェア資源を用いて、各部で実施される処理に対応するプログラムを実行することによって実現することが可能である。また、当該プログラムは、当該プログラムを記録したFD、CD-ROM、DVDなどの記録媒体や、インターネットなどのネットワークを介して市場に流通させることができる。実施の形態の概要本実施の形態に係るシステムの動作シーケンスを詳細に説明する前に、まず、本実施の形態に係る技術の原理概要を説明する。事業者Bに本発明に係る技術を適用した場合、事業者B内で事業者Aからの着信呼を処理する際に、事業者AからのSIP呼を受信したIBCF、ICSCFのいずれかにおいて、SCSCFに転送する前に当該呼の種別に応じた呼の経路制御処理を実行する。この時、ICSCF、IBCFが受信したSIP呼に音声呼と非音声呼が重畳されている場合、そのままでは自らのIMSをベースとしたパケット交換網と回線交換網のどちらに転送しても正しく処理することができず、適切な経路制御が実行できない事態が発生する。そこで、本実施の形態では、事業者Bの網構成に合わせて音声呼と非音声呼を異なる経路へ転送できるよう、単一の呼として受信したSIP呼を、事業者Bの構成に応じて、2つ以上の複数呼に分割する処理も実施可能となっている。さらに、既に音声呼または非音声呼いずれかを事業者Aのユーザと事業者Bのユーザとの間で確立している状態で、事業者Bの当該ユーザから事業者Aの当該ユーザ宛に、音声呼または非音声呼の確立していないもう一方の呼を着信した際に、サービス条件等の理由により、事業者Aのユーザに対して複数の個別SIP呼を同時に確立することができない場合には、後続の呼が確立不可能となってしまう。そこで、本実施の形態では、後続の新規呼を、確立済みの既存呼に集約して、事業者Aのユーザに対して単一のSIP呼に見せて呼を確立可能とするよう、個別の複数呼を単一のSIP呼に集約する処理も実施可能とする。事業者Aに本発明に係る技術を適用した場合、事業者A内で事業者B向けの呼を処理する際に、事業者AのSCSCFによる宛先解決を実施した結果、他網接続と判断された呼のみについて、SCSCF、ICSCF、IBCFのいずれかにおいて呼種別に応じた呼の経路制御処理を実行する。この時、SCSCF、ICSCF、IBCFが受信したSIP呼に音声呼と非音声呼が重畳されている場合、そのままでは適切な経路制御が実行できない事態が発生する。そこで、本実施の形態では、事業者Bの網構成に合わせて音声呼と非音声呼を異なる経路へ転送できるよう、単一の呼として受信したSIP呼を、対向事業者Bの構成に応じて、2つ以上の複数呼に分割する処理も実施可能とする。さらに、既に音声呼または非音声呼いずれかを事業者Aのユーザと事業者Bのユーザとの間で確立している状態で、事業者Bの当該ユーザから事業者Aの当該ユーザ宛に、音声呼または非音声呼の確立していないもう一方の呼を着信した際に、サービス条件等の理由により、事業者Aのユーザに対して複数の個別SIP呼を同時に確立することができない場合には、後続の呼が確立不可能となってしまう。そこで、本実施の形態では、後続の新規呼を、確立済みの既存呼に集約して、事業者Aのユーザに対して単一のSIP呼に見せて呼を確立可能とするよう、個別の複数呼を単一のSIP呼に集約する処理も実施可能とする。さらに、上記いずれの場合においても、SCSCF、ICSCF、IBCFが実行する呼種識別経路制御呼分割呼集約のポリシは、自網や接続先事業者の網構成の変化などに影響を受けるが、これによりポリシに変更の必要が生じた場合、SCSCF、ICSCF、IBCF自体に改修を要し、改修実施、改修後の試験実施など運用上のコストが増大する上、不適切な改修作業により当該ポリシの変更とは無関係な呼処理にまで影響が及ぶリスクを生じるという問題が発生する。そこで本実施の形態では、当該ポリシをSCSCF、ICSCF、IBCFから切り離したデータベース記憶手段の一種に格納し、改修範囲を当該データベースに限定することで、この問題を解決することが可能である。もちろん、呼種別に基づく経路制御等を行うにあたっては、ポリシデータベースをSCSCF、ICSCF、IBCFから切り離すことは必須ではなく、ポリシのデータをSCSCF、ICSCF、IBCF内部の記憶手段に備える構成を採用してもよい。上述したように、事業者Aと事業者Bのいずれか一方に、本発明に係る技術を適用することで、これまでに述べた課題を解決することができる。システムの動作:処理シーケンス例次に、本発明の実施の形態に係るシステムの動作例について、シーケンス図を参照しながら説明する。<音声のみの場合における事業者ASCSCFの動作:図3>まず、処理対象が音声のみであり、事業者AのSCSCFが呼種識別経路決定を行う場合の動作例を図3のシーケンス図を参照して説明する。UEからINVITEが送出され、PCSCFを経由してSCSCFに届くステップ1、2。SCSCFは、iFCinitialFilterCriteria処理により、宛先解決を行うステップ3、4。ここでの宛先解決により、SCSCFは、今回のINVITEに係る呼が他網宛事業者Bの網宛であると判定し、ポリシ適用処理の対象であると判断する。本実施の形態では、他網宛であると分かった呼のみを、本発明のポリシ適用処理の対象としており、これにより、自網内の音声呼接続等を不要なポリシ適用の対象から外すことができる。この点は、他のシーケンスにおいても同様である。次に、SCSCFは、ポリシDBに対してポリシ要求を行い、ポリシDBからポリシを取得するステップ5、6。SCSCFは、対象となっているSIP信号にポリシを適用して呼種識別、及び経路決定を行うステップ7。本例では、ポリシ適用の結果、呼種別が音声呼であり、SIP信号の転送先がBGCFBreakoutGatewayControlFunctionであると判定され、INVITEがBGCFに転送されるステップ8。なお、本実施の形態では、まず、BGCFに転送する例を示しているが、BGCFを介さずにMGCFMediaGatewayControlFunctionに転送するようにしてもよい。ステップ8の後、BGCF、MGCF、IMMGW、CS網の間で通常の呼接続手順が実行されるステップ9。その後、応答信号の送受信等、呼確立のための手順が実行されステップ10、呼が確立し、エンドーエンドでの音声通信が行われるステップ11。なお、ステップ9、10での手順は、通常の手順であるので、詳細については記載していない。他のシーケンス図でも同様である。<音声非音声重畳の場合における事業者ASCSCFの動作:図4>次に、処理対象が音声非音声重畳呼であり、事業者AのSCSCFが呼種識別経路決定を行う場合の動作例を図4のシーケンス図を参照して説明する。UEからINVITEが送出され、PCSCFを経由してSCSCFに届くステップ1、2。SCSCFは、iFCinitialFilterCriteria処理により、宛先解決を行うステップ3、4。ここでの宛先解決により、SCSCFは、今回のINVITEに係る呼が他網宛事業者Bの網宛であると判定し、ポリシ適用処理の対象であると判断する。次に、SCSCFは、ポリシDBに対してポリシ要求を行い、ポリシDBからポリシを取得するステップ5、6。SCSCFは、対象のSIP信号にポリシを適用して呼種識別、及び経路決定を行うステップ7。本例では、ポリシ適用の結果、呼を音声呼と非音声呼に分割し、音声呼に係るSIP信号の転送先がBGCFBreakoutGatewayControlFunctionであり、非音声呼に係る転送先がIBCFであると判定され、この判定結果に従って、呼の分割、及び転送が行われるステップ8、9、11。そして、音声呼については、BGCF、MGCF、IMMGW、CS網の間で通常の呼接続手順が実行されるステップ10。また、非音声呼については、IBCFから事業者BのIMS網に転送されるステップ12。なお、本実施の形態では、例としてIBCFを経由したIMS間接続を想定しているが、ICSCFを経由させることも可能である。他のシーケンス図においても同様である。その後、応答信号の送受信等、呼確立のための手順が実行されステップ13、エンドーエンドでの音声通信ステップ14、及び非音声通信ステップ15が行われる。<音声のみの場合における事業者AICSCFの動作:図5>次に、処理対象が音声のみであり、事業者AのICSCFが呼種識別経路決定を行う場合の動作例を図5のシーケンス図を参照して説明する。UEからINVITEが送出され、PCSCFを経由してSCSCFに届くステップ1、2。SCSCFは、iFCinitialFilterCriteria処理により、宛先解決を行うステップ3、4。ここでの宛先解決により、SCSCFは、今回のINVITEに係る呼が他網宛事業者Bの網宛であると判定し、INVITEをICSCFに転送するステップ5。次に、ICSCFは、ポリシDBに対してポリシ要求を行い、ポリシDBからポリシを取得するステップ6、7。ICSCFは、対象となっているSIP信号にポリシを適用して呼種識別、及び経路決定を行うステップ8。本例では、ポリシ適用の結果、呼種別が音声呼であり、SIP信号の転送先がBGCFであると判定され、INVITEがBGCFに転送されるステップ9。ステップ9の後、BGCF、MGCF、IMMGW、CS網の間で通常の呼接続手順が実行されるステップ10。その後、応答信号の送受信等、呼確立のための手順が実行されステップ11、呼が確立し、エンドーエンドでの音声通信が行われるステップ12。<音声非音声重畳の場合における事業者AICSCFの動作:図6>次に、処理対象が音声非音声重畳呼であり、事業者AのICSCFが呼種識別経路決定を行う場合の動作例を図6のシーケンス図を参照して説明する。UEからINVITEが送出され、PCSCFを経由してSCSCFに届くステップ1、2。SCSCFは、iFCinitialFilterCriteria処理により、宛先解決を行うステップ3、4。ここでの宛先解決により、SCSCFは、今回のINVITEに係る呼が他網宛事業者Bの網宛であると判定し、INVITEをICSCFに転送するステップ5次に、ICSCFは、ポリシDBに対してポリシ要求を行い、ポリシDBからポリシを取得するステップ6、7。ICSCFは、対象のSIP信号にポリシを適用して呼種識別、及び経路決定を行うステップ8。本例では、ポリシ適用の結果、呼を音声呼と非音声呼に分割し、音声呼に係るSIP信号の転送先がBGCFであり、非音声呼に係る転送先がIBCFであると判定され、この判定結果に従って、呼の分割、及び転送が行われるステップ10、12。そして、音声呼については、BGCF、MGCF、IMMGW、CS網の間で通常の呼接続手順が実行されるステップ11。また、非音声呼については、IBCFから事業者BのIMS網に転送されるステップ13。なお、本実施の形態では、例としてIBCFを経由したIMS間接続を想定しているが、ICSCFが他IMS網に直接接続するように構成してもよい。その後、応答信号の送受信等、呼確立のための手順が実行されステップ14、エンドーエンドでの音声通信ステップ15、及び非音声通信ステップ16が行われる。<音声のみの場合における事業者AIBCFの動作:図7>次に、処理対象が音声のみであり、事業者AのIBCFが呼種識別経路決定を行う場合の動作例を図7のシーケンス図を参照して説明する。UEからINVITEが送出され、PCSCFを経由してSCSCFに届くステップ1、2。SCSCFは、iFCinitialFilterCriteria処理により、宛先解決を行うステップ3、4。ここでの宛先解決により、SCSCFは、今回のINVITEに係る呼が他網宛事業者Bの網宛であると判定し、INVITEをICSCFに転送するステップ5。ICSCFはINVITEをIBCFに転送するステップ6。IBCFは、ポリシDBに対してポリシ要求を行い、ポリシDBからポリシを取得するステップ7、8。IBCFは、対象となっているSIP信号にポリシを適用して呼種識別、及び経路決定を行うステップ9。本例では、ポリシ適用の結果、呼種別が音声呼であり、SIP信号の転送先がBGCFであると判定され、INVITEがBGCFに転送されるステップ10。ステップ10の後、BGCF、MGCF、IMMGW、CS網の間で通常の呼接続手順が実行されるステップ11。その後、応答信号の送受信等、呼確立のための手順が実行されステップ12、呼が確立し、エンドーエンドでの音声通信が行われるステップ13。<音声非音声重畳の場合における事業者AIBCFの動作:図8>次に、処理対象が音声非音声重畳呼であり、事業者AのIBCFが呼種識別経路決定を行う場合の動作例を図8のシーケンス図を参照して説明する。UEからINVITEが送出され、PCSCFを経由してSCSCFに届くステップ1、2。SCSCFは、iFCinitialFilterCriteria処理により、宛先解決を行うステップ3、4。ここでの宛先解決により、SCSCFは、今回のINVITEに係る呼が他網宛事業者Bの網宛であると判定し、INVITEをICSCFに転送するステップ5。ICSCFはINVITEをIBCFに転送するステップ6。IBCFは、ポリシDBに対してポリシ要求を行い、ポリシDBからポリシを取得するステップ7、8。IBCFは、対象のSIP信号にポリシを適用して呼種識別、及び経路決定を行うステップ9。本例では、ポリシ適用の結果、呼を音声呼と非音声呼に分割し、音声呼に係るSIP信号の転送先がBGCFであり、非音声呼に係る転送先が他IMS網事業者BのIMS網であると判定され、この判定結果に従って、呼の分割、及び転送が行われるステップ11、13。そして、音声呼については、BGCF、MGCF、IMMGW、CS網の間で通常の呼接続手順が実行されるステップ12。その後、応答信号の送受信等、呼確立のための手順が実行されステップ14、エンドーエンドでの音声通信ステップ15、及び非音声通信ステップ16が行われる。<音声のみの場合における事業者BICSCFの動作:図9>次に、処理対象が音声のみであり、事業者BのICSCFが呼種識別経路決定を行う場合の動作例を図9のシーケンス図を参照して説明する。他IMS網例:事業者AのIMS網A100からINVITEが送出され、IBCFに届くステップ1。IBCFはINVITEをICSCFに転送するステップ2。なお、本実施の形態では、IBCFを経由したIMS間接続を想定しているが、直接ICSCFを経由する構成としてもよい。INVITEを受信したICSCFは、HSSにアクセスしてDiameterによる認証を行うステップ3、4。そして、ICSCFは、ポリシDBに対してポリシ要求を行い、ポリシDBからポリシを取得するステップ5、6。ICSCFは、対象となっているSIP信号にポリシを適用して呼種識別、及び経路決定を行うステップ7。本例では、ポリシ適用の結果、呼種別が音声呼であり、SIP信号の転送先がBGCFであると判定され、INVITEがBGCFに転送されるステップ8。ステップ8の後、BGCF、MGCF、IMMGW、CS網、UEB1の間で通常の呼接続手順が実行されるステップ9。その後、応答信号の送受信等、呼確立のための手順が実行されステップ10、呼が確立し、エンドーエンドでの音声通信が行われるステップ11。<音声非音声重畳の場合における事業者BICSCFの動作:図10>次に、処理対象が音声非音声重畳呼であり、事業者BのICSCFが呼種識別経路決定を行う場合の動作例を図10のシーケンス図を参照して説明する。他IMS網例:事業者AのIMS網からINVITEが送出され、IBCFはINVITEをICSCFに転送するステップ2。なお、本実施の形態では、IBCFを経由したIMS間接続を想定しているが、直接ICSCFを経由する構成としてもよい。INVITEを受信したICSCFは、HSSにアクセスしてDiameterによる認証を行うステップ3、4。そして、ICSCFは、ポリシDBに対してポリシ要求を行い、ポリシDBからポリシを取得するステップ5、6。ICSCFは、対象となっているSIP信号にポリシを適用して呼種識別、及び経路決定を行うステップ7。本例では、ポリシ適用の結果、呼を音声呼と非音声呼に分割し、音声呼に係るSIP信号の転送先がBGCFであり、非音声呼に係る転送先がSCSCFであると判定され、この判定結果に従って、呼の分割、及び転送が行われるステップ8、9、11。そして、音声呼については、BGCF、MGCF、IMMGW、CS網、UEの間で通常の呼接続手順が実行されるステップ10。また、非音声呼については、SCSCFが、iFC処理により宛先解決を行って、INVITEをPCSCFに転送するステップ12、13、14。PCSCFはINVITEをUEに送信するステップ15。その後、応答信号の送受信等、呼確立のための手順が実行されステップ16、エンドーエンドでの音声通信ステップ17、及び非音声通信ステップ18が行われる。<音声のみの場合における事業者BIBCFの動作:図11>次に、処理対象が音声のみであり、事業者BのIBCFが呼種識別経路決定を行う場合の動作例を図11のシーケンス図を参照して説明する。他IMS網例:事業者AのIMS網からINVITEが送出され、IBCFに届くステップ1。IBCFは、ポリシDBに対してポリシ要求を行い、ポリシDBからポリシを取得するステップ2、3。IBCFは、対象となっているSIP信号にポリシを適用して呼種識別、及び経路決定を行うステップ4。本例では、ポリシ適用の結果、呼種別が音声呼であり、SIP信号の転送先がBGCFであると判定され、INVITEがBGCFに転送されるステップ5。ステップ5の後、BGCF、MGCF、IMMGW、CS網、UEB1の間で通常の呼接続手順が実行されるステップ6。その後、応答信号の送受信等、呼確立のための手順が実行されステップ7、呼が確立し、エンドーエンドでの音声通信が行われるステップ8。<音声非音声重畳の場合における事業者BIBCFの動作:図12>次に、処理対象が音声非音声重畳呼であり、事業者BのIBCFが呼種識別経路決定を行う場合の動作例を図12のシーケンス図を参照して説明する。他IMS網例:事業者AのIMS網からINVITEが送出され、IBCFに届くステップ1。IBCFは、ポリシDBに対してポリシ要求を行い、ポリシDBからポリシを取得するステップ2、3。IBCFは、対象となっているSIP信号にポリシを適用して呼種識別、及び経路決定を行うステップ4。本例では、ポリシ適用の結果、呼を音声呼と非音声呼に分割し、音声呼に係るSIP信号の転送先がBGCFであり、非音声呼に係る転送先がICSCFであると判定され、この判定結果に従って、呼の分割、及び転送が行われるステップ5、6、8。そして、音声呼については、BGCF、MGCF、IMMGW、CS網、UEの間で通常の呼接続手順が実行されるステップ7。また、非音声呼については、ICSCFが、Diameterによる認証を行い、INVITEをSCSCFに転送するステップ9、10、11。SCSCFは、iFC処理により宛先解決を行って、INVITEをPCSCFに転送するステップ12、13、14。PCSCFはINVITEをUEに送信するステップ15。その後、応答信号の送受信等、呼確立のための手順が実行されステップ16、エンドーエンドでの音声通信ステップ17、及び非音声通信ステップ18が行われる。<事業者AIBCFにおいて呼の集約を行う場合の動作:図13>次に、事業者AのIBCFが呼の集約を行う場合の動作例を図13のシーケンス図を参照して説明する。事業者AのIMS網A100が、事業者BのCS網から音声呼の着信を受けステップ1、BGCFがINVITEをIBCFに送信するステップ2。IBCFは、ポリシDBに対してポリシ要求を行い、ポリシDBからポリシを取得しステップ3、4、INVITEをICSCFに転送するステップ5。INVITEは、SCSCF及びPCSCFを経由してUEに届けられる。その後、応答信号の送受信等、呼確立のための手順が実行されステップ9、エンドーエンドでの音声通信ステップ10が開始される。ここで、事業者AのIMS網が、事業者BのIMS網から非音声呼を着信したものとするステップ11。非音声呼に係るINVITEはIBCFに届くステップ12。IBCFは、既に開始した既存セッションに係るSIP信号と、新たに受信したSIP信号INVITEに対し、ステップ3、4で取得したポリシを適用し、呼の集約要否判定、及び呼の集約を行うステップ13。本例では、音声の既存INVITEセッションをreINVITEで変更することで呼の集約を行うことを想定しているが、reINVITEでなくUPDATEを用いてもよい。また、音声のINVITEを受信したものの、UEに対してまだ送信していない状態であった場合は、reINVITEUPDATEではなく、音声と非音声を重畳したイニシャルINVITEを送信しても良い。上記のように、本例ではreINVITEを用いるので、IBCFはreINVITEをICSCFに転送し、reINVITEはSCSCF、PCSCFを経由してUEに届けられるステップ14~17。その後、応答信号の送受信等、呼確立のための手順が実行されステップ18、非音声通信ステップ19が行われる。上記の例は、IBCFが集約処理を行う例であるが、ICSCF、SCSCFにおける集約処理も、上記と同様に既存INVITEセッションをreINVITEまたはUPDATEで変更することで実施する。また、事業者B側でも同様にして呼の集約を行うことができる。すなわち、事業者Aの網に接続された第1ユーザ装置と、事業者Bの網に接続された第2ユーザ装置との間で音声呼又は非音声呼のいずれかが確立している状態において、事業者BのIMS装置が、第2ユーザ装置から第1ユーザ装置宛に、音声呼又は非音声呼の確立していないもう一方の呼に係る呼接続要求を受信した場合に、当該呼接続要求を、確立済みの呼に集約した呼制御信号reINVITEUPDATE等を生成し、第1ユーザ装置宛に事業者A網に向けて転送する。<IMS装置の動作>次に、図14に示しフローチャートを参照して、IMS装置SCSCF、ICSCF、又はIBCFの処理動作を説明する。IMS装置が待機状態のときにステップ101、他の装置からSIP信号を受信するとステップ102、IMS装置は、当該SIP信号が、新規ダイアログのものかどうか判定するステップ103。新規ダイアログでなければ、通常のSIP手順に従って処理を継続するステップ104。ステップ103において新規ダイアログと判定された場合、ステップ105に進み、IMS装置SCSCFの場合は、iFC処理を行い、宛先解決を行うステップ106。自網宛であればステップ104に進み、他網宛であればステップ107に進む。ステップ107において、ポリシ未取得であればIMS装置は、ポリシDBにポリシ取得要求を送信する。そして、ポリシを正常に受信したかどうか判定するステップ108。ポリシを正常に受信できない場合は、ステップ109に進んでデフォルトポリシに従って処理を継続する。ポリシを正常に受信した場合、ステップ110にて、ポリシと受信信号を照合する。ポリシにマッチしていなければステップ111のNo、通常のSIP手順に従って処理動作を継続するステップ112。ポリシにマッチしている場合ステップ111のYes、呼の分割/集約のいずれでもなければステップ114に進み、呼の分割であればステップ115に進み、呼の集約であればステップ116に進む。ステップ114では、ポリシに従ってSIP処理動作を実行し、ステップ112に進む。ステップ115では、マッチしたポリシに従ってSIP信号を分割する。そして、分割したSIP信号を他装置に送信する処理を未送信信号が終了するまで行うステップ117、118。ステップ116においては、マッチしたポリシに従ってSIP信号を集約する。そして、reINVITEもしくはUPDATEの送信を行いステップ119、通常のSIP手順に従って処理を継続するステップ120。<ポリシの例>次に、本実施の形態で適用されるポリシの具体例について説明する。図15に、セッションの種別に応じた呼種識別経路決定ポリシの具体例を示す。なお、図15に示す具体例は、あくまでも一例であり、同じ帰結を導くための異なる記述方法、およびこれ以外の異なる帰結を導く記述を排除しない。図15aは呼種識別ポリシの例を示している。この例は、受信したSIPリクエストについて、MethodがINVITEである、ContentTypeヘッダにapplicationsdpが設定されている、SDPにmaudioが設定されており、それ以外のメディアタイプが設定されていないという3つの識別ルールをAND条件で結合する、すなわち以上3つすべてを満たすものを音声と判断し、それ以外を非音声と判断する場合の例である。この例では、SDPmaudio行で音声呼と非音声呼の識別を行うルールを例示しているが、AcceptContactヘッダなど、その他のチェック項目による識別ルールが設定されていても良い。また、音声呼と非音声呼の2値でなく、チャット、プレゼンス、映像など、より詳細な識別ルールを設定しても良い。図15bは経路決定ポリシの例を示している。例えば、この例の最初のポリシは、宛先が他事業者1である音声呼のSIP信号の転送先はBGCFAであり、処理としてRouteヘッダ最上位にBGCFAのアドレスをlrパラメタと合わせて設定する、ことを示している。また、呼種が全てとなっている例は、IMSベースのパケット交換網のみを運用している他事業者3宛の呼について、音声呼も非音声呼もともに同じ転送先に転送するポリシを設定する場合の例である。図16に、セッションの種別に応じた接続点選択のための呼分割に関するポリシの具体例を示す。なお、この具体例はあくまでも一例であり、同じ帰結を導くための異なる記述方法、およびこれ以外の異なる帰結を導く記述を排除しない。図16aは呼分割ポリシの例である。ここで示すポリシは、受信した他事業者1宛のSIPリクエストについて、MethodがINVITEである、ContentTypeヘッダにapplicationsdpが設定されている、SDPにmaudioが設定されている、SDPにmaudio以外のメディアタイプが1つ以上設定されているという4つの識別ルールをAND条件で結合する、すなわち以上4つすべてを満たすものを、図16bの分割ルールに従って分割する呼とみなす場合のポリシ例である。他事業者2宛の呼についても同様である。図16bは、分割対象呼のSDP分割ルールの例を示す。このルールでは、例えば、図16aに示すポリシに従って分割対象であると判別された他事業者1宛の呼について、SDPの必須行であるv行,o行等と、音声呼接続として設定されるmaudio行、およびその属性を記述するa行等を残し、それ以外の行を削除することで、分割後の音声呼用SDPを生成することとしている。非音声呼についても同様に、必須行のほか、非音声呼接続として設定されるmaudio以外のm行とその属性を記述するa行等を残してその他を削除することとしている。図17に、呼集約ポリシの具体例を示す。なお、この具体例は、あくまでも一例であり、同じ帰結を導くための異なる記述方法、およびこれ以外の異なる帰結を導く記述を排除しない。図17aは、集約対象セッション有無判別ルールの例を示す。このルールは、発着端末およびメソッドが同じSIPセッションが既に確立されているかどうかで集約対象有無を判別する場合の例である。すなわち、このルールでは、新規に呼を受信した時点で確立済の他の全ての呼の中で、同じ方向で接続が確立されたものについて、Methodが新規受信呼と同じ、RequestURIが新規受信呼と同じ、PAssertedIdentityヘッダ値が新規受信呼と同じという3つの条件をAND条件で結合する、すなわち以上3つを全て満たすものを新規呼の集約対象呼であると判断することとしている。反対方向で確立されたものについても同様である。図17bは、集約対象であると判断された新規呼を既存呼に集約するための集約ルールである。このルールにより、例えば、他事業者1宛の新規受信INVITEについて、reINVITEを生成し、旧SDPのo行sessversionをインクリメントし、新規SDP中のm行および関連する行を、旧SDPの最下部に追加することにより集約を行う。"