JP3870955B2

JP3870955B2 - 階層型中継処理を行うセッション制御装置

Info

Publication number: JP3870955B2
Application number: JP2004181989A
Authority: JP
Inventors: 一磨湯本; 貴史宮本; 辰彦宮田
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2004-06-21
Filing date: 2004-06-21
Publication date: 2007-01-24
Anticipated expiration: 2024-06-21
Also published as: CN1713610B; US20050281251A1; JP2006005815A; US7813299B2; CN1713610A

Description

本発明は、セッション制御および管理を行う装置が、受信したメッセージの中継先を決定する技術に係わり、特に、宛先に依存せず固定のアドレスに中継を行う技術に関する。

通信ネットワークを構築する際には、ネットワークの構造は階層的になる場合が多い。例えば、現在の電話網は、加入者端末を集約する回線交換機が網の末端に設けられ、当該末端の回線交換機を複数集約する上位の回線交換機が設けられ、更に上位の回線交換機が設けられる、といったような階層構造を有している。電話交換機を用いた階層ネットワークについては、例えば、特開平５−２６００９４号公報に開示されている。

一方、IPネットワークの世界においては、セッション制御サーバ（所謂SIPサーバ）を用いてネットワークを構築する動きが高まっている。セッション制御サーバは、SIPプロキシ（SIP Proxy）またはSIPプロキシの機能とSIP登録サーバ（SIP Registrar）の機能を併せ持つサーバを指す呼称である。SIPプロキシやSIP登録サーバについては、IETF（Internet Enginnering Task Force）で策定されたRFC3261の中でSIP（Session Initiation Protocol）の詳細と共に規定されている。

従来、SIPプロキシはリクエストメッセージを受信した際に、自身が責任を負うドメインまたは宛先に対するリクエストであるか否かを調べる。責任を負わないドメインに対するリクエストであった場合は、RFC3263に従いDNS（Domain Name System）検索を行い、アドレス解決を行った後に中継を行う。

一方、責任を負うドメインまたは宛先に対するリクエストであった場合は、SIP登録サーバによって作成されたロケーションサービスから中継先端末のアドレス情報を取得し、アドレス解決を行った後に中継を行う。

SIP登録サーバによって管理するロケーションサービス情報は、REGISTERメッセージを使って端末から登録される。SIP登録サーバでは、ユーザに対して一意に付与するユーザネーム（Address-of-Record）と、該ユーザが利用する端末の実アドレスであるコンタクトアドレスを対にして管理する。

特開平５−２６００９４号公報

RFC3261「セッション開始プロトコル（SIP: Session Initiation Protocol）」、２００２年６月

従来の階層型ネットワークにおけるメッセージの中継判定ロジックは、電話網にせよ、その他の通信ネットワークにせよ、必ず親ネットワークの管理装置からサブネットワークの管理装置へメッセージが流れることを前提としている。非特許文献１で規定されるSIPサーバの規格は、SIPトラペゾイド（台形）型と呼ばれる通信モデルに基づくものであり、端末と端末の間のメッセージ中継を２台のSIPサーバにより実現する場合しか想定していない。従って、非特許文献１に記載の従来技術に基づき階層構造のネットワークを構築すると、サブドメインを管理するSIPサーバ間で直接メッセージが送受信されることになり、
従来とは異なるメッセージの中継判定ロジックを開発する必要が生じる。このような中継判定ロジックは非常に複雑であり、ネットワークの制御が非常に複雑になるという問題がある。また、サブドメインを管理するSIPサーバ間で直接メッセージが送受信されるため、親のドメインを管理するSIPサーバは、配下のサブドメインに配置されたSIPサーバでどのようなメッセージ送受信が行なわれているか検知できないという問題も生じる。

本発明の目的の一つは、階層構造を持つネットワークシステムにおいて、互いに異なるドメインを管理するセッション制御サーバ間でメッセージを中継する際に、当該メッセージが、階層構造上、少なくとも最上位のドメインを管理するセッション制御サーバを必ず１回は経由するようなメッセージの送信方法を提供することにある。また、そのようなメッセージの送信方法を可能とする制御サーバを提供することにある。

また、本発明の目的の一つは、外部ネットワークから送信されたメッセージを受信する際、受信側のネットワークの階層構造上、少なくとも最上位のドメインを管理する制御サーバを必ず１回は経由するようなメッセージの受信方法を提供することにある。また、そのようなメッセージの受信方法を可能とする制御サーバを提供することにある。

上記課題の一つを解決するため、本発明では、通信セッションを管理する制御サーバ内に、受信したメッセージを特定の宛先に中継するよう送信先のアドレス設定を行う固定中継先解決手段を設ける。これにより、サブドメインに配置された制御サーバから送信されるメッセージが、必ず一回は最上位ドメインの制御サーバを経由する送信方法を実現できる。

