統合通信基盤に向けた迷惑電話情報共有/自律着信拒否システムの開発
石川茂 1) ，齋藤彰一 2) ，舟橋 健司 2) ，松尾啓志 2)

1) 名古屋工業大学 技術部
2) 名古屋工業大学 情報基盤センター
ishikawa.shigeru@nitech.ac.jp

Development of a system for sharing information/autonomous
reject of nuisance phone in Unified communications infrastructure
Shigeru Ishikawa1) ，Shoichi Saito2) ，Kenji Funahashi2) ，Hiroshi Matsuo2)
1) Technology Cooperation Division, Nagoya Institute of Technology.
2) Information Technology Center, Nagoya Institute of Technology.

概要

IP 電話，Skype for Business，VoIP Adapter を利用できる学内統合通信基盤環境における迷惑電話対策として，迷惑電話情報を共有し自律的に着信拒否できるシステムを開発した．本システムは利用者が各デバイスへの着信を拒否できる番号を一括設定できるとともに，この設定情報を統計処理した結果に基づき自律的に着信拒否の設定を行う．2016 年 11 月より運用を開始した本システムの概要を運用評価とともに紹介する．

1 開発背景迷惑電話，営業電話による業務効率の低下が問題となっている一方，その対策には大きく 2 つの問題点が動化ライブラリを作成に利用することで複数の SIPID への一括登録等を実現できる．
2.2 共有情報を用いた登録
1.2 節「個人による情報収集量の問題」に対しては，ある．

2.1 節の手法により利用者が手軽に登録した結果を

1.1 登録コストの問題

RDBMS へ蓄積し，これを共有情報として 2.1 節のプ

統合通信基盤環境においては，IP-PBX サーバの管ログラムが利用することにより本問題も解決できると

理 WebUI による着信拒否設定作業が利用者の複数の考えられる．例えば，閾値以上が登録された迷惑電話

Session Initiation Protocol（SIP）ID ごとに必要なた番号をプログラムが着信拒否設定すれば個人による対め登録には多大なコストがかかる．さらに，利用者か策の負担を大幅に軽減できる．

らの管理 WebUI の利用や他システムからの IP-PBXデータベースへの接続を禁止している場合，問題を手軽に解消することが困難である．WebUI API が非公開または存在しない場合も同様である．

1.2 個人による情報収集量の問題
不特定多数に対し様々な業界からかけられて来る迷惑電話を個人で対策し続けることは難しい．

2 解決手法
2.1 WebUI 自動操作による迷惑電話番号登録

3 開発手法3.1 迷惑電話番号登録処理
2.1 節「WebUI 自動操作による迷惑電話番号登録」を実現するため，迷惑電話番号を利用者から取得しIP-PBX サーバの管理 WebUI を操作できるように作成したプログラムと，電話番号を格納する RDBMS，Web ブラウザをヘッドレスで動作させる X 仮想フ
レームバッファから構成される迷惑電話情報共有/自律着信拒否システムを開発した．

1.1 節「登録コストの問題」に対しては，利用者に代このプログラムは Selenium とその Firefox 用ドラ

わり WebUI を制御するように作成したプログラムにイバを利用し作成した．ヘッドレスで起動した Fire-管理 WebUI を操作させることにより，この問題を解

fox に対しプログラムから送信された自動操作情報が決できると考えられる．Selenium[1] 等の WebUI 自X 仮想フレームバッファを経由し IP-PBX サーバのWebUI へ渡されるようにした．これにより，対象の複数個紐付く）を統一データベース [2] と呼ばれる

WebUI 各パーツへの操作を記述すればプログラム単本学アイデンティティリポジトリより取得する．

体で対象，即ち IP-PBX サーバ管理 WebUI を操作で3. 本システムが IP-PBX サーバへ設定した当該利用きる．その結果，指定した SIP ID に対する任意の電者の着信拒否電話番号は，後述 6. の処理により本話番号を着信拒否させることが可能となる．

システムの RDBMS へ格納される．ここでは，登本 シ ス テ ム の WebUI か ら 利 用 者 が 指 定 し た 電録または削除済みの番号に対し処理を繰り返さな話種 別（IP 電 話 [2]，Skype for Business[2]，VoIP

