まえがき

ここでは、菌XP宅に導入したIP電話について紹介しますが、音質とか、そんなところは他にもレポートが沢山あるので割愛ということで、設定でハマったことを中心に紹介させていただきます。

IP電話を申し込んだぞ

Bフレッツになって速度を持て余していたのでサーバを建ててみたたけど、それでもまだまだなので、次に電話などに手を出しました。「ぷららフォン」には加入してあるのですが、やっぱりネット回線を使って電話ってカッコいいじゃないですかぁ〜。。という、いつもの不順な動機からです。我が家の機器構成はポータル画面(→)にも公開してありますので、そっちを見てくださいね。
さて、電話端末の申し込みですが、うちはルータ(BRL-04FB)をすでに持っていますので、迷わず「アダプタタイプ」を選択しました。プロバイダは当時@Niftyだったので、それのIP電話を申し込みました。その後、ぷららに復帰。

アダプタ到着したよ。。最初のワナ

アダプタが到着したので、早速組み立て&設定をやります。
説明書を読むと、「LAN側の端子に設定用のPCを接続して・・・」とある。さて困った。うちの接続図を見てもらうとわかるのですが、この機械を接続しているラインはサーバ用のPPPoEと共有しているんです。差し替えたらサーバまで止まっちゃう・・・こっちにアダプタを持ってきて設定したら電話線がないからテストに不便だ。悩むこと数分で、嫁PCがぶら下がっている無線APをLAN側に接続して設定することにしました。@Niftyの場合は書面で送られてくる設定内容を見て手動設定しなくてはいけません。何度も確認しながら設定しました。ちなみに、ぷららは自動設定でできます。
さて、無事に設定が終わって接続。「電話かけられるかな?」とワクワクしながらトライしてみたのですが、Voip側に行ってくれません。
何が起こったんだろうと目を皿のようにして設定を見直すこと数回。でも設定はあっています。「う〜〜〜〜ん」と考え込みました。ここで、ハタっと気が付いて@Niftyの書面を見ると。。。「お客様の使用開始日は・・・」って書いてある。
なぁ〜んだ。
まだじゃん(涙)
というわけで、しばしの休息。

ちなみにですが、このアダプタって「アダプタモード」の設定をすると、WAN側はDHCPクライアントとしてのルータ動作をしているようです。LAN側に接続したPCにはプライベートでDHCPによるIPアドレスが振られ、その状態でもネット接続することができます。てっきりブリッジ動作だと思っていましたけど。

開始日来たよ。。2番目のワナ

いよいよ開始日が来たので再度トライ。でもやっぱりVoipに行ってくれません。「なんでじゃこりゃ〜〜」と考え込みました。
Voipランプは点灯(実は開始日と書かれていた以前からですが)しているので、接続認証は大丈夫そう。
困った困ったと、その晩は眠れずに考え込みました。
これもまたハタっと気が付いたのですが、「あれ?LCRランプってなんだっけなー?」。そうなんです。電話機のLCRがオンになってたのが原因だったんですわ、、これが。
でも、電話機でLCRをオフにする方法がわからなかったので、近くのノジマに歩いて行って電話機を一台買っちゃいました。

これで大丈夫か?いよいよ泥沼突入

電話機も新品にして再度トライ。
やった〜〜!!
苦節3回目にしてクリア!!
やっとVoipで発信できました。
かけた相手ですか?深夜だったので、うちの勤務先の外線にかけてテストしました。「当社の営業時間は・・・・」これが生まれて初めてIP電話で聞いた総務課のおねいちゃんの声です。
もぉここまで来れば!ってんで家族にも教えてあげて、「これでうちもIP電話じゃ〜」っと得意になっておりました。
ところが、翌日会社に「ネットがつながらねぇぞ」という電話。なんでだろう?とりあえずルータの電源を落としてみるように指示。
これで復旧したので、いつものルータハングだと思っておりましたが、「(よし、これを口実にルータも・・・)」というわけで、ルータをBRL-04FMXにチェンジしました。なんつーか、導入のためには節操もなく金をつぎ込むというか。。。
これで完璧だろうと思っていたら、翌日「またネットがつながらねぇぞ」コール。こりゃやばいということで調査を開始しました。

ネットワークが嵐ってる。。。汗

調査している間に気が付いたのですが、不具合は大きく分けて2種類あるようです。
1つ目はVoipのアダプタとルータの間で凄いデータのやりとりをしていて、他のPCからの通信すら受け付けない状態になるケース。
もう1つは、ネットワークの輻輳はないけど、Voipアダプタのランプが消灯して発信がまったくできなくなるケース。
どっちになっても家族からブーイングが出るので、調べないわけにはいきません。

アダプタのIP固定をしてみた

DHCPだとIPが分からないので何かと不便です。なのでIPを固定にしてみました。

設定画面

結果は変わらず。やっぱり不具合が発生して撃沈しちゃいましたが、何かと便利なので、このままに・・・。

NAT設定してみた

むかしからPnPと名の付くものは信用しない性格なので、VoipのポートをNATでスタティックに書いてみました。