この際、受信メッセージを、メッセージに記載される宛先アドレスへ中継する動作モードと、メッセージに記載される宛先アドレスの如何に関わらず特定のアドレスへメッセージを中継する２つの動作モードとで装置が動作できるように制御サーバを構成し、設定された動作モードに応じてメッセージの中継先を変えるように制御サーバを運用することが好ましい。実際に制御サーバを運用する場合、制御サーバは、必ずしも親ドメインの制御サーバに中継する必要の無いメッセージを受信する場合があるためである。２つの動作モードで動作するように装置を構成することにより、必要のないメッセージまで親ドメインの制御サーバに中継してしまうという不都合を解消できる。また、（制御サーバが）親ドメインに配置された場合と、サブドメインに配置された場合とで、装置構成を変えずに済むので、装置製造上、あるいはネットワーク構築上のコストメリットが大きいという利点もある。しかしながら、固定中継先解決手段を設ければ、原理的には本発明の課題の一つは解決可能である。

さらに、親ドメインにて付与するアドレス、または、サブドメインにて付与するアドレスをパブリックアドレスとして公開する。サブドメインにて付与するアドレスを公開する場合には、サブドメインのアドレス解決結果が親ドメインサーバの実アドレスとなるようにネットワークに配置されるDNSを設定する。これにより、外部ネットワークから送信されたメッセージが少なくとも最上位のドメインに配置された制御サーバを必ず１回は経由するメッセージの受信方法が実現される。

セッション制御サーバ内部に設けた固定中継先解決手段により、受信したメッセージを特定の宛先に中継するよう送信先のアドレス設定を行うため、サブドメインに属するユーザ端末から発行されたメッセージを、サブドメインに設置するセッション制御サーバから親ドメインに設置するセッション制御サーバを経由して相手先に中継することができる。

さらに、ロケーション解決手段において、ユーザが公開するパブリックアドレスと、ユーザが実際に所属するサブドメインで付与されるユーザアドレスとを登録管理するため、親ドメインに設置したセッション制御サーバが外部のネットワークシステムから送られてきたメッセージを受信した際に、受信メッセージを適切なサブドメインのセッション制御サーバに中継することができる。

（比較例）
比較のため、図９を用いて、従来のSIPサーバにより構築される階層ネットワークについて詳細に説明する。
図９は、従来のセッション制御サーバ（500a〜500d）を用いて、図１の形態のセッション制御システムを構築した場合における、メッセージの流れの１例である。サブドメイン１（3）に属する端末B（6b）が、ドメインA（1）に属する端末A（6a）に送信するリクエストメッセージは、先ず端末Bを管轄するセッション制御サーバ３（500c）に送られる。メッセージを受信したセッション制御サーバ３は、必要に応じて認証処理を行った後に、メッセージを中継するターゲットの解決を行う。

従来のセッション制御サーバでは、このメッセージ中継先のターゲット解決処理において、宛先が自身が責任を負うドメインに対するリクエストであるか否かを調べ、責任を負う宛先へのリクエストの場合は、登録サーバによって作成されたロケーションサービスから中継先端末のアドレス情報を取得し、IPアドレス解決を行った後に中継を行い、一方、責任を負わない宛先へのリクエストの場合は、宛先ドメインのIPアドレスをDNS検索などで解決した後に中継を行うという処理を行っていた。端末AはドメインAに設置されるセッション制御サーバ１（5a）に属することから、通例、端末Aを利用するユーザAに付与されるパブリックアドレスは、「sip: userA@domainA.com」のような形式となる。

端末BがユーザAにあてて送信するリクエストメッセージの宛先には、この形式のアドレスが使われることになるが、セッション制御サーバ３（5c）で自身が責任を負わない宛先へのリクエストと判定し、DNS検索で宛先ドメインのIPアドレス解決を行って中継を行うと、このメッセージは親ドメインのセッション制御サーバ２（5b）は経由せずに、直接ドメインAのセッション制御サーバA（5a）に中継されることになる。

図１は、本実施形態に係わる階層化セッション制御システムの一構成例を示す図である。階層化セッション制御システムは、ユーザAおよびユーザAが所有する端末6aが属するドメインA（1）と、ドメインAとは異なるドメインB（2）が存在し、ドメインB内は更にユーザBおよびユーザBが所有する端末6bが属するサブドメイン1（3）と、ユーザCおよびユーザCが所有する端末6cが属するサブドメイン２（4）で構成される。ここで、ドメインとは、ネットワーク上におけるネットワーク機器（端末やサーバ等）の論理的な集合を言い、サブドメインとは、ドメイン内で論理的に細分化されるドメインの単位を言う。