いように IP-PBX サーバへ設定済みの当該利用者

Adaptor[2]），登録または削除の処理種別，迷惑電話番の着信拒否電話番号を RDBMS から取得する．

号に対し上記処理を実行する．その後，RDBMS の個

4. IP-PBX サーバ管理 WebUI 画面の各パーツに対別登録用テーブルへ利用者固有の情報として格納し，し本システムサーバが生成した操作情報を，SIP

本システム WebUI 上での登録状況一覧や削除操作にID，迷惑電話番号とともにリモートプロシージャ利用する．

コール（RPC）により X 仮想フレームバッファ

3.2 共有情報を用いた登録処理へ送信する．このバッファはメモリ上に X ウィ

2.2 節「共有情報を用いた登録」を実現するため，3.1ンドウ画面をマッピングしている．ここへヘッド

節で利用者が登録した個別登録用テーブルの情報を共レスに起動させた Firefox が IP-PBX サーバ管理

有情報として利用し，登録者数がある閾値以上の迷惑WebUI 各パーツへの登録または削除操作を行い，電話番号を自動的に IP-PBX サーバへ着信拒否設定する機能を 3.1 節のシステムへ実装した．この結果，個別登録を省力化できる．
具体的には，まず自動登録機能の有効化または無効化，個別登録された電話番号の登録者数がこの値以上であれば自動登録させる閾値（1, 2, 5 人），自動登録の対象とする電話種別を本システムの WebUI から指定する．その後、本システムが個別登録と同様の方法で自動的に IP-PBX サーバへ着信拒否の設定を行う．
共有情報の変動により，設定した閾値を登録者数が下回った場合は IP-PBX サーバの着信拒否設定から当該電話番号を自動的に削除する．上回った場合は追加する．これにより，共有情報を反映した最新の迷惑電話番号へ自動的に更新する．

4 システム構成
4.1 迷惑電話番号登録処理
本システムによる迷惑電話番号登録処理の構成を
図 1 に示す．本節では，図中の処理順を示した附番に沿って以下に詳しく説明する．

1. 利用者が Web クライアントで本システムの登録用 WebUI 画面から，着信を拒否させたい電話番号（複数指定が可能），電話種別，登録または削除の処理種別を入力する．利用者を識別するため，本学構成員へ配布された IC カード身分証内に格納された基盤 ID と呼ばれる一意の識別子を用いる．

2. 当該利用者の基盤 ID に紐付いた SIP ID（一般に図1

本システムの迷惑電話登録処理の構成

IP-PBX サーバへ HTTP リクエストを送信する．
5. IP-PBX サーバ管理 WebUI による登録または削除操作に問題が無い場合，IP-PBX サーバが IP-PBX データベースへ当該 SIP ID に対する着信拒否電話の登録または削除処理を行う．

6. IP-PBX サーバへの着信拒否電話番号の登録または削除が成功した場合，本システムの RDBMS に対し当該電話番号を登録または削除する．

4.2 共有情報を用いた登録処理
本システムによる共有情報を用いた登録処理の構成を図 2 に示す．本節では，図中の処理順を示した附番に沿って以下に詳しく説明する．

させる閾値，共有情報を用いた自動登録機能の有効化または無効化の設定種別を入力する．

2. 基盤 ID に紐付いた SIP ID を統一データベースより取得する．

3. 同じ処理を繰り返さないように IP-PBX サーバへ設定済みの当該利用者の着信拒否電話番号をRDBMS から取得する．
4. 4.1 節の登録処理により IP-PBX サーバへ設定された全利用者の着信拒否電話番号を共有情報として利用し，処理 1. で設定された閾値以上の登録者数の電話番号を，処理 1. で設定された SIP ID に対し IP-PBX サーバへ登録するためのリストを作成する．処理 1. で設定された処理種別が自動登

1. 利用者は本システムの登録用 WebUI 画面から，録機能の無効化である場合は，本 4.2 節により登対象の電話種別，4.1 節により個別登録された電録された着信拒否電話番号を IP-PBX サーバから話番号の登録者数がこの値以上であれば自動登録削除するためのリストを生成する．

