第 15 部
インターネット と他の通信メディアの融合

483

第

1章

はじめに
wt(WIDE Telecommunications) ワーキンググループ (以下 wt-wg) は 、インターネットと他のテレコミュニケーションメディアとの融合の実現を目指し 、1996 年 9 月より活動している。活動開始当初の wt-wg(旧 wt-wg) は WIDE プロジェクトメンバー以外も含めて活動していた。旧 wt-wg は 1997 年 3 月末日をもって活動を停止し 、itel-wg と ifax-bof に分離した。新 wt-wg は 1997 年 4 月より、旧 wt-wg, PhoneShell ワーキンググループのうちの WIDE プロジェクト メンバーを引き継ぐかたちで発足した。1997 年 10 月に itel-wg は
wt-wg に吸収されて現在にいたる。1997 年 4 月から 1997 年 11 月までは代表者、担当ボー
ド メンバーともに大野 (東京工業大学) とし 、1997 年 12 月からは代表者を木本 (東京工業大学), 新美 (慶應義塾大学 SFC 研究所) の 2 名, 担当ボード メンバーを大野としている。
wt-wg の活動はこれまでの PhoneShell, yaics, 旧 wt, itel の各ワーキンググループの活動の発展として位置付けられる。これまで WIDE プロジェクトでは、既存のさまざまな通信サービスや通信メディア (以下、
「既存のメディア」) との連携について検討しさまざまな実
装を行なって来た。たとえば 、(上記のワーキンググループの活動には含まれないが )WIDE
プロジェクト発足当時からのメンバである中村 (慶應義塾大学) が 1980 年代末に勢力的に研究していた「 UNIX ワークステーションから FAX を制御する機構」の研究は、FAX モ
デムがまだ存在しなかった当時としては先駆的な研究であった。また、大野が 1990 年から手掛けている WIDE/PhoneShell プロジェクトでは、プッシュホンを計算機の入出力イン
ターフェースとする機構の研究開発をつづけており、近年では視覚障害者の計算機利用支援機構としても注目されている。インターネット上のメッセージをページャに転送する機構として 1991 年に誕生した WIDE/PCS は、同じような内容の商用サービスが国内で始まるより 5 年も早く実装されていた。
近年、CTI(Computer Telephony Integration) という呼称でコンピュータと電話サービスとを統合する技術が注目されているが、WIDE プロジェクトにとってこのような既存のメ
ディアとインターネットとの連携は、すでに歴史あるテーマである。wt-wg ではこれを継承発展させ、電話サービスとインターネットの相互接続のみに留まらず、さまざまなテレ
コミュニケーションメディアとインターネットとの連携についての研究をおこなっている。
本報告では、1997 年 4 月から 1998 年 3 月までの wt-wg の一年間の活動成果について報告
する。

485

486

1997 年度 WIDE 報告書

今期の活動は、既存のメディアのうちの特に電話網とインターネットの融合について、大別して二つの視点からすすめられた。一つは「電話網とインターネットを融合した通信
インフラストラクチャの整備」である。このテーマのもとでは、既存の電話網とインターネットを融合した通信インフラストラクチャを世界規模で運用する際の運用モデルについての議論と、通信インフラを構成する技術の研究が行われた。本文中では、後者の実例としてインターネット FAX とインターネット電話をとりあげている。今期の大きな成果の一つとして、InternetFAX の標準化作業への貢献があげられる。この標準化の過程について、InternetFAX の概要を交えながら述べる。インターネット電話については、概要およびその標準化動向について述べたのち、とくに Talkware 1の概要と、これを用いた RSVP 実験について報告する。
もう一つの視点は「電話網とインターネットを融合したインタフェースの提供」である。このテーマのもとでは、インタフェース開発のためのプラットホームとして WIDE/PhoneShellの改良を行い、改良した WIDE/PhoneShell を用いた実際のインタフェース開発が行われた。本文中では事例として、lifeline-wg との共同による災害時生存者情報登録システム (IAAシステム) の電話/FAX インタフェースの開発と、電話を用いたネットワーク管理支援シス
テムについて述べる。前者については lifeline-wg の報告では触れていない技術的な内容などに重点をおいた。このシステムの概要については lifeline-wg の報告内容をあわせて参照
して欲しい。また IAA システムのインタフェースの一部として、FAX の受信内容を文字/記号認識した結果を人手によって確認するシステムを開発した。このシステムも電話網とインターネットを融合したインタフェースの一部ととらえることができるため、本報告中で述べることにした。
報告書の構成はこの二つの視点に基づいている。前半の 2 章から 5 章までは、電話網とインターネットを融合した通信インフラストラクチャについて述べている。後半の 6 章から 7 章までは、電話網とインターネットを融合したインタフェースの提供について述べている。
この報告の執筆者と担当した章との対応を以下に述べる。(以下執筆順)
第 1 章, 第 6 章 1 節, 第 7 章 4 節, 第 8 章 木本 (東京工業大学大学院)
第 1 章, 第 8 章 大野 (東京工業大学大学院)
第 2 章, 第 5 章 新美 (慶應義塾大学 SFC 研究所)
第 3 章, 第 7 章 2 節 本間 (松下電送株式会社)
第 4 章 塚田 (株式会社日立製作所)
第 6 章 2 節, 第 7 章 1 節 是枝 (東京工業大学大学院)
第 7 章 3 節 野田 (東京工業大学大学院)
1 (株) 日立製作所と (株) 日立インフォメーションテクノロジーが開発した IP 電話システムの名称

第 15 部

インターネット と他の通信メディアの融合

第 7 章 4 節 辻元 (東京工業大学情報科学科)

487

第

2章

世界規模での管理運用モデル
1997 年 9 月 1 日に日本における国際公専公接続が、インターネット電話サービスだけに対して認められた。これは、通常音声のサービスなどを差し置いての先行解禁である。こ
の先行解禁に伴い、インターネット電話サービスが商業サービスとして多数立ち上がった。
しかし 、これら商業サービスには、以下のような問題点がある。

1. サービス会社ごとの独立したサービスで、相互乗り入れを考慮していない。
2. そのサービスのほとんどが 、通常電話 ! インターネット ! 通常電話という形態を想定したサービスである。

3. インターネット上のコンピュータ ! 通常電話またはその逆の形態は考慮されてい
ない。
これらは、

1. 不必要な「電話とインターネットのゲートウェイ」の乱立
2. 汎用性の低い「特化されたサービス」の乱立
3. インターネットの重要な要素である分散協調性の低下といった悪影響を及ぼし 、「多様なメディアが流れるバックボーンとしてのインターネット[143] 」におけるメディア間相互透過性を損ねている。
そこで本節では、これら問題点を解消すべく、まず、３つのインターネット上でのインターネット電話管理運用モデルを作成した。

1. 社内モデル
2. プロバイダモデル
3. ワールド ワイド モデル
さらに、この 3 つのモデルについて、以下の 4 点で考察、検討し 、実際のインターネッ
ト上での検証実験を行った。

488

第 15 部

インターネット と他の通信メディアの融合

489

1. 認証方法
2. 課金方法
3. 相手先指定方法 (名前空間)
4. ユーザ情報などの管理方法
特に、前述の 3 モデルの内、「ワールド ワイド 」モデルでは、公開鍵暗号を使用した「通行証」の概念を新たに考案した。この「通行証」概念では、ユーザやゲートウェイマシン
の認証、サービス会社を跨いだ課金も可能にし 、現在では行われていないサービス会社を跨いだインターネット電話サービスを可能としたので、詳しく述べた [144]。

なお、本章ではインターネット電話とは、図 2.1で示す 3 つの形態全てをあらわすもの
とする。

%V%

§öÂVÐÆË
%¥)!

§öÂVÐÆË

,%()#)!¥)!

%()#, §öÂVÐÆË ,%()#

図 2.1: インターネット電話の 3 形態
この図でもあきらかなようにに、通常の電話から、パソコンで動作するインターネット
電話への接続も考慮しなければならない。そこで、相互透過性を保つために、相手の指定
方法は全て数字で表すこととし 、これをインターネット電話番号と呼ぶ。詳細は 2.2.1節で述べる。
なお、本節では、これらのモデルをインターネット電話について考察したが、インター
ネット FAX にも十分応用出来る。

490

1997 年度 WIDE 報告書

2.1

インターネット 電話管理運用モデル

インターネット電話管理運用のモデルをその規模に応じて 3 つに分類した。

2.1.1

社内モデル

このモデルは、小規模な閉鎖されたネットワークでのモデルであり、企業内内線の代わりにインターネット電話を使う場合などを想定している (図 2.2)。

%-

,

%()#

0C0
0B4

0C4
:44?4A

図 2.2: 社内モデル
社内に GateKeeper[145] やデータベースを持つ。データベースでは内線番号 ( インターネット電話番号) と IP アドレスの変換テーブルを管理する。規模が小さいので、データベー
スの分散化は不要である。通話相手の指定方法は、以下の 3 種類が想定される。

1. 数桁の内線番号のみで指定
地理的な場所の違いに関係無く、数桁の内線番号のみで管理する。ただし 、規模が大きくなると不向き。

2. 代表呼び出し +内線番号で指定

代表者番号に電話をかけ、応答メッセージの後に DTMF1で内線番号を入力する (ダイアルイン )。ISDN のようなデジタル電話ではサブアドレスの使用も考えられる。

1プッシュフォンのダ イアルトーン。ピポパ音第 15 部

インターネット と他の通信メディアの融合

491

3. 下数桁が内線番号となっているインターネット電話体系の採用
会社毎 (ゲートウェイ [145] 毎) に会社番号を振るインターネット電話番号体系を作り、「会社番号」+「内線番号」という番号体系にする。
後述の他モデルとの関係を考慮すると 3. を採用するのが望ましい。
課金については、このモデルではあまり必要が無いと思われる。ただ、使用記録を残す
システムは必要である。

2.1.2

プロバイダモデル

このモデルは、1 社のみのインターネットサービスプロバイダ会社2だけで運用する事を想定したモデルである (図 2.3)。

%()#

%()#

,

0C4
:44?4AÐ¡Y®ÿ©

îVÂ