本実施例では、サブドメインから見た一階層上のドメインを親ドメインと言い、親ドメインから見た一階層下のドメインを子ドメインと称する。すなわち、ドメインB（2）から見ればサブドメイン1（3）、サブドメイン２（4）が子ドメインであり、サブドメイン1（3）、サブドメイン２（4）から見れば、ドメインB（2）が親ドメインである。なお、サブドメインが更に論理的に細分化される場合もあり、便宜上、本実施例では、細分化されたサブドメインを孫ドメインと称する。

親ドメインおよびサブドメインそれぞれには、音声や映像などを送受信する通信セッションの確立と制御を行うセッション制御情報の中継と、ユーザおよびユーザが所有する端末の状態情報であるプレゼンス情報の中継と、ＩＭ（Instant Message）やチャットで送受信されるテキスト情報の中継を行うセッション制御サーバ（5a〜5d）を設置する。セッション制御サーバ（5a〜5d）がセッション制御情報の中継のみを行ない、プレゼンス情報やテキスト情報の中継は行なわないような実施形態もありうる。端末A（6a）から、セッション制御サーバ１（5a）、セッション制御サーバ２（5b）、セッション制御サーバ３（5c）を経由して、端末B（6b）へ伸びる実線と、同じくセッション制御サーバ４（5d）を経由して、端末C（6c）へ伸びる実線は、セッション制御のための制御信号が通過する制御信号線である。制御信号線は、IP（Internet Protocol）ネットワーク上に形成されたコネクションと考えてもよい。なお本実施例では、「セッション」とは、通信開始のメッセージで始まり、通信終了のメッセージで終了する端末間の一連の通信動作を意味するものとする。

本実施例では、親ドメインの制御サーバ5bにて付与するアドレスまたはサブドメインの制御サーバ5Cまたは5dにて付与するアドレスは、パブリックアドレスとして端末A（6a）や端末B（6b）、端末C(6c)に公開されているものとする。ドメインAに属する端末Aから送信されたメッセージを、親ドメインに配置された制御サーバで5b受信するためである。サブドメインにて付与するアドレスを公開する場合には、サブドメインでのアドレス解決結果が親ドメインサーバの実アドレスとなるように、ネットワークに配置されるDNSを設定する。DNSサーバの配置場所としては、例えば、ドメインB内で、外部ドメイン(ネットワーク)と通信可能な場所、例えば、制御サーバ5bと並列な場所に設置される。

但し、必ずしもドメインB内の装置からアクセスできる必要はなく、寧ろ、外部ドメインからアクセスできることが重要である。そのため、DNSサーバをドメインB外に設置しても良い。ただし、ドメインの管理を行なう事業者が制御サーバのメンテナンスを行なうような運用形態の場合には、DNSサーバはドメインB内に設置した方が良い。ドメインB内の構成をDNSサーバに設定するというメンテナンス上の利便性のためである。なお、DNSサーバの登録・管理をドメインB外に委託するような運用を行なう場合は、DNSサーバはドメインB外に設置される。例えば、企業内にDNSサーバを設置せずに、ISPなどに委託する場合である。

図２は、サブドメイン１（3）に所属する端末B（6b）がリクエストメッセージを発信した場合の、本実施形態におけるメッセージの流れを示したシーケンス図である。ここに示したシーケンス例は、SIPのINVITEセッションのような３ハンドシェイクモデルを簡略化して記載したものだが、セッション制御サーバにおける中継先ターゲットの決定ロジックに関しては、MESSAGEセッションのようなリクエストとレスポンスの一往復でトランザクションが完結するモデルでも同様である。

端末B（6a）からユーザAにあてて送るリクエストメッセージは、先ずは端末Bを管轄するセッション制御サーバ３（5c）に送られる（F100）。セッション制御サーバには、従来どおりの中継先解決処理を行うモードと、親ドメインに設置されたセッション制御サーバに固定中継するような中継先固定処理を行うモードを新たに設ける。セッション制御サーバ３のようにサブドメインに設置する場合は、この動作モードを中継先固定処理を行うモードに設定して運用する。端末Bからのリクエストを受信したセッション制御サーバ３は、宛先が自身が責任を負うドメインに対するものでは無いことを確認して、親ドメインに設置されたセッション制御サーバ２（5b）に中継する（F110）。

動作モードを２つ以上設けるのは、実際の制御サーバを運用形態を考慮したためである。つまり、制御サーバを実際に運用する場合には、制御サーバの起動時に動作設定が行なわれ、その後装置を停止するまで設定を変えないような運用形態が多い。また、制御サーバは、必ずしも親ドメインの制御サーバに中継する必要の無いメッセージを受信する場合がある。従って、予め、中継先解決処理と中継先固定処理、両方の処理が可能なように装置を構成する必要があるためである。なお、親サーバを経由せず、サブドメインのサーバ間で直接メッセージ中継を行う場合における相手端末のアドレス指定は、例えば、親ドメインの制御サーバ5bで付与するパブリックアドレスではなく、サブドメインの制御サーバにて付与するアドレスを用いる。内線(電話)番号による電話と同様な運用である。

