rtpDir実験終了

ここしばらく rtpDir を使って IRLP, EchoLink, Allstar Linkを1台のPCで運用してきましたが，rtpDirそのものの開発も一段落したようですので（無くなるわけではなく，これからも使えます），当局のノードも EchoIRLP に戻しました。現時点では，Asterisk も停止しています。

rtpDirとAsteriskはインストールしたままですので，いつでも再開は可能です。

EchoIRLPと言っても標準のIRLP CDからのインストールではなく，AsteriskとrtpDir用に別途インストールしたCentOS5へバックアップしておいたIRLPをリストアしています。X-Windowを動かしているので，マルチターミナルで使えますし，VNCサーバーでWindows PCからもアクセスできるので管理が楽です。

クロスリンク可能なD-STARリフレクタ

Dplusを利用したD-Starリフレクターの一つである REF004 module A が，IRLP, EchoLink, Asterisk などのアナログVoIPとのクロスリンク実験目的用として定義されたようです。

VoIP間のクロスリンクは，既にそれを可能とするソフトウェアがrtpDirを始めとして存在しますが，それぞれのVoIPシステムの運用ポリシーや，ユーザーの思惑などが絡み合い，期待されたほど進んでいませんでした。特にデジタル方式であるD-Starは，アナログとの音質の差，様々なノイズの有無，機能差が大きく，アナログとのクロスリンクは否定的な意見が多いのも事実です。

しかし，ここで REF004 の管理者が Module-A を実験目的とはいえ，アナログとのクロスリンクに解放したことは，一歩前進であり，歓迎すべきだと思います。

IRLPも他VoIPとのクロスリンクは禁止しておりますが，IRLPとはネットワーク的に隔離された状態で，既存のIRLPシステムと他VoIPのクロスリンクを実験できる場（というか設定）を提供しています。

このように，新しいことが始まった初期は棲み分けをすることで既存ユーザーへの影響を抑えつつ，新しいことの問題点を洗い出し，解決し，そして将来的に一本化を目指すというステップバイステップのアプローチは，色々なところで応用できそうですね。

Asterisk/app_rptとrtpDirについて (1)

Asterisk/app_rptとrtpDirは，両者とも似たようなことができるのですが，根本的には別物です。似たことが出来ることと，両者の統合が可能なので，誤解もあるようです。

Asterisk/app_rpt
Asterisk/app_rptは，オープンソースPBXシステムであるAsteriskにアマチュア無線用の追加機能である app_rpt を追加したものです。Asterisk/app_rptをTIARA Technologyとも呼んでいます。

ベースのAsteriskはLinux上で動作するIPベースの構内電話交換機システムで，いわゆる有線電話系におけるインターネットVoIPシステムです。オープンソースであることから，今では多くの企業が社内電話システムに利用していますね。自宅用に自分で構築，利用されている猛者も多くおられるようです。端末電話機としては，最近のIPフォーンやあるいは一般家庭用アナログ電話機も利用可能です（利用電話機の種類に応じてハードウェアインターフェースが必要です）。交換機としては当たり前ですが一つのPCに複数の電話機をぶら下げることも可能です。このように，Asteriskが導入されたLinuxPCと電話機（複数可）の組み合わせをあちこちに作り，それらをインターネットで接続することで独自の大きな電話網を作ることが出来ます。

ここまでで，ピンと来る方も多いと思います。末端の電話機をノード無線機に変え，HTからアクセスしたらどうなる？そうですね，IRLP/EchoLink/WiRESなどと同様のVoIPアマチュア無線が構築できそうですね。それを実現しているのが，Asterisk上のアドオンモジュールとして開発されたapp_rptです。実体はただのCソースコードで，Asteriskと一緒にビルドして組み込みます。

PBXとしての電話機能はそのまま利用できますので，例えば業務用無線機と一緒に使えば，社内にいる社員はオフィス電話，外出中の社員は無線機でお互い通話するような業務システムが構築できるでしょう。

比較的簡単にVoIPアマチュア無線網を構築できるとは言え，システムの構築だけでは運用はできず，さらにノード番号（電話システムでの電話番号）の割当て（ナンバリング）や，ノード番号とIPアドレスとの対応，あるいは各ノードの状況把握・表示等，という運用上の仕組みが必要です。この運用上の仕組みを作り，一つの大きなAsterisk/app_rptベースのアマチュア無線VoIPネットワークとして構築されたのがAllStar Linkという訳です。このような運用の仕組みを別に作れば，AllStar Link以外の独自ネットワークも簡単にできます。