5. 共有情報に対する処理 4. の算出結果を参照する．
6. IP-PBX サーバ管理 WebUI 画面の各パーツに対し本サーバが生成した操作情報を，SIP ID と迷惑電話番号とともに RPC により仮想フレームバッ
ファへ送信する．

7. IP-PBX サーバ管理 WebUI による登録または削除操作に問題が無い場合，IP-PBX サーバが IP-

PBX データベースへ当該 SIP ID に対する着信拒否電話の登録または削除を行う．

8. IP-PBX サーバへの着信拒否電話番号の登録また は 削 除 処 理 が 成 功 し た 場 合 ，本 シ ス テ ム のRDBMS へ当該電話番号を登録または削除する．

5 システム構築
5.1 システム構築に利用したソフトウェア
本システムの構築に利用したソフトウェアを表 1 に示す．Selenium を含め，全てオープンソースソフトウェアを使用している．

5.2 システムの構築
システム全体の構成を図 3 に示す．本システム，統合通信基盤 [2]，統一データベース，認証基盤はネット
表1

図2

本システムの共有情報を用いた登録処理の構成

システム開発に利用したソフトウェア

OSCentOS 6.8

JDK

OpenJDK 7

Web Container

Apache Tomcat 6

WebUI Automation librarySelenium 2.53

RDBMS

MySQL 5.7

ワーク的に保護されたサブネットワーク内に配置されする 2 要素認証により実施する．本システムへはる．このサブネットワーク内へのアクセスは，Web ク

教職員のみ，かつ IC カード認証のみに OpenAM

ライアントはサーバ負荷分散装置（SLB）を，IP 電話でアクセス制限している．これらの認証と認可に等は UTM システム，または VoIP ゲートウェイを経成功すると，Policy Agent が基盤 ID を HTTP由する必要がある．本節では各システム間の通信につリクエストヘッダへ埋め込む．その後，RP によいて，図 3 の中の附番に沿って以下に詳しく説明する．

り Web クライアントからのアクセスが本システ

1. 利用者が Web クライアントから本システムへアクセスすると，その HTTPS 通信は本システムの仮想 IP アドレスが登録された SLB へ到達する．

Web クライアントと SLB 間はセキュアな SSL 暗号化通信路が確保されている．

2. SLB は SSL の復号処理を行い，負荷分散先であるリバースプロキシサーバ（RP）へ転送する．この SSL オフロード機能により，本システムは SSLの暗号化と復号処理の負担から解放されている．

3. RP への HTTP 通信は，RP 上で稼働している
Policy Agent へ到達し，OpenAM と連携して認証と認可処理を行う．認証処理は IC カード身分証に格納された基盤 ID，および利用者が OpenAMの提示する認証画面へ入力したパスワードの 2 要
素を OpenAM が OpenLDAP の検索結果と照合

ムの実体ホストへプロキシされる．

4. 本システムへ HTTP リクエストが到達すると，基盤 ID に紐づく SIP ID を統一データベースより検索し，この SIP ID に対し着信拒否電話番号の登録または削除処理を開始する．

5. 本システムが HTML フォーム，および共有情報から取得した電話番号について，統合通信基盤に対しヘッドレスで着信拒否の設定を行う．

6. 統合通信基盤に着信拒否電話番号として設定されている電話から発呼した場合，発呼者には呼出音が聞こえるため着信拒否されていることを発呼者が認識することはない．

7. 統合通信基盤に着信拒否電話番号として設定されている電話からの着呼は呼出音が鳴らないため，着呼側の当該利用者は迷惑電話，営業電話による業務効率の低下を回避できる．

6 運用評価6.1 利用者数の推移
本システムの運用を本学教職員向けに開始した 2016年 11 月半ばから 2017 年 9 月半ばまでの 10 ヵ月間の利用者数の推移を図 4 に示す．
この図より，利用者数は右肩上がりで上昇していることが分かる（データ点が + 印のグラフ）．その下の3 本のグラフは，4.1 節「迷惑電話番号登録処理」による個別登録と，4.2 節「共有情報を用いた登録処理」による自動登録の利用者数を示す．自動登録は利用せず個別登録のみを利用する利用者数（データ点が×印のグラフ），および個別登録は利用せず自動登録のみを利用する利用者数（データ点が*印のグラフ）はどちらも運用開始 4 ヵ月目以降は横ばいであることが分かる．
一方，個別登録と自動登録の両方を併用している利用者数（データ点が□印のグラフ）は 4 ヵ月目から上昇し，その半年後にはその 4 倍に達している．
これら 3 本のグラフは右肩上がりの上昇を示している利用者数の内訳を示すものであり，4 ヵ月目からの上昇は個別登録と自動登録を併用する利用者の増加に
図3