親ドメインに設置するセッション制御サーバ２や、ドメインAに設置するセッション制御サーバ１（5a）の動作モードは、従来どおりの中継先解決処理を行うモードに設定して運用する。セッション制御サーバ３から中継されたメッセージを受信したセッション制御サーバ２は、宛先が自身が責任を負うドメインに対するものでは無いため、宛先ドメインのIPアドレスをDNS検索などで解決して、セッション制御サーバ１に中継する（F120）。セッション制御サーバ２から中継されたメッセージを受信したセッション制御サーバ１は、宛先が自身が責任を負うドメインに対するものであるため、登録サーバによって作成されたロケーションサービスから中継先端末のアドレス情報を取得し、端末A（6a）に中継を行う。

F150からF180のレスポンスの中継処理は、従来どおり、リクエスト中継の各段階で挿入設定するViaヘッダの内容に従い中継を行う。また、F110からF130のリクエスト中継の際には、Viaヘッダと同様にRecord-Routeヘッダの挿入設定を行い、ルースルーティングを行うセッション制御サーバとして運用する。セッション制御サーバをルースルータとして運用することにより、F200からF230のような同一ダイアログ内のメッセージは、F100からF130のリクエスト中継の際に解決したルートを、Routeヘッダの情報に従って辿らせることができる。

この仕組みを、図３に示すセッション制御サーバ５のブロック構成図を用いて詳しく説明する。セッション制御サーバは、ネットワークに接続するためのネットワークインターフェース１３と、ネットワークインターフェース１３を介して受信したパケットの解析と、メッセージの中継など送信を行う際に必要となるヘッダ情報の整形操作および送信を行う通信制御部３１と、メッセージ種別や送信元情報から認証の要否判定を行う認証要否判定部２１と、認証要否判定部２１による判定結果が認証要であった場合に認証処理を行う認証部２２と、受信メッセージに中継経路の指定があるか否かの確認を行う経路指定確認部２９と、Routeヘッダが付与されたメッセージやレスポンスメッセージのように経由すべき経路が指定されているメッセージの処理を行う経路既設定メッセージ処理部２７と、経由すべき経路の指定が無いメッセージの中継先を判定する中継先判定処理部２３と、受信メッセージの宛先が自身が責任を負うドメインであった場合に、登録サーバによって作成されるロケーションサービスを検索して、中継先のアドレス解決を行うロケーション解決部３４と、受信メッセージのあて先が自身が責任を負わないドメインであった場合に、DNS検索などを行い中継先のアドレス解決を行う宛先アドレス解決部３５と、各セッションの状態管理を行う状態管理部３２と、ロケーションサービスに登録された情報や、状態管理部で管理されるセッションの有効期限管理を行うタイマ管理部３３により構成される。

なお、一般的な定義によれば、「メッセージ」とはパケットのボディ部に含まれる所定のデータを意味するが、本実施例では、「パケット」と「メッセージ」とを同義で用いている。異なる意味で使用する場合にはその旨別記する。

以上の各ブロックは、SIP（RFC3261）のプロキシサーバ機能を実現する際に必要となる機能ブロックである。従来、中継先判定処理部２３に組み込まれる判定論理は、受信リクエストを自身が責任を負う宛先に対するものとして処理する自宛処理２４なのか、自身が責任を負わない宛先に対するものとして処理する他宛処理２５なのかを判定する論理だけであった。本実施例では、受信メッセージの宛先に依らず固定の宛先に中継する中継先固定処理２６を行うべきか否かの判定論理を組み込むと共に、固定の宛先に中継する際の中継先アドレスの解決処理を行う固定中継先解決部３６を新たに設ける。

これにより、本願の目的とするサブドメインに設置するセッション制御サーバから親ドメインに設置するセッション制御サーバへのメッセージ中継機能を実現する。ここで、従来からある自宛処理と他宛処理に加えて中継先固定処理を設ける必要性は、以下の通りである。メッセージの中継処理は、自宛処理と他宛処理とに大別される。大きな分類では、中継先固定処理は、他宛処理に属する。他宛処理の中で、中継先固定処理と他宛処理とを更に分ける必要性は、中継先のアドレス(宛先)設定方法が異なるためである。具体的には、中継先固定処理では中継先アドレスを固定設定されたアドレス、または発信元のアドレス情報から算出して求めるアドレスに設定する。一方、他宛処理では既設定の宛先情報を基に、DNS検索などを行って求めたアドレスを中継先アドレスとして設定する。

