NGNの資料やIETFのRFCなどから推測すると、NGNでは、SIP (Session Initiation Protocol)を用いてシグナリングする際、SDP (Session Description Protocol)に要求する帯域をkbps単位で記述(b=AS:123など)して帯域を要求しているように思われます。しかし、コンテンツ配信などで使用されるプロトコルは通常SIPではなく、RTSP (Real Time Streaming Protocol, 現在2.0策定中)です。RTSPでもSDPを使用するので、SDPに帯域を記述してRTSPサーバへリクエストを送ると、帯域を確保できると良いのですが、SIPのように間にプロキシあるいはB2B UAが入らないと、帯域確保できないような気がします。
ひとつ考えられるやり方としては、MSRP (Message Session Relay Protocol)のように、SIPで、使用するオーディオ、ビデオ、RTSPのための帯域を確保して、そのセッション内でRTSPでコントロールというのがあります。ただ、これは、標準化された方法ではないのと、SIPとRTSPでSDPに記述する情報がダブってしまうためあまり良くないような気がします。やっぱり、RTSPもプロキシあるいはB2B UAを利用する方法を取るか、SIPでシグナリングを行った後、PLAYやSTOPなどの制御ができる新たなプロトコルを作るのが良いのでしょうね。いったいNTTは、「コンテンツ配信向けQoSユニキャスト(帯域確保)」をどのようなプロトコルで提供するのでしょうね?
と、ここまで書いてからふと思ったのですが、実は(帯域確保)って、必要なときに動的に確保するのではなく、2点間で予め確保しておくという意味かもしれないです。マルチキャストの場合には、予めIP再送信で使用する分を確保しているみたいですから・・・
http://japan.cnet.com/blog/cafe_noir/2007/11/10/entry_25001456/
株式会社 ROMクライアント
http://rom-client.com
0 件のコメント:
コメントを投稿