設定画面

平たく言えばTCPとUDPの5060,5090,5091をアダプタのWAN側に無条件転送する設定です。
結果は4日程度は耐えたのですが、その後再発。どうやらNATが原因でもないらしい(T_T)。

いちいちつなぎかえるのが面倒だ。。。汗

いちいち調査するのに嫁PCをつなぎかえるのも面倒くさいということで、なんとかそのままの接続でメンテできないか調べてみたら、情報がありましたので、それをやってみました。
まず、PCをLAN側に接続して、「その他設定→システム情報と端末の状態」の画面で「WAN側からの保守」にマークをつけます。

設定画面

つぎにWAN側に配線をつなぎかえて、telnetでVoipアダプタに接続します。

コマンド画面

ログインのIDは"r00t"、パスワードは"voipfone"です。

コマンド画面

接続できたら以下のコマンドを順に入力します。

cd net
wanport_web on
cd ..
write
reset

これでWAN側に接続したままの状態でもブラウザで設定ができるようになります。
この場合、URLにはWAN側のIPアドレスを使うことに注意してください。

例) http://192.168.1.103

この設定をした状態でDMZに指定すると、外からWEBアクセスできちゃうので、DMZは設定しない方が身のためです。
また、この方法はメーカ保証外ですので、不具合があってもクレームは絶対にあげないでください。

万策尽きたか?

色々あっちこっちの情報を探してみたのですが、みんな同じような症状に悩んでいるみたいでしたし、NTTから8月末にファームアップ予定だということで、しばらく様子を見ていました。ところが、今現在9月も後半になってもリリースされる気配はありません。「こりゃ・・・なんとも・・・」状態で何気なく設定を見直していたのですが、1つのことに気が付きました。

設定画面

「そういえばDNSって、ルータの中継を使ってたんだなぁ」っと。「ここは試しにプロバイダのDNSでも書いてみるか」。
というわけで、プロバイダのDNSを書いてみました。これでNATとUPnPを除いてIP設定は完全にルータと手が切れたはず。
結果ですが、これの設定をやったのが9月15日(月曜)の午前で、今9月18日の午後11時30分現在、一応切れずに動いているようです。
前は最長4日間で力尽きましたので、まだ安心はできませんが、とりあえず、これで様子を見ています。
変化があったら、ここで報告しますネ。

ファームアップしてるし

ファームがアップして2.61になっています。ダウンロードしてアップデート。設定は前のままで様子を見ます。
ルータの交換とVLAN化

その後ファームアップしても何度もハングアップするし、ハングするとサーバ側PPPoEまで切れてしまうため、ルータをNetGenesis SuperOPT100に交換しました。ついでにブロードキャスト/マルチキャスト防御も入れてみたのですが、見事通過してハングしてくれました(号泣)
現在はネゴシエーションを10Mbpsに落とした上で、VLANで分離しています。
それだけだとつまらないので、ハングしている最中のパケットをキャプチャしてみました。ただしSW-HUBが間にいますので、ブロードキャストとマルチキャスト、それに自身の送受信だけですが。
よくみると、Addr=239.255.255.0, Port=1900 に向けて数秒周期でUPnP検索のパケットを送信しています。

パケット画面
(クリックすると大きくなります)

これとルータがARP要求「where is 192.168.1.103(アダプタのIPアドレス)」でアダプタのMACアドレスを何度も聞きに行っていますが、アダプタはこれに回答していないようです。

パケット画面
(クリックすると大きくなります)

このため・・・
  • ルータは答えたくても答える先が分からない状態になっている。
  • アダプタは聞いているのに答えてくれない状態になっている。
以上のようなデッドロックを起こし、何度もリトライしているのだと思われます。

これはハング最中のデータなので輻輳開始分のデータはありませんが、もしかしたら、このようなパターンにハマッた場合にアダプタがUPnPの告知パケットを出さずにいきなり検索を出そうとしているのかもしれません。どういったタイミングでこのような状態に陥るのかまでは分かりませんでした。
UPnPの詳細はここ。ただしPowerPointが必要です。


参考:ARPとは?
TCP/IPの通信はご存知のとおりIPアドレスでやりとりしています。これに対してEthernetの通信はLANカードに焼きこまれている12ケタのMACアドレスによって通信します。このため、Ethernet上でTCP/IP通信をするときはIPアドレスを元にMACアドレスを調べて通信するようになっています。この処理をするのがARPパケットです。
まず、MACアドレスを知りたい機械がブロードキャストで"ARP where is xxx.xxx.xxx.xxx"と投げます。上記イメージに現れているのはこのパケットです。
すると、そのIPアドレスを持っている機械から"ARP xxx.xxx.xxxx.xxx is XX:XX:XX:XX:XX:XX"とMACアドレスの返事があります。こちらは質問した機械と回答する機械でP2P通信をしますので、上記イメージには(SW-HUBが入っているので)現れていません。
通常ARPキャッシュは実装にもよりますが、数分〜10数分は保持しますので、数秒周期で同一IPアドレスの質問が飛ぶということは、返事が返ってきていないと想像することができます。