本実施例では、親ドメインの制御サーバ5bにて付与するアドレスまたはサブドメインの制御サーバ5Cまたは5dにて付与するアドレスは、パブリックアドレスとして公開されているため、外部ネットワークから送信されたメッセージは、まず親ドメインの制御サーバで受信される。このため、親ドメインに設置される制御サーバ5b内のロケーション管理部68には、パブリックアドレスとユーザアドレスとを対にして管理する管理テーブルが設定される。一方、サブドメインの制御サーバにて付与するアドレスをパブリックアドレスとして公開するためには、サブドメインを制御するDNSサーバを、ネットワーク内のドメインB外からアクセス可能な場所に設置する。かつ、当該DNSサーバの設定を、アドレス解決結果が親ドメインサーバの実アドレスとなるように設定する。また、親ドメインの制御サーバを、ドメイン名の解決を行う際に、検索先として最初に自らのホストファイルを検索するよう設定し、ホストファイルにサブドメインの制御サーバのドメイン名とIPアドレスの対応表を設定する。

なお、DNSサーバや制御サーバの設置場所は、制御サーバの内部構成によって解決される課題ではなく、ネットワークシステムの設計上の課題であるが、図１に示す本実施例のネットワーク２では、上記DNSサーバは、ドメインB外からアクセス可能な位置に設置されているものとする。このようにネットワークを構成することで、外部ネットワークから送信されたメッセージを受信する際、最上位ドメインの制御サーバを必ず１回は経由するようなネットワークシステムが実現できる。

外部ネットワークから送信されたメッセージを受信した親ドメインの制御サーバは、サブドメインに設置した適切なセッション制御サーバに、受信メッセージを中継する必要がある。このために、ユーザが外部に対して公開するパブリックアドレスと、ユーザが実際に所属するサブドメインで付与されるユーザアドレスとを登録管理するロケーション解決手段、すなわちロケーション解決部３４を制御サーバ内に設ける。ロケーション解決手段が無いと、受信メッセージの宛先アドレスのサブドメインアドレスへの変換を行なうことができない。従って、サブドメインに属する端末のアドレス解決ができなくなり、端末への中継が実現されなくなる。また、ロケーション解決部３４には、パブリックアドレスとサブドメインで付与されるユーザアドレスとを、対にして固定的に登録管理する機能を新たに設ける。これにより、親ドメインに設置するセッション制御サーバからサブドメインに設置するセッション制御サーバへのメッセージ中継機能を実現する。

なお、図示されていないが、図３に示したセッション制御サーバは、CPU、メモリ、記憶装置を備えており、上述した制御を実行する制御用プログラムが格納されている。サーバが動作する際には、筐体内に設けられたメモリ上に制御プログラムが展開され、CPUで制御プログラムが実行される。記憶装置は筐体内部に実装される形態でも、外部記憶装置として別筐体で設置される形態でも、ネットワークで接続される形態でも構わない。認証に必要となる情報や、ロケーションサービスに登録される情報、セッションの状態情報、固定中継先のアドレス情報などは、メモリまたは記憶装置に記憶する。

また、同じく図示されてはいないが、図３に示したセッション制御サーバは、装置ユーザが制御サーバを操作するためのユーザインタフェースを備えていてもよい。ユーザインタフェースとしては、例えば、コマンド入力のためのキーボードや、ＧＵＩ入力のためのマウス、表示画面などを備えているとよい。

更に、本実施例では、図３に示した各機能ブロックが、全てソフトウェア処理により実現されていると仮定しているが、機能ブロックそれぞれに対応するプロセッサや信号処理回路などを用いて、ハードウェア的に図３の構成を実現しても構わない。上述した中継先固定処理２６を実行するかどうかの判定論理の組み込みも、装置内のメモリにインストールされた制御用のソフトウェア、ないし中継先固定処理２６用のプロセッサや信号処理回路などのハードウェアのいずれの手段によっても実現可能である。

図４は、中継先判定手段２３の処理手順を示すフローチャートである。経路指定確認部２９で受信メッセージのヘッダ情報を確認した結果、受信メッセージがレスポンスメッセージでもRouteヘッダで中継経路の指定がなされたリクエストメッセージでも無かった場合、中継先判定処理部２３に制御が移される。ここで中継先判定処理部では、受信メッセージに指定された宛先を確認し（ステップ４０）、宛先が自身が責任を負うドメインまたは宛先に対するリクエストであった場合は、自ドメイン宛中継処理に遷移して（ステップ４４）、ロケーション解決部３４の処理を行う。一方、宛先が自身が責任を負うドメインまたは宛先に対するリクエストではない場合は、動作モード設定の確認を行う動作モード設定確認処理に遷移する（ステップ４１）。

ステップ４１の動作モード設定確認では、セッション制御サーバの環境設定などで設定された動作モードを確認して、親ドメインに設置されたセッション制御サーバに固定中継を行うか否かを判定する。動作モードの設定方法は、環境設定ファイルを通じて設定を行う方法以外に、セッション制御サーバの起動コマンドの引数として指定する方法など、コマンド投入による設定方法を用いても構わない。