IRLP/EchoLink/WiRESと比べた時の一番大きな特徴は，いわゆるリフレクター，カンファレンス，ルームと呼ばれるような複数ノードが集まるための特別な仕組みはなく，どのノードでも，他の複数のノードと接続ができます。つまりノード=リフレクターです。これは，元々電話会議ができるように考えられているからでしょうね。Allstar LinkのGraphical Statusを見ると，現時点でのノード（楕円）どうしの接続状況がわかります。

Asteriskには，チャネルインターフェースという概念があります。これは，元々電話システムで利用されている様々な物理インターフェース（アナログ電話，ISDN，IP電話など）やセッション制御プロトコル(SIP，H323，IAXなど）に対応するために追加可能なように作られた個別モジュールです。アマチュア無線機との物理インターフェースとしてはCM108ベースのUSBドングルが主に利用されているのですが，このために chan_usbradio というチャネルインターフェースが用意されています。

このチャネルインターフェースの仲間として，chan_echolink，chan_irlp，chan_dstarというものがそれぞれ開発されています。その名の通り，これらのモジュールを組み込むことで，Asterisk/app_rptシステムとEchoLink，IRLP，D-Starシステムをインターフェースすることが可能になっています。すなわち，Asterisk/app_rptに接続された無線機からこれらのVoIPネットワークへ乗り入れることができます。

一台のAsteriskシステムには複数のチャネルを持たせることができます。さらに一つのチャネルは，一つのノードと対応し，ノード番号を割り当てます。すなわち，一台のAsterisk/app_rptシステムには，同時に複数の電話機や無線機だけではなく，chan_echolink，chan_irlp，chan_dstarを使ったノードを同時に複数持たせることが可能です。

一方，前述のように一つのノードは複数の他ノードと接続が可能ですので，結果として異種VoIPが同時に接続でき，実質ブリッジソフトウェアのように動作します。

ここが元々異種VoIP間ブリッジソフトウェアを意図して開発されたrtpDirとの違いであり，混同しやすい部分です。Asterisk/app_rptの場合には，Asteriskに元々あった電話会議システム機能の結果としてブリッジになっているだけで，ブリッジソフトウェアとして意図，設計されている訳ではありません。

さらに混乱しやすいのは，chan_rtpdirというチャネルインターフェースがあり，rtpDirとの統合が可能になっていることです。この場合には異種VoIPブリッジとしての役割はrtpDirが受け持ち，Asterisk/app_rptはあくまでAsterisk/app_rptのみのノードとして動作します（つまりchan_rtpdirと，chan_irlp，chan_echolink，chan_dstarとは排他的に利用することになります）。

rtpDirにおけるイベントハンドリング

rtpDirは、開始時、終了時、接続時、切断時にイベントハンドラーをコールバックすることができます。イベントハンドラーを使用するには、5198.confファイルで、

events=yes
eventpgm=イベントハンドラー

を設定します。eventpgmはデフォルトで/root/rtpDir/evt.shになっていますが、自由に設定可能です。

イベントハンドラーには、イベントに応じた値が引数として渡されます。（左から第1引数～です）

開始時：　Started at rtpDir動作開始時間
終了時：　Shudown at rtpDir動作終了時時間
接続時：　Connected ノード at 接続時間
切断時：　Disconnected ノード at 切断時間

当局ではIRLPと他VoIPの接続を排他的に行うために、このイベントハンドラーを使っています。アイドル時には全種類のノードとの接続を許しますが、接続したノードがIRLPノードあるいはリフレクタであれば他VoIPをdisableし、逆に他VoIPが接続した場合にはIRLPをdisableしています。接続/切断ノードの種類はConnected/Disconnectedに続く第2引数の最初の3文字を見ればわかります。

stnxxxx：　IRLPノード
refxxxx：　IRLPリフレクター
astxxxx：　AllStarノード (Asterisk)
XRFxxx：　D-Star XRFリフレクター
上記以外：　EchoLinkノードのコールサイン、コンファレンス名

(xxxxはノード番号）

よって必要に応じて、より細かな制御も可能です。

rtpDirの本来の主旨は複数VoIPを繋ぐことなのですが、IRLPのクロスリンクポリシーがあるため、このような制限をかける必要が出てきます。

クロスリンクについてのその後

IRLPのクロスリンクに関するポリシーをさらに守るため、当局のrtpDirでは：

• IRLPノードあるいはリフレクターと接続中は、他VoIP(EchoLink, Asterisk, D-Star)はdisableにする　（他VoIPは接続できない）
• 他VoIPのいずれかが接続中は、IRLPはOFFLINEにする　（IRLPは接続できない）

ような設定としました。つまりIRLPと他VoIPは排他的になります。なお、IRLP以外のVoIP間ではクロスリンクが可能です。

ちなみに、EchoIRLPは元々IRLPとEchoLinkが排他的になるように設計されています。これもIRLPポリシーに準拠した設計です。

IRLPとのクロスリンクを停止しました

最近のrtpDirやAsterisk/app_rptの出現により複数VoIPシステムのクロスリンクが可能となってきている状況を鑑み、Dave Cameron (VE7LTD)から改めてIRLPのポリシーについて下記のようなアナウンスがありました。

当局でもこのポリシーに準拠するため、他VoIPとIRLP間でのクロスリンクができないようrtpDirの設定をいたしました。IRLP（ノード、リフレクター）と他VoIPが当局のrtpDirに接続されている場合、他VoIPからの送信データはIRLP（ノード、リフレクター共に）にリレーされません。（例えば、当局のノードがIRLPに接続されている状態で、他VoIPから送信してくることはポリシー違反になり、そのような状況を避けるためです。）

IRLPノード(stn8437)としては、通常のIRLPノードのように動作します。

=====
(Date: Wed, 28 Jan 2009 17:50:12 -0000)

The Internet Radio Linking Project (IRLP) is a radio to radio linking
network. In order to maintain this, certain guidelines must be
followed to ensure the network stays secure for all IRLP nodes.

Certain technical advances in software have been created that allow
single radios/repeaters to be connected to more than one voice over
IP (VoIP) system. These systems include Echolink, Asterisk (app_rpt),
rtpDir, D-STAR, and EQSO (and possibly others). Most of these
advances challenge the security of IRLP when used in a manner that is
contrary to the IRLP guidelines.

The guidelines that must be followed to ensure the security of the
IRLP system are:

1) All IRLP traffic must originate from a locally received RF signal.
This is the original principle design criteria of the IRLP system.
This is due to third party regulations in some countries where IRLP
is used that require that the originating voice signal must be from
another amateur. It prevents non-amateur operators from transmitting
over amateur frequencies. It also promotes the use of radio in
Amateur Radio, hence our motto "Keeping the Radio in Amateur Radio".

2) Any crosslink traffic into IRLP must not masquerade behind another
IRLP node. In other words, an IRLP node that allows other VoIP
systems to access it must not allow users from the other VoIP systems
to dial into another IRLP node at the same time.

