IP電話を作っていない企業がNGN対応の端末やサービスを実装するのは大変そう・・・

NTTがNGNトライアルのモニター募集，首都圏と大阪で700人程度ということで、次世代ネットワーク（NGN）フィールドトライアルのモニター募集を2007年1月18日（木）午前9時30分から開始するそうです。サービスの提供業者は、NTTグループやNGN用のSIPサーバを実装しているNECなど、IP電話やNGNのノウハウがあるところだけのようですね。これから他の企業も増えてくるのでしょうか？IP電話を作っていない企業がNGNに対応する端末やサービスを実装する際に何が大変そうなのかについて少し考えてみたいと思います。

「ラフ・コンセンサス・アンド・ランニング・コード」の思想に基づく仕様が元のはずなのに・・・

NGNで使用されるSIP (Session Initiation Protocol)の元になる仕様はRFC3261など、インターネットで使用するプロトコルを提案するIETF (Internet Engineering Task Force)によって発行された文書です。このIETFの基本的な考え方は、「ラフ・コンセンサス・アンド・ランニング・コード」ということで、始めからキッチリとした仕様を作り、それに従って実装するのではなく、何となく合意を得られた(ラフ・コンセンサス)仕様に元に実装し、動かして使ってみながら仕様を改良していき、ダメなものは淘汰され、生き残ったものがデファクト・スタンダードになるというものです。RFC3261を読んで頂くとわかるようにSIPもそのような思想の元に仕様書が記述されているため、非常にあいまいな部分が多くなっています。また、プロトコルを拡張するための基本ルールに基づいて拡張することが非常に容易です。このため、インターネットの世界では、いろいろな人たちの実装をいろいろな人たちが利用して、便利なものを採用していく文化がある程度出来上がっています。例えば、RFC3261に基づくSIPサーバをフリーライセンスで実装し、それをインターネット上で使用しながら改良していくことが可能です。

ところが、このような思想に基づいた仕様をNTTのNGNでは、クローズドな環境に適用しています。このクローズドな環境に端末やサ　ービスを提供するためには、NTTが提供するSIPサーバの仕様にあわせて端末側やサービスサーバ側のSIPの実装をしなければなりません。また、IP電話IP-PBXのSIPサーバでは、G.711などIP電話で使用されるコーデック以外のものやSIPメッセージに想定外のヘッダが入っていると、エラーを返してくることが多いようです。これは、IETFのRFC3261の拡張ガイドラインにのっとって端末側主導でSIPメッセージを独自拡張することができないことを意味します。NGNなどもIP-PBXと同様にNTTの許可無く拡張することができないような気がします。すなわち、NTT側が想定していない新しいサービスやコーデックを独自で展開しようとしてもインターネットのようにはできないということになります。

ＮＧＮは、SIPを使っているということで、IETFのRFCに基づいたSIPを実装して搭載すればすぐにNGNに接続できると思いがちですが、実際にはNTTのNGNのSIP仕様に基づいたSIPを実装して搭載しなければNGNにはつながりません。IP-PBXのように拡張された部分あるいは想定外のものを無視するか、エラーを返すかは運用ポリシによる違いとも言えますが、端末やサービスを作る側は、その部分をものすごく意識して実装しなければならなくなりそうです。

IPパケット送受信のお作法

NGNのひとつの特徴であるQoS保証の実現ですが、NGNの網内についてはSIPで帯域を要求できれば保証してくれるのですが、実はそれだけではQoS保証は実現できず、端末やサービスサーバにも今まであまり考えていなかったお作法を実装する必要があります。以前もちょっとふれたパケットのシェーピング/ポリシングとIPパケットの優先制御です。例えば、5Mbpsの使用要求を出せば端末やサーバは後は何もしなくても良いということではなく、5Mbps以上IPパケットが送出されないようにしたり、5Mbps以上のパケットを受信したらパケットを捨てる処理をしなければなりません。そのような処理をしないとQoSの保証は実現できなかったりします。このため、リーキーバケットなどを実装しなければなりません。

このQoS保証の基準も標準みたいな話はあまり聞いたことがないので、NTTのNGNのとして仕様が何かあるのではないかと思われます。例えば、コーデック毎に、パケット間隔やパケット遅延時間が決まっているような気がします。G.711μlawが20msのパケット間隔で、G.711Alawだと10msみたいなのが。ＮＧＮの端末やサービスサーバはそういう基準に合わせて正しくパケットを出すといったお作法を正しく守る必要があります。結構大変そうですね。

本当に多くの端末やサービスがNGNに対応しようと思うと大変なことに？

上の話は本当に一例でしかありませんが、NGNに対応した端末やサービスを実装するためには、NGN環境向けに新しい商品を導入するたびに、これらの検証や相互接続性テストを行う必要があります。しかし、そういう体制はちゃんとそろっているのでしょうか？体制が無いとすると、かなり大変な状態になりそうです。それに、インターネットの場合には、固定料金みたいな感じなので、多少のトラブルは目をつぶってもらえる可能性がありますが、NGNの料金体系によってはトラブルが許されない事態となります。

そういう点から考えてみると、実はNGNへ端末やサービスが参入するハードルは非常に高いように思いますね。