ステップ４１の動作モード設定確認の結果、動作モードが設定されていた場合は、親ドメインへの固定中継を行うものと設定して中継先固定処理（ステップ４３）に進み、動作モードの設定がされていない場合は、従来どおりの他ドメイン宛中継処理（ステップ４５）を行う。なお、他宛処理で複数の動作モードを設定せずに、受信メッセージを一律固定アドレスへ中継する処理も可能である。その場合、処理フローは、ステップ４１の動作モード設定確認処理を飛ばして、ステップ４０からステップ４３の中継先固定処理へ進むことになる。

図５は、固定中継先解決手段３６の処理手順を示すフローチャートである。中継先判定手段２３で判定処理を行った結果、中継先固定処理２６を行うと決定された場合、固定中継先解決部３６に制御が移される。固定中継先解決部では、先ず固定中継先となるアドレスの設定が行われているか確認する（ステップ５２）。設定が有る場合は、設定されているアドレスを中継先の宛先に指定して中継処理を行う（ステップ５３）。固定中継先アドレスの設定は、例えば、図６に示すように、親サーバのアドレスをIPアドレスもしくはFQDN（Fully Qualified Domain Name）形式で、セッション制御サーバの環境設定ファイルに設定する。または、動作モードの設定をコマンド投入で行う場合に、コマンドの引数として固定中継先アドレスの指定を行う形でも構わない。
以上の処理により、親ドメインへ設置されたセッション制御サーバへの、受信メッセージの一律固定中継が可能となる。

一方、固定中継先のアドレス設定が行われていない場合もあり得る。この場合、図５のフローは、中継先アドレスの自立解決を図る処理に遷移する。この場合は、受信メッセージに含まれるヘッダ情報の中からメッセージ送信元アドレスを取得し、該アドレスの設定内容がドメイン形式の記述指定か否かを検査する（ステップ５４）。検査した結果、設定されていたアドレスの形式が「sip:ua2@192.168.1.100」のようなIPアドレス形式であった場合は、中継処理不能としてエラー応答を返す手続きを行う（ステップ５８）。ステップ５８のエラー応答処理では、返信するエラーコードの設定を行うと共に、通信制御部３１にエラー応答返信のための指示を行う。

ステップ５４の検査結果が「sip:ua2@sub1.domainB.com」のようなドメイン形式であった場合は、ドットで区切られた左側のドメイン部から削除して順次DNS検索を行って該当するセッション制御サーバを検索する（ステップ５５）。送信元アドレスが「sip:ua2@sub1.domainB.com」だった場合には、「sub1」を削除した「domainB.com」でDNS検索を行って、該当サーバの有無を調べる。また、送信元アドレスが「sip:ua2@termB.sub1.domainB.com」で、「termB」を削除した「sub1.domainB.com」が自身のアドレスであった場合は、更に「sub1」を削除した「domainB.com」でDNS検索を行う。
ステップ５５におけるDNS検索の結果、ヒットするサーバが存在した場合は検索結果を中継先の宛先として設定し（ステップ５７）、存在しなかった場合には中継不能としてエラー応答を返す手続きを行う（ステップ５８）。
図７は、サブドメイン１（3）に属する端末B（6b）に着信する場合の、本実施形態におけるメッセージ中継の流れの一例を示した方式説明図である。

ドメインA（1）に属する端末A（6a）が、ドメインB（2）内のサブドメイン１（3）に属する端末B（6b）に送信するメッセージは、先ず端末Aを管轄するセッション制御サーバ１（5a）に送られる。メッセージを受信したセッション制御サーバ１は、必要に応じて認証処理を行った後に、メッセージを中継するターゲットの解決を行う。中継先ターゲットの決定は、図３から図５で説明した手順に従う。宛先確認を行った結果（ステップ４０）、自身が責任を負うドメインに対するリクエストでは無いため、次に動作モードの設定確認を行う（ステップ４１）。セッション制御サーバ１はサブドメインに設置している訳ではないので、動作モードの設定は行われないため、通常の他ドメイン宛中継処理（ステップ４５）を行う。

端末Bを利用するユーザBに付与するパブリックアドレスを、親ドメインのアドレスを用いて「ua2@domainB.com」のような形式で運用する場合、セッション制御サーバ１における宛先アドレス解決部３５におけるDNS検索の結果、中継先アドレスはセッション制御サーバ２（5b）のアドレスが設定されて中継される。