3) Any non-IRLP software must not cause problems to any IRLP node,
IRLP reflector, or IRLP server.

4) Any crosslinks between networks must be voluntarily dialed into by
all IRLP participants. In other words, all IRLP participants in the
crosslink must dial into the crosslink. The participants can not be
remotely called into the crosslink.

5) IRLP PGP keys are only assigned to users that support IRLP, either
by purchasing IRLP hardware or by making a donation to the project.
Donations need not be financial, but should benefit the network as a
whole, not just a small group of users.

Scenario Example - If there are a series of nodes that are maintained
as a separate "mini-network" through a reflector or other bridging
system, those nodes can run in any way you want, as long as your
modifications do not affect other nodes in the IRLP system, and the
intentions of the mini-network are known. An example of this is a
system where a published reflector channel supports Echolink,
asterisk, and IRLP. As long as non-participating nodes can not be
remotely and involuntarily dialed into the system, there is no breach
of the guidelines.

Scenario Example - A large net is being run on an IRLP reflector for
the Space Shuttle launch. An IRLP node (not the conference reflector)
sets up a system, using specialized software, which allows people
from Echolink to dial in and talk on the net. This is an example of a
crosslink, and is a breach of the guidelines.

IRLP systems authenticate using a public/private key pair. This pair
of keys allows a secure method of determining the identity of a node
you are calling. These keys are registered with the IRLP servers, and
without the keys, there is no communication between two IRLP nodes.

If a node is setup in a way that intentionally ignores the
guidelines, or if a PGP key is determined to be obtained through
fraudulent means, the PGP key will be removed, which will remove your
IRLP node from the system. This prevents non-compliant systems from
accessing the IRLP system.

Sidenote - The IRLP system is supported by volunteers. Any problems
that come about because of installing additional software to your
node are difficult for the volunteers to support. Volunteers will
help out where they can, but they can not help out in most cases.
Also, volunteers contribute their time and services with the
expectation that the nodes they are assisting are not closed to the
rest of the network.

David Cameron
IRLP System Designer
VE7LTD
=====

D-STARリフレクター XRF001への接続

2週間ほど前に入手しようと決心したD-Star DVDongleが昨日届きました。2週間というのは、入手を決心して、メールで見積もりを貰い、銀行振り込みをして手元に届くまでの時間です。

（クリジットカードが使えればよいのですが、DVDongleを扱っている米国のショップでは海外注文は銀行振り込みのみ可能ということでした。）

