間違いだらけのネットワーク作り(98) 99/10/16
「FRF12とVoIP」

 このシリーズ(96)でVoIPでよく話題になる企業が公衆FR128Kで実験したところ、FTPやPingで負荷をかけるとRTP圧縮や優先制御をしても使いものにならない、という結果がホームページ(今年7月時点の記事)に公開されていることに触れました。数日のうちにその企業の方からメールを頂き、その後使用しているルータがFRF12をサポートしたので改善されたということです。拠点も増えているとのこと。7月の3拠点から、現在何拠点なのか、構成がどう変わったのかは分かりません。

 FRF12はフレームリレー・フォーラムの標準で、データ系のVCと音声のようなリアルタイム系のVCが低速のインタフェース(FR網へのアクセス回線など)を共有するとき、リアルタイム系の遅延を大きくしないようロング・フレームをフラグメントする方法を規定しています。UNI、NNI、END-TO-ENDの3種類が規定されていますが、上記企業では公衆FR網で接続されるルータ間ですから、END-ENDでしょう。下図がFRF12の公開ドキュメントから引用したEND-ENDの構成図です。

 
 

 両端のDTEがルータということになります。分割されたフレームには通常のヘッダの後に12ビットのシーケンスナンバー等を持つフラグメント・ヘッダが付加されます。FRF12の詳細は次のページを参照してください。http://www.frforum.com/5000/5000index.html
 

 FRF12自体は難しくはないのですが、何故、FRF12サポート以前の音質が使いものにならないほど悪かったのか、完全には納得できません。仮に1キロバイトのデータ・フレームが回線上に送出されたとしても128Kではシリアル化遅延は約60ミリ秒です。音声パケットが待たされたとしても、ゆらぎ吸収バッファで対応できる範囲のように思うのですが。優先制御が弱くて連続してデータ・フレームが送出されるとダメですが。

 自営FR網上のVoFRでは64Kの回線上に音声PVCとデータPVCを多重化しFTPで負荷をかけても、データフレームのフラグメントなしで問題なく利用できている事例があります。フレームリレー交換機での優先制御とFRADでのゆらぎ吸収バッファ(最大200ミリ)が効いているためです。

 FRF12サポート以前に音質がヒドかった原因はより詳細な情報がないと分かりませんが、FRADやルータの持っている機能のちょっとした差や設定の違いが、音質に大きく影響することは間違いないようです。

 

 
ホームページへ