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

Abstract

【課題】階層構造を持つネットワークシステムにおいて、各階層に設置するセッション制
御サーバを介したメッセージの送受信を実現すること。
【解決手段】セッション制御サーバ５内に、設定された動作モードの確認を行う動作モー
ド確認手段４１と、設定された動作モードに応じて受信メッセージを特定の宛先に中継す
るようアドレス設定を行う固定中継先解決手段３６を備える。また、ユーザが外部に対し
て公開するパブリックアドレスと、ユーザが実際に所属するサブドメインで付与されるユ
ーザアドレスを登録管理するロケーション解決手段３４を備える。
【効果】公開するアドレスに親ドメインのアドレスを利用した運用が可能になるため、所
属するサブドメインの変更による影響を外部に隠蔽できる。また、トラフィックの管理を
親ドメインで一括管理できる。
【選択図】図３

Description

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

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

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

従来、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アドレスもしくはFQ
DN（Fully Qualified Domain Name）形式で、セッション制御サーバの環境設定ファイル
に設定する。または、動作モードの設定をコマンド投入で行う場合に、コマンドの引数と
して固定中継先アドレスの指定を行う形でも構わない。
以上の処理により、親ドメインへ設置されたセッション制御サーバへの、受信メッセー
ジの一律固定中継が可能となる。

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

ステップ５４の検査結果が「sip:ua2@sub1.domainB.com」のようなドメイン形式であっ
た場合は、ドットで区切られた左側のドメイン部から削除して順次DNS検索を行って該当
するセッション制御サーバを検索する（ステップ５５）。送信元アドレスが「sip:ua2@su
b1.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@su
b1.domainB.com」のようにサブドメイン１を示すアドレスとなるため、セッション制御サ
ーバ２はメッセージをセッション制御サーバ３に中継する。このようにロケーション解決
を行ったメッセージ中継では、宛先をロケーション解決結果のアドレスに差し替えて中継
を行う。

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

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

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

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

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

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

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

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

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

符号の説明

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

Claims (16)

1. ドメインとサブドメインの集合により形成される階層構造を備えたネットワークシステ
   ムにおいて、
   前記ドメインおよびサブドメインに配置された複数のセッション制御サーバと、前記複
   数のセッション制御サーバと通信端末間を接続する通信回線とを備え、
   前記サブドメインに設置されたセッション制御サーバは、前記受信メッセージに示され
   た宛先によらず、当該受信メッセージを事前設定された固定の宛先に中継する手段を有す
   ることを特徴とするネットワークシステム。
2. 請求項１に記載のネットワークシステムにおいて、
   前記制御サーバは、前記受信メッセージの宛先が、自己の管理するドメインに属するか
   属しないかを判定する手段を有し、
   属しない場合には、当該受信メッセージを前記親ドメインに配置されたセッション制御
   サーバへ中継することを特徴とするネットワークシステム。
3. 請求項１に記載のネットワークシステムにおいて、
   前記固定の宛先が、親ドメインに設置されたセッション制御サーバのアドレスである手
   段を有することを特徴とするネットワークシステム。
4. ドメインとサブドメインの集合により形成される階層構造を有するネットワークシステ
   ムにおいて、
   前記ドメインおよびサブドメインに各々配置された複数のセッション制御サーバと、少
   なくとも２つの通信端末と、前記複数のセッション制御サーバと通信端末間を接続する通
   信回線とを備え、
   親ドメインに設置された前記セッション制御サーバは、他ドメインから中継されてきた
   経路未設定の自ドメイン宛リクエストメッセージを、サブドメインに設置された適切なセ
   ッション制御サーバに中継する手段を有することを特徴とするネットワークシステム。
5. 請求項４に記載のネットワークシステムにおいて、
   前記親ドメインに設置するセッション制御サーバは、サブドメインに属するユーザが外部
   に公開するパブリックアドレスと、サブドメイン内でローカルに利用されるユーザアドレ
   スとを対にして、ロケーションサービス情報として固定設定する手段を有することを特徴
   とするネットワークシステム。
6. 請求項４に記載のネットワークシステムにおいて、
   前記サブドメインに設置するセッション制御サーバは、該サーバが管理するロケーション
   サービス情報が更新されると、該ロケーションサービス情報で管理するユーザアドレスを
   コンタクトヘッダに設定し、親ドメインのアドレスをパブリックアドレスのドメイン名と
   して送信元ヘッダに設定して、前記親ドメインに設置するセッション制御サーバにSIP（S
   ession Initiation Protocol）のREGISTERメッセージを用いてロケーションサービス情報
   の登録を行う手段を有することを特徴とするネットワークシステム。
7. メッセージを送受信するインタフェースと、
   受信したメッセージに対して受信解析とヘッダ整形を行い、当該ヘッダ整形が行われた
   受信パケットを前記インタフェースに転送する通信制御部と、
   受信メッセージの宛先が自己が管理するドメインに属するか否かを判定する中継先判定
   処理部と、
   受信メッセージを特定の固定宛先に中継を行うための処理を行なう固定中継先解決部と
   、
   受信メッセージの宛先が自己が管理するドメインに属するものであった場合に、メッセ
   ージ中継先のアドレス解決を行うロケーション解決部とを有し、
   前記受信メッセージの宛先が自己が管理するドメインに属さない場合には、前記特定の
   固定宛先に、前記受信メッセージを中継することを特徴とするセッション制御サーバ。
