35歳でエンジニアを志し、現在38歳で社内SEとして勤務しているからあげです。
題名のとおり理解が不足している特に音声系。
なまじっか音声系のリアルの現場で研修を受けたことがあるからか、それとも苦手意識で音声系は勉強が不足しているのか。。。
また、フレームについて再度おさらいして、理解を深めるためにも記事にしていく。
ジッタ、バッファ
ジッタが発生しないようにQoS環境を設定したりして対応する。
VLANでネットワークをそもそも分けたり、QoS(Cos、DSCP)によって優先制御する。
ここまで基本のきですが、これが発生しないように自動的に調整してくれるのがジッタに対するバッファ機能。
じゃあ、このジッタに対するバッファ機能はなにをどうしてくれているのでしょうか。
sender→音声→パケット化→ネットワーク→非パケット化→音声→receiver
の流れ。
そもそもジッタは音声パケットが常に一定でないこともあり(UDPだし)揺らぎが生じること。
バッファは途切れ途切れの通信を一定のかたまりにして音声として聞き取れる状態にできるだけしてくれる機能。
ではでは、さっきの流れでどこでバッファを設けて対応しているか？
そう、インターネットを経て対向機器が、パケットから音声化する部分ですよね。
なんでここ間違えるん私wwww
バッファを多く取るとどういったことが発生する？
パケットがインターネットを移動して、対向機器で音声化する部分。
つまりバッファが多すぎるとパケットから音声化するときの遅延が発生してしまう。
まじで悔しいw
フレームを見直す
- イーサネットフレームの基本型↓↓↓
プリアンプル:dst mac:src mac:type:data:FCS
- IPパケットを含めると↓↓↓
dst mac:src mac:type:src ip:dst ip:TCP:data:fcs
いつも疑問だったmacはなぜ宛先が先にくるのか。。。それは受信側が、あ、俺宛てだ。と最初に認識するためらしい。非パケット化と言えばその通りではあるねと。
- 音声混じり(ipヘッダ以降)↓↓↓
ipヘッダ:UDP:RTPヘッダ:音声データ
ヘッダ問題は絶対ミスりたくない。。。
コメント