システム全体の構成よるものといえる．

Number of users [persons]6.3 迷惑電話番号登録数の推移
4030

2016 年 11 月半ばから 2017 年 9 月半ばまでの 10 ヵ月間の利用者一人あたりの迷惑電話番号平均登録数の推移を図 5 に示す．この図より，登録数は右肩上がり

20で上昇していることが分かる（データ点が + 印のグラ10フ）．その下の 2 本のグラフは，4.1 節「迷惑電話番号登録処理」に基づき個別登録された登録数（データ点0

図4

Numbers of phone numbers/person

Number of users
Individual information only
Shared information only
Both02468
Elapsed months [months]

10が×印のグラフ）と，4.2 節「共有情報を用いた登録処理」に基づき自動登録された登録数（データ点が*印の迷惑電話情報共有/自律着信拒否システムの利用者数グラフ）を示す．個別登録よる登録数に比較し，自動登録よる登録数が大幅に上昇していることが分かる．

20

Numbers of phone numbers
Based on Individual information
Based on Shared information15

これら 2 本のグラフは右肩上がりの上昇を示している登録数の内訳を示すものであり，自動登録による登録数の増加がこの上昇傾向に大きく寄与しているとい10

える．

6.4 迷惑電話番号登録数に関する評価

56.2 節で述べたように，個別登録と自動登録の両方00

図524
68
Elapsed months [months]

10

利用者一人あたりの迷惑電話番号平均登録数を併用している利用者数の増加は，共有情報量の増加と，それに伴う本システムによる自動登録による登録数の増加を同時にもたらす．この効果は自動登録のみを利用している利用者にもおよび，利用者一人あたり6.2 利用者数に関する評価
本システムにとって，個別登録と自動登録の両方を併用している利用者数の増加は望ましい傾向である．
なぜなら，個別登録のみの利用では 1.1 節の問題は解決できるものの 1.2 節の問題が解決できず，自動登録のみの利用では両者の問題は解決できるものの共有情報量が増えないため，自動登録される電話番号数が少ない状態に留まるからである．もし利用者全員が自動登録のみであれば，本システムによる登録は 1 件も実施されないことになる．
また，個別登録，または自動登録のどちらか一方のみの利用者数が横ばい傾向である原因は 2 つ考えられる．1 つは本システムの利用方法に関するドキュメン
トが現在ほど充実していなかった運用開始当初より利用を始めたアーリーアダプターが本システムに関する理解が不十分な状態にある可能性があることである．
そうであれば，本システムに関する今後の情報発信方法の工夫により減少すると推測される．
もう 1 つは共有情報を信頼せず自ら情報を生産する利用者と，情報を生産せず消費するだけの利用者が社会に一定数存在するという可能性である．そうであれば，上記の工夫によっても減少しないはずであり，今後の推移を興味深く見守っていきたい．の平均登録数における自動登録よる登録数の上昇に表れている．こうしたことから，本システムの自動登録機能が効果的に機能していることが確認できる．

7 まとめ
統合通信基盤環境に向けた迷惑電話情報共有/自律着信拒否システムを開発し，10 ヵ月間運用した結果，本システムの有効性を確認できた．今後は登録速度のボトルネックとなっている WebUI 自動化処理の改善手法について検討を進めていく予定である．

参考文献[1] Simon Stewart， The Architecture of Open
Source Applications: Selenium WebDriver ，www.aosabook.org/en/selenium.html，2016.
[2] 齋藤彰一，打矢逸，松尾隆弘，松井俊浩，内匠啓志， 名古屋工業大学におけるユニファイドコミュニケーションシステムの導入 ，大学 ICT 推進協議会 2015 年度年次大会論文集，

1F3-5，2015．