8. 請求項７に記載のセッション制御サーバにおいて、
   受信メッセージに対してDNS検索を行い、メッセージの中継先のアドレス解決を行う宛
   先アドレス解決部を有し、
   前記中継先判定処理部は、受信メッセージの宛先が自己が管理するドメインに属さない
   ものであった場合に、固定宛先への中継処理を行うか、受信メッセージの宛先が属するド
   メインに中継を行うかを判定し、
   固定宛先への中継処理を行うと判定した場合には、前記特定の固定宛先へメッセージを
   中継することを特徴とするセッション制御サーバ。
9. 請求項８に記載のセッション制御サーバにおいて、
   前記通信端末間で形成される通信セッションの状態管理を、所定の有効時間単位で行う
   状態管理部と、
   前記通信回線を介して通知される前記通信端末のアドレス情報を管理する端末ロケーシ
   ョン管理部と、
   受信メッセージに中継経路の指定が行われているか確認する経路指定確認部とを備える
   ことを特徴とするセッション制御サーバ。
10. ドメインとサブドメインの集合により形成される階層構造を備えたネットワークシステム
    に配置されるセッション制御サーバであって、
    メッセージを送受信するインタフェースと、
    受信したメッセージに対して受信解析とヘッダ整形を行い、当該ヘッダ整形が行われた
    受信パケットを前記インタフェースに転送する通信制御部と、
    受信メッセージの宛先が自己が管理するドメインに属するか否かを判定する中継先判定
    処理部と、
    受信メッセージを特定の固定宛先に中継を行うための処理を行なう固定中継先解決部と
    、
    前記受信メッセージの送信元ユーザが外部に公開するパブリックアドレスと、前記サブ
    ドメイン内でローカルに利用されるユーザアドレスとを対にして管理するロケーション管
    理部とを有することを特徴とするセッション制御サーバ。
11. 請求項１０に記載のセッション制御サーバにおいて、
    サブドメインに属するユーザが外部に公開するパブリックアドレスと、サブドメイン内
    でローカルに利用されるユーザアドレスを対にして、ロケーションサービス情報としてロ
    ケーション管理部に固定設定することを特徴とするセッション制御サーバ。
12. 請求項１０に記載のセッション制御サーバにおいて、
    ユーザアドレスとコンタクトアドレスの対を管理するロケーションサービス情報の変化
    を監視し、該ロケーションサービス情報に変化が生じた時に、ユーザアドレスをコンタク
    トヘッダに設定し、親ドメインのアドレスをパブリックアドレスのドメイン名として送信
    元ヘッダに設定して、親ドメインに設置するセッション制御サーバにSIP（Session Initi
    ation Protocol）のREGISTERメッセージを用いてロケーションサービス情報の登録を行う
    ことを特徴とするセッション制御サーバ。
13. 通信端末間で形成される通信セッションを監視制御する機能を備えた複数のサーバを用
    いた通信の通信制御方法において、
    同じドメインに属する前記通信端末から送られてくる経路未設定の他ドメイン宛リクエ
    ストメッセージを受信した場合に、事前設定された固定の宛先にメッセージを中継するこ
    とを特徴とする通信制御方法。
14. 通信端末間で形成される通信セッションを監視制御する機能を備えた複数のサーバを用
    いた通信の通信制御方法において、
    他ドメインから中継されてきた経路未設定の自ドメイン宛リクエストメッセージを、宛
    先を検索キーとして、
    サブドメインに属するユーザが外部に公開するパブリックアドレスと、サブドメイン内
    でローカルに利用されるユーザアドレスとを対にして設定管理するロケーションサービス
    情報を検索することにより、中継先のアドレス解決を行うことを特徴とする通信制御方法
    。
15. 請求項１３に記載の通信制御方法において、
    前記複数のサーバのいずれかのサーバとして、前記通信セッションを管理制御する機能
    を備えたセッション制御サーバを用いることを特徴とする通信制御方法。
16. 少なくとも２つの通信端末間に形成されるSIP（Session Initiation Protocol）による
    通信セッションの制御機能を備えたサーバの制御プログラムであって、以下のステップを
    実行する制御プログラム；
    受信メッセージにおける経路指定の有無を確認するステップ、
    受信メッセージに経路指定が無い場合に、受信メッセージの宛先が自身が責任を負うド
    メイン宛のものであるか否かを確認するステップ、
    自身が責任を負うドメイン宛のものであった場合に、ロケーションサービス情報を検索
    してアドレス解決を行い、メッセージを中継するステップ、
    自身が責任を負わないドメイン宛のものであった場合に、サーバ動作モードの設定確認
    を行うステップ、
    サーバ動作モードの設定が行われている場合に、設定された固定アドレスにメッセージ
    を中継するステップ、
    サーバ動作モードの設定が行われていない場合に、宛先に設定されているドメインに設
    置されているサーバのアドレスをDNS検索で解決して、メッセージを中継するステップ。
    

Images