- ベストアンサー
ＩＰ電話のクロックの同期について
ＩＰ電話って、送受信でそれぞれの内蔵クロックで動いていますよね。 もし、受信側のクロックが少し遅いと、パケットが少し早い周期で来てしまうので、バッファがドンドン溜まっていくと思います。 たとえ、ＲＴＰで「これは最初から１０００秒後のパケットだよ」と言う情報が入っていても、その１０００秒が送信側と受信側でずれていたら、おかしくなると思います。 ＩＰ電話って、どこかでＮＥＴ ＴＩＭＥコマンドとかを使って、すべての機器の時刻を一致させている物なのでしょうか？ その場合、ローカルのネットワーク網の場合はどうなるのでしょうか？
- DanceDanceDance
- お礼率14% (1/7)
- IP電話
- 回答数7
- ありがとう数4
- みんなの回答 （7）
- 専門家の回答
質問者が選んだベストアンサー
NTTの電話では問題なく使用できるのならば、NTTの電話で使用すべきでしょう あと何年も使用するような物ではなさそう 本気で対応を考えるには、予算と資料が不足している 対策費の代わりに通話料と考えれば何年かは持つでしょうから
その他の回答 (6)
- mii-japan
- ベストアンサー率30% (874/2820)
＞モデムは非同期だと思います。 ＞昔の物で、取り扱い説明書や仕様書が無くなっていますので良く判りません。 ＞目的は、「モデム対向の通信を安定して行いたい」です。 エラー再送の制御はアプリソフトか、アプリソフトが使用してるデータ通信プログラムの機能です 通常は、エラー再送するはずです、エラーが1ビットであろうがバーストエラーで数百ビットであろうがです 非同期通信ならば、1バイト毎にスタート・ストップで同期を取ります、そして1回の伝送は長くても数百バイトだと思います この単位で、エラーチェックを行い、エラーならば再送要求を行うのが通常の仕様です ですから、ビットエラーが発生しても、訂正して通信を続けられる訳です 直面している問題は、クロック云々によるデータ脱落の可能性がどうのこうのと言うより、通信プログラムだと思います 通信プログラムの仕様を確認するのが一番確実です *****余談****** 昔使用していたもので、「一定以上エラーが連続すると回線不良とみなして通信を切断する」と言うおせっかいな機能を持ったものがありました 仕様書では「一定以上エラーが連続すると」でしたが実際は再送の累計回数が・・・でした、正常な通信が連続してもカウンタをリセットしないため、連続して使用していると必ず通信断を起こしました ***************** モデムテスタがあれば、回線試験を行えば推測を確認することができるかと思います 想定以上にエラーが多いのかも知れません、モデムの速度を落としてみたら如何でしょう
補足
モデムの設定を変えて通信速度を遅くしたいのですが、１０年以上も前の物で、どこをどうすれば良いのか判りません。 取り扱い説明書も無い状態です。 仕方が無いので、現状は電話線で通信できているから、今の設定のまま、何とか電話線をＩＰ網に変えようとしています。 この装置は、アナログの信号入力を直接電話線へ出力する機器で、モデムの機能を内蔵した装置です。 今までモデムと言っていましたが、装置の中にあるモデムの機能の事です。 コンピュータなどではないので、アプリケーションでどうにかする事も出来ませんし、中のマイコンのプログラムの再送処理などをいじる事も出来ません。 最初から、ＩＰ用の物を作るのが楽で早いと思うのですが、それが許してもらえないので困っています。
- mii-japan
- ベストアンサー率30% (874/2820)
＞実際のモデム装置同士の対向で試験しました。 そのモデムは同期モデムですか、非同期モデムですか 同期モデムならば、受信クロックを使用する設定にしてください 非同期モデムならば、スタートビットで同期が取られます （同期モデムは通常モデムのクロックで動作です、非同期モデムならば、送信PCのクロックで動作です） だいぶ、クロックにこだわっていますが、何を行いたいのですか モデム対向の通信を安定して行いたいのですか それとも、最初からこだわっているクロックの事を確認したいのですか（そのためにモデム対向で通信テストを行っている） 後者でしたら、これ以上はご自分で調査してください
補足
モデムは非同期だと思います。 昔の物で、取り扱い説明書や仕様書が無くなっていますので良く判りません。 目的は、「モデム対向の通信を安定して行いたい」です。 今までは、電話を使って通信していたのですが、ＩＰネットワークに線が変わるので、何とかしてＩＰ網でデータ通信を行いたいのです。 それで、色々と調べたら、ＮＴＴのローカルネットワーク網がＧ．７１１で構成されていて、ＶｏＩＰもＧ．７１１だから通信できるだろうと思って、試験したらダメでした。 ＶｏＩＰとＮＴＴ内のデジタル回線網の違いを調べると、デジタル回線網は、同一のクロックで通信が行われているのを知り、そこがＶｏＩＰで通信できない原因だろうと思いました。 電話でなら送受信できるモデムを、ＩＰ網で通信させる方法をＩＰ電話以外の方法でご存知でしたら、その方法を教えて下さい。 よろしくお願いします。
- mii-japan
- ベストアンサー率30% (874/2820)
前の回答を書いてから気づいたのですが、もしかしてモデムテスタ等でそれもバーストモードで測定していませんか ？ そうであれば、エラーを検出する可能性はかなりあります 現実問題として、まともに設計製作された機器・システムならば、ビットエラー率1/1000000 パケットエラー率1/100程度のエラーならばエラー修復・再送でアプリケーションの実行に影響を与えない用に設計されています データロスの原因はエラーによる廃棄もあります 実用レベルならば問題にするほどのことではありません 探究心からならば、今までの回答を参考に、いろいろ調べてください それから、くどいようですが、1分を越えるデータ伝送で、同期の再確立を行なわないような事はありません 通常はパケット毎に同期再確立が行なわれます
補足
＞前の回答を書いてから気づいたのですが、もしかしてモデムテスタ等でそれもバーストモードで測定していませんか ？ いいえ、実際のモデム装置同士の対向で試験しました。 ＞現実問題として、まともに設計製作された機器・システムならば、ビットエラー率1/1000000 パケットエラー率1/100程度のエラーならばエラー修復・再送でアプリケーションの実行に影響を与えない用に設計されています 私も、再送等でエラーを回避していると思うのですが、実際に通信開始後１１分３０秒で、通信エラーを起こして装置が止まってしまいました。 この時間は、たまたま起きた時の時間で、１時間以上通信できた時もありました。 ＞それから、くどいようですが、1分を越えるデータ伝送で、同期の再確立を行なわないような事はありません ＞ ＞通常はパケット毎に同期再確立が行なわれます これは、どういう事ですか？ ＲＴＣＰで同期を取っているのでしょうか？ その場合、同期を取り直した時に、既に受信側で溜まっていたバッファの中の余分なデータがクリアされるのでしょうか？ 送受信の装置の基準クロックが、受信側の方が遅い時、徐々にバッファにデータが溜まっていくと思います。 それで、同期を修正すると溜まっていたデータを破棄して新しいデータをデコードするのでしょうか？ その場合、破棄されたデータ分だけ音飛びして、モデム通信でエラーを起こしたのでしょうか？
- mii-japan
- ベストアンサー率30% (874/2820)
＞無音時間で吸収されるとしても、ＦＡＸだと長時間音声データが続く事になりますが、大丈夫なのでしょうか？ 基本的なことですが、IP電話はデータの脱落を許容するUDP伝送を使用しているはずです で、上記のようなことは吸収されます（データ脱落時はエラーになるが無視される） ＞この原因が、ジッタやパケットロスではなくて、送受信のＩＰ電話のクロックのズレが原因だと思っているのですが、違うのでしょうか？ 受信側の処理が微妙に遅くてパケットが廃棄されたか、速くてデータ再生無しが発生したかのどちらかでしょう 用途に対して通信方式の選定が誤っています（仕様外の用途）
補足
>受信側の処理が微妙に遅くてパケットが廃棄されたか、速くてデータ再生無しが発生したかのどちらかでしょう これの原因が、クロックのズレではないのでしょうか？ それとも、他の原因があるのでしょうか？ （同じメーカの同一の型式のＶｏＩＰターミナルを使いました。） ＞用途に対して通信方式の選定が誤っています（仕様外の用途） ＶｏＩＰはＩＰネットワークで音声帯域の伝送が目的で、モデムは音声帯域を使ってデータ転送するのが目的だと思います。 仕様外になりますか？ 私個人としては、モデムのアナログデータを送信側でデジタルデータに直して、ＩＰ網に流し、受信側でモデムのアナログデータに変換するのが良いと思います。 しかし、昔の規格のモデムで、フォーマットが判らないので仕方なくアナログデータをそのままＩＰ網で伝えるのにＶｏＩＰを利用しようとしています。
- mii-japan
- ベストアンサー率30% (874/2820)
＞受信されるデータからクロックを抽出する機能と言うのは、受信側の機器がそのクロックを使って音声をデーコードするのでしょうか？ 一足飛びに飛ばないでください、クロック抽出は、物理層でのことです 質問の事項はアプリケーション層になります 音声はサンプリングされA/D変換されてエンコードされ伝送されます、このときの規格にサンプリング周波数、量子化（ディジタル化）ビット数等があります ディジタル化したデータをリアルタイムで送るか、バッファに貯めて送るかは、データ伝送アプリケーションによります そのデータを伝送するのがネットワーク層、物理層です（表現はかなり省略しています） ＞その８ｋＨｚと２０ｍｓが送受信で微妙にずれていた場合の事を考えています。 これはサンプリングとバッファしたデータを送信する時間間隔の規格です 質問の微妙なずれは、最悪でも1/1000、通常は1/数万です（1/1000ずれていれば時計が1日に90秒くらいずれます）そして1/1000の周波数のズレを耳で検出できる人はほとんどいません それから、最初の質問のようなことは誤差が生じても無音時間で吸収されてしまいます それよりも影響があるのは、微妙なずれではなく大幅な伝送遅れやデータ消失です（エラーもしくはタイムアウトによる）これは音飛びなどを引き起こします が 原因となるのは 質問されているようなことではありません
補足
私の質問は、まさにこの部分です。 ＞質問の微妙なずれは、最悪でも1/1000、通常は1/数万です（1/1000ずれていれば時計が1日に90秒くらいずれます）そして1/1000の周波数のズレを耳で検出できる人はほとんどいません ＞ ＞それから、最初の質問のようなことは誤差が生じても無音時間で吸収されてしまいます ＩＰ電話は無料なので、長時間連続で通話している場合の事を聞いています。 耳ではズレを聞き分けれ無くても、ＦＡＸのようなデータ送信の場合はどうなるのでしょう？ 無音時間で吸収されるとしても、ＦＡＸだと長時間音声データが続く事になりますが、大丈夫なのでしょうか？ データの転送時間の送れ（ジッタ）は、バッファで吸収して対処しているのは、判っています。 でも、基準としている２０ｍｓが、送信側が１９．９９９ｍｓだと、受信側が正確に２０ｍｓでデコードしていると徐々にバッファにデータが溜まっていってしまって、いつかバッファオーバーランになってしまう気がしているのです。 バッファがオーバーフローした時に、どのように補正がかかるのでしょうか？ その事は、送信側は自分の内部のクロックを基準にしているので２０ｍｓが１９．９９９ｍｓにズレているとは気が付かないと思っています。 やろうとしている事は、モデムの口しかない装置をＩＰ電話を使ってデータ転送しようとしています。 スイッチングＨＵＢとＳＩＰサーバだけの簡単な構成のローカルなネットワークを作って試験した所、１０分程度でエラーが発生してデータ転送できなくなってしまいます。 この原因が、ジッタやパケットロスではなくて、送受信のＩＰ電話のクロックのズレが原因だと思っているのですが、違うのでしょうか？
- mii-japan
- ベストアンサー率30% (874/2820)
クロックについてですが、重要なのは時刻ではなく周期です クロックは、ルータ・スイッチングHUB等のネットワーク機器を経由するごとに再構築されます、また送受信されるデータ（パケット）ごとに再構築されますから、ずれが蓄積されることはありません ネットワーク機器は受信されるデータからクロックを抽出する機能もあります １パケットは最大でもMTUの範囲ですから１万数千ビット毎に再構築されます ですからローカルでもそれなりに使用できるわけです
補足
受信されるデータからクロックを抽出する機能と言うのは、受信側の機器がそのクロックを使って音声をデーコードするのでしょうか？ その規格は、ＲＴＰ・ＲＴＣＰ・ＶｏＩＰ・Ｇ．７１１のどこで規定されているのでしょうか？ Ｇ．７１１の規格を調べたら、８ｋＨｚサンプリングと言うのがあり、ＳＩＰで２０ｍｓごとに１パケットで送るような取り決めをするような事があったのですが、その８ｋＨｚと２０ｍｓが送受信で微妙にずれていた場合の事を考えています。
お礼
色々と教えて下さって、ありがとうございました。 規格が判らないフォーマットのデータだから、モデムのアナログ信号をそのままＩＰ電話で転送しようと思ったところで無茶な事だったのですね。 とりあえず、装置が壊れるまでは、今の状況でいくようにしてみます。 壊れてしまえば、パソコンにＡＤボードと接点入力ボードを入れて、イーサネットで通信するよにします。 （ノイズ対策や、サージ対策が必要ですが） ありがとうございました。
補足
ＮＴＴ電話ですが、実際は会社の内線を使用しています。 内線がＩＰ電話に変わります。 対策費としては、対向で２０万円までならＯＫです。 ５対向なので１００万で済めば大丈夫です。 ＶｏＩＰのモデムが、５万くらいだから、余裕があると思ったのです。 この内線だけは撤去しないようにお願いして、今の状態を残すのが一番良さそうですね。