以下、図面を参照して本発明の実施形態について説明する。図1は、本発明の呼制御装置の一実施形態である呼処理サーバ装置の構成例を説明するための構成図である。
図1に示した呼処理サーバ装置20は、コンピュータであり、内部にCPU(中央処理装置)、主記憶装置、補助記憶装置、通信装置、入出力装置等のハードウェアを備える。呼処理サーバ装置20は、それらのハードウェアを用いて所定のプログラムを実行することで、呼制御に係る所定の機能を実現する。
呼処理サーバ装置20は、メイン処理部21と、加入者管理DB部22と、番号変換管理DB部23とを備える。呼処理サーバ装置20は、発側の呼処理ネットワーク11に接続されている。この場合、発側の呼処理ネットワーク11は私設網である。この発側の呼処理ネットワーク11には、内線電話機10が接続されている。また、発側の呼処理ネットワーク11には、着側の呼処理ネットワーク12が接続されている。着側の呼処理ネットワーク12は公衆網である。この着側の呼処理ネットワーク12には、電話機13が接続されている。
本実施形態において、呼処理サーバ装置20は、SIP(Session Initiation Protocol)通信プロトコルを使用して呼を確立するためのネットワーク構成の一部として機能する。また、図1は、内線電話機10を発側の電話機、電話機13を着側の電話機として呼を確立する場合に送受信される通信信号の一例を示す。一般に、SIP通信プロトコルを使用して呼を確立する手順では、発側の電話機から、発側の呼処理ネットワークと着側の呼処理ネットワークを介して、着側の電話機へとINVITEリクエスト信号を送達する必要がある。もし発着の電話機のユーザが異なる通信事業者の加入者である場合、発側の呼処理ネットワークは発側の通信事業者によって運営されるものであり、着側の呼処理ネットワークは着側の通信事業者によって運営されるものである。そのため、図1は、発側の呼処理ネットワーク11と着側の呼処理ネットワーク12とを分けて記載している。
図1において、発側の呼処理ネットワーク11は、内線網の呼処理ネットワークであり、内線番号を割り当てた内線電話機10を収容している。また、着側の呼処理ネットワーク12は、公衆網の呼処理ネットワークであり、電話番号を割り当てた電話機13を収容している。
呼処理サーバ装置20は、IETF(Internet Engineering Task Force) RFC(Request For Comment)3261(2002−06)において機能要件が定義されているSIP proxy、SIP registrar、SIP redirect serverの機能要件のすべての機能または一部の機能を実装した装置である。この場合、呼処理サーバ装置20は、INVITEリクエスト信号のルーティング機能、および、発側の呼処理ネットワーク11に収容されている加入者情報管理の機能を有している。
呼処理サーバ装置20は、INVITEリクエスト信号を送受信して中継する装置であり、発側の呼処理ネットワーク11において、INVITEリクエスト信号を対象として、電話番号変換処理を実施する。呼処理サーバ装置20が備えるメイン処理部21は、呼処理サーバ装置20の外部との間でINVITEリクエスト信号を送受信する。加入者管理DB部22は、発側の呼処理ネットワーク11に収容されている電話機/加入者の情報をあらかじめ保持する。番号変換管理DB部23は、発電話番号と着電話番号の変換に必要な情報をあらかじめ保持する。
図3は、加入者管理DB部22のデータベースのテーブル構成の具体例を示している。本テーブルは、「加入者のURI(Uniform Resource Identifier)情報」によって発加入者を指定して、その指定に紐づく「加入者の位置・グループID(identifier;識別子)」を取得する用途のため存在する。すなわち、加入者管理DB部22は、「加入者のURI情報」を検索用キー情報とした問い合わせに対し、検索用キー情報に対応する「加入者の位置・グループID」を表すデータを返信する。
「加入者のURI情報」は、加入者を一意に特定する識別子であり、電話番号とドメインの識別子とを含んで構成される。電話番号はドメインごとに一意であればよく、ドメインが異なれば、電話番号は重複してよい。例えば、内線番号は、企業毎に一意であり、企業が異なれば、内線番号は重複してよい。なお、ドメインは、ドメイン名とも呼ばれ、インターネット等のネットワーク上で、コンピュータ、端末装置、通信制御装置等のノードを特定する名前である。
「加入者の位置・グループID」は、電話機の地理的な位置と、内線電話機のグループとを特定する識別子である。それぞれの内線電話機は、位置IDとグループIDを各1つ割り当てられている。ここで、位置IDが位置を一意に特定する識別子である。また、グループIDがグループを一意に特定する識別子である。
図3に示した例において、例えば一番上のレコードの「加入者のURI情報」フィールドには「sip:51−1001@company1.com」が格納されている。この「sip:51−1001@company1.com」が加入者を一意に特定する識別子である。また、この「sip:51−1001@company1.com」のうち、「sip:」を除いた区切り記号(あるいは区切り文字)「@」より前の「51−1001」が発電話番号であり、区切り記号「@」より後の「company1.com」がドメインである。
また、一番上のレコードの「加入者の位置・グループID」フィールドには「3001;3901」が格納されている。この「3001;3901」のうち、区切り記号「;」より前の「3001」が位置IDであり、区切り記号「;」より後の「3901」がグループIDである。
図4は、番号変換管理DB部23のデータベースのテーブル構成の具体例を示している。本テーブルは2つの用途のために存在する。1点目は、特番種別と位置IDを指定して、その指定に紐づく変換後のURI情報を取得する用途である。2点目は、ドメイン種別とグループIDを指定して、その指定に紐づく変換後のURI情報を取得する用途である。そのため、本実施形態の番号変換管理DB部23は、次のようにデータベースを構成する。すなわち、番号変換管理DB部23のデータベースは、各レコード231に、以下の第1フィールド232と、第2フィールド233と、第3フィールド234とを含むテーブルから構成される。
第1フィールド232は、「特番/ドメイン種別」のフィールドであり、特番種別又はドメイン種別のいずれか一方を格納する。特番種別は、特番を表すデータである。特番は、特殊番号とも呼ばれ、通常の電話番号とは異なる用途の電話番号である。国内の電話番号では0又は1から始まる。ただし、市外局番は特番ではない。また、接続する電話会社を選ぶための事業者識別番号も特番ではない。特番には、「110」の3桁特番である緊急(通報)特番、「0」の1桁特番である外線特番等がある。第1フィールド232に格納される特番種別は、例えば、特番を表す1から4桁の数字から構成される。また、ドメイン種別は、上述したドメインを表すデータである。ドメイン種別は、ドメインそのものであってもよいし、あるいは、ドメインのうち、URI情報を一意に特定するのに必要な一部のデータから構成されていてもよい。すなわち、ドメイン種別は、上述したドメインの一部又は全部から構成される。
第2フィールド233は、「位置/グループID」のフィールドであり、位置ID又はグループIDのいずれか一方を格納する。位置ID及びグループIDは、図3を参照して説明した加入者管理DB部22のデータベースに格納されたものと同じである。例えば、同一レコード231において、第1フィールド232が特番種別を格納している場合、第2フィールド233は位置IDを格納する。また、同一レコード231において、第1フィールド232がドメイン種別を格納している場合、第2フィールド233はグループIDを格納する。
第3フィールド234は、「変換後のURI情報」のフィールドであり、変換後のURI情報を格納する。第3フィールド234に格納される「変換後のURI情報」には、発信先のURI情報を表す場合と、発信元のURI情報を表す場合との2種類がある。この第3フィールド234に格納される「変換後のURI情報」の種類は、同一レコード231の第1フィールド232に格納されたデータが特番種別なのか、ドメイン種別なのかによって異なる。また、第3フィールド234に格納される「変換後のURI情報」は、第1フィールドに格納されているデータと第2フィールドに格納されたデータとに対応付けられている。すなわち、同一レコード231の第1フィールド232が特番種別を格納している場合、第3フィールド234は、第1フィールド232の特番種別と第2フィールド233の位置IDとに対応する特番の発信先の電話番号を表すURI情報を格納する。また、同一レコード231の第1フィールド232がドメイン種別を格納している場合、第3フィールド234は、第1フィールド232のドメイン種別と第2フィールド233のグループIDとに対応する発信元の代表番号を表すURI情報を格納する。
番号変換管理DB部23は、特番種別と位置IDとを検索用キー情報として、又は、ドメイン種別とグループIDとを検索用キー情報として、次のように変換後のURI情報を抽出する。すなわち、呼処理サーバ装置20は、緊急特番への発信の場合には最寄りの緊急機関に着信させるための処理を行う。このため、番号変換管理DB部23は、メイン処理部21からの「特番種別」と「位置ID」とを検索用キー情報とした問い合わせに対し、最寄りの緊急機関の電話番号を表す「変換後のURI情報」を返信する。また、呼処理サーバ装置20は、内線電話機からの発信の場合、「ドメイン種別」と「グループID」とに紐づいて、着側の電話機に対して発電話番号として代表番号を通知する処理を行う。このため、番号変換管理DB部23は、メイン処理部21からの「ドメイン種別」と「グループID」とを検索用キー情報とした問い合わせに対し、代表番号を表す「変換後のURI情報」を返信する。
図4に示した例において、レコード231aの第1フィールド232には「110」が格納されている。この「110」は特番種別である。レコード231aの第2フィールド233には「3001」が格納されている。この「3001」は位置IDである。そして、レコード231aの第3フィールド234には「sip:03−0000−0001@public.jp」が格納されている。この「sip:03−0000−0001@public.jp」は特番種別「110」と位置ID「3001」とに紐付けられたURI情報である。この第3フィールド234に格納された「sip:03−0000−0001@public.jp」は、例えば、最寄りの緊急機関の電話番号を表すデータである。この場合、「03−0000−0001」が最寄りの緊急機関の電話番号である。
また、図4に示した例において、レコード231bの第1フィールド232には「company1.com」が格納されている。この「company1.com」はドメイン種別である。レコード231bの第2フィールド233には「3901」が格納されている。この「3901」はグループIDである。そして、レコード231bの第3フィールド234には「sip:03−9000−0001@public.jp」が格納されている。この「sip:03−9000−0001@public.jp」はドメイン種別「company1.com」とグループID「3901」とに紐付けられたURI情報である。この第3フィールド234に格納された「sip:03−9000−0001@public.jp」は、例えば、発側における代表番号を表すデータである。この場合、「03−9000−0001」が代表番号である。
なお、図3及び図4において、URI情報が含む記号「−(ハイフン)」は、可読性のための表記であり、実際の通信信号では設定されない場合もある。
また、番号変換管理DB部23は、第1フィールド232に格納されたデータが、特番種別又はドメイン種別のどちらなのかということを、第1フィールド232に格納されたデータの内容あるいは形式によって判別することができる。例えば、番号変換管理DB部23は、第1フィールド232に格納されたデータが、ドメインを表す文字列における区切り記号「.」(ピリオド)を含む場合に、当該データがドメイン種別であると判別することができる。あるいは、番号変換管理DB部23は、例えば、第1フィールド232に格納されたデータが、「0」又は「1」から始まる1〜4桁の数字である場合に、当該データが特番種別であると判別することができる。なお、各フィールドに格納するデータは、文字列(数字列を含む)そのものであってもよいし、文字列に対して所定の変換処理、圧縮処理等を施したデータであってもよい。
次に、呼処理サーバ装置20の動作について図2A及び図2Bを参照して説明する。なお、図2Aに示したフローチャートと図2Bに示したフローチャートとは結合子A21、A22及びA23によってそれぞれ結合される。以下、図1に示した構成において、内線電話機10が外線発信を行う場合について説明する。
内線電話機10は、外線発信を意図して、番号変換前INVITEリクエスト30を送信する。番号変換前INVITEリクエスト30には、発信先を示す「Request−URI」パラメータと、発信元を示す「P−Asserted−Identity」パラメータとが設定される。
なお、発信元を示す「P−Asserted−Identity」パラメータを内線電話機10で付与すると、内線電話機10のユーザによりパラメータの値を詐称される可能性があるため、次の構成を用いることがある。すなわち、番号変換前INVITEリクエスト30を中継する呼処理サーバ装置(図示なし)を発側の呼処理ネットワーク11に配置し、その呼処理サーバ装置で「P−Asserted−Identity」パラメータを検証して付与する場合もある。この検証の仕組みに関する説明は割愛する。
呼処理サーバ装置20は、番号変換前INVITEリクエスト30を受信し(S101)、メイン処理部21、加入者管理DB部21、番号変換管理DB部23により、以下の処理を行う。
メイン処理部21は、受信した「P−Asserted−Identity」パラメータから、「発加入者のURI情報」を取得し、その「発加入者のURI情報」を加入者管理DB部22に入力する(S102、IN#31)。ここで、「S」に続く数字はステップの番号を表す。「IN#」あるいは後述する「OUT#」に続く数字は送受信される情報の番号を表す。
加入者管理DB部22は、メイン処理部21から入力された「発加入者のURI情報」を検索用キー情報として、該当する「発加入者の位置・グループID」を特定し、メイン処理部21に出力する(S103〜S104、OUT#32)。
メイン処理部21は、S101で受信した「Request−URI」パラメータから、外線を意図した発信であるか、否かを特定する(S105)。S105において、メイン処理部21は、例えば、外線特番「0」がURIの冠頭プレフィックスに設定されている場合に、外線発信であることを特定する。
外線発信であることを特定した場合(S105で「Yes」の場合)、メイン処理部21は、受信した「Request−URI」パラメータを、公衆網で流通する形式に加工する(S106)。例えば、外線特番「0」を削除することと、URIのドメイン部を公衆網のドメインに置換する加工を行う。続けて、外線発信であることを特定した場合、メイン処理部21は、受信した「P−Asserted−Identity」パラメータから「発加入者のドメイン種別」を取得する(S107)。メイン処理部21は、その「発加入者のドメイン種別」およびS104(OUT#32)で取得した「発加入者のグループID」を番号変換管理DB部23に入力する(S107、IN#33)。
なお、S107では、メイン処理部21が、発加入者のドメイン種別を、「P−Asserted−Identity」パラメータとは別のパラメータから取得する場合もある。例えば、IETF RFC7316(2014−07)で規定される「P−Private−Network−Indication」パラメータがINVITEリクエストに設定されていた場合、このパラメータからドメイン種別を取得することもできる。
続けて、番号変換管理DB部23は、メイン処理部21から入力された「発加入者のドメイン種別」と「発加入者のグループID」を検索用キー情報として該当する「変換後のURI情報」を特定し、得られた該当する「変換後のURI情報」をメイン処理部21に出力する(S108〜S109、OUT#34)。
続けて、外線発信であることを特定した場合(S105で「Yes」の場合)、メイン処理部21は、S109(OUT#34)で取得した「変換後のURI情報」を含むように、番号変換後INVITEリクエスト信号40に「P−Asserted−Identity」パラメータを設定する(S110)。なお、最終的に、この上書きによって変更された設定値が、代表番号として発信先に通知される発電話番号である。
次に、メイン処理部21は、S101で受信した番号変換前INVITEリクエスト30又はS110で加工された番号変換後INVITEリクエスト信号40に設定された「Request−URI」パラメータから発信先が緊急特番であるか、否かを特定する(S111)。メイン処理部21は、例えば、外線特番「0」を除去した後のURIが緊急特番「110」だった場合に、発信先が緊急特番であることを特定する。
発信先が緊急特番であることを特定した場合(S111で「Yes」の場合)、メイン処理部21は、S111で特定した「Request−URIの特番種別」およびS104(OUT#32)で取得した「発加入者の位置ID」を番号変換管理DB部23に入力する(S112、IN#35)。
番号変換管理DB部23は、メイン処理部21から入力された「Request−URIの特番種別」と「発加入者の位置ID」を検索用キー情報として該当する「変換後のURI情報」を特定し、得られた該当する「変換後のURI情報」をメイン処理部21に出力する(S113〜S114、OUT#36)。
続けて、発信先が緊急特番であることを特定した場合(S111で「Yes」の場合)、メイン処理部21は、S114(OUT#36)で取得した「変換後のURI情報」を含むように、番号変換前INVITEリクエスト30又は番号変換後INVITEリクエスト信号40に「Request−URI」パラメータを設定する(S115)。
呼処理サーバ装置20は、メイン処理部21、加入者管理DB部21、番号変換管理DB部23による、上記の処理を行った後、次の処理を行う。すなわち、呼処理サーバ装置20は、上記の処理後、番号変換後INVITEリクエスト信号40を送信(あるいは番号変換前INVITEリクエスト30に対して変換処理を行わずに番号変換後INVITEリクエスト信号40として送信)する(S116)。
S116で送信された番号変換後INVITEリクエスト信号40は、着側の呼処理ネットワーク12に配置された呼処理サーバ(図示なし)を経由し、最終的に電話機13に到達する。電話機13は、受信した「P−Asserted−Identity」パラメータを参照して、発電話番号表示を行う。
次に、図5を参照して、図2A及び図2Bに示した処理における入出力パラメータの具体例について説明する。なお、加入者管理DB部22は図3に示したデータを記憶しているものとする。また、番号変換管理DB部23は図4に示したデータを記憶しているものとする。なお、図5は、図2A及び図2Bに示した処理における通信信号について、通信名と、パラメータ名と、設定値と、備考又は補足説明とを一覧にして示した図である。
まず、内線電話機10は、外線発信を意図して、番号変換前INVITEリクエスト30を送信する(S101)。この例では、図5に示したように、番号変換前INVITEリクエスト30には、発信先を示す「Request−URI」パラメータ『sip:0−110@company1.com』と、発信元を示す「P−Asserted−Identity」パラメータ『sip:51−1001@company1.com』とが設定される。
呼処理サーバ装置20は、番号変換前INVITEリクエスト30を受信し(S101)、メイン処理部21、加入者管理DB部21、番号変換管理DB部23により、以下の処理を行う。
メイン処理部21は、受信した「P−Asserted−Identity」パラメータ『sip:51−1001@company1.com』から、「発加入者のURI情報」『sip:51−1001@company1.com』を取得し、その「発加入者のURI情報」『sip:51−1001@company1.com』を加入者管理DB部22に入力する(S102、IN#31)。
加入者管理DB部22は、メイン処理部21から入力された「発加入者のURI情報」『sip:51−1001@company1.com』とを検索用キー情報として、該当する「発加入者の位置・グループID」『3001;3901』を特定してメイン処理部21に出力する(S103〜S104、OUT#32、図3)。
メイン処理部21は、受信した「Request−URI」パラメータ『sip:0−110@company1.com』から、外線を意図した発信であるか、否かを特定する(S105)。本例では、外線特番「0」がURIの冠頭プレフィックスに設定されており、メイン処理部21は、外線発信であると特定する(S105で「Yes」)。
外線発信であることを特定した場合、メイン処理部21は、受信した「Request−URI」パラメータ『sip:0−110@company1.com』を、公衆網で流通する形式に加工する(S106)。本例では、外線特番「0」を削除することと、URIのドメイン部『company1.com』を公衆網のドメイン『public.com』に置換する加工を行う。加工後の「Request−URI」パラメータは『sip:110@public.com』となる。
続けて、外線発信であることを特定した場合、メイン処理部21は、受信した「P−Asserted−Identity」パラメータ『sip:51−1001@company1.com』から「発加入者のドメイン種別」『company1.com』を取得する(S107)。メイン処理部21は、その「発加入者のドメイン種別」『company1.com』およびS104(OUT#32)で取得した「発加入者のグループID」『3901』を番号変換管理DB部23に入力する(S107、IN#33)。
続けて、番号変換管理DB部23は、メイン処理部21から入力された「発加入者のドメイン種別」『company1.com』と「発加入者のグループID」『3901』とを検索用キー情報として、該当する「変換後のURI情報」『sip:03−9000−0001@public.com』を特定してメイン処理部21に出力する(S108〜S109、OUT#34)。
続けて、外線発信であることを特定した場合、メイン処理部21は、S109(OUT#34)で取得した「変換後のURI情報」『sip:03−9000−0001@public.com』を含むように、番号変換後INVITEリクエスト信号40に「P−Asserted−Identity」パラメータ『sip:03−9000−0001@public.com』を設定する(S110)。なお、最終的に、この設定値が、代表番号として通知される発電話番号である。
次に、メイン処理部21は、加工後の「Request−URI」パラメータ『sip:110@public.com』から、発信先が緊急特番であるか、否かを特定する(S111)。本例では、外線特番「0」を除去した後のURIの電話番号が緊急特番「110」であるため、発信先が緊急特番であると特定する(S111で「Yes」)。なお、110等、緊急特番とみなす電話番号は、所定の記憶装置にあらかじめ登録しておく。
発信先が緊急特番であることを特定した場合、メイン処理部21は、特定した「Request−URIの特番種別」『110』およびS104(OUT#32)で取得した「発加入者の位置ID」『3001』を番号変換管理DB部23に入力する(S112、IN#35)。
番号変換管理DB部23は、メイン処理部21から入力された「Request−URIの特番種別」『110』と「発加入者の位置ID」『3001』とを検索用キー情報として、該当する「変換後のURI情報」『sip:03−0000−0001@public.com』を特定してメイン処理部21に出力する(S113〜S114、OUT#36)。
続けて、発信先が緊急特番であることを特定した場合、メイン処理部21は、S114(OUT#36)で取得した「変換後のURI情報」『sip:03−0000−0001@public.com』を含むように、番号変換後INVITEリクエスト信号40に「Request−URI」パラメータ『sip:03−0000−0001@public.com』を設定する(S115)。
呼処理サーバ装置20は、メイン処理部21、加入者管理DB部21、番号変換管理DB部23による、上記の処理を行った後、番号変換後INVITEリクエスト信号40を送信する(S116)。
送信された番号変換後INVITEリクエスト信号40は、着側の呼処理ネットワーク12に配置された呼処理サーバ(図示なし)を経由し、最終的に電話機13『sip:03−0000−0001@public.com』に到達する。そして、電話機13『sip:03−0000−0001@public.com』は、受信した「P−Asserted−Identity」パラメータ『sip:03−9000−0001@public.com』を参照して、発電話番号表示『03−9000−0001』を行う。
次に、図6を参照して、図2A及び図2Bに示した処理における入出力パラメータの他の具体例について説明する。なお、加入者管理DB部22は図3に示したデータを記憶しているものとする。また、番号変換管理DB部23は図4に示したデータを記憶しているものとする。なお、図6は、図5と同様、図2A及び図2Bに示した処理における通信信号について、通信名と、パラメータ名と、設定値と、備考又は補足説明とを一覧にして示した図である。
まず、内線電話機10は、外線発信を意図して、番号変換前INVITEリクエスト30を送信する(S101)。図6に示したように、番号変換前INVITEリクエスト30には、発信先を示す「Request−URI」パラメータ『sip:0−09−9999−9999@ccompany2.com』と、発信元を示す「P−Asserted−Identity」パラメータ『sip:51−1001@company2.com』とが設定される。
呼処理サーバ装置20は、番号変換前INVITEリクエスト30を受信し(S101)、メイン処理部21、加入者管理DB部21、番号変換管理DB部23により、以下の処理を行う。
メイン処理部21は、受信した「P−Asserted−Identity」パラメータ『sip:51−1001@company2.com』から、「発加入者のURI情報」『sip:51−1001@company2.com』を取得し、その「発加入者のURI情報」『sip:51−1001@company2.com』を加入者管理DB部22に入力する(S102、IN#31)。
加入者管理DB部22は、メイン処理部21から入力された「発加入者のURI情報」『sip:51−1001@company2.com』を検索用キー情報として、該当する「発加入者の位置・グループID」『3001;3901』を特定してメイン処理部21に出力する(S103〜S104、:OUT#32)。
メイン処理部21は、受信した「Request−URI」パラメータ『sip:0−09−9999−9999@company2.com』から、外線を意図した発信であるか、否かを特定する(S105)。本例では、外線特番「0」がURIの冠頭プレフィックスに設定されており、外線発信であると特定する(S105で「Yes」)。
外線発信であることを特定した場合、メイン処理部21は、受信した「Request−URI」パラメータ『sip:0−09−9999−9999@company2.com』を、公衆網で流通する形式に加工する(S106)。本例では、外線特番「0」を削除することと、URIのドメイン部『company2.com』を公衆網のドメイン『public.com』に置換する加工を行う。加工後の「Request−URI」パラメータは『sip:09−9999−9999@public.com』となる。
続けて、外線発信であることを特定した場合、メイン処理部21は、受信した「P−Asserted−Identity」パラメータ『sip:51−1001@company2.com』から「発加入者のドメイン種別」『company2.com』を取得する。メイン処理部21は、その「発加入者のドメイン種別」『company2.com』およびS104(OUT#32)で取得した「発加入者のグループID」『3901』を番号変換管理DB部23に入力する(S107、IN#33)。
続けて、番号変換管理DB部23は、メイン処理部21から入力された「発加入者のドメイン種別」『company2.com』と「発加入者のグループID」『3901』とを検索用キー情報として、該当する「変換後のURI情報」『sip:03−9001−1111@public.com』を特定してメイン処理部21に出力するS108〜S109、OUT#34)。
続けて、外線発信であることを特定した場合、メイン処理部21は、S109(OUT#34)で取得した「変換後のURI情報」『sip:03−9001−1111@public.com』を含むように、番号変換後INVITEリクエスト信号40に「P−Asserted−Identity」パラメータ『sip:03−9001−1111@public.com』を設定する(S110)。なお、最終的に、この設定値が、代表番号として通知される発電話番号である。
次に、メイン処理部21は、加工後の「Request−URI」パラメータ『sip:09−9999−9999@public.com』から、発信先が緊急特番であるか、否かを特定する。本例では、外線特番「0」を除去した後のURIの電話番号『09−9999−9999』が緊急特番ではないため、発信先が緊急特番ではないと特定する(S111で「No」)。なお、110等、緊急特番とみなす電話番号は、所定の記憶装置にあらかじめ登録しておく。
呼処理サーバ装置20は、メイン処理部21、加入者管理DB部21、番号変換管理DB部23による、上記の処理を行った後、番号変換後INVITEリクエスト信号40を送信する(S116)。
送信された番号変換後INVITEリクエスト信号40は、着側の呼処理ネットワーク12に配置された呼処理サーバ(図示なし)を経由し、最終的に電話機13『sip:09−9999−9999@public.com』に到達する。そして、電話機13『sip:09−9999−9999@public.com』は、受信した「P−Asserted−Identity」パラメータ『sip:03−9001−1111@public.com』を参照して、発電話番号表示『03−9001−1111』を行う。
以上のように、本実施形態の呼処理サーバ装置20は、「着電話番号変換」の機能と「発電話番号変換」の機能とでデータベースを共通化する。すなわち、本実施形態の呼処理サーバ装置20は、「着電話番号変換」の機能と「発電話番号変換」の機能とを、同一のDBを参照して実施することができる。これにより、例えば代表番号通知サービスのDBのリソースを専用に用意することを不要とし、効率的な代表番号通知サービスを提供することができる。なお、「着電話番号変換」は、緊急特番を、端末の位置に応じた電話番号に変換する機能である。また、「発電話番号変換」は、内線番号を、外線の代表番号に変換する機能である。また、「代表番号通知サービス」とは次のサービスである。すなわち、内線電話機から外線発信するIP電話サービスにおいて、内線電話機から外線発信する場合に、複数の内線電話機をグループ化し、同一グループの内線電話機のいずれから発信しても、共通の外線電話番号を発電話番号として着信側の電話機に通知するサービスである。
次に、図7及び図8を参照して、本発明に係る実施形態の基本構成について説明する。図7は、呼制御装置の基本構成を示す概略ブロック図である。上述した実施形態では、呼制御装置の一実施形態として、図1に示す構成について説明したが、呼制御装置の基本構成は、図7に示すとおりである。すなわち、呼制御装置1は、記憶部2、属性特定部3、発信元書換部4及び発信先書換部5を基本構成とする。
記憶部2は、変換前の電話機の識別情報に含まれる電話機情報2−1と、電話機の属性を示す属性値2−2と、変換後の識別情報2−3とを関連付けて記憶する。属性値特定部3は、呼制御信号の発信元の識別情報に基づいて、当該発信元の属性値を特定する。発信元書換部4は、呼制御信号の発信元の識別情報を、当該識別情報と属性値特定部3が特定した属性値2−2とに関連付けられた変換後の識別情報2−3に書き換える。発信先書換部5は、呼制御信号の発信先の識別情報を、当該識別情報と属性値特定部3が特定した属性値2−2とに関連付けられた変換後の識別情報2−3に書き換える。これにより、発信元番号の変換と発信先番号の変換の両方を実現しつつ、管理すべきデータベースの数を少なくすることができる。
図8は、記憶装置の基本構成を示す概略ブロック図である。上述した実施形態では、記憶装置の一実施形態として、図1、図3及び図4に示す構成について説明したが、記憶装置の基本構成は、図8に示すとおりである。すなわち、記憶装置8は、変換前の電話機の識別情報に含まれる電話機情報と、電話機の属性を示す属性値と、変換後の識別情報とを関連付けて格納する。また、記憶装置8は、発信元変換用レコード7と発信先変換用レコード8とを格納する。発信元変換用レコード7は、変換前の発信元の識別情報に含まれる電話機情報と、発信元の電話機の属性値と、発信元の変換後の識別情報とを関連付けて格納する。発信先変換用レコード8は、変換前の発信先の識別情報に含まれる電話機情報と、発信元の電話機の属性値と、発信先の変換後の識別情報とが関連付けて格納する。これにより、発信元番号の変換と発信先番号の変換の両方を実現しつつ、管理すべきデータベースの数を少なくすることができる。
なお、本発明の実施の形態は上記のものに限定されない。例えば図1に示した各構成要素を、適宜、統合したり、分割したりすることができる。また、各構成要素が有するプロセッサが実行するプログラムは、一部又は全部をコンピュータ読取可能な記録媒体や通信回線を介して頒布することができる。
なお、図7及び図8に示した本発明の実施形態に係る基本構成と、図1、図2A、図2B、図3及び図4に示した上記実施形態の構成との対応関係は次の通りである。すなわち、図1の呼処理サーバ装置20が、図7の呼制御装置1の一例である。図1の番号変換管理DB部23が、図7の記憶部2の一例である。図3の「加入者のURI情報」に含まれる「51−1001」等の発電話番号と「company1.com」等のドメインとが、図7の電話機情報2−1の一例である。図3の「加入者の位置・グループID」が、図7の属性値2−2の一例である。図4の「変換後のURI情報」が、図7の変換後の識別情報2−3の一例である。図1の番号変換前INVITEリクエスト信号30が、図7の呼制御信号の一例である。図2Aのメイン処理部21及び加入者管理DB部22によるS102〜S104の処理が、図7の属性値特定部3の一例である。図2Aのメイン処理部21及び番号変換管理DB部23によるS107〜S110の処理が、図7の発信元書換部4の一例である。図2Bのメイン処理部21及び番号変換管理DB部23によるS111〜S115の処理が、図7の発信先書換部5の一例である。図1の番号変換管理DB部23が、図8の記憶装置6の一例である。図4のレコード231aが、図8の発信先変換用レコード8の一例である。そして、図4のレコード231bが、図8の発信元変換用レコード7の一例である。また、図1の加入者管理DB部22が、本発明の第2記憶部の一例である。また、図3の「加入者のURI情報」が、本発明の変換前の電話機の識別情報の一例である。