どうするNGN 〜 Forward Error CorrectionやFull Intra Requestの仕様は？

NTTのNGNでは、QoS保証があり、最大遅延時間が保証されていたり、インターネットと比較してパケットロスが少ないために動画などのメディアストリーミングに乱れが少ないと言われています。確かに、SIPによるシグナリングで使用する帯域を予め確保するので、パケットロスが発生しないように思われがちです。しかし、NGNであっても100%パケットロスが発生しないわけではありません。このため、NGNに接続する端末は、パケットロスが発生する可能性を考慮して仕様を決める必要があります。

パケットロスが発生するとどのような状況が発生するでしょうか？例えば、H.264ストリームを考えると、パケットロスしたデータが一瞬だけ表示されず、すぐに次の映像が表示されるように思います。ところが、失われたデータによっては、しばらく映像が出なくなってしまいます。 H.264は、非常に簡単に言ってしまえば、IDRフレーム、Bフレーム、Pフレームのように役割の違う画像の集まりによって動画を作ります。このうち、IDRフレームというのが、１画面全体の映像のデータを持ったフレームで、BフレームやPフレームは、IDRフレームからの差分データによって構成されています。このため、IDRフレームがパケットロスによって伝送できないと、その後にBフレームやPフレームのデータを受信しても、差分の元のデータ情報がないために正しい画像が表示できないわけです。

インターネット上のVoDのストリームのようにデータの遅延があっても問題がなければ、端末側にバッファを用意し、ダウンロードしながら再生するなどの方法を取ることができます。しかしながら、TV電話やTV会議システム等のように遅延が許されない端末では、バッファによる方法を取ることはできません。

このような問題を回避するための方法として、FEC(Forward Error Correction)やFIR(Full Intra Request)のような方法がありますが、実は、IETFなどでもちゃんとした仕様がまだ決まっていなかったりします。NGNではどうするのでしょうか？既にNGNトライアルで一般家庭にIPTVやTV電話を使ってもらっているのに公開されている資料には仕様が載っていないためちょっと不思議に思ってしまいました。パケットロスは発生しないと主張するのかな（笑)。

■FEC (Forward Error Correction)

FECは、非常に簡単に言ってしまえば、パケットロス等によって元のデータの一部が失われても修復できるように情報を重複して送る方式です。はじめからFECコーデックみたいな感じで、ひとつのメディアストリームとH.264ストリームとFECの差分ストリームの2本以上に分けて送る方式があります。何となく、2本以上のメディアストリームに分けて送る方が主流のような気がしています。

2本以上のストリームに分けて送る場合、元のストリームとそれに対応するFECのストリームを分かるようにSDPへ記述しなければいけません。この記述をできるようにするために[RFC4756]という仕様があります。この仕様では、2つ以上のストリームをグループとして扱えるようになります。

実は、このストリームをグループとして扱えるのは、結構重要だったりします。もし、SDPにストリームをグループとして記述できないとすると、SDPの記述を見ただけでは単に独立した2本のメディアストリームが流れるのか、元ストリームとFECストリームかの区別が付かなくなってしまいます。また、元ストリームとFECストリームの対応付けも分からなくなってしまいます。

NGNの仕様はどうなっているのでしょうね？

■FIR (Full Intra Request)

FECがあればパケットロスも一安心と言いたいところですが、現実にはFECで100%修復できるわけではないことと、FECを使用すると修復用のデータがどうしても増えてしまうためいつでも使用できるわけではありません。このため、受信側端末がIDRフレームを正しく受信できなかった場合に、IDRフレームの再送要求を出す方法があります。これをFIRまたはFast Updateと呼んでいるようです。

例えば、SIPを用いたTV会議システム等の世界においてFIRは、従来、SIPのINFOメソッドにXMLで記述されたコマンドを送信することで実現されていました。このコマンド仕様は、IETFのDraft[XML-MC]に記載されています。しかし、NTT NGNでは、SIPのINFOメソッドを許可していません。このため、この方法を利用することはできません。なぜINFOメソッドを許可していないのか理由は分かりませんが。INFOメソッドは、SIPサーバを経由してしまうために、勝手に送られるとSIPサーバの負荷が高くなってしまうからかな？

それ以外にこれを実現する方法としては、RTCP Feedback([RFC4585] )を使用する方法があります。RTCP Feedbackでは、RTCPでACKやNACKのような情報を送ることで、パケットが正しく受信できたかどうかを確認することができます。さらに、まだ、Draftですが、[CCM-AVPF]という方法が提案されています。こちらは、前のRTCP FeedbackにFIRなどを追加したもので、RTCPを使ってFIRを送信することができます。RTCPを使用した方法は、前のINFOメソッドを使用した方法とは異なり、SIPサーバを経由することなく端末間でやり取りすることができます。個人的には、こちらの方が良さそうな気がします。

RTCP Feedbackによる方法で、ひとつ考慮しなければいけないのは、RTPの[RFC3550] に記載されているRTCP最小送信間隔との関係です。データの一部が失われるタイミングはいつかわかりません。[RFC3550] では、通常の最小送信間隔を5秒として、さらに短くする場合のお勧めとしては、360/メディアのビットレート(kbps)としています。例えば、ビットレートが360kbpsだと、最小送信間隔は1秒ということになります。H.264の動画データは、もっとビットレートが高いので、さらに最小送信間隔を小さくすることは可能かもしれませんが、あまり間隔を短くするとマルチポイントなどのときなどにRTCPパケットの量が増えすぎるので問題となりそうです。

ここで、FIRとは関係ないRTCPが送信された後にFIRのRTCPを送信することを考えると、FIRのRTCPはいったい前のRTCPからどのくらい間隔をあけて送信すれば良いのでしょう？あまり間隔が短いと端末側がFIRのRTCPを受信できないかもしれません。例えば、端末側がRTCPの最小送信間隔を5秒として設計されていた場合、5秒よりも早いタイミングでRTCPを送信して端末側が正しくRTCPを受信できるのかという問題があります。しかし、前のRTCPから5秒後にFIRのRTCPを送るとなると、5秒間動画が表示されないことになってしまいます。

NGNの仕様はどうなっているのでしょうね？独自仕様じゃないと良いけど・・・

参考文献

[RFC4756] Forward Error Correction Grouping Semantics in Session Description Protocol [XML-MC] XML Schema for Media Control [RFC4585] Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF) [CCM-AVPF] Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF) [RFC3550] RTP: A Transport Protocol for Real-Time Applications