図８には、制御サーバで管理されるロケーションサービス情報の管理テーブルの構成例を示す。セッション制御サーバ１から中継されるメッセージを受信するセッション制御サーバ２でも、同様に中継先ターゲットの決定処理を行う。この場合は、宛先確認の結果（ステップ４０）、自身が責任を負うドメインに対するリクエストと判定されるため、自ドメイン宛中継処理に遷移する（ステップ４４）。ここでロケーション解決部３４によるロケーションサービス検索を行うことになるが、ドメインBのようにサブドメインを設けて、セッション制御サーバの階層化中継処理を行う場合には、親ドメインに設置するセッション制御サーバにおけるロケーションサービス情報の運用管理を、通常とは異なる固有の設定で運用を行う。具体的には、図８の８０に示すように、各サブドメインに属するユーザに付与するパブリックアドレスと、各サブドメイン内で実際に付与されるユーザアドレスとを対にして、ロケーションサービス情報として固定設定する形で運用を行う。

このようなロケーションサービス情報の検索を行った結果、中継先アドレスは「ua2@sub1.domainB.com」のようにサブドメイン１を示すアドレスとなるため、セッション制御サーバ２はメッセージをセッション制御サーバ３に中継する。このようにロケーション解決を行ったメッセージ中継では、宛先をロケーション解決結果のアドレスに差し替えて中継を行う。

セッション制御サーバ２から中継されるメッセージを受信するセッション制御サーバ３でも、同様に中継先ターゲットの決定処理を行う。ここでは、宛先確認の結果（ステップ４０）、宛先が「ua2@sub1.domainB.com」であることから、自身が責任を負うドメインに対するリクエストと判定されるため、自ドメイン宛中継処理に遷移する（ステップ４４）。
最後にロケーション解決部３４によるロケーションサービス検索を行う。宛先である「ua2@sub1.domainB.com」に対応する端末B（3）のコンタクトアドレスが、図８の８２に示すような形で登録されている場合には、検索が成功して該コンタクトアドレス宛にメッセージの中継が実現される。

図１０は、親ドメインのロケーションサービス情報の自動登録を行う、サブドメインのセッション制御サーバの内部ブロック構成図である。
サブドメインに設置するセッション制御サーバ5c内部のブロック構成は簡略化して示しているが、図３に示した機能ブロックも有するものとする。

端末6bからREGISTERメッセージを用いたユーザアドレスとコンタクトアドレスの対応関係を登録されるセッション制御サーバ5cは、該登録メッセージを受信するネットワークインタフェース１３と通信制御部３１を備え、受信メッセージに記されたユーザアドレスとコンタクトアドレスの対応関係をロケーション管理部６８にロケーションサービス情報として登録する。ロケーション管理部に登録される情報の変化を監視するユーザアドレス登録部７０は、ロケーション管理部６８に登録される情報に変化が生じると、変化が生じたユーザアドレスをコンタクトヘッダに設定し、図６に示すような形で事前設定された親ドメインのアドレスをパブリックアドレスのドメイン名として送信元ヘッダに設定し、セッション制御サーバ5bにREGISTERメッセージを用いてロケーションサービス情報の登録を行う。

ネットワークの階層構造が３階層以上になった場合でも、本実施例の制御サーバは適用可能である。その場合、最上位層のセッション制御サーバにロケーション解決手段を設けて、当該ロケーション解決手段で下位層のアドレスとのマッピングを行う。マッピングは、本実施例の親ドメインに設置するセッション制御サーバと同様の手法で行なう。これにより、外部ネットワークから受信したメッセージを、親ドメインの制御サーバを必ず経由して配下の制御サーバに送信することが可能となる。また、最下位層のセッション制御サーバは、本実施例のサブドメインに設置するセッション制御サーバと同様に中継先固定処理を行う。これにより、ネットワークの階層構造が３階層以上になった場合でも、サブドメインから送信されたメッセージを、必ず親ドメインの制御サーバを経由して外部ネットワークに中継することが可能となる。

中間層に設置するセッション制御サーバは、下流から上流に流れるメッセージに関しては、上記サブドメインに設置するセッション制御サーバと同様に中継先固定処理を行い、上流から下流に流れるメッセージに関しては上記親ドメインに設置するセッション制御サーバと同様にロケーション解決手段におけるアドレスマッピングを行うことにより適用可能である。すなわち、中間層に設置する制御サーバに中継先固定処理機能を持たせることより、ネットワークの階層構造が３階層以上であっても、孫→子→親ないし親→子→孫という、順番に階層を辿っていく方式でのメッセージの中継処理が可能となる。

以上、本実施例の制御サーバを用いることにより、サブドメインに属するユーザ端末から発行されたメッセージを、サブドメインに設置するセッション制御サーバから親ドメインに設置するセッション制御サーバを経由して相手先に中継することができる。

また、ロケーション解決手段において、ユーザが公開するパブリックアドレスと、ユーザが実際に所属するサブドメインで付与されるユーザアドレスとを登録管理するため、親ドメインに設置したセッション制御サーバが外部のネットワークシステムから送られてきたメッセージを受信した際に、受信メッセージを適切なサブドメインのセッション制御サーバに中継することができる。

