中妻穣太さんの日記から、SKYPEについてのトラックバックをいただきました。ありがとうございます。いつも参考にさせていただいてます。
ということで、本日は、中妻さんの記事を参考に、「日本の通信産業の構造が、ここ数年でどうなっちゃうの?」という点について、技術と経営の両面から考えてみたいと思います。
どうやってファイヤーウォールをくぐり抜けてるか?
基本的な原理は、既にいくつかの、ファイアウォールを越えて内部情報を取得する類のアプリケーションで実装されているものと同じだと思います。
1.端末にエージェントプログラムが常駐。
2.エージェントは「今ボクにコール来てない?」とひっきりなしに外のスーパーノード*1に問い合わせる。
Outbound(内側から外側への通信)なので、普通ファイアウォールは通す設定になっている。
3.コールが来てたらセッションをつなぐ。
4.セッションがつながったらUDPで通話。
という仕組みじゃないかなー、と推測しています。
私も、(詳しいことはわかりませんが)、そんなしくみ(すなわち、内側から常時問い合わせてるの)かなーと思ってました。
が。
私は、外出してノートパソコンからブロードバンド携帯のカードでインターネット接続することが多いもんで、「Skypeを立ち上げてたらパケットがダラダラ垂れ流されて請求書を見て青ざめる」という事態を避けたかったので、Windowsの「接続の状態」でパケットの送信/受信のバイト数を見ていたのですが、不思議なことに、「ひっきりなしに」送受信のやりとりが発生するということがないんです。というか、数分間、まったく1バイトも送受信がなかったりします。(高めのパケットパックに入ってれば、1時間でせいぜい数円程度の通信量。)
もし、outboundで「数分間に一度郵便受けを見に行く」方式だとすると、電話をかけたほうは数分間待たされることもある、ということになるわけですが、そんなアホな「電話」ってのもないはずで。リアルタイムにinboundにパケットが入ってこれるカラクリが何かあるんじゃないでしょうか。
この仕組み自体は既にファイアウォール越えテクニックとして知られているものですが、たぶんファイアウォールを越えればできるってもんでもなくて、「常時接続」「P2P」「VoIP」「遅延を減らす」「音質の向上」などの条件がクリアされることが、Skypeの登場には必要だったのではないでしょうか。
そうなんでしょうね。
何か単純でない技術的な障壁がないのであれば、どう考えても、金の力にあかせて、とっくにMicrosoftがWindows(MSN) MessengerにSKYPEと同じ機能を実装しているはずです。
Skypeを携帯に移植できるか?
SKYPEのような機能を携帯に移植して「世界中どこへかけてもタダの携帯電話」ができるか、という点についての中妻穣太さんのコメントですが、
障壁となりうるものとしては、以下のようなものが考えられます。
・アプリケーションのサイズ。PC版Skypeは9MBもあります。こんなものを載せられる携帯端末は今のところ存在しません。もちろん携帯向けにはもっと小さいものが作れるでしょうが…。
「SDカードをHDD的に使って、メモリにロードして実行」って、今の端末でできるのかな…?
・携帯のスペックとアプリケーションの速度。携帯のCPU・メモリ性能はPCよりもはるかに限られたものしかありません。確実なところはなんとも言えませんが、音声CODECを遅延なく扱うのは厳しいかも…
あくまで「P2P」という形にこだわるなら別ですが、技術的にはサーバー側で重い処理は引き受ければ、似たようなサービスはできるような気もします。
「ドラクエ」ができるんならできるんじゃないの?というシロウト考え、ですが。(笑)
基地局の容量逼迫。パケット定額制は実は携帯電話会社にとってバクチでして、基地局は「常時接続なんぼでもこいや!」と胸をはれるほどには性能に余裕はありません。局所的に多数の人間が一斉に常時接続でリッチコンテンツを送受信し始めたら、基地局がパンクすることが予想されます。
これはおっしゃるとおりだと思います。が、携帯電話会社のビジネスモデルが破綻することと、技術的にできるかどうかはまた違う話で、携帯電話会社が好むと好まざるとに係わらず世の中が変わっていく可能性があるところが、SKYPEがインスパイアするおもしろいところかと思います。
…と、いろいろイチャモンをつけてはみたものの、「携帯でSkype」がとっても魅力的なのは事実。
まずは「携帯でP2P」というところにどこまで可能性があるか、ちょっと考えてみようかな…。
ちなみに、知り合いが携帯電話でMSN Messengerを使うのに成功したというウワサを聞きました。(技術的にどう実装したのかというような細かいところはまだ聞いてませんが・・・。)
アプリで音声を使わせない等の制約がないのであれば、できると思うんですけどねえ。(あくまで、シロウト考え、で。)
今後の「バトル」のシナリオ
さて、多分、携帯電話でSKYPE的なサービスをする場合、(技術でなく)ユーザビリティの観点から見た場合の最大の問題は、「相手の電話番号以外に、ユーザ名とかパスワードとかいろいろ入れなきゃいけなくて、めんどくさい」ということかと思います。
つまり、携帯電話キャリアさん自体がそういうサービスを実装して、ゲリラよりは若干高めだが「めんどくささを考えたら、ま、こっちでいいか」というくらいの料金体系まで下げたところで、このゲリラ戦は終了するはずです。
すなわち、今後の日本の携帯電話市場は、
1.まずは、SKYPEのようなゲリラ的なサービスが登場。(ただし、公式メニューになるはずもなく、ユーザーは結構めんどくさいユーザ名とかパスワードとかの入力を強いられるが、それでも、という人だけが使う。)
携帯のアプリに音声が通せる、など、技術的にこうしたゲリラ的サービスが使える「抜け道」が開いていれば、の話ですが・・・。
2.報道などで「タダで携帯で世界中の人と話せる方法があるらしい。」てなことが、だんだん知れ渡ってくる。
3.これと前後して(あるいは全く関係なく)、ユーザーの獲得などで伸び悩んでいる3番手以下の携帯電話キャリアの中から「当社利用者同士の会話は無料」「IP電話やパソコンなどのSKYPEユーザーとも通話無料」てな「禁断の一手」に手を出すところが現れる。
4.業界秩序を乱すそうした料金体系に眉をひそめていた1、2番手のノーブルなキャリアさんも、競争上しぶしぶ、料金体系を固定料金的なものに近づけてきて、市場が均衡状態となる。
というような、弁証法的?発展段階を経るのではないかと想像されます。
「誰が」やってくれるのか?
第3のステップですが、これをどういうところがやってくださるかというと、やはり「あの」会社さんあたりではないでしょうか。
NASDAQを日本に連れてきていただいたおかげで(NASDAQは結局撤退しちゃったけど)、「官僚より官僚的」とまで言われた東証さんが「マザース」市場を創設し、営業活動でベンチャー企業を回るようにまでなっちゃうというように、日本の資本市場を大きく変えた、とか、
ADSLモデムを駅前でばらまいて(ご本人のADSL事業は極めて収益性が悪いけれども)、おかげで、日本のブロードバンドが世界トップクラスの普及率と低料金になっちゃった、とか・・・・でおなじみの「あの」会社さん、です。
(当然、今注目度急上昇の「あちらの」会社さんあたりも激しく興味を示されるに違いありませんが、まだ、いくらなんでも数千億円の投資をしていくには、財務的な体力が厳しいのではないかと・・・。)
「あの」会社さんのほうは、実際、携帯電話会社の買収にも意欲を示されているようですので、当然、携帯電話会社をグループ化したあかつきには、IP電話などとの無料通話は打ち出してこられるのではないかと、想像いたします。
あの会社さんも、ADSLというような「物理層の上」のレイヤーを押さえているだけでは、競争ばっかり激しくて、いつまで経っても利益を安定的に出すのは厳しいわけで。固定・携帯を含めた「物理層」を全部押さえてはじめて、理論的に超過利潤が発生する可能性が出てきます。
当然、「業界の和を乱す」だけでなく、NASDAQのように結局「当て馬」に終わってしまう可能性も高い戦略なわけですが、一消費者としては、ぜひともやっていただけるとありがたいですね。
(ではまた。)
[PR]
メールマガジン週刊isologue(毎週月曜日発行840円/月):
「note」でのお申し込みはこちらから。
[voip][p2p][keitai]Skype話その3・SIPに目もくれなかったSkype
磯崎さんにトラックバックをいただきました。ありがとうございます。 Windowsの「接続の状態」でパケットの送信/受信のバイト数を見ていたのですが、不思議なことに、「ひっきりなしに」送受信のやりとり …
ちょうど今日の日経でこんな記事がありました。
http://www.nikkei.co.jp/keitai/saishin/20040805e001y00605.html
磯崎さん曰く:
「もし、outboundで「数分間に一度郵便受けを見に行く」方式だとすると、電話をかけたほうは数分間待たされることもある、ということになるわけですが、そんなアホな「電話」ってのもないはずで。リアルタイムにinboundにパケットが入ってこれるカラクリが何かあるんじゃないでしょうか」
クライエントがスーパーノードへTCPベースのセッションを一旦張ったら、そのセッションはタイムアウトさえしなければ、常時スーパーノードからのinboundパケットを受け付け可能です。
つまり、クライエント側からのpolling無しでも、着信時にはスーパーノードから瞬時にクライエントの方へパケットが送れる紐付けはされていると思います。一時間に一パケットの細々とした”keep-alive”トラヒックでも、ファイヤーウォールに因るセッションの自動タイムアウトを回避するには十分な筈です。 (^^)