@nifty v6サービスでSMARTalkを使用する
光回線に切り替えたのでADSL回線用に維持していたアナログ電話回線は廃止する予定。
その為、契約していたSMARTalkを固定電話の代わりに設定することにした。ついでにSMARTalkのVoIP回線経由での一般公衆回線とのモデム間通信も実験してみた。
注:SMARTalkの新規登録は現在無期限停止中
ネットではSMARTalkでの接続にそれなりに実績のあるGrandstream HT801をチョイス。
DHCPでIPアドレスを自動付与しないとHT801へアクセスできない為、DHCPサーバが立っているテスト環境で設定を実施。
以下最終設定内容、赤枠が設定変更対象の項目。
1.BASIC SETTINGS
・Internet Protocol
デフォルトでIPv4 Onlyとなっている、現状変更する必要なし。
・IPv4 Address
デフォルトでdynamically assigned via DHCPとなっている。
実際の運用では固定IPアドレスで運用予定の為、statically configured asで直接指定している。
・Time Zone
GMT+09.00(Japan,Korea,Yakutsk)に変更。
2.ADVANCED SETTINGS
・Firmware Upgrade and Provisioning
Firmwareのバージョンが古かった(1.0.19.11)為かfm.grandstream.com/gsとなっている。
このアドレスだとFirmwareの確認自体が失敗していた。
grandstreamのHPのFirmware配布ページにHTTP Upgrade ServerのURLが記載されているのでそちらに変更。
但し上記設定でもFirmware自動アップグレードはxml Config dataがダウンロードできないとのエラーで失敗している。
その為、Always Skip the Firmware checkへ設定変更している。
・System Ring Cadence
電話機から聞こえてくるPBXの各種トーンの設定。
デフォルトでも問題はないが国内PBXに準拠した音に変更している。
値は先人が公開しているのを流用。
・Call Progress Tones
電話をかけているときにPBXが返してくる各種トーン。
これもデフォルトで問題ないが国内PBXの音に準拠。
・Disable Weak TLS Cipher Suites
セキュリティ上問題のあるTLSのバージョンを使用させない設定。
私は特に設定していないが気になるなら設定可能。
その場合はMinimum TLS VersionをTLS1.2に設定しておけばOK。
3.FXS PORT
・Primary SIP Server
SMARTalkの場合はsmart.0038.netと設定。
・NAT Traversal
Keep-Aliveへ変更。
SMARTalkを発信専用として使用するのであれば変更の必要はない。
着信する場合はSMARTalkの交換機にこちらから接続してコネクションをキープしておかないとファイアウォールではじかれて着信出来ない。
・SIP User ID
SMARTalkのSIPアカウントを設定。
・Autenticate ID
SMARTalkのSIPアカウントを設定。
・Autenticate Password
SMARTalkのSIPパスワードを設定。
上記SMARTalkの各情報はSMARTalkのMypageから確認可能。
・Check SIP User ID for incomming INVITE
・Allow Incomming SIP Messages
両方ともYES(no direct IP calling if Yes)に設定。
インターネット側からのHT801へのSIP攻撃対策。
・SLIC Setting
JAPAN COへ変更。
・Caller ID Scheme
NTT Japanへ変更、Number Displayへ対応。
・Gain
基本的に変更不要。
相手側からの音声が小さくて聞き取りずらい場合はRXを変更する。
マイナス値が小さくなる程音声は大きくなる。
TXも基本触らない。
これは交換機への到着レベルが高くなると音割れの原因となる為。
交換機への到着レベルはこちらではわからないのでデフォルトのままで運用推奨。
どうしても変更する必要がある場合は+5dBまでに抑える。
補足:
これは国内の機器の大半は-15dB送信で交換機への到着レベルの許容上限が-10dBであるため。
一応交換機では到着レベルを-15dBで想定しているのでそれを上回らないように大半の機器が送信レベルを-15dBにしている。
しかし上限が-10dBまであるので-10dBで送信している機器もある。
通常は交換機と機器との間にKm単位の距離があるので途中信号が減衰して交換機への到着レベルが送信レベルより数dB~10数dBほど低くなるためどちらでもあまり問題にならない。
これはアナログ電話時代での話なのでIP交換機で同じかどうか不明だが、恐らく大きな変更は無いと思う。
補足終わり:
上記設定で正常接続を確認。
STATUS画面でUser IDにSIPアカウントが表示され、RegistrationがRegisteredになっていればOK。
この状態で着信テストは問題なかった。
*今回の作業ではまった点
・ファームウェアのアップグレード
最新バージョンである1.0.33.4へのアップグレードは失敗した。
配布されているひとつ前のバージョンである1.0.29.8へのアップグレードは成功した。
自動アップデートはエラーとなるのでファームウェアをダウンロードして手動でアップグレードを行ったが、以下のエラーが発生する。
エラーメッセージからWEBブラウザからのファームウェアファイルのアップロードサイズに制限が設けられており、それに引っ掛かっている様子。
その為ファームウェアを公開されている古い順に当てていったが最新版は同じエラーで適用できなかった。
リリースノートでは公開されている1.0.29.8と1.0.33.4の間に1.0.31.1がある様だがメーカHPでは公開されていない。
1.0.29.8までが7MB台、1.0.33.4が8MBオーバーなので8MBに境界があるのではないかと推測。
WEBのCGIの問題であれば別途TFTPかFTPサーバーを立ててコマンドラインからアップグレードすれば回避できるかもしれない。
(若しくは公式のファームウェアサーバへFTPかTFTP接続する設定にして自動アップグレードする)
しかし現状SMARTalkの運用では1.0.29.8でも問題なさそうなので取り合えずペンディング。
追記:
リリースノート見てたら1.0.33.4より古いバージョンはWEB UIから1.0.33.4以降へアップグレードできないと書かれてた。
アップグレードはprovisioningを使ってやらないとダメとの事。
メーカHPではWEBのFirmwareはHTTPで公開していると書かれていたのでファームウェアの自動アップグレード設定を以下の様にして再度HT801をリブートしたらFirmwareの自動アップグレードに成功した。
アップグレード後のSTATUSは以下の通り。
あとリリースノートを見ているとHT801のHardware Versionは4.0Aまである様だ。
1.1Aというのは相当古い様子。
1.0.33.4から任意のFWバージョンへダウングレードできるみたいだが、Hardware Versionに依ってファームウェアのダウングレードに制限があるとの記載。
以下リリースノートから要約して抜粋
・対象:HT801 HW 4.0A
1.0.29.8以降へアップグレードするとそれ以前のバージョンへのダウングレードはサポートされない。
・対象:HT801 HW3.1A/HT802 HW2.0A
1.0.27.2以降へアップグレードするとそれ以前のバージョンへのダウングレードはサポートされない。
・対象:HT801 HW1.1B,1.1C/HT802 HW1.6B,1.6C
1.0.23.5以降へアップグレードするとそれ以前のバージョンへのダウングレードはサポートされない。
・対象:HT801/HT802 HW 不問
1.0.3.2以降へアップグレードすると1.0.2.X以下のバージョンへのダウングレードはサポートされない。
・対象:HT801/HT802 HW 不問
1.0.2.7へアップグレードすると1.0.1.X以下のバージョンへのダウングレードはサポートされない。
取り合えずダウングレードしないなら関係はなさそう。
一応HP上で公開されている過去FWは1.0.29.8と1.0.27.2だけだがそれ以前のFWもある様子。
リリースノートに記載のある1.0.33.4~1.0.3.2までは確認できた。
1.0.2.x系は無い様子。
fm.grandstream.comにログインできればダウンロードできるのかもしれない。
・本体のIPアドレスが変更できない
テスト環境でセットアップ後、本番環境へ移すためにIPアドレスをDHCPでの取得から固定IPへ変更を掛けた。
しかしどうやってもIPアドレスの変更を適用できなかった。
これはHT801の仕様であるらしく現在使用しているIPアドレス体系と異なるIPアドレスを設定したら無効化される様子。
多分間違ったIPアドレス体系へ設定してLANコンソールへアクセスできなくなることを防ぐためだと思われる。
取り合えず本番環境のIPアドレス体系と同じアドレスを払い出すDHCPサーバを用意してIPアドレス取得後に本番IPアドレス体系の固定IPアドレスへ変更して適用すれば問題なく設定変更出来た。
・その他
G3FAXが使えるみたいなことも情報としてあった。
CODECにPCMUを使っている様なのでサンプリング周波数8000Hzの64Kbps通信なら3.4Kの音声帯域は劣化なく伝送できる為、G3FAXが伝送できるのも納得。
今更過ぎて情報が無かったが3.4K帯域を使用するSuperG3FAXも通るのではないかと思う。
3.4Kアナログ帯域線では最大33.6Kbpsまで可能なので双方向28.8Kbps程度なら通信できそう。
FAXがOKならアナログモデムでの通信は可能なので、環境が用意できれば実際にアナログモデム経由でのシリアル通信ができるかも試してみたい。
2022/1/28追記:
アナログ公衆回線との間でモデム間接続をテストしてみた。
結論としてはモデム間接続は可能であった。
但し以下の問題が発生した。
・問題点
1.モデム着信が不安定
これはモデムが着信してアンサートーンを返しても相手モデムがアンサートーンを認識できずに切断されたり、アンサートーンを認識してネゴシエーションに移行してもネゴシエーションが失敗する等の事象が発生した。
2.通信エラーが発生する
ネゴシエーションが成功してモデム間が接続できても通信エラーが発生しており、入力していないのに文字が湧いて出てくる。
また文字を入力してもなかなか相手に表示されない。
これはモデム間でエラー発生の為にエラー訂正機能が働いているがエラーを補正しきれなかったりデータ再送を繰り返しているからと推察されれる。
・原因推測
1に関してはモデムの受信信号レベルがモデムの受信レンジを外れている可能性が高いと推定した。
IP網経由の場合は電話局からの引き込み線部分が無いので受信レベルの低下が発生しない為にHT801で6dBの損失を追加している。
しかし私の経験上6dBの損失はかなり状態の良い回線で、通常は7~13dB位の損失が発生する感じ。
恐らくモデムの受信レンジは-20~-40dB辺りに設定されており受信レンジの上限付近の為に着信が安定していないと推測。
2.関しては文字化けや文字が湧いて出てくる現象はエラー訂正機能が働いているが回線でそれを超えるエラーが発生しているときによく起こる。
これは回線品質が悪くて回線自体にノイズが乗っている場合がほとんど。
しかし今回は回線ノイズは考えられないため、高変調方式の為にサンプリングする際に量子化ノイズが発生しているのではと推測。
・問題対応策
上記推測から問題点の対策として以下の対応を実施。
1.HT801で受信信号レベルのゲインを-6dBから-10dBへ変更
局交換機出力-15dB推定でモデム信号受信レベル-21dBが-25dBへ低下、受信レンジ上限-20dB付近で不安定であった場合、これで安定するはず。
2.モデムの設定で変調方式をV.90からV.34へ変更
・対応結果
V.90の時は33.6Kbpsや28.8Kbpsで接続されていたがV.34設定後は概ね14.4~20Kbpsまで低下した。
しかし接続自体は安定し、通信エラーの発生は無くなった。
またモデムの着信に失敗する事象も発生しなくなった。
・結果考察
対応策を実施し安定した通信が可能となった事から原因推測は概ね間違っていないと思われる。
1.の対応策に関しては厳密にいえば送信レベルのゲインも-4dBほど下げてやるのが良いと思われる。
今回は相手が公衆電話回線であることと受信レベルのゲイン調整で安定したので特に触らなかった。
恐らくほとんどのモデムの送信信号レベルは-15dBに固定されていると思われる。
相手もVoIP接続のモデムの場合は双方ともに基本的に受信レベルゲインを下げる調整で対応するのが適切だと思う。
モデム間通信でこのような結果だったのでFAX通信も同じような調整が必要かもしれない。
2.に関してはHT801の機能では音声帯域の完全再現が出来ていない為と考えられる。
通常音声通話では300Hz-3.4KHzの信号が再現できれば概ね問題ない認識。
局交換機の場合は300Hz-4KHzまでをサンプリングしているが恐らくHT801が3.4KHz-4KHzの周波数帯を完全には処理していない可能性が高い。
2022/1/31追記:
モデムのATコマンドを調べて何とかPV-BW5600が使用しているコマンド体系らしきものが特定できたのでデータを取ってみた。
あとHT801の設定も一部変更している。
・ゲイン設定
・Fax Mode
Fax ModeはT.38からPass-Throughに変更した。
Pass-ThroughだとG.711の変調方式になるみたいでこちらの方が安定しそうだったため。
G.711はサンプリング周波数8000Hz/8Bit符号の64Kbpsのビットレートとなり、INS回線と同等の品質で論理的にはデータ復元時に劣化が無い。
・モデム間接続時のモデム接続状態情報
CONNECT 9600/ARQ/V34/LAPM/V42BIS
ati11
AIWA 56000 Data/Fax Link Diagnostics...
Modulation V.34
Carrier Freq (Hz) 1829/1920
Symbol Rate 3200/3200
Trellis Code 64S-4D/64S-4D
Nonlinear Encoding ON/ON
Precoding OFF/ON
Shaping OFF/ON
Preemphasis (-dB) 0/6
Recv/Xmit Level (-dBm) 29/15
Near Echo Loss (dB) 20
Far Echo Loss (dB) 67
Carrier Offset (Hz) -12080
Round Trip Delay (msec) 978
Timing Offset (ppm) -16736
SNR (dB) 28
Status : 0000,0111,0000,0000,0000,0000,0000,0000
OK
モデム間は9600bpsで接続されているがエラー訂正とデータ圧縮が効いているので端末間の通信速度は19200bps相当。
一応V.34の規格的には最高速度は33600bps、V.34はFAXの通信方式と同じなのでG3 FAX相当。
受信レベルは-29dB/送信レベルは-15dB(モデムで固定)
推測通り送信レベルは-15dBであった。
受信レベルはHT801のゲインで-10dBしているので本来の到着レベルが-19dB、元の設定では-6dBだったので受信は-25dBだったと思われる。
-6dBより上の設定では着信してもネゴシエーションできなかったので、受信レンジの上限は予想した-20dB辺りよりもう少し低い-23-25db辺りかも。
あとNiar Echoは少し高い気がする。
対策するとしたらモデムとHT801に間にモジュラージャックかませて600オーム抵抗で終端してみるかモジュラーケーブルにノイズフィルターかませる位か?
往復遅延が978msなので約1秒、SNRは28dBなのでまあこんなもの。
Statusについては情報が無いので不明。
取り合えずこんなところかな。
あとモデム間は場合によってはV.32で接続していた。
CONNECT 9600/ARQ/V32/LAPM/V42BIS
ati11
AIWA 56000 Data/Fax Link Diagnostics...
Modulation V.32bis
Carrier Freq (Hz)
Symbol Rate
Trellis Code
Nonlinear Encoding
Precoding
Shaping
Preemphasis (-dB)
Recv/Xmit Level (-dBm)
Near Echo Loss (dB)
Far Echo Loss (dB)
Carrier Offset (Hz)
Round Trip Delay (msec)
Timing Offset (ppm)
SNR (dB)
Status : 0000,1101,0000,0000,0000,0000,0000,0000
OK
この場合は各種情報は確認できなかった。
| 固定リンク
「@nifty光」カテゴリの記事
- @nifty v6サービスでSMARTalkを使用する(2022.01.19)
- @nifty光のv6プラスでポート開放機能を試してみる(2021.11.08)
- @nifty光 導入に伴うルータ設定覚書(2021.04.12)
- @nifty光のv6プラス接続でIPv4通信のuploadが極端に遅い件について(2021.04.11)
「SMARTalk」カテゴリの記事
- SMARTalkサービス終了のお知らせ(2024.06.18)
- @nifty v6サービスでSMARTalkを使用する(2022.01.19)
「VoIP」カテゴリの記事
- @nifty v6サービスでSMARTalkを使用する(2022.01.19)
コメント