【第1回】プレゼンスって、必要？：IP電話の誤解を解く（2/3 ページ）

[寺下義文，ITmedia]

ビジネスユースで直面する問題

　では、ビジネスユースではどうだろうか？

　IMのビジネスユースでは一見、パーソナルユースの場合と同じ便利さが享受できると思える。企業ユーザーの多くはそう考えるだろう。だが実は、そうでもない。

　まずビジネスとして用いる場合、コミュニケーションを取りたい相手はいつも特定されているわけではない。ときには、名刺すら取り交わしたことのない相手ともコミュニケーションを持たなければならない場合もある。したがって、そうした不特定多数をバディリストに登録してしまうと、その人名リストの量は膨大なものになる。そうなると、相手の状態を確認する前に、相手を見つけ出すための作業も始めなければならなくなるだろう。

　また、技術的にも大きな問題に直面する。この問題を理解いただくためには、プレゼンスがどのような仕組みで実現されるかを知る必要がある。

　プレゼンスは、インターネット技術の標準化団体、IETFにおいてRFC3856（Standards Track）として規定されており、RFC3265のSUBSCRIBE／NOTIFYという2つのメソッドによって実現される（図2）。

図2●プレゼンスの基本的なシーケンス

　まず、プレゼンティティ（2002番の端末）の状態を知りたいウォッチャー（2001番の端末）は、プレゼンティティの状態を、その状態に変化がある都度通知してもらうためにF01のSUBSCRIBEを発行する。このとき、TOヘッダにはプレゼンティティを表すアドレスを指定し、さらに通知有効期限（Expire）を指定する。

　これをプレゼンスを管理するサーバが受諾すると、200（ok）の応答と同時に、その時点のプレゼンティティの状態をNOTIFYに乗せて返す。

　一方、プレゼンスサーバは各端末の状態を管理するために、各端末が電源ON（つまりREGISTER要求）を受け取ったことを契機にして、ウォッチャーがプレゼンスサーバに向けて行ったのと同様の方法で、状態変化を通知し続けるようプレゼンティティに依頼する（F05〜F07）。

　このF07のNOTIFY（online）を受信したことで、プレゼンスサーバは、プレゼンティティ2002が「offline」から「online」に変化したことを知り、一方でウォッチャー2001からの変化通知要求を受諾している（有効期限内である）ことから、F08のNOTIFYをウォッチャーに送信することになる。以上のように、文字通り極めてシンプル（SIMPLE）なシーケンスだ。

　では、このシーケンスのどこが問題なのか。それは一意のプレゼンティティの状態変化を大多数のウォッチャーが要求している場合、F08がそのウォッチャーの数の分、バースト的に発生するということだ。

　ビジネスユースにおいて、例えば1000名程度の会社で全員が全員をリストに登録したとすると、サーバに及ぼす負荷はねずみ算的に増え、システム的にいとも簡単に破たんしてしまう。コンシューマユースであれば、1対nのnはそれほど多くはならないため、このような事態にはなりにくいが、ビジネスユースではnは会社の規模に応じて増え、深刻な問題を生み出すことになるのだ。