îVÂ


0C0
0B4
Ê{

,

0C4
:44?4AÚs

図 2.3: プロバイダモデル
このモデルでは、以下の事項を前提条件とする。

 発信者は、そのプロバイダの契約者のみとする。
 通話先がインターネットの場合は、通話相手はそのプロバイダ契約者のみ
 通話先が公衆交換回線網 の電話の場合は、通話相手は特に限定しない。
3

2 以下プロバイダと省略

3 通常の電話網。以下 PSTN とする

1997 年度 WIDE 報告書

492

 使用するゲートウェイは、そのプロバイダ所有の物のみとする。
 インターネット電話番号から IP アドレスへの変換テーブルを持ったデータベースはそのプロバイダが管理する。
インターネット電話番号体系については、後述のワールド ワイド モデルを考慮して、各プロバイダに特有の番号を上数桁に割り当て、各ユーザに下数桁に割り当てる。

PSTN 電話に発信する場合は、電話番号に特定の pre x をつけて指定し 、IP アドレス
変換データベースは使用しない。これは、一般的に内線電話から外線発信する場合には 、
0 や 9 といった pre x を付けて発信することが多いので、インターネット電話でも同様に扱った。
課金については、顧客情報管理のデータベースで一元管理する。

2.1.3

ワールド ワイド モデル

このモデルは先のプロバイダモデルを拡張し 、複数のプロバイダが分散協調を行いつつ運用するモデルである。このモデルでは、利用者が契約していないプロバイダのゲートウェ
イから PSTN へ発信する事も可能である (図 2.4)。

%()#

%()#


0C4
:44?4A


0C0
0B4
Ê{

Ð¡Y®ÿ©

îVÂ

,

îVÂ

,

0C4
:44?4AÚs

図 2.4: ワールド ワイド モデル
インターネット電話番号から IP アドレスへの変換テーブルについては、全世界的なデー
タベースを集中管理することは困難であり、分散管理が必要である。このインターネット
電話番号をサービス主体 (ここではプロバイダ ) と無関係に割り当てると、番号IP ア
ドレスのデータベースを管理するのが複雑になる。そこで、上位数桁をプロバイダ番号と!

第 15 部

インターネット と他の通信メディアの融合

493

し 、下位数桁をユーザ番号とし 、Domain Name System[146, 147] のように階層構造で管理する。
PSTN 電話に発信する場合は、プロバイダモデルと同様に、電話番号に特定の pre x をつけて指定する。
課金については、利用者が契約しているプロバイダに課金情報が集まる必要があり、プ
ロバイダ間での課金情報のやり取りを定める必要がある。本章では、この課金のための仕組みを「通行証モデル」として提案し 、2.3節で詳細を述べる。

2.2

インターネット 電話番号とデータベース

本章では、インターネット電話番号とそれを管理するデータベースについて述べる。

2.2.1

インターネット 電話番号

前述のように、通常の電話からインターネット電話への接続も考慮するために、相手先指定には全て数字を用いる。これは、通常の電話から補助装置を伴わずに入力できるのが、数
字と一部の記号に限られるためである。本章では、これをインターネット電話番号と呼ぶ。
このインターネット電話番号は「ワールドワイドモデル」の実現を考慮すると、インターネット電話番号 IP アドレスの変換テーブルが階層的に分散管理できるような体系にする必要がある。
そこで、既存の電話番号体系と同様に、!

国番号 [148] + プロバイダ番号 + ユーザ識別番号とする。
ユーザ識別番号は、利用者がプロバイダとサービス契約を結んだ時点で、プロバイダが発行する。
このような階層構造にすれば、各プロバイダは自社の契約者分についての変換データベー
スを管理すれば良く、また、他のプロバイダ契約者にインターネット電話をかける際も検索が容易になる。

2.2.2

データベース

インターネット電話番号を管理するデータベースは、前述のように各プロバイダ毎に自社契約者のインターネット電話番号と IP アドレスの対応を管理する。たとえば 、Domain
Name System[146, 147] を利用し 、TPC.INT[149, 150] と同様の仕組みを用いれば 、容易に分散管理が可能である。
分散データベースに Domain Name System を使用する利点はもう１つある。ダ イアル
アップ型接続や DHCP[151] などを利用すると、インターネット電話の IP アドレスが動的1997 年度 WIDE 報告書

494に変化する場合がある。これは Domain Name System Dynamic Update[64, 65] を利用することで対応が可能である。
最近では、LDAP[152, 153] といった広域分散データベースも普及してきている。これらの使用についても今後検討が必要である。

2.3

通行証モデル「ワールド ワイド モデル」で使用する通行証モデルを、図 2.5を元に説明する。

ÚðÓ§Ã

0C00B4
Ó;q0C4:44?4A0C4:44?4A%()# ,

ÚðÓ§ÃA, %()#

ÚðÓ§Ã

図 2.5: 通行証モデル
まず、条件として、プロバイダ A,B,C は提携関係にあり、利用者はプロバイダ B とのみ契約しているとする。
また、利用者の近くには契約してるプロバイダ B のゲートウェイがなく、また通信先の近くにもプロバイダ B のゲートウェイがないという場合を想定する。
最初に、利用者は身近なプロバイダ A のゲートウェイに電話をかけ、数字で構成されたID と PIN4を入力する。ID と PIN は、公開鍵暗号などによる安全な通路を通り、プロバイ
ダ B のデータベースに到着する。プロバイダ B のデータベースで認証を行い、正しく認証された場合は、プロバイダ B の秘密鍵を用いて電子署名をした通行証を発行する。この通行証はプロバイダ B の公開鍵のみで開くことが可能である。つまり、通行証がプロバイダ
B の公開鍵で開くことができた場合は、この通行証を携えた通信が無条件で PSTN へ発信
してよいことをプロバイダ B が保証することになる。つまり、PSTN への発信にかかったコストは、電子署名をしたプロバイダ B が支払を保証することをあらわす。なお、この通
4 Presonal Identi cation Number。数字だけのパスワード。

第 15 部

インターネット と他の通信メディアの融合

495

行証は盗聴などによるリプレ イアタックを防ぐために、時刻による有効期限が設定されている。
そして、通行証はプロバイダ A に渡り、実際に PSTN へ発信するプロバイダ C に渡る。
プロバイダ C は、通行証の有効性を確認し 、PSTN への発信をおこうなう。
通話が終了したら、その通信ログを課金情報としてプロバイダ C がプロバイダ B に送る。このようにすることで、プロバイダ C のゲートウェイには ID や PIN と言った個人情報を渡さずに全てが処理でき、セキュリティーレベルの低下を防ぎつつ、かつ利用者が直接契約していないプロバイダを利用することができる。
この場合、各ブロバイダのゲートウェイ、データベースなどのなりすましなどを防ぐた
めには、それぞれのマシン毎に秘密鍵と公開鍵を用意し 、公開鍵暗号による認証を行う必
要がある。

2.4

インターネット FAX への応用

今回は、インターネット電話でのモデリングと通行証モデルを提唱したが、これらはイ
ンターネット FAX でも同様に取り扱うことが出来る。
現在、インターネット FAX は IETF で国際標準化がすすめられており、その一部が RFCとして制定された [154, 155, 156, 157, 158, 159] 。この RFC でのインターネット FAX シス
テムは配送に電子メールを利用している。この電子メールに S/MIME などの公開鍵暗号
方式を組み合わせれば 、本章のモデルはインターネット電話での場合と同様に適応可能で
ある。

第

3章

インターネット

3.1

FAX

はじめに

1998 年 3 月、IETF より InternetFAX に関する RFC が 6 本公開された [154, 155, 156,
157, 158, 159]。
それらの RFC は、IETF の FAX ワーキンググループから提出された RFC である。
IETF において、WIDE プロジェクトは FAX ワーキンググループの立ち上げや Store &Foward 型プロトコルの提案 [158] をおこなってきた。

図 3.1: 製品版 InternetFAX
今までの FAX は ITU で標準化が、そして InternetFax の標準化は IETF で行われてきた。このような、IETF 以外の標準化組織で標準化が行なわれてきた従来のプロトコルが、
インターネット上のプロトコルとして実装され、標準として普及することが今後も予想される。したがって、今後も IETF 以外の標準化組織との協調関係が必要となる。

496

第 15 部

インターネット と他の通信メディアの融合

497

本章では、ITU-T の Study Group 8 と協調しておこなった、InternetFAX の標準化について述べる。

3.2 FAX とインターネット の融合
3.2.1

電子メールと FAX

FAX は、一般公衆回線網を使用したアナログの通信方式である。そのプロトコルを、デジタルのインターネット上で動かすため、さまざ まな検討が行われた。FAX のプロトコルである T.30 を、そのまま UDP や TCP 上に実装する方式も考えられたが、この方式はFAX をインターネットに移行することを中心に着目しているため、インターネットを使う
メリットや、インターネットの持つ特性を活かせない。
そこで WIDE Project からは 、インターネットの特性を有効に活用できる方式として、
電子メールの機構上に FAX を融合する Store & Foward 型プロトコルの提案を行った。
表 3.1に FAX と、電子メールの関係を示す。

FAX
電子メール

ネットワーク
一般公衆回線網 (PSTN)
インターネット

扱うデータ
画像
メッセージ

実時間性
あり
なし

複数配信
不可
可能

送信相手
個人または組織個人

能力交換の機能ありなし

表 3.1: FAX と電子メールの関係
電子メールには、画像や音声などを送るためのフォーマットである MIME([160],[161]) がある。その MIME のメッセージフォーマットで、FAX の画像フォーマットを添付し 、電子メールとして送付することで、基本的な FAX 通信はおこなえる。これが、Store & Foward
型の InternetFAX である。ユーザはコンピュータ上の電子メールアプリケーションを使用
して、FAX の画像を見ることができる。
従来の FAX は、相手の識別に電話番号を使用するため、1 台の FAX を家庭や組織などの複数の人で共有することになり、個人宛の FAX データを送信できなかった。InternetFax では、電子メールの機構をそのまま使用することで、個人宛のデータの送信が可能となった。
また、電子メールであるため、複数の宛先への同時送信も可能である。
しかし 、Store & Foward 型 InternetFax は従来の FAX が持つ利点である実時間性やセキュリティの確保などの一部の機能が欠如している。
現在、実時間性の問題解消には、RSVP[162] の利用や SMTP の直接配送などの手法が検討されている。また、セキュリティ確保には、S/MIME[105] といった電子メールのセキュ
リティ確保の方法が、蓄積転送型 InternetFAX として新たな機構を作成せずに、そのままの形で利用できる。

1997 年度 WIDE 報告書

498

その他に Store & Foward 型 InternetFAX に欠如している重要な点が、能力交換の機能(ネゴシエーション ) である。
現在の FAX は、通信プロトコル上に能力交換の機能を保有している。現在の蓄積転送型
InternetFax には、能力を交換する機能が存在しなく、受信側で再現する努力を行うか、または、送信側でデータの制限を行っている。
しかし 、現在では能力交換の必要が高まりつつあり、それらを解消するため、LDAP な
どのプロトコルを使用して、能力交換をおこなう実験を開始した。

3.2.2

InternetFAX の実装

IETF の FAX ワーキンググループでは、当初４つの項目について検討した。それらの項目を以下に示す。

1. データフォーマット
2. アドレッシング表記
3. 送達確認
4. セキュリティ
Store & Foward 型 InternetFAX と FAX の違いとして、能力交換の機能があると述べたが、能力交換を必要とする重要な情報として、データフォーマットがある。そこで、蓄積型 InternetFax で、能力交換を不要にするために、扱うデータフォーマットを規定した。
このデータフォーマットは最低限の機能を定義することで、必須となる実装を定めることで、インタオペラビリティを確保した。それらを規定したドキュメントとして、WIDE
案 (TIFF-F minimum set) のデータフォーマットを規定した。以下にその主な条件を記述する。

 データをインテル方式で記述
 IFD とイメージデータが順番に配置
 用紙をＡ４
 圧縮方式を MH
 データは LSB First EOL は non-Byte Boundary RTC が付加されていても受信は可能とする

第 15 部

インターネット と他の通信メディアの融合

499

これらの項目は、現在の FAX を中心として、送信側／受信側の見解から分析し 、従来のFAX から InternetFAX への移行を容易にするべく条件を規定した。
その後、データフォーマットは、TIFF-F から TIFF-FX へと拡張が行われ、アドレッシ
ング表記も決まった。そして、今後の検討項目として次の項目があげられた。

 データデータの拡張フォーマット
 InternetFAX から PSTN への中継
 PSTN から InternetFAX への中継
 実時間性 送達確認 (受領確認)
 セキュリティ(認証／暗号) 能力交換機能

3.3 InternetFAX の標準化活動
3.3.1

IETF における標準化活動

InternetFAX の標準化の動きを以下に示す。

 96/6 IETF モントリオール会合にて InternetFAX に関する初めての BOF が開催。
 96/7 WIDE プロジェクトで国内の FAX メーカを含めて InternetFAX の標準化を検討のための BOF を発足。

 96/12 IETF SanJose 会合にて WIDE 案を提出。Store & Foward 型として標準化を進めることになる。

 97/4 IETF Menphis 会合にてデータフォーマットを集中審議。
 97/4 〜 97/8 メーリングリスト上で審議が継続され、標準化の対象が四つの項目に整理された。

 97/8 WIDE より四つの項目についての Internet Draft を IETF に提出した。
 97/8 IETF Munch 会合にてデータフォーマットが TIFF-F に決定した。
 98/3 IESG より RFC として定義された。

1997 年度 WIDE 報告書

500
3.3.2

ITU-T における標準化活動

現在、従来の FAX の標準を定めている ITU-T (旧 CCITT) でも InternetFAX の標準化が進められている。
現在、FAX プロトコルの標準化作業は、日本の FAX メーカが中心となり、ITU-T で提案が行われおり、IETF と ITU-T で、それぞれ違う InternetFAX のプロトコル仕様を、定義する可能性が考えられた。IETF と ITU-T で違う標準を定めてしまうのは、世界中の混乱となる。そこで、われわれも、急拠 ITU での活動も標準化の作業に組み込み作業を開始した。
IETF と ITU は、過去よりあまり良い関係を保っていない。そのため、同じ仕様でも別々に勧告書が書かれており、若干の意味の違いなどが 、発生していた。しかし 、1998 年 1 月
からは ITU-T の勧告 (A.5) により、IETF の RFC を参照できることになり、IETF の FAX
ワーキンググループでの標準化作業に ITU 側も注目するようになった。
ITU-T における InternetFAX の標準化の動きをあげる。

 '97 10 月 Determination at SG8
 '98 1 月 中間会合 White Document
 '98 2 月〜 5 月 郵便投票
 '98 6 月 Decision at SG8 勧告化（予定）3.4

今後の取り組み今後、ITU と IETF が共同でおこなう標準化作業が増えることが考えられ、InternetFAX
で培われた ITU と IETF の関係を崩さずに進めていきたい。
InternetFAX としては、規格が RFC となり、Internet Standard となるべく、第一歩を踏み出した。今後は、積み残した問題である、送達確認，セキュリティ，能力交換や中継機能の解決について検討していく。

第4章

インターネット 電話

4.1 IP 電話概要
4.1.1

IP 電話とは

従来の電話網は図 4.1に示すように、発信側電話機−着信側電話機間を複数の交換機を経由して 1 本の回線により接続する回線交換網である。一方 IP 電話、いわゆるインターネッ
ト電話は発信側端末−着信側端末間の回線の一部区間、あるいは、全区間をインターネッ
ト、イントラネットなどのパケット交換網を用いて接続するものである。この場合の端末とは、電話機、ならびに、IP 電話ソフトウェアが動作しているコンピュータ端末 (以下 PC
端末) である。

図 4.1: 従来電話と IP 電話

IP 電話では、中継部分にインターネットなどの IP 網を使用しているので回線交換網のように 1 つの通話が 1 つの回線を占有せず、複数の通話で共有可能であるため、回線の使用効率が高まっている。また、通話に必要な帯域幅に関しても、ISDN (Integrated Services
Digital Network) の場合、音声 1 回線当り音声符号化方式に PCM (Pulse Code Modulation)を用いて 64kbps の帯域幅の設計であるのに対し 、IP 電話では PCM よりも高圧縮の音声符号化方式を用いており、同じ帯域幅ならば 、より多くの音声回線を通すことができる。

501

1997 年度 WIDE 報告書

502

したがって、IP 網部分の通話当りの利用コストを下げられることから、従来の長距離電話
サービスと比較して低通話料金が可能なのである。

4.1.2

接続形態

IP 電話の接続形態には、次の 3 種類がある。
(a) PC 端末− PC 端末接続(b) 電話機− PC 端末接続(c) 電話機−電話機接続

図 4.2: IP 電話の接続形態

PC 端末− PC 端末接続は、図 4.2(a) のようにインターネットにより両端末間を直接接続する形態である。この接続形態の利点は、たとえば 、発信側、着信側の両ユーザがイン
ターネットに接続している PC 端末を所有していれば無料 ( インターネットに接続するための料金を除く) で通話できることである。欠点は、両ユーザが PC 端末を所有していないと通話できないことである。この接続形態は、IP 電話が現在のように注目される以前から一部のユーザによって実験的におこなわれていた。その後、数社が IP 電話クライアントソフ
トウェアを無償配布したことにより、急速に普及していった。
電話機− PC 端末接続は、図 4.2(b) のように従来の電話網に接続されている一般電話機とインターネットに接続されている PC 端末の両者を接続する形態である。この接続形態

第 15 部

インターネット と他の通信メディアの融合

503を実現するためには、電話網とインターネットの間で接続プロトコル、音声信号などを変換・中継するゲートウェイが必要である。
電話機−電話機接続は、図 4.2(c) のように発信側、着信側電話機間の各々が接続している電話網間をインターネットを用いて中継する接続形態である。この接続形態も電話機−
PC 端末接続と同様にゲートウェイが必要である。この接続形態は、インターネットを中継部分に使用しているので従来より低通話料金であるとともに、PC 端末などの特殊な機器
ではなく一般的な電話機を所有しているユーザ同士で通話できることから、公−専−公接続サービスの解禁により注目されている。

4.1.3

IP 電話の標準化動向

これまで IP 電話に関する国際標準は ITU (International Telecommunication Union) の標準化部隊である ITU-T (ITU-Telecommunication Standardization Sector) により主に進められてきたが、IP 電話が注目されるようになり、いくつかのグループで標準化が進められている。

 ITU-T SG16
ITU-T においてマルチメディアシステムとサービスに関して議論している SG (Study
Group) である。現在は IP 電話の勧告である H.323 、H.225.0、H.245 の改訂版等について検討中である。

cf. http://www.itu.int/itudoc/itu-t/com16.html

 IMTC VoIP ForumVoIP (Voice over IP) Forum は IMTC (International Multimedia Teleconferencing
Consortium) の Activity Group の一つであり、米国のメーカ中心の業界団体で、IP
電話の実装に関する要求条件について議論している。Implementation Agreement の確定を目指している。

cf. http://www.imtc.org/i/activity/i voip.htm

 ETSI Project TIPHONTIPHON (Telecommunications and Internet Protocol Harmonization Over Networks)
は ETSI (European Telecommunications Standards Institute) のプロジェクトの一つであり、欧州を中心としたメーカ、キャリアが参加している。IP 電話システムの電話
番号体系、料金体系、セキュリティなど広範な話題について標準化を目指している。

cf. http://www.etsi.fr/tiphon/tiphon.htm

 IETF iptel WG

1997 年度 WIDE 報告書

5041998 年 3 月にそれまでの siptel BOF から iptel に名称を変更して IETF の Transport
Area の正式な WG となった。1998 年 4 月現在、チャーターについて検討中である。
cf. http://www.ietf.org/html.charters/iptel-charter.html
IP 電話の接続手順、すなわち、呼制御プロトコルは、ITU-T により勧告として標準化されており、ITU-T 勧告 H.323 とその関連勧告として規定されている。IP 電話などの音声に関する主要な勧告は次のとおりである。

 H.323: Packet based multimedia communications systems
IP 電話システム全体の定義、構成要素の定義、全体の接続シーケンスを定義している。

 H.225.0: Call signalling protocols and media stream packetization for packet based
multimedia communication system

端末管理のために用いられる RAS (Registration, Admission & Status) プロトコルと呼接続のための Q.931 をベースとしたコールシグナリングプロトコルのデータ構造、シーケンスについて定義している。

 H.245: Control protocol for multimedia communication
マルチメディア通信をするための、能力交換、論理チャネル制御などの制御プロトコルのデータ構造、シーケンスについて定義している。

4.2 Talkware 概要
Talkware は、性能・使いやすさの向上したパソコンと、これらを相互に接続する PC-LANの普及を背景として、

 LAN を利用した電話 画面を共有しながらの対話 相手不在時の音声メールによる伝言
 マルチメディアの同期技術を利用したボイスアノテーション (音声注釈)
 ゲートウェイを介した既存電話システムとの相互接続等の機能の提供を目的として (株) 日立製作所と (株) 日立インフォメーションテクノロジーが開発した IP 電話システムである。

第 15 部

インターネット と他の通信メディアの融合

図 4.3: Talkware システム構成図

図 4.4: Talkware カード

505

1997 年度 WIDE 報告書506

図 4.5: Talkware クライアント一式

4.2.1

構成

Talkware は次の大きく二つの製品から構成される。
(1) Talkware クライアント
ネットワーク経由で Talkware クライアント同士、および 、後述の Talkware ゲート
ウェイ経由で一般の電話機と接続して通話する。一般のデスクトップ PC あるいは
ノート PC に専用のハード ウェアを接続して、専用のソフトウェアにより実現する。
ハードウェアは音声信号を A/D 、D/A 変換、および、圧縮、伸長をおこなう CODEC
チップを搭載した ISA バス用 Talkware クライアントボード、CODEC 機能とネットワーク機能の二つの機能を搭載した Type-II PC カード の Talkware カード の二種類を提供している (図 4.4参照)。
音声入出力には、これらのハードウェアに専用アダプタをつなぎ 、ハンドセット、ヘッド セット等を接続し 、一般の電話機と同じ使い勝手が得られる (図 4.5参照)。
また、ソフトウェアは、Talkware VCM(Voice Communication Manager) を使用する
事により、プッシュボタン式電話機の GUI で電話をかけることができ、同時に電話
帳機能、音声メイル機能、ボイスアノテーション機能が利用できる (図 4.6参照)。

(2) Talkware ゲートウェイ

第 15 部

インターネット と他の通信メディアの融合

図 4.6: Talkware VCM

507

1997 年度 WIDE 報告書

508

IP 網と電話網の両方に接続し、両者の間で Call Signaling の中継、音声の中継を行う。
一般の PC に専用のハード ウェアを接続して、専用のソフトウェアにより実現する。
ハードウェアは CODEC チップ、および、電話網側の回線制御用チップを搭載したフルサイズの ISA バス用 Talkware ゲートウェイボードを提供している (図 4.7参照) 。

図 4.7: Talkware ゲートウェイカード
ボードのへのインタフェースはアナログ 2 線の電話機インタフェースで、PBX や交換機側からは普通の電話機として扱えるように設計されている。
ソフトウェアは、ネットワーク側からは Talkware クライアントとして扱えるように設計されており、管理者用モニタ機能、電話帳機能、音声ガ イダンス機能を提供する。また、製品版にクライアントの IP アドレス入力機能、TPC.INT 方式による接続先ゲートウェイ決定機能を付加する拡張キットも存在する。

4.3 WIDE 秋合宿での Talkware を用いた RSVP 評価実験
4.3.1

目的

1997 年 9 月 2 日〜 5 日に静岡県浜松市で開催された WIDE 秋合宿において、RT-Bone
WG と itel WG(1997 年 9 月で活動終了し wt-wg に吸収合併) の共同で、Talkware を用いて RSVP による帯域予約が音声通信に与える影響について評価実験を行った (図 4.8参照)。

第 15 部

インターネット と他の通信メディアの融合509

図 4.8: 実験風景

4.3.2

方法

(1) 実験環境
実験環境のおおまかな構成は、研究会会場と慶應義塾大学 SFC の間を専用線 (地上回
線、衛星回線) で結び、RSVP に対応した CISCO 製ルータを用いて接続する。CISCO
製ルータに接続されているセグメントに NTT データ通信 (株) 提供の RSVP proxy を設置する。会場に帯域予約ありおよび帯域予約なしの 2 台の Talkware クライアントを用意し 、慶應大 SFC に設置されている Talkware ゲートウェイと接続し 、Talkware
クライアント−電話機接続で会話する (図 4.9参照)。

Talkware クライアントおよび Talkware ゲートウェイはいずれも RSVP をサポートしていないため、RSVP proxy が帯域予約ありの Talkware クライアントの通信トラ
ヒックを検知すると代理で RSVP メッセージを送信し 、会場の Talkware クライアン
トと慶應大 SFC の Talkware ゲートウェイとの間の専用線に帯域を確保する (図 4.10
参照)。
(2) 評価方法
被験者に帯域予約ありの Talkware クライアントと帯域予約なしの Talkware クライ
アントを用いて慶應大 SFC に設置してある Talkware ゲートウェイ経由で電話をかけてもらい、実際に会話をしてもらい、最後にアンケートの質問項目に回答してもらう。今回使用したアンケートの質問項目は図 4.11のとおりである。

510

1997 年度 WIDE 報告書

図 4.9: 実験環境の構成

第 15 部

インターネット と他の通信メディアの融合

511

図 4.10: RSVP proxy(右側の PC) と実験風景

4.3.3

結果と考察

実験期間中 (9 月 2 日 21:00 頃〜 5 日 8:30 頃) に 50 人以上に被験者となってもらった。今回の実験では、資源予約した Talkware クライアントとしていないものの 2 台を用意し 、自由に使用してもらってアンケートを記入してもらった。そして、44 枚の回答が得られた。
その回答の内訳は表 4.1のようになっており、全体のおよそ 3 分の 2 が資源予約した方のTalkware クライアントを使用していた事がわかる。
表 4.1: アンケート結果
回答
資源予約した方
資源予約しない方
未記入
合計

人数
28 人
14 人
2人
44 人

資源予約の有無により音質にどのような影響を及ぼすかを分析する。図 4.11のアンケー
トの音質に関する項目について、資源予約ありとなしの各々の場合で集計した結果、表 4.2

1997 年度 WIDE 報告書

512
Q0:

簡単に名前と所属をお願いします。

Q1:

電話をかけたのは 9 月何日何時何分ごろですか?

Q2:

電話をかけた時ネットワークは混んでいましたか?

3 すかすか3 ふつう
3 まっくろQ3:

ど ちらの talkware を使用しましたか?

3 資源予約した方
3 していない方
Q4:

talkware の圧縮方式はどちらですか?

3 16k ADPCM
3 32k ADPCM
Q5:

音質についてお聞きします。

Q5.1:

会話はできますか?

Q5.2:

相手は誰かわかりますか?

Q5.3:

ノイズが気になりますか?

Q5.4:

遅延は感じますか?

Q5.5:

普通の電話と比べて音質は?

Q6:

1 できない1 なんとかできる
1 できる

1 わからない
1 なんとかわかる
1 わかる
1 とても気になる
1 少し気になる
1 気にならない
1 感じる
1 少し感じる
1 感じない
1 わるい
1 同じ
1 良い

Q3 で資源予約した方の talkware を使用した人にお聞きします。

Q6.1:

合宿中に資源予約しない方の talkware も使いましたか?

Q6.2:

Q6.1 で Yes と答えた場合、資源予約の効果を体感できましたか ?

Q6.3:

Q6.2 で Yes と答えた場合、具体的に何が改善されましたか ?

1 Yes
1 No

1 Yes
1 No

1 ノイズが減った
1 遅延が小さくなった
1 音質が良くなった
1 その他

図 4.11: アンケート項目

第 15 部

インターネット と他の通信メディアの融合

513〜 4.6 に示すような結果となった。
表 4.2〜 4.6 のいずれの結果をみても、資源予約なしの場合よりも資源予約ありの場合の方が、状況が改善されている事がわかり、RSVP による音質改善の効果があるといえる。
また、表 4.6 では、いずれの場合も一般の電話の音質と同等かそれ以下という結果となった。これは、資源予約の有無の結果ではなく、Talkware で使用している CODEC 方式によるところが大きい。一般電話では 64kbps PCM 相当の品質であるのに対し 、今回の実験で使用した Talkware では 32kbps あるいは 16kbps の ADPCM を使用して会話していたからである。したがって、仮にネットワークによるパケットロス、遅延等がなくとも一般電話の品質以上にはならない。しかし 、携帯電話、特にデジタルのハーフレートのものよりは音質が良い、との意見もあった。
また、資源予約によって、具体的にどのような内容が改善されたか調査した結果、表 4.7に示すように、「ノイズが減った」、「音質が良くなった」とする意見が多かった。しかし 、遅延が小さくなったという意見は少なかった。

4.3.4

まとめ

以上の結果をまとめると、RSVP による資源予約の有無の二つの条件の下で、リアルタ
イム音声通信を行うアプリケーションとして Talkware を用いて音声通信してもらう実験をおこなった。そして実験後、アンケート調査した結果、資源予約が音声品質の改善に効果があるということがわかった。
今後の課題としては、

 今回のアンケートは通話品質の主観的評価が中心となっているが、客観的な評価評価
方法についての調査、検討を今後おこなう。

 WIDE バックボーンを用いて Talkware による WIDE 内線の実現と評価実験を予定しており (1998 年度に実施予定) 、それに向けて評価方法、アンケート項目などにつて再検討する。

最後に、今回の実験の準備段階から協力して下さった RT-Bone WG の方々、そして、実験に快く協力して下さった WIDE 合宿参加者の方々に感謝いたします。

514

1997 年度 WIDE 報告書
表 4.2: Q5.1 「会話はできますか? 」

Q5.1
資源予約あり資源予約なしできない

なんとかできる

できる

その他

|
35.7 %

46.4 %
42.9 %

42.9 %
21.4 %

10.7 %|

表 4.3: Q5.2 「相手は誰かわかりますか? 」

Q5.2
資源予約あり資源予約なしわからない

なんとかわかる

わかる

その他

3.6 %
7.1 %

28.6 %
64.3 %

64.3 %
28.6 %

3.6 %|

表 4.4: Q5.3 「ノイズが気になりますか? 」

Q5.3
資源予約あり資源予約なしとても気になる

少し気になる

気にならないその他

25.0 %
71.4 %

57.1 %
28.6 %

17.9 %|||

表 4.5: Q5.4 「遅延は感じますか? 」

Q5.4
資源予約あり資源予約なし

感じる

少し感じる

感じない

その他

14.3 %
28.6 %

21.4 %
42.9 %

42.9 %
28.6 %

21.4 %|

表 4.6: Q5.5 「普通の電話と比べて音質は? 」

Q5.5
資源予約あり資源予約なし

わるい

同じ

よい

その他

67.9 %
78.6 %

32.1 %
21.4 %||||

第 15 部

インターネット と他の通信メディアの融合

表 4.7: 資源予約による改善の効果
回答 (複数回答)
ノイズが減った
音質が良くなった
遅延が小さくなった
その他

人数
12 人
8人
1人
3人

515

第

5章

電話網とインターネット を融合した通信インフラス
ト ラクチャの今後
本節では「電話網とインターネットを融合した通信インフラストラクチャの整備」の今後の予定を述べる。

5.1

実験について現在、前述のインターネット電話モデルの検証として、実際のインターネット上で (株)日立製作所と (株) 日立インフォメーションテクノロジーのインターネット電話システム、
Talkware[163] の改造機を用いて、国内 3 箇所、米国内 1 箇所の計 4 点にゲートウェイを設置し 、実験をすすめている。
このゲートウェイの設置個所を 98 年度は増設し 、さらに実験を進めていく。
また、tpc.int 型や LDAP といった分散データベースの実用性の検証、経路の状態を考慮した最適化ゲートウェイの発見実験、PSTN 電話番号空間とインターネット上での名前空間との対応付け方式の検証などの実験を予定している。

5.2

おわりに

実験のほかにも、スケーラビリティなどについて考察をすすめる必要がある。また、インターネット FAX への応用も実験を含めて行い、IETF への提案等も考慮していきたい。

516

第

6章

電話網とインターネット を融合したインタフェースの構築

6.1 WIDE/PhoneShell の現状
東工大の大野を中心にして PhoneShell ワーキンググループで開発されてきた WIDE/PhoneShell
は、公衆電話網とインターネットとの橋渡しを実現するシステムである。1990 年に開発が始められた WIDE/PhoneShell は 、当初ネットワーク管理の支援を主な目的としていた。
WIDE/PhoneShell ではプッシュホンをインタフェースとして用い、計算機の操作を電話網経由で行なう。このためシステム管理者はネットワークを経由せずに遠隔地から計算機の管理作業を実施可能で、ネットワーク障害時でも管理作業に支障をきたさない。
その後 1995 年から行なわれた拡張による Poshdutil 等の導入によって、WIDE/PhoneShellを用いたアプリケーションの開発が容易になった。また 1996 年には一般的な Voice FAX
モデムの音声制御機構を扱えるような拡張がなされた。これによって、それまで用いていた PNC-3500 だけでなく、Voice FAX モデムも電話回線制御機器として本格的に利用できるようになった。これらの結果として、WIDE/PhoneShell は電話をインタフェースとしたさまざまなサービスの開発環境としても注目されはじめた。たとえば視覚障碍者用の計算機インタフェースとしても注目を集めている。
しかし、開発をすすめる過程で問題点もあきらかになった。これまでの WIDE/PhoneShell
は、利用者との入出力に主に DTMF を用いることを想定していていた。しかし多様なサービスを実現するためには、音声や FAX データの取り扱いも必要となる。これまで音声やFAX データを取り扱う際には外部のプログラムを併用していたが、これらのデータの扱いも統合する必要がある。そこで、FAX や音声などのストリームデータを扱うことを考慮にいれて、WIDE/PhoneShell 全体の設計見直しを行なった。次節では 1996 年度から行なっている Rockwell 系 Voice FAX モデムへの対応と、1997 年度に行なった FAX, 音声を取り扱うための拡張について述べる。
さて昨今 InternetFAX の標準化やインターネット電話の標準化策定動向などが 、話題になっている。WIDE プロジェクトが自らの実装を持ってこれらの標準策定作業、相互接続性検証などに積極的に臨むためには、実装プラットホームを整備する必要がある。wt-wg

517

1997 年度 WIDE 報告書

518

では、WIDE/PhoneShell をこのような実装プラットホームととらえ、WIDE/PhoneShellを用いたアプリケーション開発環境を整備した。この WIDE/PhoneShell を活用した電話サービス開発プラットホームパッケージ (以下 WIDE/PhoneShell ボックス) に必要なハード ウェア仕様については次節で述べることにする。

WIDE/PhoneShell ボックスを用いたアプリケーションとして、インターネット防災訓練
での IAA システムに対するインタフェースや電話インタフェースを用いた計算機管理シス
テムなどが開発されている。次章では主にこれらの応用事例について述べる。応用事例のなかには、WIDE/PhoneShell ボックスを用いていないものもあるが、「電話網とインターネットを融合したインタフェースと」の応用事例としてここで取り上げることにした。それらと同等のシステムを WIDE/PhoneShell ボックスの上に実装し 、相互接続性を検証することは今後の課題として挙げておく。

6.2 WIDE/PhoneShell の拡張
本節では、ボイス FAX モデムを利用した、WIDE/PhoneShell の拡張について述べる。

6.2.1

背景

WIDE/PhoneShell は、DTMF を利用して電話網とインターネットとの間で情報のやりとりを行う機能を持つ。しかし 、インターネットと電話網の間で FAX の送受信をするには、Hylafax([164]) など 、他のツールを必要とする。また、インターネットと電話網の間で音声の送受信をするには、コンピュータのオーディオデバイスを制御するツールが必要である。

WIDE/PhoneShell 単独で音声や FAX を利用できないのは、WIDE/PhoneShell で当初から利用している NCU(PNC-3500) の機能に由来するものである。
PNC-3500 には、モデムとしての機能はないため、音声や FAX 画像を送受信できない。
以下に PNC-3500 の機能を示す。

 電話回線の制御
 DTMF の送受信
 音声のミキシング
AT モデムを利用すれば 、FAX の送受信、DTMF の送信は可能であったが、DTMF の受信や音声の再生ができないなど 、機能が不足しており、WIDE/PhoneShell では利用していなかった。

第 15 部

6.2.2

インターネット と他の通信メディアの融合

519

拡張方針

近年普及しつつある音声機能を拡張した Rockwell 系の ボ イス FAX モデムを利用すると、モデムとしての機能の他に、音声の録音や再生、DTMF の送受信が行える。そこで、現在利用している PNC-3500 でななく、ボイス FAX モデムを利用し 、WIDE/PhoneShell
単独で音声や FAX 画像を送受信できるように拡張する。
拡張の方針を以下に示す。

 Voice FAX モデムの NCU 機能を利用して、電話回線の制御を行う
 Rockwell 系ボイス FAX モデムの音声拡張機能を用いて、音声の録音や再生を行う
 ボ イス FAX モデムの FAX 送受信機能を用いて、FAX の送受信を行う
また、この拡張作業は以下のようなスペックのマシンで行った。

 PCMCIA スロットを利用可能なノート PC
CPU Pentium 120MHz
Memory 48MBHDD 2.1GB OS

BSD/OS 3.0

 ボ イスモデム

NTT-IT Thunder Card または、TDK DATA VOICE 3400

 ネットワークカード

ne2000 互換のイーサネットカード

次節から、WIDE/PhoneShell の拡張を AT モデムへの対応と機能の追加に分けて説明する。

6.2.3

AT モデムへの対応

WIDE/PhoneShell を開発し始めたころの AT モデムの機能は、音声の録音や再生、DTMFの受信機能を持たなかったため、WIDE/PhoneShell の目指す機能を実現するには力不足であった。そのため、WIDE/PhoneShell は AT コマンドに対応してはいたが、AT モデム
を使って運用することはほとんどなかった。当時 AT モデムでは実現できなかった部分をRockwell 系ボイス FAX モデムの音声拡張コマンド [165] を 用いて実現した。
WIDE/PhoneShell の主要部分は、wncud、ncumond、in.poshd 、libposh.a 、クライアン
トプログラムからから構成される (図 6.1) 。まず、in.poshd が wncud に送る命令を AT モ

1997 年度 WIDE 報告書

520

結果

Client命令
着信の通知

in.poshd

命令

ncumond

結果

wncud

制御
監視
NCU

公衆電話網

図 6.1: WIDE/PhoneShell の構成

機能
ダ イアル
オフフック
オンフック
DTMF の送信

PNC-3500
CRN01234567
OFH
ONH
PTTabc123

ボ イス FAX モデム

ATD[TP]01234567
ATH1
ATH0
AT#VTS=a,b,c,1,2,3

表 6.1: PNC-3500 とボイス FAX モデムのコマンド 比較

第 15 部

インターネット と他の通信メディアの融合

521

デムコマンドに対応させた。実際にはダイアルコマンド、オフフック、オンフック、DTMFの送信等を AT モデムのコマンド へ変更した (表 6.1) 。
ncumond は、wncud が NCU に送るコマンドを元に NCU の状態を推定している。wncud
が NCU に送るコマンドを AT コマンドに変更したため、AT コマンドを元に NCU の状態を推定するように ncumond を変更した。
以上の作業で、以前から用いられている PNC-3500 を利用した場合と同等の機能を持つようになった。

6.2.4

音声への対応Rockwell 系の voice FAX モデムの音声拡張機能を利用して、音声の録音、再生を行っている。
音声を録音、再生する機能を wncud に導入した。
WIDE/PhoneShell では、シリアルデバイスにデータを書き込む際に sgttyb 構造体を利用していたが、以下に示す問題が明らかになった。

 19200bps 以上の DTE 速度が設定できない。
 フロー制御ができない
以上の問題を解決するために termio を利用した。再生の手順を以下に示す。

1. ボイスモデムを音声モードにする
2. サンプリングレート 7200Hz に指定する
3. 量子化数を 4bit に指定する
4. 音声の再生先を電話回線に指定する
5. 音声データをファイルから読み込み、モデムに書き込む
次に録音の手順を示す。

1. ボイスモデムを音声モードにする
2. サンプリングレート 7200Hz に指定する
3. 量子化数を 4bit に指定する
4. 音声の録音元を電話回線に指定する
5. 音声データをモデムから読み込み、ファイルに書き込む
また、音声の録音、再生中に DTMF の検出を行っている。録音、再生する音声のフォー
マットは Rockwell ADPCM 4bit サンプリングレート 7200Hz である。音声のコンバートは mgetty 付属のソフトを使っている。

1997 年度 WIDE 報告書

522
6.2.5

FAX への対応

AT モデムの FAX 送受信機能を用いて FAX の送受信を行う。FAX の送信手順を以下にしめす。

1. FAX モードに切り替える
2. パラメータを設定する
3. データをファイルから読み込み、モデムに書き込む
送信する FAX のイメージは ghostscript を利用して生成を行っている。FAX の受信の手順は以下の通りである。

1. FAX モードに切り替える
2. パラメータを設定する
3. データをモデムから読み込み、ファイルに書き込む
Hylafax 等既存の FAX 送受信ツールと同様なアプローチで実装を行ったため、詳細はここでは述べない。

6.2.6

音声、FAX の利用方法

音声、FAX の送受信を行うには、表 6.2コマンドをクライアントプログラムから、in.poshd
へ送る。

機能
音声の再生
音声の録音
FAX の送信FAX の受信コマンド!play voice le!rec voice le!fax send le!fax receive le

表 6.2: 音声、FAX 機能の利用方法

6.2.7

今後の展開

今回の実装では、音声、FAX の機能を wncud に組み込んだ。その結果以下に示す問題が生じた。

第 15 部

インターネット と他の通信メディアの融合523

 in.poshd やクライアントプログラムから wcud がすべて同一のホストで動かす必要がある。

 クライアントプログラムから FAX 機能や音声機能を利用しにくい wncud が複雑化した以上に示した問題点を解決するために、以下のように設計を見直す必要がある。

 wncud を単純化するために拡張した機能の一部を in.poshd に移す。
 in.poshd と client 間で、DTMF とコマンド の通信経路を分ける。
 wncud と in.poshd が別々のホストで動作する場合を考慮して、wncud と in.poshd の間に音声ファイルや FAX イメージの転送機能を足す。

 クライアントプログラムから FAX や音声機能を利用するための API を作成する。

第7章

電話網とインターネット を融合したインタフェース
の構築事例

7.1

電話を用いたインタフェース

wt-wg の活動の一環として、IAA システムのための電話を用いた登録・検索インタフェー
スの設計実装を行った。IAA システムとは、lifeline ワーキンググループで開発されている
披災者情報登録システムである。

7.1.1

背景

lifeline ワーキンググループでは、インターネット災害訓練を行っおり、その一部として、被災地の生存者情報を伝えるためのシステム、IAA システムを構築してきた。IAA システ
ムは被災者の生存情報をインターネット上のデータベースに被災地から登録し 、被災地外からの検索を可能にするシステムである。しかし 、実際の災害時に IAA システムを利用する場合、以下に示す問題がある。

 コンピュータを利用できる保証はない
 十分な数のコンピュータを確保できる保証はない 電源やインターネットへの接続性を確保できる保証はない コンピュータを利用して生存者情報を登録・検索するのに十分な知識があるとは限らない
そのためコンピュータを利用しない生存者情報データベースへのアクセス手段が必要となる。
本報告ではコンピュータを使わずに生存者情報を登録する方法として、公衆電話網から生存者情報にアクセスするテレフォンサービスについて述べる。

524

第 15 部

7.1.2

インターネット と他の通信メディアの融合

525

設計

公衆電話網から被災者情報を登録する方法として、音声認識を利用して電話から生存者情報を登録する方法が考えられる。しかし 、電話の音声は必ずしも明瞭ではなく、災害時であることを考えると周辺の騒音も大きいことが予想される。しかも、不特定多数話者の音声認識になるので現状では簡単には実装できない。
そこで、ほとんど全ての電話で利用可能なタッチトーンを利用して登録する方法を採用した。
また、検索結果の読み上げは困難であるので、FAX を利用して検索結果を送信する。

7.1.3

登録システム

電話の音声ガイダンスにしたがってタッチトーンで生存者情報を登録するためのシステムである。このシステムを利用するとコンピュータなしで、IAA データベースに生存者情報を登録できる。登録可能な情報は、
「氏名」
「年齢」
「性別」
「郵便番号」「本人の状態」である。文字情報である氏名は , ページャへ仮名文字を送信する方法を利用して登録する。
このシステムは拡張した WIDE/PhoneShell を用いて実装され、テレフォンサービス部とデータベースアクセス部から構成される。以下にそれぞれの部分の機能について述べる。

 テレフォンサービス部{ WIDE/PhoneShell を利用して音声ガ イダンスを行う{ WIDE/PhoneShell を利用して利用者の入力した DTMF を認識する{ 利用者の入力した DTMF を生存者情報へ変換する{ 生存者情報をデータベースアクセス部へ送る

 データベースアクセス部

テレフォンサービス部から送られた生存者情報を IAA データベースへ送る。

7.1.4

検索システム

電話の音声ガイダンスにしたがって、タッチトーンを利用して検索に必要な情報を入力
し 、検索結果を FAX で受信する。入力可能な情報は「氏名」
「年齢」
「性別」
「郵便番号」とし 、文字情報である氏名は、ページャへ仮名文字を送信する方法を利用して登録する。このシステムは、拡張した WIDE/PhoneShell を用いて実装され、テレフォンサービス部とデータベースアクセス部から構成される。以下で各部分の説明を行う。

 テレフォンサービス部{ WIDE/PhoneShell を利用して音声ガ イダンスを行う

1997 年度 WIDE 報告書

526{ WIDE/PhoneShell を利用して利用者の入力した DTMF を認識する{ 利用者の入力した DTMF を生存者情報へ変換する{ 生存者情報の問い合わせをデータベースアクセス部へ送る{ データベースアクセス部からの検索結果を整形し 、WIDE/PhoneShell を利用して FAX で送信する。

 データベースアクセス部{ テレフォンサービス部が送られた生存者情報を IAA データベースへ送る。
{ IAA データベースからの検索結果をテレフォンサービス部へ送る。
7.1.5

運用結果

1998 年 1 月 17 から 18 日に行われたインターネット災害訓練でこのシステムを運用した。運用結果等については lifeline ワーキンググループの報告を参照してもらいたい。

7.2 FAX を用いたインタフェース
7.2.1

概要

lifeline ワーキンググループで構築している IAA システムの安否情報データベースの FAX
ユーザインタフェースを提供したので、ここに報告する。これは FAX を用いて災害時生存者安否情報を登録するものであり、今回は InternetFAX のプロトコルを使い構築した。
この機構は、FAX で送られてきた情報（画像データ）を IAA データベースに登録できるように、OCR や OMR 技術を利用し 、計算機の取り扱えるコード 情報に変換する。
また、OCR/OMR 部分は InternetFAX のプロトコルで画像データを入力するネットワー
ク装置、OCR/OMR BOX として構成した。このことにより、より汎用性の高い装置となった。
なお、通常の FAX からの画像情報は、InternetFAX により、InternetFAX プロトコルに変換され、、入力するデータにまとめられる。

7.2.2

OCR/OMR BOX

OCR/OMR BOX では、InternetFAX のプロトコルで、画像データの通信をする。
従来の OCR や OMR は、システムに組み込まれた物がほとんどであり、他のシステム
から認識処理を利用するのは困難であった。そこで本システムでは、OCR や OMR の機能
をネットワーク上の独立した装置とすることで、多くの機器からの認識処理の利用を容易におこなえるようにした。

第 15 部

インターネット と他の通信メディアの融合

527

文字認識の処理には、CPU のパフォーマンスを多く要求される場合が多く、今までのシステムでは、処理速度を向上させるには、システム全体を変更する必要があった。しかし 、本システムでは、ネットワーク上に OCR や OMR の利用できるシステムを複数置き、分散処理をおこなうことで、処理速度の向上を期待できる。コストの面では、特殊なオペレー
ティングシステム上に構築することにより、不必要なプログラムが動作せず、パフォーマ
ンスの悪いコンピュータでも利用でき、安価に構成することができる。
また、本システムは、入力データとして、InternetFAX の画像フォーマットをサポートする。そのため、電子メールサーバのスプール機能や転送機能を活用し 、処理を分散でき、
OCR/OMR BOX への負荷を減らせる。
また、入力データをキューイングすることで、低コストのシステムを構築し 、運用できる (図 7.1)。
第３回インターネット災害訓練では、IAA システムにおける FAX を用いた登録システ
ムとして、このシステムを使い、訓練に参加した。
また、この OCR/OMR BOX の応用として、WIDE プロジェクト 1998 年春合宿にて、トラブルチケットシステムの文字認識システムとしての運用実績を持つ。
今後、このシステムを、さまざまな利用形態に対応し 、自由に画像や文字認識を利用できるシステムに展開していく。

Fax

Fax

InternetFAX

Mail ServerLAN

OCR/OMR BOX
図 7.1: OCR/OMR BOX の分散処理1997 年度 WIDE 報告書

528
CPU
MemoryHDD
NICIntel 486 以上
8MB 以上500MB 以上
NE2000 互換または、3com Etherlink III

表 7.1: OCR/OMR BOX の必須ハードウェア

7.3

情報ボランティアによる登録内容確認システム

FAX を用いてインターネット上のデータベースに情報を登録するには、FAX のデータを機械可読のデータに変換する必要がある。この作業を人間がすべて行なうと、手間がかかる上に変換ミスが生じる場合がある。また、機械のみを用いて変換すると、人間であれば認識できる文字が認識できない、誤認識に気づかないなどの問題が生じる。

wt-wg では 、人間と機械の協調作業をモデル化し 、第三回インターネット災害訓練で、FAX データを IAA データベースに登録する際の情報ボランティアによる登録内容確認シ
ステムを構築した。
本節では、このシステムの概要および第三回インターネット災害訓練への応用事例を述
べる。

7.3.1

システムの設計

このシステムは情報入力部、情報認識部、情報協調部の三部から構成される。(図 7.2)

情報入力部

情報協調部

IAA

FAX

情報認識部

図 7.2: 被災者情報登録システムの概要

第 15 部

インターネット と他の通信メディアの融合

529

A. 情報入力部
情報入力部は、紙に記述された手書きの被災者情報を情報認識部が処理できる機械可読の形式に変換する。(図 7.3)

インターネットFAX

FAX

FAX画像

情報認識部
PSTN

Internet
情報入力部

図 7.3: 情報入力部

B. 情報認識部
情報認識部は、入力画像を、情報入力ボランティアが情報の修正やチェックを行いやすい形式に変換する。(図 7.4)
変換を行う際、情報認識部は OCR を用いて紙に書かれた文字を認識し 、OMR を用いて文字の位置を把握する。

情報認識部

FAX画像
OMR

成功

OCR
情報協調部

失敗

図 7.4: 情報認識部

状態

(a)
(b)
(c)

人間の支援
全データを入力
一部データを入力
入力データのチェック

モード
文字認識失敗モード
文字修正要求モード
承認要求モード1997 年度 WIDE 報告書

530
状態

(a)
(b)
(c)

ボランティアに提供されるデータ
FAX の画像一枚
複数の FAX 画像と、それに対応する一部の文字
複数の FAX 画像と、それに対応する文字

C. 情報協調部
情報協調部は、ボランティアによる情報の入力をサポートするためのインタフェースを提供する。情報協調部は三部から構成され、それぞれ情報の形式が異なる。

(a) 情報の切り出しに失敗した場合、システムはボランティアに一枚の FAX 画像を提供する。ボランティアは FAX 画像を見ながら必要な情報をすべて入力する。
(b) 情報の切り出しに成功した場合、システムはボランティアに、項目ごとに切り出された画像を提供する。また、もし切り出された画像に対応する文字が認識できていれ
ば 、その情報も提供する。ボランティアは切り出された画像を見ながら情報を入力する。

(c) 情報の認識に完全に成功した場合、システムはボランティアに、項目ごとに切り出された画像と、それに対応する文字を提供する。ボランティアは切り出された画像を見ながら認識情報が正しいかど うかチェックする。
各情報は、ボランティアの操作により他の状態へ移動する場合やデータベースへ入力される場合がある。(図 7.5)
情報認識部
WWWサーバ

全て入力が必要

2
WWW
クライアント

一部修正が必要

承認が必要
5
IAAシステム
データベース

図 7.5: 情報協調部

7.3.2

2
WWW
クライアント3
4

WWW
クライアント1

システムの実装

本節ではシステムの実装について述べる。

第 15 部

インターネット と他の通信メディアの融合

531

A. 情報入力部
情報入力部には、PSTN からの FAX 情報をインターネットに転送できる、松下電送シス
テム製の UF-770i を使用した。情報入力部から情報認識部へのデータ転送には SMTP を用いた。安否情報の登録に用いる登録用紙を図 7.6に示す。

図 7.6: IAA 情報登録用紙

B. 情報認識部
情報認識部では以下の動作を行う。

1. 情報入力部からの画像を FAX で受ける。
2. 画像情報を OCR/OMR で認識する。
3. 認識した情報を情報の種類に応じて分割する。
4. 認識した情報を情報協調部に lpd プロトコルを用いて送信する。
C. 情報協調部
情報協調部では以下の動作を行う。

1997 年度 WIDE 報告書

532

1. 情報認識部からのデータを Perl スクリプトを用いて HTML に変換する。
2. ボランティアが、CGI スクリプトを利用して各情報をチェックし修正する。
3. ボランティアが、登録された情報をチェックし承認する。
4. IAA データベースシステムに情報を登録する。
インタフェースは、情報認識部の認識結果により異なる。

 情報認識部の認識結果が文字認識失敗モード の場合、画像一枚と入力用 CGI が提供される。

 情報認識部の認識結果が文字修正要求モードの場合、項目ごとに切り出した画像と入力用 CGI が提供される。

 情報認識部の認識結果が承認要求モード の場合、画像一枚と確認要求用 CGI が提供される。
今回我々は、悪意を持つ第三者の影響を防ぐため、情報協調部が提供するページをパス
ワードによりプロテクトした。

7.3.3

インターネット 災害訓練におけるシステムの運用結果

システムを運用した結果、12 件の安否情報が登録された。
登録数
文字認識成功文字認識失敗6
6

この認識結果は比較的悪い値である。
認識に失敗したデータをチェックした所、画像が 10 ％縮小していた。しかし我々は人間と機械を仲介するインタフェースを提供していたため、データの登録は問題なく行われた。
次に、三種のインタフェースについてそれぞれ情報処理にかかった平均時間を調査した。
モード
文字認識失敗モード
文字修正要求モード
承認要求モード

平均処理時間 [秒]

119.8
74.2
14.1

記入欄の切りだしが成功している場合の方が、情報処理にかかる時間が 45.6 秒はやい。

第 15 部

7.3.4

インターネット と他の通信メディアの融合

533

今後の課題とまとめ

wt-wg では、FAX と OCR/OMR を用いて被災者情報の登録に適したシステムを提供した。FAX を用いることにより、インターネットを直接利用できない人でも被災者情報を登録できた。また、情報処理の効率を向上させるため、人間と機械がインターネット上で効果的に協調するための仕組みを提供した。
今回参加した実験は、インターネット上における人間と機械の協調作業モデルの一つであり、今回実装したシステムはモデルのシステム化の一事例に過ぎない。今後このシステ
ムの実験を重ね、システムのインタフェース向上をはかる。また、さまざまな協調作業をモデルに当てはめ、その協調作業を支援するシステムを構築し評価する。さらに、モデルを記号化して入力することで、システムを自動的に構築し協調作業を支援できる汎用的なシステムの構築を目指す。

7.4

さまざまなアクセス手段を備えたルータ運用支援機構

7.4.1

はじめに

コンピュータネットワークの規模が大きくなるにつれ、ネットワークに接続される機器も増加している。これに伴いネットワークの管理作業も増加し 、管理者への負担を増大させている。ネットワークの管理が管理者に与える負担の主な要因と次の 2 点で挙げられる。
1 つは、ネットワーク構成機器が多様化と管理対象が増加の結果としてネットワーク管理に幅広い知識が求められようになったことで、もう 1 つはネットワーク管理手段がネットワークに依存したものに限られていることである。そこで、この 2 つの問題点を改善するためのシステムを提案し 、NIIS(Network Information Integrated Support) システムと名付けた。この節では、NIIS システムの設計と実装、およびその利点について述べる。

7.4.2

ネット ワーク管理の負担

最初にネットワーク管理の負担を増大させている原因について考察し 、その解決方法を提案する。

1. 管理作業の複雑化 現在のインターネットはさまざまな機器を用いた構成され、また管理ツールと称してさまざまなアプリケーションプログラムが用いられている。しかしそれらの操作法や設定方法が機種ごとに違うために、管理者には多くの知識と経験が要求される。

2. ネットワーク管理手段の不足 現在のネットワーク管理手段の多くが、「ネットワーク管理をネットワーク経由」で行うことを前提としている。このようなネットワーク管理
手段は、ネットワークが正常に機能していて、管理者や管理プログラムが管理対象の

1997 年度 WIDE 報告書

534

計算機に到達できるときには設計どおりの能力を発揮するが、ネットワークに障害が発生し 、目的の計算機に到達できない状況では管理できない。
第 1 の問題点を解決する方法の一つとして、" システムをどのように運用していくか " について記述方法を定め、これに基づいてさまざまなネットワーク機器を管理する仕組みを構築するものが挙げれられる。第 2 の問題点を解決するためには、ネットワーク構成機器
やネットワーク管理支援ツールの設定変更を、ネットワークに依存しない手段でも行える必要がある。

7.4.3

NIIS システムの設計と実装

システムの概要

NIIS システムはこれまで述べた問題点を解決することを目的としたネットワーク管理支
援システムである。NIIS システムは NIIS サーバと NIIS クライアントから構成される (図7.7)。
管理者は NIIS クライアントを用いて運用ポリシを NIIS サーバに送信する。NIIS サーバ
では受け取った運用ポリシを元に、設定すべき機器に対応する設定ファイルを生成し 、機器の設定更新する。運用ポリシとは " システムの運用方針を明確に記述したもの" として、
NIIS システムで記述法を定めたものである。運用ポリシを送信する手段としての NIIS ク
ライアントは、FAX や WWW などのさまざまな手段が提供される。
NIIS サーバ
ネットワークに接続された複数の機器は NIIS サーバにより一元的に管理される。NIIS サー
バは、クライアントから受け取った運用ポリシを設定ファイル作成部に送る (図 7.8)。設定
ファイル作成部では、運用ポリシをもとに、個々の機器や管理ツールに対応した expect[166]スクリプトに変換される。この expect スクリプトを実行することにより、設定の変更や管理情報の入手を行なうことができる。
NIIS クライアント
現在検討されている NIIS クライアントは WWW 、端末インターフェイス、電話、その他のインタフェイスを用いたものである。

WWW クライアント WWW クライアントは CGI1を利用している。フォームにデータを入力することにより、運用ポリシを記述し 、NIIS サーバにデータを送る。

端末クライアント 文字端末から利用するための、shell や emacs 上から起動できる文字型
クライアントがある。また telnet を使用することでも、文 字端末から NIIS サーバを利用できる。
1 Common Gateway Interface

第 15 部

インターネット と他の通信メディアの融合

端末からの
アクセス

ルータ
ルータ

PC
telnetアクセス制御LANNIISサーバ

公衆電話網

インターネット

TEL

Web

電話やFAXなどからのアクセス

WWWからのアクセス

図 7.7: システム構成

TEL

web

expect

運用
ポリシ

スクリプト

設定
ファイル
作成部

expectPC

expectPC

expectルータ

PC

図 7.8: NIIS サーバ

535

1997 年度 WIDE 報告書

536

電話クライアント 遠隔地から NIIS サーバにアクセスするための手段として、電話を用いて運用ポリシを入力する NIIS クライアントを作成した。これを電話クライアントと呼ぶ。この電話クライアントを用いることで、ネットワークの外部から公衆電話網を介して、NIIS サーバにアクセスできる。これにより、ネットワークが分断され、遠隔地からネットワーク経由でのアクセスができない状態でも有効利用可能な通信手段を確保できた。
電話クライアントでは、ユーザからの入力は DTMF 信号2を用い、ユーザへの指示や問い合わせには音声ガイダンスを用いる。電話クライアントの内部では、ユーザからの DTMF 信号による入力を NIIS プロトコルに変換し 、NIIS サーバへ送る。また
NIIS サーバからの応答は音声ガイダンスに変換して、ユーザに送る。電話クライアントの実装には WIDE/PhoneShell[167] を利用した。
その他のインターフェイス その他に、NIIS クライアントとして FAX やページャ、電子
メールの利用などが考えられる。例えば 、本間 [168] らのシステムを用いることで、運用ポリシを紙に書いて、FAX を利用して NIIS サーバに送ることができる。これら、さまざまなアクセス手段の利用により、管理作業の負担の軽減が期待できる。

7.4.4

NIIS システムを用いたルータの運用事例

NIIS システム運用事例として、ファイアウォールの制御を取り上げる。特にファイアウォー
ルの重要な機能のひとつであるパケットフィルタリングについて運用支援を行なった。
フィルタ運用ポリシ
典型的なパケットフィルタリングの設定方式として、始点と終点のアドレス、ポート番号などを指定してパケットの通過を制限するものがある。NIIS システムではフィルタリングの運用ポリシを記述するために図 7.9のような記述事項を定めた。これをフィルタ運用ポリ
シと呼ぶ。 印を付した 6 項目は必須である。
NIIS クライアントは、入力されたフィルタ運用ポリシを NIIS プロトコルを用いて NIIS
サーバに送る。図 7.10は始点 IP アドレスの NIIS プロトコルにおける形式である。SA はアドレスが始点 IP であることを表す識別子である。
NIIS サーバでは、フィルタ運用ポリシを元にそれぞれのルータに対応した設定ファイルが生成される。図 7.11はソフトウェアフィルタリングを行なう screend に対応した設定ファイル (expect スクリプト ) の例である。
次に NIIS クライアントのうち、とくに電話を用いたクライアントについて、入力方法を述べる。
図 7.12に電話クライアントを用いる際のシステムの動作を示す。管理者が電話をかけると、WIDE/PhoneShell が電話クライアントを起動する。電話クライアントは NIIS サーバに接続し、管理者からの入力を受け付ける。管理者は電話クライアントからの音声ガイダンス

3

2 Dual Tone Multi Frequency

第 15 部

インターネット と他の通信メディアの融合

537

3 始点 IP アドレス
3 終点 IP アドレス
3 プロトコル3 始点ポート番号
3 終点ポート番号
3 許可または拒否
始点サブネットマスクアドレス
終点サブネットマスクアドレス
フィルタ設定に関する注釈
図 7.9: フィルタ運用ポリシによる指示にしたがって、入力を行う。管理者が入力した DTMF 信号は WIDE/PhoneShell
によって電話クライアントに伝えられる。電話クライアントは入力された信号列を NIIS プ
ロトコルを用いてて NIIS サーバに送信する。NIIS サーバは電話クライアントからの要求を処理し 、電話クライアントに応答する。電話クライアントは、NIIS サーバからの応答に対応した音声ガ イダンスを行う。以上の繰り返しにより、ユーザは対話的にサービスを受けフィルタ運用ポリシを記述していく。ユーザが電話を切ると、WIDE/PhoneShell は電話
クライアントに対して、終了の指示をする。指示を受けた電話クライアントは、NIIS サーバとの接続を切断したのちに処理を終了する。

SA <address><address> ::= <num> "." <num> "." <num>"."<num> "." | <*><num> ::= <d> | <d><d> | <d><d><d><d> ::= any one of the ten digits 0 through 9<*> ::= the asterisk character (ASCII code 42)
図 7.10: NIIS プロトコルの形式の例 (一部)
電話クライアントにはさまざまな利用法がある。例えば 、ユーザがファイアウォールの外部からメールを読む際に、pop3 のポートをアクセス可能にする必要がある。その場合、電話クライアントを通してフィルタ運用ポリシを記述すれば 、フィルタの設定を外部からでも容易に変更できる。従来のようにシステムにログインし 、システム管理者になってから変更する方式や、残留管理者に頼んで変更してもらう方式と比べて短時間でフィルタの538

1997 年度 WIDE 報告書#!/usr/contrib/bin/expect -f
spawn ftp $routerwhile 1 {expect {"Name*" {send "$user\r"}"Password:*" {send "$password\r"}"230*" {send "cd /etc\r"}"250*" {send "put $screend.conf\r"}"*226*" {send "bye\r";break}}}spawn rlogin $routerwhile 1 {expect {"Password:" {send "$password\r"}">"{send "ps\r";break}}}send "/tmp/find_screend.pl\r"
expect -re "/etc/screend.conf\r\r\n(.*)>"
set process_id $expect_out(1,string)
send "screend -L /var/log/screend"
send "kill -9 $process_id\r"}expect ">"send "exit\r"{

図 7.11: screend 対応の設定ファイル

第 15 部

インターネット と他の通信メディアの融合

5 クライアントからのNIISサーバ

要求を処理する電話
クライアントWIDE/PhoneShell

4 数字の並びが
NIISプロトコルに置き換えられる
6 サーバからの応答は音声ガイダンスに置き換えられる
2 WIDE/PhoneShellが

応答する
公衆電話網
12#14#2#...

3

TEL

音声ガイダンスに従って数字を入力

ユーザ

1 電話をかける

図 7.12: 電話クライアント概要図539

1997 年度 WIDE 報告書

540
変更作業を実施できる。

7.4.5

考察

NIIS システムにはさまざまなアクセス手段が用意されているため、管理者のその時々の状況に応じた最適な手段を選択し 、利用することができる。また、これらのアクセス手段に共通する特長として、入力時に設定エラーをチェックするために設定間違いが減少する
ことが挙げられる。NIIS システム全体では以下のような利点があると考えている。

 異なる種類のルータ間の設定方法の違いが隠蔽されるため、管理者は運用ポリシを記述するだけで、設定方法の違いを気にしなくてよい。

 管理機能が NIIS サーバに一元化されているので、システムの保守が容易になる。
 expect を使用することで、多様な機器の設定に柔軟に対応でき、拡張性が高い。
クライアントのうち、特に電話を用いたクライアントは以下の特長を有しているため、有用であるといえる。

 電話は広く普及しているので、利用が容易である。
 コンピュータ、PDA 等の特別な機材を必要としないのでこれらの機器を持ち歩かな
くてもよい。

 携帯電話があれば、外出先などからも管理作業ができる。仮に携帯電話がない場合でも公衆電話等から利用できる。

7.4.6

今後の課題

NIIS システムの実装、運用を進める上で、以下の課題がある。

NIIS クライアント の追加

現在のところ電話クライアント、端末クライアント、WWW クライアントが実装されている。今後さまざまなユーザインターフェイスに対応した NIIS クライアントを提供する必要がある。アクセス手段を複数用意することで、ネットワークが分断された状態でも必要最低限のネットワーク管理ができる。今後は、すでにインフラストラクチャの整っているペー
ジャ、FAX などを用いた NIIS クライアントの開発を行い、システムの可用性を高める。
NIIS システムの運用
現段階は実験段階であり、管理者の手間、単純な入力間違い、管理作業に要する処理時間
等どの程度減少するか十分な統計調査を行なっていない。実際に運用を開始するためには、十分に実験を繰り返して安定した評価を得る必要がある。

第 15 部

インターネット と他の通信メディアの融合

541

運用ポリシの抽象化
今後の展開を考えると、運用ポリシをあるレベルで抽象化することが重要である。そのために運用ポリシを記述する言語を用意する必要がある。この運用ポリシ記述言語を構成するためには、管理のために必要な事項を体系化しなければならない。

7.4.7

まとめ

電話や WWW など 、さまざまなアクセス手段を利用してネットワーク管理を支援するシ
ステムを提案した。NIIS システムにより、種々の構成機器や管理ツールを十分な設定知識がなくても、容易に運用でき管理作業を軽減できる。また、管理手法の幅が広がったこと
で、ネットワークの外からでもシステム管理が可能になり、小人数の管理者によるシステ
ム運用が可能になった。特に、電話などネットワークに依存しないアクセス手段は非常に有効である。管理者は、時間と場所にかかわらず、最も適したアクセス手段を選択できる。
現段階では、NIIS システムは screend のみに対応しているが、現在 YAMAHA や Cisco のルータなどへの対応を進めている。また、今後さまざまな NIIS クライアントの開発を行な
う予定である。

第

8章

おわりに
本報告では、wt-wg の活動を二つの視点から述べた。この二つの視点は異なったメディアを融合させていく二つの方式に対応していると考えられる。
「二つのメディアを対等に扱って相互乗り入れを図る方式」「一方のメディアから他のメディアを利用する方式」という二つである。今期は両者のアプローチから研究をすすめ、それぞれ成果をあげることができた。ここで述べた内容は 98 年度も継続して研究される。前半で述べた「電話網とイ
ンターネットを融合した通信インフラストラクチャの整備」については、日本国内へインターネット電話ゲートウェイ装置を展開した広域実験などが予定されている。また、後半の「電話網とインターネットを融合したインタフェースの構築」というテーマについては、本文中で述べた WIDE/PhoneShell ボックスを用いたさまざまなアプリケーションの開発
や、それらの相互接続実験などを行う予定である。

542