更に、本実施例の制御サーバを用いてネットワークを構築することにより、階層構造を持つネットワークシステムの各階層にセッション制御サーバを設置した場合に、メッセージが各階層のサーバを経由する運用が可能になる。従って、名刺に記載するなどして公開するアドレスに親ドメインのアドレスを利用することにより、組織変更やサーバの増設などにより所属するサブドメインが変更されるような場合の影響を外部には隠蔽できるという効果がある。
また、ログや課金に絡むトラフィックの管理をサブドメイン毎に行わなくても、親ドメインのセッション制御サーバで一括して行うことができるという効果も奏する。

本発明の実施形態に係わる階層化セッション制御システムの一構成例を示す図。サブドメインに属する端末から発信が行われた場合の中継処理の一例を示すシーケンス図。セッション制御サーバ内のブロック構成図。中継先判定手段の処理手順を示すフローチャート。固定中継先解決手段の処理手順を示すフローチャート。固定中継先アドレスの設定の一例を示す図。サブドメインに属する端末への着信時の中継処理の一例を示す方式説明図。ロケーションサービス情報の管理テーブルの一例を示すテーブル図。従来のセッション制御サーバを用いて階層化システムを構築した場合における、メッセージ中継の一例を示す方式説明図。親ドメインのロケーションサービス情報の自動登録を行うサブドメインのセッション制御サーバ内のブロック構成図。

符号の説明

２３．中継先判定処理部
２４．自ドメイン宛中継処理部
２５．他ドメイン宛中継処理部
２６．中継先固定処理部
３４．ロケーション解決部
３５．宛先アドレス解決部
３６．固定中継先解決部。

Claims

ドメインとサブドメインの集合により形成される階層構造を有するネットワークシステムにおいて、
前記ドメインおよびサブドメインに各々配置された複数のセッション制御サーバと、少なくとも２つの通信端末と、前記複数のセッション制御サーバと通信端末間を接続する通信回線とを備え、
親ドメインに設置された前記セッション制御サーバは、他ドメインから中継されてきた経路未設定の自ドメイン宛リクエストメッセージを、サブドメインに設置された適切なセッション制御サーバに中継する手段を有し、
さらに、前記親ドメインに設置するセッション制御サーバは、サブドメインに属するユーザが外部に公開するパブリックアドレスと、サブドメイン内でローカルに利用されるユーザアドレスとを対にして、ロケーションサービス情報として保持する手段を有し、
さらに、前記サブドメインに設置するセッション制御サーバは、該サーバが管理する前記ロケーションサービス情報が更新されると、該ロケーションサービス情報で管理するユーザアドレスをコンタクトヘッダに設定し、親ドメインのアドレスを送信元ヘッダに設定して、前記親ドメインに設置するセッション制御サーバにSIP（Session Initiation Protocol）のREGISTERメッセージを用いてロケーションサービス情報の登録を行う手段を有し、
前記親ドメインに設置するセッション制御サーバは、前記REGISTERメッセージの送信元ヘッダに設定されている前記親ドメインのアドレスをパブリックアドレスのドメイン名として、前記ユーザアドレスと対にして前記ロケーションサービス情報として記憶することを特徴とするネットワークシステム。
ドメインとサブドメインの集合により形成される階層構造を備えたネットワークシステムに配置されるセッション制御サーバであって、
メッセージを送受信するインタフェースと、
受信したメッセージに対して受信解析とヘッダ整形を行い、当該ヘッダ整形が行われた受信パケットを前記インタフェースに転送する通信制御部と、
受信メッセージの宛先が自己が管理するドメインに属するか否かを判定する中継先判定処理部と、
受信メッセージを特定の固定宛先に中継を行うための処理を行なう固定中継先解決部と、
前記受信メッセージの送信元ユーザが外部に公開するパブリックアドレスと、前記サブドメイン内でローカルに利用されるユーザアドレスとを対にして管理するロケーション管理部とを有し、
さらに、サブドメインに属するユーザが外部に公開するパブリックアドレスと、サブドメイン内でローカルに利用されるユーザアドレスを対にして、ロケーションサービス情報として前記ロケーション管理部に固定設定し、
さらに、ユーザアドレスとコンタクトアドレスの対を管理するロケーションサービス情報の変化を監視し、該ロケーションサービス情報に変化が生じた時に、ユーザアドレスをコンタクトヘッダに設定し、親ドメインのアドレスをパブリックアドレスのドメイン名として送信元ヘッダに設定して、親ドメインに設置するセッション制御サーバにSIP（Session Initiation Protocol）のREGISTERメッセージを用いてロケーションサービス情報の登録を行うことを特徴とするセッション制御サーバ。