さて、rtpDirからDVDongleを使ってD-Starゲートウェイあるいはリフレクタに接続するにはdextra_cliというアドオンソフトウェアを導入します。このソフトウェア自体は設定項目も少なく、実行はとても簡単です。DVDongleをノードPCのUSBに差して、dextra_cliとrtpDirを同時に実行するだけです。dextra_cliがDVDongleを使ってAMBEのコーティング・デコーディングをし、さらにrtpDirが他VoIPシステムとのインターフェースを行います。

dextra_cliを利用してD-Starネットワークに接続するには、接続先のD-Starゲートウェイあるいはリフレクタがそれぞれdextra_srvあるいはdextra_reflectを動かしている必要があります。これはD-Starで一般的に使われているDplusの代替です。但しdextra_cliはDplusとは接続できません。ゲートウェイ側ではDplusと同時に動かすことは出来るようです。DextraはまだDplusほど世の中に浸透していないので、現時点ではXRF001というリフレクターが使えるだけのようです。

今日初めて"XRF001 B"リフレクターに接続していたら、rtpDir/dextra_srv/dextra_reflect/dextra_cliの作者であるKI4LKFから呼ばれて初交信を楽しみました。途中からはVKからの参加もあり日米豪交信となりました。私自身は通常のアナログ無線機から自分のIRLPノードにアクセスして、rtpDir経由でXRF001にアクセスという形になります。

ちなみにDextraはrtpDirなどを使った他アナログVoIPシステムとのクロスリンクを前提に作られています。現在の主流であるDplusに比べるとDextraは発展途上でありますし（まだ実験段階）、それゆえ浸透という意味でもまだまだのようですが、今後アナログシステムとのクロスリンクに理解のあるゲートウェイオーナーがDextraを導入してくる例も増えてくるでしょう。その時が楽しみですね。

私のrtpDirがXRF001に接続している時なら、EchoLinkのJI1BQW-L、あるいはIRLPの8437に接続すれば、XRF001にいる局の交信に参加可能です。

D-Starといってもこれはあくまでアナログアクセスという傍流なので、私としては近い将来にD-Star無線機を入手してキチンと主流、基本を理解・経験しておかないといけないなと感じています。

ところで不思議なのは日本のD-Starでは現在Dplusさえも導入されていないということ。DVDongleも使えないし、リフレクターもできないようですね。何故なのかしら。（レピーターもゲートウェイもJARLが設置しているから？）これからレピーターの数がますます増えてくれば当然欲しくなってくる機能ですね。

IRLPボードなしでIRLP

IRLPに参加するためにはIRLPボード等のコスト＋ドネーション(計US$188)を支払う必要があります。これは新ユーザーがソフトウェアインストール後、そのIRLPノード番号が認証用暗号化キー束に登録されるための条件です。

一方、rtpDirやAsterisk/app_rptなどのソフトウェアの出現により、IRLPボード無しにIRLPソフトウェアだけでIRLPノードを構築、運用することが可能になってきています。

*IRLPはそのポリシーとして末端は無線であることを求めていますが、これらのソフトウェアを利用することで無線機インターフェースとしてIRLPボード以外の選択肢が出てきたと言うことです。

このような新しい状況を考慮して、IRLP設計者のDave CameronはAsteriskのユーザーに対して、$40のドネーションだけで新しいIRLPノード番号を認証用暗号化キー束に登録してくれるようです。ハードウェアを輸入する必要がなくなるので、必要なものは全てネット上で入手できますね。

このような形態を希望する場合には、Dave Cameronに個別に連絡を取ってみましょう。

Asterisk: chan_dstar

rtpDirによるD-Starサポートに続いて、Asterisk/app_rptにおいても D-Star用のチャネルドライバchan_dstarが開発されました。現在テストが行われているようです。この場合もDVDongleが必要です。

chan_dstarは、rtpDirとは全く別物で、Asterisk/app_rpt単独システム上に載せるD-Starサポート用モジュールです。rtpDirは必要ありません。

逆にAsterisk/app_rptをrtpDirと共に使う場合には chan_dstar を入れてはいけません。これはEchoLink/IRLP用チャネルドライバ（chan_echolink, chan_irlp）も同様です。Asterisk/EchoLink/IRLP/D-StarとのインターフェースはrtpDirが行います。

rtpDirのD-STARサポート

rtpDirによるD-Starのサポート開発が進んでいるようです。すでにD-Star側の音声は復号できており、他のVoIPに流すことができているようです。他VoIPからの送り側もテストが進んでいるようです。

当ノードでも試してみたいのですが、私にはDV Dongleの入手をすぐに予定できそうにありません（値段が高いのと、クレジットカードで買えないようなので手間がかかりそう）。追々検討します。