なんとなく実験 with SIProp開発記

私も、初期のコード設計に参画したIMS/NGN相互接続実証実験プロジェクトである「HOTARUプロジェクト」が、ついに、ソースコードの一般公開までたどり着きました。

最初の江崎先生の

「おまえら、がんがれ。」

の鶴の一声から、およそ4年。
今思えば、凄まじいスタートではありましたが、何とかソースコードの一般公開までたどり着きました。

現時点のソースコードは、すでに、世界規模のIMSの相互接続イベントである、SIPit(3回)とPlugfestとPlugtestsをくぐり抜けており、それなりの品質に達しております。

もし、IMS/NGNにご興味のある方がおりましたら、ぜひとも、本プロジェクトの成果をお試しいただければと思います。

yusukeたん と、Google Waveについての妄想しておりました。

で、yuskeたんのアウトプットは、こちらに。

ということで、この解釈が正しいとすると、Google Waveですが、立場としては、萌えないと言わざるをえません。（各所でも、ちゃんとそういっているんですけど。）

まぁ、要するにこれって、SIPが、『P2P的』にやろうとしていたものなんですよね。それのHTTP＋Cloud(サーバ)集約版。

GUIというかクライアントアプリをHTTP(クラサバ系プロトコル)に集約して、時代背景であるCloudで処理させるためのプロトコルと。
（時代背景＝yusukeたんのエントリーにある、Viewerとしてのモバイルは今だけど、真のクライアントとしての時代はまだまだ先という話。本Blogでもこの辺は時々突っ込んでます。）

本気で『現時点での普及を目指して』作るのなら、これですね。(時代は、サーバ集約に向かってますから。モバイル端末が、真のクライアントとなるまでは、止まりません。)
さすが、Googleさんという感じです。

そして、これでまたデータがGoogleさんに吸い上げられていくわけですが・・・

Google I/O 2009ネタ。

「Webは開発プラットフォームとして機が熟した、グーグルCEOが講演」

のロードマップスライドの一部、こちら、にXMPPの文字列が！！！

Androidでは、βの時にXMPP(GTalk)との連携機能が付いていましたが、セキュリティー上の問題により、現在、使用不可能となっているので、もしかしたら、Google App Engineと連携して復活するかもしれませんね！
Google App EngineのこのAPIと連携する場合のみ、使用可能となるとか！

今後の動きに、期待です！＞＜

ドコモ「プッシュトーク」サービス終了 とのこと。
日本で一番流行ったSIPベースサービスだったのですが！！！ｗｗｗっｗｗっっｗ
（噂では、裏のシステムで使っていたらしいです。)

しかし、CMにしても遊び感覚でうまく使える物として、悪くなかったと思うんですけどねぇ。
DSのピクトチャットを使った遊びが小学生の間で流行ったような感じで、使われる可能性もあったのですが、やはり、この手のは従量課金じゃつらいですよね。。。

「Skypeが企業向け事業を推進，SIP対応サービスのベータ・テスト開始」という記事。

SIP対応のPBX（社内電話交換機）を使用している企業は，オフィスの電話機から世界中の固定電話や携帯電話に低価格で発信できる。

うおっ。
ついに、AsteriskとSkypeが追加ソフトウェアなしにつながる日が来るのか！！！

Skype中心にコミュニケーションソフトをまとめられれば、面白いことになりそうなんだけど、、、
SIPの復権が近い！？！？！？

「Open Embedded Software Foundation」（OESF）の事業説明会の内容が、日経さんによってリークされました。＞＜
(まぁ、歓迎なんですけどね。一応、リーク記事なので、驚いてみている次第で。(;^_^A アセアセ・・・)

「AndroidをIP電話やテレビに使う」というリーク記事です。

米グーグルが携帯電話向けに開発したAndroidを，組み込み機器向けプラットフォームとして活用することを推進する「Open Embedded Software Foundation」（OESF）が，3月に発足する。携帯電話以外の機器に利用する際に足りない機能を開発し，無償公開するのが主な活動だ。

事業説明会で使った資料や詳細など希望の方は、下記まで連絡してください。

office アットマーク oesf.jp

「Android SDKからのAPI削除、Googleが理由を説明」という記事です。
(Android-SDK-Japanのこちらの投稿も合わせて、読むとよいかとおもいます。)

発端は、こちら。

Android SDKのβ0.9をリリースした際に、GTalkServiceとBluetoothのAPIを削除した。

原因としては、こちら。

Googleは「根本的なセキュリティの問題」が幾つかあるためとし、3つの理由を挙げている。
・Google Talkでは友人の電子メールアドレスや、時には本名も分かってしまうが、Androidユーザーがそれを望まない可能性があるため。
・Androidデバイス内でIntent（メッセージ）を送信する設計になっているため、ほかのデバイスからIntentが送られてきた場合に、それを送信したアプリケーションが確認ができないという問題がある。
・当初のGTalkServiceの設計では、セキュリティ問題の回避やユーザー管理などをアプリケーション開発者が行うようになっており、負担が重くなることにある。

解決策は、こちら。

ただしGoogleはこの種の機能を断念したわけではなく、最初のAndroid端末が登場した後の優先課題として、高速でセキュアなデバイス間メッセージ送信機能の開発を挙げている。

と、まだ、根本的な解決策は出ていないわけですが、｢今のSIPはどげんかせんといかん｣と思っている私的には非常に興味深いですね。
できることなら、PureなP2P対応にしていただきたいと思うのですが、GTalkベースなので、無理ですかねぇ。

やはり、自分で作るしかないのかなぁ。

ひとまず、「クラウド時代の企業コンピューティング：暗号化とデータセキュリティ動向」で情報収集してこようっと。考えているアイデアもあるので、だめだしも聴いてみたいし。

ドコモさんが、「ドコモ　利用者の居場所・嗜好反映　今秋「生活支援型」で情報配信」というサービスを、907シリーズから導入するとのこと。

概要的には、こんな感じ。まぁ、モデルとしては、もう、数年前から言われていたものですね。

利用者の好みや居場所に合わせ、店舗やイベント、地域情報などを自動的に配信する「生活支援型」情報サービスを開始する。周辺の小売店の特売など、その時と場所で役立つ情報をタイミング良く知らせる仕組み

で、これに似たアプリを、次回もあると噂されているVoIPカンファレンス用のネタとして、この７月より、実装中だったりします。

ドコモさんのやつは『位置情報＋個人の嗜好情報』で対個人向けですが、SNSをベースにした『位置情報＋コミュニティー』として、グループ向けのものとなる予定です。で、この仕掛けが、P2P SIP的な何かの雛形となればいいなとか、妄想している今日この頃です。

おまけ
VoIPカンファレンスの発表は、このノリでいくか（ｗ

ついに、SIP＋無線LAN入りの「iL」が一般発売開始です。

無線LAN対応、宅内のVoIPも使える「N906iL」

なに！！これは、うまく応用すると、面白いことになるのでは？？？
たぶん、規約違反にはなりそうだけど、間にAsteriskを挟むとか！＜よい子は、ちゃんと、利用規約をチェックしてね！

ホームU経由のVoIPも可能で、ホームU同士の通話は24時間無料となる。VoIPサービス用に050番号が発行される。

このへん、いや〜〜な雰囲気もありますが。。。

ホームUの利用には、アクセスポイントとなる専用アンテナと対応ブロードバンド回線が必要となる。

とりあえず、ご購入して、902iLとの差分でもチェックしてみよう。
（GPL部分のコードは、ダウンロードできるはずでしょうから。）

さて、実は、前々回のエントリー、前回のエントリーは、まだ、続いています。（そして、これが最後）

完全にリアルが融合してくる世界

が、今回のお題目で、

局所的、刹那的なネットワーク（アドホック通信）が必要な理由

という、ところになるでしょうか？
(実際に、この世界が来るのは、20年以上はあとでしょう。)

さて、前々回のエントリーで、『ネットワーク側に、自分の分身を作る』というお話をさせていただきましたが、これは、

全世界の人が、一つの仮想空間に放り込まれる

ということになります。
これは、セカンドライフやMMORPGの世界です。

この仮想空間内では、その自分の分身が、様々な行動(イベント)を起こすことで、日常やゲームが進行していきます。例えば、仮想空間内での売買取引 や モンスターを倒す などの行動ということになります。

では、『ネットワーク側に、自分の分身を作る』という意味での仮想空間の規模は、どのくらいになりそうか、ちょっと、考えてみましょう。

接続者数(アカウント数)としては、ソーシャルグラフのようなものを考えると、コミュニティー別に疑似人格を作るということもあり得るでしょう。例えば、SIPropのnoritsuna や NEETのnoritsunaなどです。

そうなると、実質的な接続者は、全世界人口の数倍、数百億を超える数となるでしょう。

さらに、行動(イベント)としては、ゲーム内では、インターフェースの都合上(マウスなど)、平行には、1イベントくらいしか起こせません。

しかし、現実の世界においては、平行で行動(イベント)が起きえるシチュエーションが、考慮され始めています。

例えば、ユビキタス空間基盤推進協議会 というところで、「場所にucodeを付与する「空間コード」が描く社会」というようなものが、検討・実証実験されています。
(この空間コードとAR(artificial reality)の世界をうまく融合していけば、ずいぶんと面白そうな世界となると思いませんか？『攻殻機動隊』や『電脳コイル』の世界とか。)

そして、このような世界では、

人が一歩歩くたびに、無数のセンサーからのイベントを受け取ることになる

ため、平行で起きる行動(イベント)が、数十という単位になることが予想されます。

さて、ここで、話を現時点での仮想世界に戻しまして、セカンドライフを考えてみましょう。
セカンドライフでは、1つの島(サーバ？)に、50人までしかアクセスできないという制限があります。MMORPGでは、もっと優秀ではありますが、似たような制限があります。

どうでしょうか？本来は、『数百億アカウント x 数十並列の行動(イベント)』を処理したいのに、現時点での仮想世界では、『数万アカウント x 1〜2並列の行動(イベント)』というレベルにしか達していません。

ここまで、桁が違うと順当な進化では、対応することは不可能でしょう。まったく、新しいブレークスルーが必要と思われます。(これでは、みんな大好き『攻殻機動隊』や『電脳コイル』の世界を、実現できないのです！)

すべてが、接続されてはいながらも、すてが、処理できることが重要な課題の一つなのです。
そこで、

・サーバ側
　永続的に保持したい情報
・クライアント側
　刹那的に処理すればよい情報

という風に分けたりして、分散するなんていう方法論を検討していたりするわけです。
(本当は、もっともっと考慮すべきことが山積されています。ありすぎるので、割愛。)

そして、このように、

今までとは全く違う世界を見据えて、その世界で、ちゃんと動くネットワークを、『再』設計して、『新規』に作り直そう

というが、第八回P2P SIP勉強会の講師の大西さんの研究テーマであります。
そして、この勉強会は、この世界の知識の共有や情報交換、議論をしている勉強会なのです。

ちなみに、この話は、NwGNというキーワードの世界のお話となります。
ご興味のある方は、P2P SIP勉強会に参加してみてください。

最近、SIPがらみの話をしていると言うことで、Distix にて、SIPっぽい話をしてきました。資料は、こちら。PPT版、PDF版。

タイトルは、

SIP、次のフィールドへ

として、いまのIP電話としてのSIPの次は何？という内容です。

要約して言えば、

●次のSIP
　・NGN/IMSで、使われているような汎用セッション用プロトコルとしてのSIP
●さらに、次のSIP
　・移動し、無数に存在する端末の世界(NsGN)における、ソーシャルグラフ(パーミッションやグルーピング化、セキュリティー)を実現するためのプロトコルとしての真・SIP

という、お話です。

前者は、どうでもよいところなのですが、後者は、少々補足を。

まず、話のでだしとしては、最近のバズワード(！？)でいえば、『クラウド化』の話から入ります。私としても、この方向は、来ると思っていて、直近の数年は、こちらの世界となると思います。
(NGNも、P-CSCFというサーバより先は、全く存在が見えない『クラウド』な世界ともいえなくもないですし。。。)

で、その後、5〜10年くらい先の世界を見据えたのが、今回のお話です。

そして、そのくらいの世界においては、

●無線端末
　・移動し、且つ、人間が肌身離さず持っている
●センサー
　・無数に存在し、人間やリアルの情報をデジタル化する

が、台頭してくるのではないかと予測しております。
そして、この世界においては、

●局所的、刹那的なネットワーク（アドホック通信）
　・その場限りで消費してしまう、情報やサービス
　　-ゲームのすれ違い通信
　・クライアント同士でのサービス提供
　　-クライアント端末がサービス提供者(サーバ)になる
●ケータイするデバイス
　・センサーやスピーカー、バイブレーション
　　-物理的な入出力を持ち、物理情報をデジタル化できる
　・肌身離さず持っている
　　-人間をリアルタイムに把握できる

という、状況になるであろうと。
前者においては、アドホックなその場限りのネットワークとなるため、そのような環境で使える『ユビキタスソーシャルグラフ』のようなものが、必要となり、そこにSIPが使えないか？、そして、それこそが、次の次のSIPの役割ではないかというお話です。

簡単には、趣味、嗜好が合う人とグルーピング化されて、情報交換するってイメージです。
例としては（いまいちですが）、街を歩いていて、あるSNSの『お酒好きコミュニティー』に加入している人が近づいてきたら、何か、アクションがある。(または、起こす。この場合は、サーバ的なイメージです。)
そして、それは、

近づいてきたときという、その一瞬の時間だけ意味を成す情報を交換し合うネットワークを構成する

という感じです。

で、後者の話もあるのですが、こちらは、ちょっと、話がずれていて、私がAndroidの先に見ている世界の話となっています。
この手の『センサーが付いた』『肌身離さず持っている』デバイスは、

人間(リアル)の情報を、デジタル(バーチャル)化することができる

ので、

人間のバーチャル化を、手助けするデバイスへの発展

する可能性を持っているのではないかと思っています。
（現時点では、sunspotのほうが、そのもののイメージでありますが、こちらは、現時点では全く手が出せない状態なので、保留中です。もう少し補足すると、PCのようにコモディティー化＋超低価格化することが重要なので、そこが見えてこないと、ぐっと来ないのです。）

このへんは、2006〜2007年くらいのエントリーに書きまくっているAIタグが付いているエントリーのお話である、

ネットワーク側に、自分の分身を作る

に繋がっていき、これをより発展させる可能性を秘めていると考えていて、これが、私的にAndroidに期待することであるというお話です。

●この辺なエントリー
・SIPropの位置付けの俯瞰
・情報をためるということ

ん？「NsGN」って始めて聞いたって？？？そりゃ、「NGNとNwGNの中間」を意味する私の造語ですから！！！
ん？なんで、「s」か？だって？？？そりゃ、「sは、Nとwの中間のアルファベット」ですから！！！

と、ちゃんとオチが付いたところで、今日は、お開き。<(_ _)>

「通信ソフトウェア開発」という連載記事が公開されております。

そして、第二回記事「SIP」に、激しく同意せざるを得ない部分を発見したため、エントリーです。

ここですよね。SIP嫌いなルータ屋やプロトコル屋さんが多い一つの理由は。

ある先輩からは“SIPなんて重たくて駄目だよ。交換ソフトとして組み込むのは厳しい”と一蹴されたものだった。その時の指摘のポイントはプロトコルがテキストベースだからというもの。

まさに、ジレンマ。ほんとに、そう思います。
現状であれば、ルーティングに関わる部分(ViaやRoute系)だけをバイナリ化できれば良さそうなのですが、そもそも、SIP-URIがテキスト形式ですし。。。
かといって、この辺りをヘタにいじってしまい互換が無くなってしまうと、SIPを使う意味がないと。(今までの資産(SIP Stack)が生かせなくなると、SIPを使う意味が無くなる。と、思う。)

対策として、ソフト内部処理では、テキスト形式で処理せず、扱いやすい数字、ビット列に直してしまうこともできる。これなら性能はあがるしメモリ量も大幅に削減できる。 しかし、そうするとそもそもSIPを使う必要があったのか？という疑問が生じてしまう。

で、実は、これが、某所Stackの裏目標でもあったりするのですが、なかなか、解を得るところに行ってません。orz

SIPサーバのソフトとして、これが最良であるというものを早く確立したいが、もう少し時間がかかりそうだ。

ということで、著者の沢村さんの今後に、とても期待します！
なんというか、このことを他に考えている人がいたというのが、素直にうれしい。。。

ついしん
このへん、良いネタをお持ちの方がいらっしゃいましたら、ぜひとも、こっそり教えてください。<(_ _)>

閑話休題

続いて、「SIP 性能課題（前回の続き）」という記事があり、ちょっと、気になったのでコメントを。

前回、SIPによる性能影響について書いたところある方からもう少し解説を、との意見をいただいた。

この「ある方」というのは、IMSのアプリケーション領域のSIPを想定しているのではないでしょうか？
（上記の次の行に、不穏な台詞もあるのですが。。。そこは、あえて無視で！)

アプリケーション領域であれば、SIPの処理より、アプリケーションとしての処理(DBアクセスや音声処理)の方が、圧倒的に高負荷のため、SIPの処理など気にする必要はないという

ですが、著者の沢村さんは、セッションを張るため(現状では、ルーティングがメイン)のSIPのことをおっしゃっているので、このような質問が来たのではないかと、邪推してみた次第です。

「「楽天メッセンジャー」事業化見送り、会社も12月末で解散 」だそうです。いろいろと思いもあるし、ネタもないので、エントリー化。

2007年4月27日に設立されて、もう、解散ですか。動きが速いなぁ。この辺の見切り力は、すばらしい。

で、気になるのは、下記のFusionさんの買収の行方がどうなるのか？ですね。Fusionさんは、Skypeさんと組んでいるわけで、当初からどうなるのか気になっていたわけですが、この流れからすると、すべてFusionさんに一本化するという流れになるのかな？

楽天がフュージョン・コミュニケーションズを夏に子会社化するなど、楽天の通信事業の推進体制が変化していることも挙げている。楽天メッセンジャーの解散は、「現行の体制の見直しの1つ」だと説明している。

でも、こんな話も書いてあるので、どうなるのか、ドキドキものなのですが。。。Fusionさんが、変なことになるといろいろと困ることがあるので、気になっているのですが。。。

楽天では同じく20日、メディア・通信関係の株式への投資事業などを行なう楽天メディア・インベストメント株式会社の解散も発表している。

あと、もう一点、気になるのは、この辺りで。。。約半年で、1億の赤字ですか。。。何に使ったんだろう？？？

9月末までの期間で約1億円強の営業赤字が発生しているという。

「SIPに潜む脅威と対策――IPAが初の本格調査報告書を公開」だそうです。実際の資料は、こちら。

内容的には、SIPのプロトコルとして、弱点となりうるもの一覧と言うところです。SIP実装者にとって、目新しいものはありませんが、SIPの入門書を読み終えた人が参考にすると、とても勉強になる内容だと思います。

やはり、今年はSIPセキュリティー元年といってよい年だったと思います。I-Dも、いろいろと公開されましたし、セキュリティー報告も相次ぎましたし。来年は、製品発表が相次ぎそうですね。
下記に、その辺をピックアップしてまとめておきます。

●セキュリティー記事
・多発するVoIP攻撃

・NECさんのセキュリティーソリューション

・盗聴からVoIPを守れ！敵を知ることがその第一歩

・VoIPの脆弱性検証に使えるファジングツール10選

・VoIPの落とし穴を埋めるもの

●I-D
・SIPにおけるSIPS URIスキームの使用ガイドライン
draft-ietf-sip-sips-07

・SIPのセキュリティメカニズムを使用したコールフロー例
draft-ietf-sip-sec-flows-01

・SIPのための証明書管理サービス
draft-ietf-sip-certs-04

・ZRTP：Diffie-Hellman鍵交換によるRTP拡張
draft-zimmermann-avt-zrtp-04

最近、eBayのSkype買収のその後が、話題となっているので、「eBayの難題、Skype」あたりから、ちょっとだけ。

これは、正しい路線ですよね。音声は、収益的にはおいしいので。だって、(日本国内なら)64kbits/sの帯域(未圧縮音声の場合。Skype(GIPS)ならもっと低サイズ！)で、3分数円の従量課金が出来るのですから！(少なくとも、今は。)

今のSkypeにとっての最善手はモバイルのような別領域の音声通信に進出することと、MySpaceのような大型ウェブサイトにSkypeを組み込む契約を増やすことだ。

長期的には、これと絡めたパーミッション管理システムだというところでしょうか？こちらのエントリーなどで、しばしば取り上げている話ですが。。。

Whitmanはステージ上で、eBayがPalPalを、ウェブのどこででも使える本格個人認証＆評判システムへと成長させたいと考えていることを示唆していた。

で、最後に、「Skype、独自の携帯電話発表へ」を、絡めて、ここの上にeBayシステムをP2P化して構築してもらいたいですね。

「iPhoneアプリに見る「ネットに繋がった端末向けのアプリのあるべき姿」」というエントリー。

Appleが従来型のAPIを公開せずに、AjaxのみをiPhoneアプリ用の開発環境として提供すると決めたのは、業界の「ネットに繋がった端末向けのアプリのあるべき姿」をはっきりと方向付けるものとして一つの一里塚と見ることもできる

ほんとに、そう思います。

ただ、今のブラウザは、パワーが必要(電池食い)なので、もうすこし、その辺を考えた仕組みが欲しいですよねぇ。

たとえば、HTML(HTTP)基準だけではなく、ほかのIM(SIP)の特性なども持ち合わせたようなものを装備して欲しいですね。今のブラウザでは、受信待ちをしたいアプリを作ることがむずかしいので。。。

「知っていますか？ 携帯電話のこんなトリビア」という、書籍『携帯電話はなぜつながるのか』からネタを引っ張ってきた便乗記事です。

何個か、気になった点があったので、ピックアップです。

●お話し中の「プーッ，プーッ」音は信じられない？

どんな時に「プーッ，プーッ」音が鳴るかというと，お話し中はもちろんですが，電話をつなぐ電波や回線に余裕がない時も鳴ります。

う〜ん、いろいろな都合なので書けないのでしょうが、実際にはもっといろいろなパターンがあるそうですが、そこへつっこむ話ではなく、ポイントは「エラーをエラーとして返さない」と言うところでしょうか？

PBX系の某IP電話でよくあるパターンとしては、発生したエラーを分類せずに「エラー応答をそのまま表示」したりします。
そのため、よく知らない人が見たら、例えば「404 Not Found」とエラーが表示され、「壊れた！」と大騒ぎになってしまうことがあります。そして、「信頼性が低い」とレッテルを貼られるわけです。

このほかの例としては、

「SIPの場合、ACKが届くタイミングなどにより、RTPの接続されるまで時間が空くことがある」

そのため、「受話器を取ってから、1秒くらい通話できない」可能性があります。
そこで、通話できる状態になったときに「ピッ」などと音を流す仕組みとして、「最初はしゃべっちゃいけないんだ。待っていよう。」という行動をユーザにさせるという電話機もあったりします。

ということで、何が言いたいかというと「UI重要」って話です。要は、「使えること」が重要とか言う話です。
失敗パターンは、↓ということで。
・auのトラブルで、「110番」に電話が殺到！？

●端末はほとんど寝ている？

待ち受け状態の時には，必要最小限の時間だけ動作させるようにしています。これが，「間欠受信」と呼ぶ技術です。

これこそが、ケータイ向けの待ち受けアプリとして、ブラウザ+Ajax(Comet)だとつらいだろうなぁと思う点の一つです。電池食い過ぎちゃうんですよねぇ。。。

この辺が、どうにかなれば、よいのですが。。。うまく組み合わせて使うの言うのも良さそうですが、当面はやはり、ネイティブなアプリになるのかなと思っています。

「行き詰まるＳｋｙｐｅとＡｓｔｅｒｉｓｋ」というエントリーがありました。

う〜ん、eBayに買収された時点で、終わっていたような。。。(;^_^A アセアセ・・・

Ｓｋｙｐｅが行き詰まっている原因はビジネスモデルに自己矛盾があるからです。

う〜ん、こちらも聞いた話だと、マーク・スペンサー氏が、CEOからCTOになったのは、結局出資者からの要請だったということですし。「Ciscoを超えるには、おまえじゃだめ」とか言われたとか言われないとか。

Ａｓｔｅｒｉｓｋが行き詰まっているのは開発元である米デジウム社が金儲けを始めようとしているからだそうです。

ともに、政治レイヤーでいろいろとあってということが原因と言うことなのですかねぇ。

というのは、実は、どうでもよくて((;^_^A)、本命は、一番最後の一文です。

いずれにしても、テレコミュニケーションのインタビュー記事で述べているように音声通信は激減しているのですから、縮小しつづけるマーケットでＳｋｙｐｅだ、Ａｓｔｅｒｉｓｋだと言ってもしょせん、これからのメインテーマではないと思います。

はい、まさに、全てを物語っているのではないでしょうか？やはり、音声はもう、「当たり前」のサービスであるということです。
これに、プラスで価値をつけなければいけない時代になっているのではないでしょうか？

そのキモとなりそうなものが、プレゼンス情報と私は考えています。
iPhoneには、いろいろとセンサーデバイスが載っていますが、これらもプレゼンスの世界を見据えてのものかと思います。
たとえば、Twitterと加速度センサーを組み合わせて、加速度センサーが歩いているという状態を検知したら、Twitterに「現在、移動中！」などのプレゼンス情報をあげるというような感じです。

そして、このTwitter(HTTP)とiPhone(SIP?)の仲介役として、われわれSIPropプロジェクトでは「雷電」を開発中というわけです。

「非ケータイ」ネットワークの未来」という小寺信さんのコラムです。

モバイルにおける非ケータイネットワークの在り方は、圧倒的な無線LANのカバーエリアに依存する。インフラ代が無料で、ケータイと同じ事ができる、というのはひとつの解だろう。あるいはオンラインである時に、取り込み中とか通話可能とかのステータスがわかることも、新しいメリットだ。「それってケータイでいんじゃね？」と言われない何かが、非ケータイネットワークには必要なのである。

たとえば、スマートフォンといわれるPDAに近いものも、ケータイじゃなくて何か他の形になるのでは？など思っていたりします。
そして、そのデバイスには、PIAXのようなものが搭載されて、新しいネットワークが形成されるというのが、私の希望なわけですが。。。(;^_^A

「多発するVoIP攻撃――VoIP導入には慎重な検討が必要」という記事です。

現状、VoIPシステムに対する攻撃方法は、

VoIPトラフィックのスニッフィング、特定のVoIPシステムの実装の欠陥を突いた攻撃、コールマネージャサーバへの攻撃

が、やはり、もう一点、「端末への攻撃」をあげるべきではないでしょうか？
クライアントで、電源が入っている間、IMやソフトフォンは、ずっと、アクセスを待ち受けているわけです。すなわち、インターネット上にさらされているということです。
もし、IMやソフトフォンに脆弱性があれば、すぐに、乗っ取られ、踏み台や重要なデータが抜かれてしまうかもしれません。
最近は、ハードウェアの端末なども高性能であり、Linuxが載っていたりしますから、こちらも乗っ取られたら大変なことになります。(特に、この手の機器ですと、気がつかない可能性があるため、深刻です。)

ということで、IMやソフトフォンのセキュリティーにも気をつけてねというお話しでした。

「Asterisk開発者，マーク・スペンサー氏への質問を募集します」という記事です。

2007年5月8日に、インタビューするらしいので、それまでに質問を投稿しておくと、聞いてもらえるかもしれないとのことです。

私は、「Asteriskとして、アプリケーションサーバをどうするのか、構想があるのか？」というネタを投稿してみました。

「「競争のための通信事業者への規制は重要」，欧州委員会がフォーラムで強調 」という記事です。

欧州の方でも、やはり、キャリア対策は大変で、日本と同じようなことになっています。というお話のようです。

ただ、向こうは、向こうで、こんなことを思っているとのこと。

「EUよりも日本の方が，電気通信分野のインフラ投資が進んでおり，規制環境も柔軟と言われている。EUは今後，設備投資の促進と規制緩和などをどのように進めるのか」

やはり、隣の芝生は青く見えるのでしょうか？(;^_^A アセアセ・・・

「平成電電破綻の次にあるもの」というコラムです。

2007年3月5日，驚くべきニュースが新聞やテレビを賑わせた。捕まったのは，格安電話の「CHOKKA」を手掛けていた通信ベンチャーの平成電電の佐藤賢治元代表取締役ら計5人。容疑は3人の投資家から，通信機器への投資と称して2005年8月頃に1億円の現金をだましとったということだ。

ということで、その辺は私は門外漢なので、つっこみたいところではなく、本命は、この件で規制の動きが出てきたという部分です。

通信市場の規制を緩和し開放した結果，参入してきた平成電電によって規制の再強化を強いられる。一連の市場開放によってADSLなどブロードバンドが急速に普及したが，ここにきてマイナス面も出てきた格好だ。

(中略)

ユーザーの「自己責任」の範囲は，広がりつつある。

(中略)

移動系の新規参入で、ユーザーは通信自由化の恩恵をきちんと受けることができるのか。通信事業者にはビジネス運営，総務省には市場開放の真価が問われる。

インターネットの通信においては、ISPが一日メンテナンスで使えなくなっても、困る人は少ないと思いますし、実際、定期メンテナンスなどで毎週深夜数時間は利用できないISPもあるわけですし。

とはいっても、本当にこのようにしてしまうと「ライフライン」レベルを求める人は少なく、破綻する可能性があるので、維持させるための仕組みは別途必要になるかもしれません。ただ、その場合は、今の電話網のサイズを縮小することなども含めて議論すべきだと思います。

「IETF P2PSIPワーキンググループ設立」という無印吉澤さんのエントリーです。

気になったのは、この辺。

プレゼンス機能まで含んだリファレンス実装が手元で動かせるようになると、Asteriskのように草の根で普及していく可能性が出てくると思うんですけど……SIMPLE準拠のプレゼンス機能をどうやって/どこまで実装するかは、悩みどころのような気がします。ともあれ、今後の成果に期待ですね。

吉澤さん、これ、すごいことになりそうです。(;^_^A アセアセ・・・
でも、確かに、おもしろそうなネタですね！

※用語などは、この辺を参照してください。

「MS、「Windows Mobile 6」を発表へ--Liveサービスとの連携を強化」との記事です。

ついに、VoIP系の機能が搭載されました。やはり、スマートフォンのデファクトになりつつありますし、Windows Mobileを無視することは難しそうですね。
そして、LCSがより、不動のものになっていくわけです。

Windows Mobile 6でなされた変更のうち、コンシューマーの目には映らないものとして、VoIP通話のサポートがある。Microsoftは個人がVoIP通話することを可能にするソフトウェアは提供しないが、通信事業者やデバイスメーカーが希望すればVoIPをサポートできるような仕組みは用意している。

「NET&COM2007」が、2007/02/07〜2007/02/09まで開催されました。
また、「NTT R&Dフォーラム」も、2007/02/08〜2007/02/09まで開催されました。

その中から、面白そうなものをピックアップです。

■NTTさんの野望
●【NET&COM2007】「“NGN”はNTTだけでは実現できない」−−NTT橋本常務が宣言

NGNのコンセプトをまとめたイメージ・ビデオを上映した後に，NTTが構築中のNGNの特徴を概説。構成する技術はITU-Tが定める標準仕様と同じとし，世界標準としてのNGN構築の一環である点を強調した。

ITU-Tの仕様は、こちらのエントリーで書いた「トランザクションレベル」の仕様しかないのですよね。
サービスをする上で、重要な「シーケンスレベル」の部分は、どうなっているのかというと、

「NTTが何かを支配するというのはあってはならないこと。悪意のあるユーザーを排除する目的の制限はかけるが，NGNはNTTの独善ではできないサービス。オープンとコラボレーションがキーワード」

●【NTT R&Dフォーラム】「R&DなくしてICT社会の到来なし」，NTTの花澤第三部門長

となりそうなわけですが、、、

NGNの接続インタフェースの一つである『SNI』（application server-network interface）の仕様をオープンにしたことは，バーチャルの世界からネットワークを使うという新しい試みとなる

(中略)

「NGNのインタフェースを開示したあとも，『SNIの仕様がよく分からない』，『SNIの開示情報が十分でない』などの意見があるが，NGNのアプリケーションを作る上で，ネットワークはどういう機能を提示すればいいのかという議論をしながらSNIを固めていく」

■相反するもの
●【NTT R&Dフォーラム】「ICTの影の部分もNGNで解決する」，NTT和田社長が基調講演

和田社長はICTによって生まれた影の部分についても言及。ワンクリック詐欺や不正アクセス，著作権侵害，チャットやオンライン・ゲームに没頭しすぎるインターネット依存症などを例に挙げた。
(中略)
和田社長は，NGNがこれらの影の部分を解決する手段になり得ると位置付けた。その手段として，「回線ごとの発信者IDをチェックすることによってなりすましを防止したり，ネットワークの入り口で不正アクセスや異常トラフィックをブロックしてセキュリティを確保する」といった

このセキュリティコントロールって、どうやるんでしょうね？この話を見る限りだと「NGNしかないネットワーク」を想定しているようにしか思えないのですが。。。インターネットとの融合は無しなのかな？

■IMSの一つの解
●【NET&COM2007】ノーテルとIBM，NGN上で動くネットワーク・ゲームをデモ公開

ケータイ端末―ケータイ網―インターネット―NGN―サーバ という経路でのデモだそうです。

端末からフランスにある模擬的なNGNまでは，ソフトバンクモバイルの携帯電話網からオーストラリアのオプタスの携帯電話網を通り，インターネットを経由して接続している。

●【NET&COM2007】HTCのスマートフォンをIP電話に，NVCがソリューション展示

う〜ん、画面を見るとX-Liteにみえますが、気のせいですかね？

ネットワークバリューコンポネンツ（NVC）は東京ビッグサイトで開催中の「NET&COM2007」で，NTTドコモのスマートフォン「htcZ」を利用したIP電話ソリューションを展示した

「NTTドコモがフルブラウザ定額を3月開始，PC用定額サービスも今秋準備」という記事です。

NTTドコモはiモードに対応していないSymbian OS搭載の「M1000」とWindows Mobile搭載の「htc Z」向けのパケット定額サービス「Biz・ホーダイ」も発表した。月額定額料金はパケ・ホーダイと同じ5985円。

パソコンに接続して行なうデータ通信やiモード通信は対象外だが、両機種でのWebブラウジングやメールにかかるパケット通信は定額で利用できる。

とか、思ったら、さらに、

対象端末に専用のアプリケーションをダウンロードし、別途設定をすることによりご利用いただけます。

でも、定額化の一歩として、素直に喜びたいと思います。＞まぁ、私は利用しませんが。(;^_^A アセアセ・・・

そして、「ソフトバンク、“対ドコモ”の新パケット定額サービス」という記事です。

さすが、ソフトバンクさん、間髪入れずに発表です。(;^_^A
で、内容を見てみると、、、

「パケット定額フル」はS!メール・Yahoo!ケータイ・PCサイトブラウザが定額で利用できる。SMS送信は1通5.25円、PCサイトダイレクトとパソコン接続でのデータ通信は1パケット0.021円となる。 一方の「パケット定額Biz」は、S!メール・Yahoo!ケータイ・PCサイトダイレクトが定額の対象となっている。SMSやPCサイトブラウザ、パソコン接続でのデータ通信は対象外。こちらの対象機種はX01HTとX01NKの2機種。

2007/01/30までのVoIP系のニュースをまとめて。

●NTTの中間期決算から見えてくるもの

売上高が3期ぶりに前年同期比で僅かに増収（0.3％）となったもの、営業費用が2.0％増加し、営業利益は9.4％減の6,915億円にとどまった。売上高営業利益率も1.4ポイント悪化し13.2％となった。

●NTTの光ファイバの貸し出し形態，NGNの接続ルールの議論で再検討

1分岐単位の貸し出しは，NGN（次世代ネットワーク）の接続ルールを検討する際に改めて議論する方針を打ち出した。これから構築するNGNであれば，1分岐単位で貸し出す仕組みをあらかじめ取り入れることで，上記の問題を緩和できる可能性が高いからだ。

●通信・放送問題タスクフォースが初回会合，改革の進展をチェック

タスクフォースの位置付けを，「政策を提案した竹中懇談会とは異なり，既に作成した報告書や政府与党合意，改革プログラムをチェックする役割を果たす。付け加えはあるかもしれないが，新しい政策を一から提言する機関ではない。『いつまでに報告書を作成する』などの時限的な組織でもない」と説明した。

●ウィルコム、最大800kbpsの「W-OAM typeG」を今春導入

着実に早くなっているのですが、つぎのブレークスルーは何なのでしょうか？無線の高速化で取り入れられそうなものは、もう、一通りは行ってしまった感がありますが。
PCカード型の「AX530IN」ですが、プレミアム感を出すために、とか、訳のわからないことをやる暇があったら、W-SIM版をさっさと出してください。

●市外局番を省略して電話をかけるとつながらない現象が全国で多発

番号計画問題。とても複雑なので、もう、見たくもありません。

●理想と現実が交錯するNGNフィールド・トライアル

映像系かNNI接続ばかりですね。

●NTT東西、IPv6対応のIPテレビ電話サービスを相互接続

今更感はありますが、逆にNGNがあるので、必要になったと言うところですかね。

NECさんより、立て続けに2つ、VoIPのセキュリティーソリューションが発表されました。
やはり、今年は、セキュリティー関連の一つのキモとなりそうですね。

●「IP電話の盗聴を困難にする技術、東北大学とNECが共同開発」

SRTPやIPsecのような暗号化方式ではなく、音声データを複数のデータに分割し、それらのデータをインターネット上の異なる経路で送信。分割されたデータから元の音声に復号する方式の技術である。

●「IP電話による“迷惑電話”を撃退、NECが新技術を開発」

IP電話を使って不特定多数にかけられる“迷惑電話”を、サーバー上で遮断する技術「VoIP SEAL」を開発したと発表した

具体的には、サーバーで電話を一度受けて、相手に何らかの質問をする。そして、その応答から電話をかけてきた相手がプログラムか人間かを判断する。「応答の内容ではなく、応答のタイミングなどから判断する」（NEC）。

インターネット側の世界では、これのクライアント版ソリューションが、間違いなく必要になってくると思われますので、今のうちにつくっておかないとなりませんね。

「ビジネスコミュニケーションの変遷と、IMの今」という連載が、開始されています。

何はともあれ、現在のソフトフォンが生き残るには、こちらの道を究めていくという方向しかなさそうですので、ソフトフォンがらみの動向が気になる方は、是非ともチェックしていただきたい連載です。

2007/01/12までのVoIP系のニュースをまとめて。

●フュージョン，Skypeから固定電話への着信サービスを開始

やっとという感じでしょうか？

●J:COM、下り最大160Mbpsの超高速インターネットサービス開始

VoIP界のダークホースのJ:COMさんです。個人的に、CATV系は弱いので、少しルートがほしいのですが。。。誰か、紹介してくれないかなぁ。

●NTTドコモ、133億円で日テレ株式の3％を取得、提携を強化

一応。

●バーコードリーダーを接続できる法人向けフルブラウザ登場

企業向けに結構需要がありそうですね。ただ、カメラで撮れる方が便利な気がしますが。

●IM経由の攻撃が増加、高度化へ

今年のキーワードの一つとなりそうですね。

●NTTレゾナントと三菱総研、IP電話の利用動向を調査――050型IP電話から0AB〜J型IP電話への切替意向は4割以上

ほとんどが従来の固定電話の番号を引き継ぐことができ、固定電話並みの品質と、緊急通報がかけられるという利点がある。

ん？後半の2つは、0AB〜J型だからではなく、0AB〜J型でしかサービスをしていないだけでは？？？
まぁ、利用者からすれば、どちらも同じことではありますが、調査報告の結論としてはどうなんでしょうね？

●NGN時代は“方言吸収”がカギ，アプリ・サーバーで進むSIP対応

う〜ん、タイトルとして取り上げるべきは、そこじゃない気がするニュースですね。

Asterisk1.4の開発者向けマニュアルが、公開されてます。
doxygenで、作成しただけのようですが。。。

こういうのを出してくるということは、もうそろそろ、正式リリースということなのでしょうか？？？

「ASP、大規模企業向けAsterisk IP-PBX導入ソリューションを展開」という記事です。

ついに、Asteriskも大規模運用に向けて動き出したと思ったのですが、

接続台数はAT-3000が100台まで、AT-5000が500台まで。

でも、こういう市場で使われ始めたという事実が、非常に重要ですので、どんどんとやってもらいたいものです。

「Webサイト向け問い合わせ用IP電話サービス，リンクが開始」という記事です。

ユーザーがリンクをクリックすると，IP電話の問い合わせ用画面が立ち上がり，すぐに無料の問い合わせができるようになる仕組み。

まぁ、モデルにより、対策は可能だと思いますので、こちらは、問題ないかと思うのですが、

ヘッドセットなどを持っていないユーザーでも，固定電話や携帯電話の電話番号を指定すれば事業者から電話をかけてもらえるという。

「ITU TELECOM WORLD 2006」が、2006/12/04〜2006/12/08 まで、香港で開催されました。

その記事が、各所であがってきておりますので、面白そうなところをリンクしておきます。。

■NGN&VoIP関連(キャリア)
●KDDI小野寺社長、「ウルトラ3G」などモバイル事業戦略を語る

●ドコモ中村社長、「903iシリーズ」など紹介し中長期ビジョン語る

●NTTドコモ，ハチソンなどアジアの8携帯電話事業者がアライアンス

●TELECOM 2006 会場にみたNGNのダイナミックな展開

■NGN&VoIP関連(ベンダー)
●「ネットワーク接続のリスクを考慮したICTを」富士通の秋草会長

●「既存ネットワークのIP化では不十分」NEC矢野社長が語る理想のNGN像

●米ArubaがNGN時代のFMC戦略を発表，沖電気工業との協業も

●パナソニック モバイルが4Gシステム開発シミュレータを展示

●モトローラのシームレス・コミュニケーションシステム，研究所で開発したコンセプト・システムを展示

■ケータイ端末関連
●沖アクセステクノロジーがIMS対応携帯電話を参考展示

●ACCESSがLinuxにフル対応，WindowsMobileやSymbianOSとの関係をCTO鎌田氏に聞く

●“中国産”の3G携帯，TD-SCDMA産業連盟がアピール

●NTTドコモが“音”で携帯電話にデータを送る「アコースティックOFDM」を披露

●テンキーのすき間に文字キーを置く携帯電話用の新インタフェースが登場

●香港メーカーがHSDPA端末を展示，HSDPA/無線LANデュアルも

■無線インフラ関連
●ITU内海氏、「ブロードバンドの普及でユーザー参加型の情報社会が到来」

●クアルコム，高速無線「FLASH-OFDM」をオンライン・ゲームでアピール

●KDDI研、モバイルWiMAXとEV-DO携帯間のハンドオーバー技術をデモ

●モバイルWiMAXで高品質動画を伝送，富士通がデモ

■IPTV関連
●番組配信プラットフォーム「Microsoft TV IPTV Edition」をデモ
●MicrosoftのMehta氏、「Microsoft TV IPTV Edition」の特徴を紹介

●パナソニック、無線LAN携帯電話を利用したDLNA機能やテレビ電話デモ
●パナソニック モバイル、無線LAN/携帯デュアル端末でDLNAによるビデオ制御やIPテレビ電話をデモ

●東芝もIPテレビ電話などが可能な無線LAN/携帯デュアル端末を開発
●シンクラ，IP電話，DLNAクライアントの1台3役端末，東芝が参考出品
●東芝、FMCやIMSを見据えた無線LAN利用のIPテレビ電話携帯端末を試作

●アクセスがDLNA 1.5対応の試作PDAをデモ展示

●シスコがコンテンツ配信技術Video2.0を発表，その目的と特徴を聞く

「GoogleはVoIPから撤退していない」という記事です。

クリック・トゥ・コールは地元商店にイタズラ電話をかける人があまりにも多かったため、Google Mapsでは11月末から利用中止となっている。
Googleはサービス中止の報道後、このサービスを再開したようだが問題再発防止の対策がなされた形跡は見当たらない。

やはり、この手のサービスは、結構難しいのかもしれませんね。

※少なくとも私にも、よい いたずら防止策は思いつきませんし。(ビジネスモデル自体に手を入れないと無理な気がします。)

NTT東のひかり電話，障害はソフトウエアの不具合が原因 という記事です。

2006年12月5日に起きた障害の原因が公開されました。

原因は、また「バグ」だそうです。

通信を識別するための信号情報の重複が，3台あるうちの1台の呼制御サーバーあてに発生。この際，重複した情報をメモリー上から消去する処理が機能するはずだったが，「捨てていく機能が働かなかった」（NTT東日本）。そのため，サーバーのメモリー上に不要なデータが蓄積され呼処理に影響を与えたという。

吉澤さんの「SIPropの意義 / SIPの相互接続性問題を、NAT越え問題と対比して考える」のエントリーにて、

実際、「SIPには方言がある」ということ自体は関係者の間で周知されていると思うのですが、僕みたいに「SIPがどんなものか何となく知っている」程度の人間には、具体的にどういう問題があるのかさっぱり分かってないのではないでしょうか。

というところがありましたので、相互接続問題の大枠の整理をしてみたいと思います。
実際に詳細を見ていくと、大きく3つの問題に分かれることになります。


●トランザクション(SIPスタック)レベルの問題
こちらは、どのくらいRFCに準拠しているか や RFCの曖昧さから出てくる問題点となります。

たとえば、ダイアログ(セッション)を終了するBYEの問題があります。
RFC的には、

既存ダイアログ外のBYEに対する応答は、既存ダイアログが見つからなかったことを示す481応答を返すべきである[SHOULD]

とされています。
BYEは、既存ダイアログを終了させるメソッドであるため、その終了させるべきダイアログがなければ、481応答を返すことは妥当のように思われます。

しかし、違う考え方もあります。
それは、BYEというトランザクションレベル(リクエスト〜レスポンスまで)で処理を考えた場合です。
その場合、たとえ終了させるべきダイアログがなく、BYEのセッション終了としての動作は失敗したとしても、BYEトランザクションとして正常に処理されれば、BYEトランザクションとして200OK応答を返すという考え方です。
この動作は、トランザクション動作としては正しいですし、BYEのセッション終了としても481応答が[SHOULD]であるため、RFC的には問題ない動作となります。

そして、これを現場レベルの視点で見ると、

481応答を返すには、BYEのダイアログに対して、既存ダイアログをチェックするルーチンが必要になる → 工数が増える！！！

という課題が出てきます。
そのため、SIProp的に制約条件といっているものが考慮されて、RFC推奨の481応答実装ではなく、200OK応答実装がされてしまう場合があり、ダイアログ外のBYEに対する応答に2種類の実装が存在してしまうのです。

●シーケンス(UA・機能)レベルの問題
基本的に、RFCでは、トランザクションの定義はありますが、シーケンス(機能)に関する定義はありません。そのため、SIPをPBXのプロトコルとして使用する場合には、独自でシーケンス(機能)を定義する必要があるのです。
※一部「draft-ietf-sipping-service-examples」にて、シーケンスの推奨仕様が示されています。

たとえば、電話でよく使用される保留機能(保留シーケンス)があります。
シーケンス(機能)の推奨仕様「draft-ietf-sipping-service-examples」には、「Re-INVITEにより保留音に変更する」と「Mediaサーバへの転送する」の二つが提案されています。
しかし、日本における実サービスとしては、「マイクとスピーカをミュートし、音声を保留音に変更する」というSIPを一切使用しない独自実装になっていることが多いです。

これは、保留機能というものが、 RFCのSIPの仕様外の機能である点 と 各社が独自に持っているPBXとの整合性を取るために独自にシーケンス(機能)を定義して実装 してしまっているからです。
（もちろん、SIProp的に制約条件といっているものが考慮されている場合もあります。)
そのため、「保留機能」といっても、何種類ものシーケンス(機能)が存在してしまうのです。特に、この場合は、シーケンス(機能)自体が変わってしまうため、相互接続問題が発生してしまいます。

●スペック(機能仕様)レベルの問題
これは、プロトコル的には、シーケンス(UA・機能)レベルの問題と同じではあるのですが、UAとしては、影響が出るものなので、ここでは別としています。
こちらは、同じ名称でも、具体的には別物というものとなります。

たとえば、電話でよく使用される留守電機能(留守電シーケンス)があります。

・家庭用電話機では、電話機自体に留守電を保存し、再生します。
・ケータイでは、キャリア側(サーバ側)に留守電を保持し、再生することもできます。
・PBXでは、留守電メッセージをMP3などに変換して、メールで送信する機能もあったりします。

というように、一口に「留守電機能」といっても、端末メーカーやPBXメーカーにより、スペック(機能仕様)自体が全く違っていたりするのです。
上記の例では、ケータイでは、家庭用電話機のようにケータイ端末自体に録音する機能も持っており、「留守電機能」といっても2種類の機能があるわけです。

これで、さらにやっかいなものは、別の名称なのに、実は、同じ機能などもあり、問題を複雑にしています。グループ着信や代表着信などは、その最たる例です。

こういった感じで、SIPの相互接続問題といっても、Stackレベルからスペックレベルまで複雑に絡み合っているのです。

2006/11/20までのVoIP系のニュースをまとめて。

●「ソフトバンクとYOZAN，基地局設置スペースを共同利用」

WiMAXなどの次へ向けてということのようですね。
それに、周波数効率を上げるためには、セルを小さくするのが一番早いですしね。

●「ACCESS、沖電気など3社、商業用 IMS ソリューションを共同開発」

また、新たなIMSソリューションです。各社さん、今後数年の生き残りをかけて必死と言うところですね。

●「台湾FIC、プログラム可能なLinux携帯電話を発表」

Linux採用のケータイだそうです。
最近のMobileOSの流れは、WindowsMobileかLinuxかとなってきましたね。これもうまさに、PCの世界と同じって感じです。

●「「Windows CEは第2のブレークスルーを迎えた」、マイクロソフトが最新版を出荷」

ついに、

IP電話の標準プロトコルであるSIP（Session Initiation Protocol）を使った通信機能を装備

そして、なんだかんだで、最大の変更点は、

同時実行できるプロセス数を32から3万2000に、各プロセスが利用できる仮想メモリーの容量を32Mバイトから2Gバイトへ、それぞれ拡張した。

●エリクソン，既存端末でFMCを実現する家庭向け3G基地局発売へ

同じ電波を利用して、「ホーム・ベースステーション」を実現しようというもののようです。

通信方式はW-CDMA，HSPA（high speed packet access）に対応。携帯電話事業者が商用サービスで使っている電波と同じ周波数を利用して通信する。

●Yahoo!とVodafone、英国でのモバイル広告で提携

世界的にも、インターネット系サービス事業者と携帯事業者が、手を結びつつあるようですね。
日本でも、楽天さんやDoCoMoさん、GREEさんやKDDIさんといったあたりが、記憶に新しいと思います。

これで、携帯にインターネット系サービスを取り入れる準備ができれば、いろいろと面白いことになりそうですね。

「大きな成長の可能性を秘めたモバイルIM市場」というレポートがでています。

モバイルIMではプレゼンスが極めて重要だ。モバイルIMでは、ユーザーは連絡相手の状態、相手が今何をしているのか、応対可能なのかどうか、といったことを確認することができる。

モバイルIMの弱点の1つは、セキュリティ問題である。アンダーソン氏は、モバイルIMは十分にセキュアであると考えているが、ユーザーはそのように感じていないようだ。

というところで、「時間」と「場所」のプレゼンスを生かし、待ち受け問題を解決したたIMが登場すると、一気にモバイルIMが普及する可能性は高いと思います。

「URLを意識しなくなる日」という記事が出ています。

URLから、「検索」などによるサイトへの誘導へ変わってきているため、だんだんとURLを意識しなくなっていくというお話です。

これは、電話番号やSIP-URIにもいえる話ですね。現在も、ケータイやインターネット電話では、電話帳(ブラウザ的に言うところのブックマークに相当)機能により、電話番号を意識する機会は減っています。
しかし、電話帳機能も、「番号ベースの考え方」が軸となっているため、URLの検索のようなファインダビリティーを重視したものが、電話番号にも登場する可能性は高そうですね。

企業向け機能が強化され、着実な進歩を見せたMSのコミュニケーション製品群 という記事で、LCS2007が詳細に詳解されています。

う〜ん、3年も開発していた割には、それほど変わってないですね。これといって目立つ機能もないですし、いまいちという感じがします。

という感じではありますが、なぜ、ユーザ視点で見るといまいちかは、他のベンダーやキャリアとの提携に力を入れていたためではないかと推測されます。

パートナーによるCommunications Server 2007対応電話
MicrosoftはCommunicatorソフトウェアをLG-Nortel、Polycom、Thomson Telecomなどのサードパーティにライセンス供与している。

ソフトバンクモバイルが「予想外割引」を発表 です。

隠し球、来ました！！！

ゴールドプランでは、ソフトバンク携帯電話同士の通話料が0円

※定額にはいろいろと制約があるようです。定額とは思えない制限もありますし。まぁ、時期尚早感は、あったので、仕方ないと言うところですね。さすがに、現在の電波の利用効率で、完全定額は難しいと言うことですね。

NTT西のひかり電話でまたも大規模障害、9月のNTT東とは別の原因か と記事が出ております。

NTT西日本さんで、IP電話大障害が起きているようです。
さすがに、これだけ立て続けに起こると、何らかの規制ができてしまうのは免れないかもしれませんね。最近、やっと、いろいろと規制が外れてきた(見逃してもらえる？)という状況であったのに。。。

しかし、今回の障害の原因は、何なのでしょうかね？ 前回の原因であるバグは、修正済みと言うことですので、他の原因と考えられますね。
また、しばらく、目を離せなそうです。

2006/10/20までの気になったけど、それほどつっこむようなものでもないVoIP関連Newsです。

●総務省、電話番号の使用状況。固定/IP/携帯電話ともに使用数が増加傾向

固定電話の使用状況は約8,145万番号で、IP電話が約1,007万番号。

●スイス政府、IP電話の盗聴実験を実施

クライアントサイド・アプリケーションを使用。通話に使用されたPCのマイクとスピーカーの音声を録音し、インターネット経由でパケットを転送するという方法をとっている。

●ウィルコムの八剱社長が退任へ，後任には喜久川経営企画本部長

「八剱氏の役割は元々、DDIポケットからウィルコムになる際にいち早く軌道に乗せることだった。今回の社長の交代は、当初の予定通り、元KDDIのメンバーが役職に就いた形になる」

●au、来春にJavaアプリが楽しめる「オープンアプリ」導入へ

オープンアプリは勝手アプリ（一般アプリ）として提供されることになり、EZwebの公式メニュー上で配信されることはなく、オープンアプリ配信にあたって両社の審査は行なわれない。

●沖電気が中小向けIP電話システム，無線LAN搭載機など40端末を接続

安価な製品がほとんどなかったなどの事情から，中小規模の拠点の内線システムのIP化はまだ10％程度にとどまっているとされる。

価格は，IPstage MXが50内線モデルで270万円から，同SXは10内線モデルで71万円から。

●NTTドコモが903iシリーズなど14機種を発表，N900iLの後継機種も登場

DoCoMoさんのページ。
や〜〜〜〜っと、N902iLが出るそうです。
フルブラウザとFeliCaの搭載は、面白そうなところですが、やはり、GPSがほしかったですね。プレゼンス機能を生かすには、GPSが必須だと思いますので。

●「NTTに頼らない光回線を」――KDDI、東電の光通信事業を吸収

さて、これで、NTTさんは、

光ファイバーの解放義務緩和

●エニーユーザー，中小企業向けIPセントレックスを開始

「のぞみ電話」と呼ぶIPセントレックス・サービスを開始した。

●ASPがAsteriskアプライアンスの正式出荷を開始

Asteriskが、じわじわと来てますね。

日経さんにて「日本のAsterisk最新事情」という特集が組まれております。
(内容的には、日経コミュニケーションの記事の再編成のようですが。)

何点か、気になったところにコメントです。

●日本のAsterisk最新事情（2） Asteriskのポテンシャル

オープンソースであるAsteriskは，APIが公開されているため，ユーザーは自由にアプリケーションを開発できる。それ以上に大きな意味を持つのが，コミュニティの存在である。コミュニティに参加するアプリケーション開発者は，一般公開されたAPIに合わせて自由にソフトウエアを作成できる。例えば携帯電話向けのSymbian OSは，世界中の携帯電話機メーカーが採用。そのユーザーに向けて，多数のアプリケーションが開発されている。ユーザーは自由にアプリケーションを選んで入手し，利用できる。Asteriskも，これと同じ環境を生み出す可能性を秘めている。

●日本のAsterisk最新事情（5） 「黒船Asterisk」，他陣営はこう見る

「まだ我々の敵ではない」「気にはなっている，だが脅威ではない」とIP-PBXメーカー

こちらのエントリーで、NTTさんの大規模障害が、どのような障害理由であったかを簡単に考察しましたので、続いてどのような対策をすべきかを考察してみようか思います。

■高負荷について
まず、一つめの原因である高負荷状態となった点について、補足事項を含めて、考察します。

●パケット流量
さて、SIP網におけるパケットの流量なのですが、実は、「え？そうなの？？？」という事実があったりしますので、その辺から、解説します。

・SIPパケット
SIPベースのIP電話がどのように通信を行うかは、「こちら」をみていただくとよいかと思います。

下の方に有る図の 3〜4, 7〜9 の矢印が、通話を開始する(セッションを張る)SIPパケットとなります。この 9 矢印まで終わった時点で、通話が確立されます。
そして、これ以降は、1〜3分おきくらいに(キープアライブ処理のため)、同様のやりとりをします。
パケットサイズ的には、矢印1つ、1000Bytesくらいです。

・RTPパケット(音声、映像などのメディアパケット)
通話開始後は、音声を相手に届けるために、RTPという音声パケットが流れるのですが、これが、上記図の 10 の矢印に相当するモノになります。
パケットサイズ的には、256Bytes前後のパケットが1秒間に50個、流れます。（256Bytes * 50packets/s * 2(全二重) = 4kBytes/s = 32kbps です。すなわち、ISDNが64kbps(同時2通話)なのと同じとなります。)

で、上記図をよく見ていただくと、セッションを張ったUA同士で直接やりとりされます。すなわち、P2Pでやりとりされているのです！

・パケットのまとめ
要するに、SIP網において、サーバを経由するパケットは、最初の通話開始の(セッションを張る)SIPパケットとキープアライブのSIPパケットだけで、その他のパケットは、P2Pで通信されるのです。(正確には違いますが、大枠としてはそういう認識でOKです。)
すなわち、サーバを経由するパケットは、通話全体のパケットの数%にも満たないような量しかないのです。

逆に言うと、(通話全体から見れば)ほとんど、パケットが通らないはずのSIPサーバが、高負荷状態となって落ちているのです！！！
それくらい、SIPサーバというヤツは、負荷に弱いわけです。

●原因
負荷に弱い原因は、下記の理由と思われます。

・Text型パケットである
・可変長のパケット、ヘッダーである
・何らかのDBに依存して、ルーティングを行う

■バグについて
つづいて、バグについてですが、ご存じのようにバグというモノは、コードの量に比例して増加し、運用年数に反比例して減っていきます。

●今後のSIP網
現在の通話のSIP網は、今後、NGN(IMS)に置き換えられていく流れとなっています。
すなわち、現在のコードがさらに拡張(増加)され、新規運用となるのです。

●まとめ
バグの性質と今後のSIP網を考慮すれば、当面の間は、バグを取り切ることは不可能ではないかと思います。

■対策
さて、ここでSIP網がどのような構造をしているかを考えますと、NGNがインターネットを再構築しようとしていると言われているように、SIP網というのは本質的にインターネットと同じ構造をしています。

しかし、現在のSIP-Proxy(SIPにおけるRouterの役割をするもの)は、ある発信先への経路情報は、唯一に決定されるという実装になっていることが多いようです。NTTさんの実装がどうなっているかは分かりませんが、経験から言わせてもらえれば唯一に決定される実装になっているはずです。

すなわち、インターネットが安定して稼働するキモである「迂回路」が実装されていないのです。

そして、「迂回路の実装」こそが、SIP網に施すべき安定化対策であると、私は考えています。これにより、「負荷分散」が可能となり付加対策され、「マルチベンダー」になることにより「一つのバグにより全体が落ちる」ことが無くなります。

現状での対策としては、キャリアやISP間で相互接続をして、迂回路を設定できるようにするというあたりが、現実的なところだと思います。
さらに、その先としては、SIP-Proxy自体に迂回設定を実装していくことも考えられます。SIP自体が、セッション層のTransportととしての役割を持っているため、SIP自体をIPに近い機能を持ったRoutingプロトコルとして使用してしまおうという考え方です。
これの具体例としては、SIPベースで、BGPのようなプロトコルを実装してしまうようなイメージです。SIP IXさんが、一番近いところにいるといえるでしょう。

つながらないのが“常識”の標準プロトコル「SIP」 という記事が出ております。

この件の詳細は、SIPropもあわせて、ご覧いただければと思います。

相互接続問題のほかに、あまり語られていないことが、語られていますので、スポットを当てます。

SIPは，IP電話以外にも用途が広がる重要な標準プロトコルである。

SIPは、Session Initiation Protocolの略であり、2点間(以上)のセッションの制御をするというシンプルな機能であり、これは、今までのインターネットなプロトコルであるHTTPやFTPなどで採用されている、クライアント-サーバモデルではなく、クライアント-クライアント(P2P)モデルなのです。
これこそが、今までのプロトコルとの決定的な違いであり、今までと違った「用途が広がる重要な標準プロトコル」であるわけです。
その典型的な使用例の一つとして、「電話用のプロトコル」として、使用されたのです。

もちろん、クライアント-サーバモデルでいろいろなプロトコルが策定されたように、クライアント-クライアント(P2P)モデルのSIPでも現在も活発にいろいろな拡張がなされています。

ただ、この拡張しすぎや汎用性を高くしすぎているため、逆に、相互接続性に難が出てしまったわけですね。。。。。。
いずれ、SGMLが汎用性が高すぎて使いにくく、サブセットとしてXMLが定義されたような感じで、SIPも機能単位で再定義されるかもしれません。

・VOIP―ディテールで興ざめ
いまある、VoIPサービスの簡単な解説です。

たぶん誰かがもっとうまい解決法を提案してくるだろう。それまでは、私は現在出てきているのどのサービスにも賭ける気にはなれない。

・Adobe FLASHがVoIP機能を搭載！
ついに、きました。一年くらい前から、ＳＩＰ搭載とかいわれておりましたが、ついに公開のようです。

・CIAJ，情報家電の技術仕様「DLNA」に対応した携帯電話を試作
ついに、ケータイにDLNAを搭載だそうです。これに、プレゼンスを組み合わせると、いろいろと楽しいことができるわけですが、そこまでは実装されていないみたいですね。

・au用Windows Live for Mobile、本日より提供開始
おお、BREW版だそうです。まぁ、それだけといえば、それだけなのですが。。。

・Yahoo!とMSのIM、相互乗り入れが可能に
数年越しの相互乗入れが、ついに実現しました。やはり、これも、Skype効果でしょうか？それとも、ビジネスモデル疲れですかね？(;^_^A アセアセ・・・

・ボーダフォン孫社長、新端末とコンテンツで「一気に変えていく」
まずは、既存のラインナップやサービスの整理と言うところでしょうか。本当の勝負サービスは、まだ開発中と言うところのようですね。

OpenSER用のXMPP Gatewayモジュールが、リリースされたそうです。

世界中のXMPPサーバやGoogleTalk(Skypeも)などとお話可能になりますね。
これで、ますます、セッション層のプロトコルは、何でも良さそうな様相を呈して参りました。早くSkypeプロトコルが公開されることを祈るのみです。(;^_^A アセアセ・・・

「総務省，IP電話などの信頼性を高めるための技術基準を検討開始」という記事が出ております。

何がしたいのかよくわからないですね。

IPネットワークの信頼性を確保するための管理方法や技術基準を検討する

おまけ

IP電話にぜい弱性があるわけではない。まだ発展途上の段階にあり，トラフィック制御やオペレーションに関する技術基準や必要機能などを今後検討していく必要がある

いまさらですが、落ち着いたようですので、このタイミングでエントリーします。

●経緯
・NTTさん発表資料 「ひかり電話」の通話状況について
・9/19 NTT東日本のひかり電話，連休明けの通話量増でつながりにくい状態
・9/19 NTT東のひかり電話でトラブル，通話集中でつながりにくく
・9/20 NTT東のひかり電話がまたつながりにくく，システム再起動のため
・9/21 【続報】NTT東がひかり電話の規制を解除，明日22日の規制の可能性は否定せず
・09/22 【続報】NTT東のひかり電話，「22日午前現在は安定中」，障害原因は不明のまま

●一般的な原因と対策
・一般的な原因

・SIPプロトコルのINVITE(通話開始)は、応答が得られるまで、0.5秒、1秒、2秒・・・と32秒まで、7回再送を行います。(そのあと、あきらめます。)
・「つながりにくくなる」とは「処理が遅くなる」であり、それは「0.5秒以内に応答できなくなる」ということを示していて、一回のINVITEが、(つながりにくさが増加してくごとに)２，３回とどんどんと指数関数的に増えていくのです。
・さらに「つながりにくく(処理が遅くなる)」なると、「INVITEの再送回数も増える」ため、どんどんと負のスパイラル(輻輳状態)に落ちていきます。
・最後に、サーバが処理しきれなくなり、ダウンします。

・一般的な対策

・サーバの数を増やす→物量作戦（ｗ
・限界になる前に、Transactionレベルで「エラーを返す」→クライアントトランザクションを作らなくてよいので処理が軽くなる。
・再送を開始する秒数を増やす。→0.5秒ではなく、2秒にするなど。
・最大再総回数を減らす。→32秒までではなく、8秒までにするなど。
(再送値は、RFC的には「MUST」ではなく、基準値として提示されているだけ。)

・一般的なシナリオ
現実的に、起こる一般的なシナリオは、

・停電後の復旧

・登録処理(REGISTER)が、一斉にSIPサーバに押し寄せるため

こちらのパターンのキモは、

・ユーザの操作ではなく、IP電話機が自動で行う点

●NTTさんの場合の原因と対策
・NTTさんの場合の原因

・連休明けで通話が通常よりも多かった(約3倍)
・それにともない、ソフトのバグを顕在化した

・NTTさんの場合の対策
対策として、「発着信規制」で、サーバにかかる負荷を軽減させたと言うことのようです。
なぜ、そういえるかというと、「発着信規制」なので、

・ある閾値を超えた発信開始(INVITE)に対して、Transactionレベルで「エラーを返す」

・INVITEの認証をしなくてよい
・Transactionレベルで「エラーを返す」場合は、クライアントトランザクションが生成されないため処理が軽い

以上をまとめると、

・発信開始(INVITE)に対する、再送スパイラル(輻輳)が起きた
・そのトリガーが、通常の3倍の発信開始(INVITE)により、バグが顕在化したため

そのバグの勝手な予想としては、通話がトリガーと言うことであったので、

・INVITEとCANCELのクロス処理にバグがあったのではないか？

・応答を受け取っていない場合、CANCELを送信してはいけない
・2xx応答以上を受け取っている場合は、CANCELは無効となる
・CANCELは、HopByHopと呼ばれる動作をする

第9回ETJP全体ミーティングにて、SIPropとENUMについて10分ほど枠をもらったのでプレゼンをしてきます。

第9回ETJP全体ミーティング
日時： 2006年 9月20日(水) 10:30〜12:00
場所：東京都千代田区西神田3-8-1 千代田ファーストビル東館13F
　　　 株式会社日本レジストリサービス 会議室
http://jprs.co.jp/map.html

・制御Moduleがプロトコルに依存していない
・SIP的には、Forkingという概念がある
・ENUMを引けるResolverがある
　→ENUMはマルチプロトコルである

AsteriskとSkypeを接続するというソリューションが、11月より提供されるそうです。こちらとこちら。

内容的には、

The second generation PIKA Connect for Asterisk is a channel driver for the popular open source Linux-based Asterisk PBX, enabling connectivity to Skype.

Skype clients running on Windows based PCs are connected to the channel driver via PIKA’s AllOnHost™ (host-based) voice processing technology. Skype clients can be distributed across an unlimited number of Windows PCs to achieve the density requirements the voice application may require.

なので、実質独自なプロトコルと言うことになるようですね。

ちなみに、プレゼンスは、考慮されていないようです。まぁ、Asteriskのプレゼンス機能自体が、腐っているので、当然といえば、当然ですが。

『 SIP IX 』プロジェクトがスタートしたそうです。こちら。

プロジェクトの概要としては、

『SIP IX』では、SIPサーバ同士をピュアにインターネット上で相互接続することで、VoIPサービス事業者や企業の枠に囚われない自由なSIPネットワークの構築を推進します。
また、それによりSIPの多彩な可能性を追求・提案していきたいと考えています。

気になる相互接続問題については、サポートフォーラムの方に

問題が起こるとすれば、ピアリングした際に相手のIP-PBX（SIPサーバ）との相互接続で仕様の違いによるエラーが発生する可能性はあり得ます。
IP-PBXは各社独自仕様でSIPを拡張しているケースが多いので、違うIP-PBX同士ではうまくつながらないことがあるのです。

『SIP IX』は現在のところ、お互いのSIPサーバの相互接続までを保証するものではありません。

[自分のSIPサーバ]--[SIProp]----[SIP IX]----[SIProp]--[他者のSIPサーバ]

それによりSIPの多彩な可能性を追求・提案していきたいと考えています。

「GoogleとeBayが提携、Google TalkとSkypeの互換実現へ」という記事が出ております。こちら。

これ、しれっと、すごいこと書いてあります。

SkypeとGoogle Talk間の互換性の向上なども、今回の提携に含まれるという。
SkypeとGoogle Talkは、オープン標準経由でチャットとプレゼンス機能の互換性を実現するとしている。

ただ、やはり、発着信がないと片手落ち感は否めないため、ぜひとも、発着信までできるようにしてもらいたいものです。いちおう、

SkypeとGoogle Talkを使用したClick-to-Call機能の統合および開発を行う。

■XMPP関連リンク
●jabber.org
●RFC 3920: Extensible Messaging and Presence Protocol (XMPP)
●RFC 3921: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence
●RFC 3922: Mapping the Extensible Messaging and Presence Protocol (XMPP) to Common Presence and Instant Messaging (CPIM)
●RFC 3923: End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP)

Asteriskに、Google Talk(jabber)が、接続できるようになったとのこと。こちら。

Asteriskは、プレゼンスやメッセージが非常に弱いので、これは、新しい起爆剤になる可能性がありそうですね。要注目という感じです。

「Black Hat」会議で、SIP用のセキュリティーテストツールが公開されたとのことです。こちら。

SIPが主要な製品に取り入れられた時には、こうしたツールによってVoIPシステムがより安全なものになることを願っている、とEndler氏は言う。同氏によると、「VoIPシステムのセキュリティは、まだ幼年期にある」という。

いや〜〜〜、(以下、自主規制)。やばすぎるんで、勘弁してください。いろいろと。<(_ _)>

また、フリーのテストツールとしては、「protos」というツールがあります。
こちらは、オーバーフローやエラーを起こしそうなSIPメッセージを投げるというものです。
例としては、

INVITE sip:test@test SIP/2.0

aaaa(ずっと、続く) sip:test@test SIP/2.0

それが、正常に動作しているかどうかは、チェックしないため、自分で確認する必要があります。

PHPに、Jabberクライアントクラスというのが、実装されているそうです。こちら。

さらに、MSNメッセンジャーやYahoo!メッセンジャーなども使用できるようです。当然、Jubberに対応しているので、GTalkとも通信可能ですね。

これは、うまく何かに使えそうですね。

「ネット電話フィッシング「vishing」が登場」だそうで、内容を見てみると、

「vishing」と呼ばれるこの手口では、盗んだ個人情報を使って低料金のインターネット電話会社にデジタル音声応答システムを設定し、特定地域の電話番号に無作為に電話をかける。
相手が出ると自動音声で、クレジットカードが不正利用されたので、これから言う番号に電話するようにと指示。この番号に電話すると、アカウントの確認と称して自分のクレジットカード番号を入力するよう求められ、さらに暗証番号やカードの期限、生年月日などの情報を求められることもある。

アナログ電話では、引き入れている回線分しか同時発信できないが、IP電話発信では同時発信回線数は無制限(である場合がある)

というところですね。これにより、回線コストがかからないため、さらに低コスト且つ大量に、発信できるわけです。

SIPropにて、JPNICさま主催の「VoIP/SIP総合接続検証タスクフォース」へ、参加させていただくことになりました。

VoIP/SIP総合接続検証タスクフォースが、相互接続する場を与え、SIPropが、その結果をフィードバックしたリファレンス実装という位置付けとなれるように、がんばって参りますので、よろしくお願いいたします。

平成１８年「情報通信に関する現状報告」（情報通信白書）が、公表されました。こちら。

「ユビキタスネットワークによる新しい潮流」とかいって、Web2.0と結びつけているのですが、あんまり関係ない気が。。。ちなみに、ユビキタスネットワークとは、下記のように定義されているようです。
（まぁ、これのからみゆえでしょうが。。。)

いつでも、どこでも、ネットワーク、端末、コンテンツなどを自在に安心して利用できる情報通信ネットワークであり、利用者の生活領域にまで広く浸透することに特色。

あと、VoIP関連で参考になりそうな資料へのリンクをつけておきます。

・通信・放送分野における事業者の相互参入・事業連携(トリプルプレイ)
・情報通信機器の国内出荷
・携帯インターネット利用状況
・移動通信
・IP電話の普及(利用者数)
・IP化の進展に対応した競争ルールの在り方に関する検討
・情報通信ネットワークの高度化

「KDDIが無線IP電話を使ったSIを支援、デュアル端末にミドルウエア実装」という記事が出ています。

パートナー企業が顧客向けのアプリケーションを開発しやすくするため。ミドルウエア自体がBREWで開発されており、携帯電話網や無線LAN経由でオフィス側に設置した専用のアプリケーションサーバーと直接連携し、データベースなどの業務システムにアクセスできるようにする。システムインテグレータなどが開発したクライアントソフトはこのミドルウエアを介して通信する。これにより、KDDIによるアプリの承認作業などを回避できる。

ミドルウェアにどのような機能があるかは、記述されていませんが、最大のネックである「KDDIの認証」が不要になるというのは、とても、大きな話ですね。

「IP電話の通話品質を上げる」ミドルウエアというものが、出てきたそうです。
http://itpro.nikkeibp.co.jp/article/NEWS/20060623/241659/

発想的には、SIPropと同じようなところで、SIPropの音声版という感じですね。まさに、補完関係にありますので、仲良くさせていただければとなどと妄想してしまいます。(;^_^A

といったところで、この問題なのですが、この辺も相当大変なんですよ。

無音圧縮(無音が続くとRTP送信をStopする)とか、下手にいれると「RTPが10秒間届かなかったら、切断」などという電話機があると切れてしまうわけです。
とくに、ジッター/バッファー調整の自動調整なんて、涙ものですね。これ、実際に繋げて、聞いてみるしかないのですが、神様が聞かないと差が解らなかったりするんです。

ジッター（パケットごとに転送速度や到着間隔がばらつくこと）の状態を検知し，動的にバッファの大きさを変える「ジッタバッファ制御技術」も開発

MS社が、オフィス電話市場へ本格参戦するようです。「Microsoft Office Communications Server 2007」と「Microsoft Exchange Server 2007」とロードマップ。
まさに、ついにという感じですね。

Microsoft Office Communications Server 2007の機能としては、

この戦略に向け、MicrosoftはOffice 2007の一部として統合的な通信機能を発表した。リアルタイム通信プラットフォーム「Microsoft Office Communications Server 2007」は、既存のソフト、サービス、デバイス間でのVoIP通信管理や音声・ビデオカンファレンス、IM通信を可能にする。このプラットフォームと連係する通信クライアント「Microsoft Office Communicator 2007」は企業向けの「ソフトフォン」、IM、Webカンファレンスなどの機能を提供する。

Microsoft Exchange Server 2007の機能としては、

「ユニファイド・メッセージング」（UM：Unified Messaging，統合メッセージ機能）という新しい機能が搭載される。MicrosoftはまだUMの仕組みについて公に多くのことを語ってはいないが，予定されているUMの機能には役に立ちそうなものがいくつかある。

・ボイスメール、FAXのOutlook連携

・Microsoft Office Communications Server 2007連携

・IP-PBX連携

そのPBXが「SIP over TCP」と「RTP over TCP」をネイティブでサポートしているのならば，Exchangeの統合メッセージング機能が使えるかもしれない

こちらで掲載中の中川氏のBlogに、SIPropの存在意義と言うべきポイントの解説がエントリーされていたため、ご紹介させていただきます。

さて、いきなり引用を。

■標準規格準拠へのジレンマ

当初の我々の製品は、当時（今も？）勃興していた「SIPプロトコル準拠」を謳い文句にはしていたが、仕事を続けていると、社内の限られたリソースをどう配分していいのかと悩むことが多々あった。

＜中略＞

Gphoneについては、途中からはビジネスユーザーメインに切り替えたものの、当初は一般コンシューマ相手のSIPソフトフォンであったことから、新機能も追加していかなければユーザーに飽きられる。しかし、追加する新機能は「SIP準拠」かどうか、そういう縛りもあった。

つまり、新機能は自由に追加したいが、新機能が「SIP互換」を保てるのか、保てないものを追加すべきかどうか、というジレンマがあった。

まさに、この部分が、SIPの混沌としている部分であります。ビジネスフォン関連では、本当に、各社まちまちに実装してくれておりまして。。。(ノ_・、)シクシク
そこで、この標準を作るべく、SIPropプロジェクトを立ち上げているというわけであります。

最後に、もう一点、気になる点があったので、引用いたします。

まぁ、オープンソース化か、実は今後ひっそりとSIP化するという動きがあったりすると、かなり激震が走って面白いかも、と個人的には思う。実際この2つが重なれば、VoIPクライアントのさらに多くがSkypeになるのではないかなぁ。いや、ただの当たらない勘ですが。

私のつたない知識の範囲では、プロプライエタリな通信規格で普及してるものってないかなぁというところです。
なぜ、普及していないかといえば、通信機器の場合には、いろいろなデバイスへの組み込みが必須要件となるため、一社が独占の状況で普及させるのは非常に困難だと思われるためです。
特に、このような下位レイヤーの場合、それ自体に製品を魅力的にする価値はなく、当たり前の機能となってしまうため、コスト要求が非常に強い部分となり、より一社独占を妨げる要因となっています。(本当に、どこも払ってくれないのですよ。。。ただの通信モジュールには。こちらのエントリーを参照。)

といったところで、現在のSkypeでは、微妙かなぁと言うところですね。たぶん、XMPP(Jubber)系（GoogleTalk,Gizmo)のほうが、有力でしょうね。

ただ、指摘にあるようにSkypeがSIPをしゃべってくれれば相当面白いのですが。。。
いや、Skypeが通信規格を公開してください！SIPropで、Skype←→SIP変換しますので！（まぁ、これが言いたかっただけなんですが。(;^_^A アセアセ・・・）

噂の自作ケータイ。こちら。

Java VM（MIDP 2.0）「intent」は、あるけど、SIPフォンが載っていいるわけではないのですよねぇ。
う〜ん、微妙だなぁ。ガジェットとしては、面白いんだけどなぁ。

私なりに考えている全体像の中でのSIPropの位置付けの解説をしたいと思います。
今更と言うところや説明不足も多々ありますが、私の説明用資料に近いものなので、ご容赦を。。。
そのうち、各層について、もっと掘り下げたものを書こうかと思います。

■全体像
下記のブロック図が、私の考えている全体像となります。（ちょっと、ださい図なので、書き換え予定。）また、最後に、データの流れなどを書いたポンチ絵もありますので、そちらも会わせてみていただければと思います。
全体の要素として、「アプリケーション」「マイニング」「プラットフォーム」があり、それらが連携することにより、１つのサービスが実現されると考えています。（各要素は、状況により、要素技術へと細分化されていきます。）
この図を元に、下記に簡単に説明を加えていきます。

■プラットフォーム
各デバイス間を相互に接続し、境界を排除するための世界。
シームレス・コミュニケーション といったあたりです。

●アプリ層
アプリケーションを使う上で、デバイスに依存しないUIや操作性を提供する層。
この辺のイメージは、中島聡氏のブログに的確な解説があるので、そちらをご覧いただければと思います。
デバイスも多様化し、使用法も多様化することがすることが、考えられますので、ある程度分野別にいろいろとミドルウェアが出てくるとは思います。

例：UIEvolutionさんのUIEngine

●セッション層
認証やパーミッション管理、デバイス間のセッション管理を行う層。
セキュリティー機能が付加した電力網のようなものを想定してもらえればよいかと思います。
SIPropは、ここの標準化を目指しています。
ここについては、後ほど、詳細な解説をする予定です。

例：NTTコミュニケーションズさんのm2m-x

●ネットワーク層
デバイス間のコネクションを確立するための層。
ここは、あまり説明は必要ないでしょう。SkypeのA2Aなどですね。

例：SkypeさんのSkypeや ソフトイーサさんのPacketiX

■データ
Googleが目指しているとおもわれる世界。
こちら側は、あまり強い分野ではないため、まとめ切れていません。名称も適当です。(;^_^A

●AI層
行動履歴などから「自分」の志向を判断し、適切な結果を導く層。
セマンティックされたデータと行動データから、思考して、最適解を導き出すという部分となります。

例：ハードディスクレコーダーの自動録画機能
(まぁ、まだまだAIと呼ぶには、アレですが。。。)

●ファインダビリティ層
入力された情報から的確な情報を探し出す層。
これは、書籍「アンビエント・ファインダビリティ」より、命名しました。
必要な情報をどうやって見つけ出すかという部分となります。詳細は、該当書籍をあたってもらえればと思います。

例：各検索エンジン

●マイニング層
あまたの情報を収集分類する層。
セマンティックやタグ付けといった意味づけに関するものやRFIDなどの膨大なデータ、動画といったものを情報処理するかという部分となります。

例：各検索エンジンのBot

■アプリケーション
●エージェント
上記の層から上がってきたデータを統合し、ユーザに見せるためのUI層。
私のイメージとしては、「外部脳・・・もう一人の自分」というものになります。

イメージ的には、こちらが究極に進化したもの。正確には、あの「何か」が出始めてきたときに、見て、「自分の分身がバーチャルな世界で勝手に動き回ったら面白いんじゃないの？」というところが、この妄想の原点になっています。

このような感じで、SIPropは、「プラットフォーム」の中層である「デバイスを繋げるための要素技術」であるというのが私の考えです。

最後に、この辺の話をポンチ絵にしたものを、貼り付けておきます。
2004年10月のあるデスマーチプロジェクト終了後の休暇中に暴走した状態で書いたもので、かなり恥ずかしいのですが、死蔵していても何も生み出さないので、公開してみることにします。
何かのお役に立つことを祈って。。。

総務省から、「ＩＰ時代における電気通信番号の在り方に関する研究会第二次報告書」が、公表されました。

気になる点としては、下記の点ですね。

発信者が呼接続を継続するかを選択可能な機会を確保するた め、インターネットを経由している点について、インターネットへの転送前にガ イダンスにより発信者に告知することが現実的な対策と考えられる。

セキュリティーや品質保証の問題から、必要と言うことになっているようですが、どうなのだろうという気がします。

セキュリティーに関しては、最近では暗号化機能がつき始めていますし、NGNではIPsecを使用しますし、解決は時間の問題と思われます。それに、既存の固定電話も物理的なリーチが必要と言うだけで強固なセキュリティーが施されているわけではないですから。
品質保証に関しては、ベストエフォートがだんだんと認知されつつある現在、固定電話の品質基準の方を見直した方がよいような・・・というようなことをいうとやばそうなので、この辺はあまりつっこまない方向で。

感想としては、やはり、既存の固定電話ベースでの検討結果という感じですね。IPベースで検討するともっと違う結果となりそうなのですね。

基本設計ですが、だいたい、イメージが出来てきたので、設計を一気に更新いたしました。

とくに、実オブジェクトブロック図 が、よい感じに出来ており、読んでもらえればだいたいの動作がつかめるのではないかと思います。
あとは、細部を詰めていくという感じですので、詳細設計を見据えつつ、やっていこうかと思います。

つぶやき
まぁ、いろいろとつっこまれる要素はあるのですが、今のところ、無視してやっています。

SIPropの設計ページを作成しました。

今回は、下記のものについての要件定義と基本設計のキモとなりそうなところを洗い出してあります。

・メッセージ部
・シーケンス部
・スクリプト部
・スクリプト用関数

という感じですが、たぶん、見ても良くわからないかと思います。次回は、各部分のアーキテクチャをもう少し具体的に設計しようかと思います。この辺を書けば、だんだんと何が言いたいのか見えてくるはずですので。
その次は、詳細設計と称して、簡単なクラス図を書いていきたいと思います。

しばらく、地下に潜って活動しておりましたが、その結果が出ましたので、ご報告＆リニューアルです！

2006年上期 IPA未踏ソフトウェア創造事業に、採択されました。採択内容は、こちら(１ 今村　謙之)。

採択された物は、こちらの「SIProp」プロジェクトとなります。詳細は、リンク先のページをご覧ください。
簡単に説明しますと、SIP(IP電話)の相互接続問題を解決するためのミドルウェアということになります。

しばらくは、これを中心の更新していく予定ですので、SIPやP2Pがらみに興味のある方はよろしくお願いいたします。

ENUM の 設定を行いましたので、そのメモを貼り付けておきます。
何かの参考になれば、幸いです。

DNSサーバは、BINDバージョン：9.3.2 を、使用しました。

また、構成は、「日本ENUMトライアルのTier構成」の構成となっております。

■Tier1-Bの設定
設定は、CIDRの設定と同じです。
JPNICから、通知されるネームサーバ名をそのまま利用してください。

●named.conf
・設定例

zone "ns101.0.0.0.0.2.2.0.0.1.8.e164.arpa" {
type master;
file "8100220000.enum";
};

●ゾーンファイル
・設定例

$TTL 86400
@ IN SOA ns.noritsuna.jp. master.noritsuna.jp. (
2006021001 ; serial
3600 ; refresh 1hr
900 ; retry 15min
604800 ; expire 1w
86400 ; min 24hr
)
IN NS ns.noritsuna.jp.

0.0.0.0.0.0.2.2.0.0.1.8.e164.arpa. IN PTR ns.noritsuna.jp.
0.0.0.0.0.0.2.2.0.0.1.8.e164.arpa. IN PTR ns.noritsuna.jp.

■Tier2の設定
●named.conf
ゾーンの指定ですが、逆引きの設定とほぼ同じです。
簡単に言えば、番号を逆さまにして、ドットで区切り、「e164.arpa」をつけるだけです。

・RFC
RFC 2916「E.164 number and DNS」

・設定例

zone "0.0.0.0.0.0.2.2.0.0.1.8.e164.arpa" {
type master;
file "810022000000.enum";
};
zone "1.0.0.0.0.0.2.2.0.0.1.8.e164.arpa" {
type master;
file "810022000001.enum";
};

●ゾーンファイル
「SOA」「NS」レコードは、普通のゾーンファイルと一緒です。

ENUM番号用に、「NAPTR」レコードを追加することになります。
「NAPTR」レコードのフォーマットは、下記の通りです。

・フォーマット

X.X.X.X.X.X.X.X.X.X.X.e164.arpa. IN NAPTR order preference service flags regexp replacement

・パラメータの意味

order・・・数値。プライオリティー。小さいものから処理されます。
preference・・・数値。orderに対するプライオリティー。
service・・・文字列。提供するサービスの文字列。
SIPサービス：E2U+sip
電子メールサービス：E2U+msg:mailto
Webサービス：E2U+web:http
flags・・・文字。「u」をするらしい。
regexp・・・正規表現。ENUM番号からURIを生成するための正規表現。
replacement・・・正規表現。「.」を指定すればOK。

・設定例

0.0.0.0.0.0.2.2.0.0.1.8.e164.arpa. IN NAPTR 100 10 "u" "E2U+sip" "!^.*$!sip:test-sip@noritsuna.jp!" .
0.0.0.0.0.0.2.2.0.0.1.8.e164.arpa. IN NAPTR 100 10 "u" "E2U+msg:mailto" "!^.*$!mailto:test-sip@noritsuna.jp!" .
0.0.0.0.0.0.2.2.0.0.1.8.e164.arpa. IN NAPTR 100 10 "u" "E2U+web:http" "!^.*$!http:www.noritsuna.jp!" .

●テスト
dig コマンド(bindに付属)の結果で、「;; ANSWER SECTION:」に、設定した「NAPTR」が、出てくればOKです。

・コマンド

/usr/bin/dig NAPTR X.X.X.X.X.X.X.X.X.X.X.e164.arpa. [@IPアドレス]

・結果例

$/usr/bin/dig NAPTR 0.0.0.0.0.0.2.2.0.0.1.8.e164.arpa.

; <<>> DiG 9.2.4 <<>> NAPTR 0.0.0.0.0.0.2.2.0.0.1.8.e164.arpa.
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62865
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;0.0.0.0.0.0.2.2.0.0.1.8.e164.arpa. IN NAPTR

;; ANSWER SECTION:
0.0.0.0.0.0.2.2.0.0.1.8.e164.arpa. 86285 IN NAPTR 100 10 "u" "E2U+sip" "!^.*$!sip:test-sip@noritsuna.jp!" .
0.0.0.0.0.0.2.2.0.0.1.8.e164.arpa. 86285 IN NAPTR 100 10 "u" "E2U+web:http" "!^.*$!http:www.noritsuna.jp!" .
0.0.0.0.0.0.2.2.0.0.1.8.e164.arpa. 86285 IN NAPTR 100 10 "u" "E2U+msg:mailto" "!^.*$!mailto:test-sip@noritsuna.jp!" .

;; AUTHORITY SECTION:
0.0.0.0.0.0.2.2.0.0.1.8.e164.arpa. 86285 IN NS ns.noritsuna.jp.

JPNICの日本ENUMトライアル にて、申請が受理され、番号を払い出してもらいました。

うちの割り当て番号は、下記の通りです。

810022000000 〜 810022000099

しかし、上記リンク先を見ると、私が一番乗りのような気がしなくもないのですが、たぶん、気のせいでしょう。(^-^;A

近いうちに、ENUMのDNSサーバを立ち上げますので、そのときのインストールメモを公開予定です。
ターゲットDNSサーバは、「BIND9」です。

無印吉澤さんから、こちらのエントリーに、トラバを頂いたました！！！
(というか、初トラバです！！！(^-^;A)

さて、その中で無印吉澤さんが、P2P-SIPの存在意義について、3点ほど疑問点を
投げかけているので、反応してみました。


●一点目

・P2P SIPは中央集中サーバが不要
←Skypeは認証などのための管理サーバ
　（Network Management Server）を必要とする

課金を考える以上、やはり、管理サーバ的なものをはずすことは出来ないと
思います。
そのため、VoIPとして、考えるのなら「管理サーバは必要」と思います。

しかし、Winnyのようなソフトを作りたい場合、Skypeでは実装できないで
あろう点は、メリットとしてあげて良いかと思います。


●二点目

・P2P SIPはオープンなSIPプロトコルに基づく
←Skypeはプロプライエタリなプロトコル

オープンなプロトコルであれば別にSIPでなくても
いいわけで、それこそJXTAのようなオープンな
P2Pプロトコルでも良さそうです。

もう、おっしゃる通りかと。
上であげたWinnyという例であれば、実際、Freenetでも実装すればよいわけで、
わざわざSIPを絡める必要なんて無いんですよね。

あえてメリットとしてあげるなら、知っている人が比較的多い点かと。
そのため、コンセンサスが取りやすいといったあたりがメリットとして
あげられそうです。
(純粋な技術的メリットではない点は、ここに追記しておきます。)

●三点目

・P2P SIPは既存のSIP端末を利用できる
←Skypeを利用するには独自端末が必要

これも、2番目のと似てますが、「既存のSIP端末」ってのが、あるから実装
コスト安いという点が、メリットなのかと思います。
(純粋な技術的メリットではない点は、ここに追記しておきます。)

理論的には、SIPスタックはもうあるので、その上に載せるアプリ部分を
書けばよいというお話です。
(あくまで、「理論的」にはです。はい。(^-^;A)

と、書いてきましたが、私自身も別に技術的にはSIPじゃなくてもいいじゃん
と、思っております。(^-^;A
ただ、SIPをやってきたので、それをベースにするのが一番楽ですし、ぜひ、
そうなってほしいという願望があるので、P2P-SIPいいんじゃないの？と
いっているにすぎなかったりします。
(事実上、2番目にあげたメリットですね。)

「IPv6採用で半年間で1万台の電話機をスピード導入」 ですって！

IPv6 の商用事例としては、世界最大級らしいんですって！

「音声系はIPv6，データ系はIPv4に統一し，・・・・・・・IPv6とIPv4の
　ネットワークはタグVLANにより論理的に分かれている。」ですって！

いろいろと解説を入れたいところではありますが、いろいろとありまして
解説を入れるのは避けようと思います。

ではでは、このへんで、失礼いたします。ぺこ <(＿ ＿)>

「o」と「e」が、逆らしいですよ。タイトルの。(^-^;A

そういえば、今日は、「4月1日」らしいですよ。
まっ、深い意味はないですが、そのままってやつですね。（ｗ

ということで、期待した方、すみませんでした。ぺこ <(＿ ＿)>


何かが心に貯まってしまった方は、こちらで、和んでください。

「A P2P Approach to SIP Registration 〜SIPレジストへの P2P アプローチ〜」
というものが、2005/01/20にドラフトとして公開されていました。

そこで、ほぼ、ゼロに近い英語力((^-^;A)を総動員して、読んでみましたので
その辺の所感をば、少々。


●4. Peer-to-Peer Background
DHT-P2P の基本について書かれているようなので、P2P に興味がある方は、
「入門」として読んでみるとよいかと思います。

あまり、取り立てて面白そうなことは書いてなさそうです。

あと、全体を通して、Chord が、題材に取り上げられています。
私も、Chord は、よく知らないので、そのうち勉強してみようと思います。


●5. P2P SIP Overview
DHTを利用したP2Pを動かしたらどんな動作をするか？というものの
おおざっぱな解説ですね。まぁ、Overview ってタイトルですし。(^-^;A

SIP 的には、SIPProxyサーバ、ロケーションサーバ、レジストラ を、介した
RFC3261の16.12.1.1 Basic SIP Trapezoid を、どう回避して、UA間で通信
させるのか？ということになります。

SIP的なミソと思われるのは、ここ！

If the receiving node is not responsible for
the portion of the hash space corresponding
to that resource-ID, it will return a 302 -
Redirect response, and also report the node
nearest in the hash space that it is aware of.

問い合わせが来て、自分の管理下にないノードであれば、

「302 - Redirect response」

を返すことにより、他へ転送させようと言うわけです。
ウ〜ン、SIPの特性をうまく使った良い方法なんじゃないでしょうか。


●6. Architecture
基本アーキテクチャは、Chord ベースのようなので、こちらの知識が必要
かもとか思いましたが、どうやら、Chord のアーキテクチャ解説をしている
だけな様です。

ここを読むだけでも、Chord をある程度理解できそうな気がします。
というか、そんな気になりました。(^-^;A


●7. Headers and Parameters
●8. DHT Operations
●9. User-level operations
●10. Examples
このあたりが、具体的な実装に関わる話です。

事実上、Chord を SIP に併せて実装したらどうなる？ということが、延々と
書かれております。

まとめてみると、こんな感じでしょうか？
SIP(RFC3261など)に準拠した形で、P2P機能を持たせています。
こう考えると、やはり、SIPの拡張性はすごいですね。

・REGISTER メソッドによる、参加宣言。
・INVITE メソッドによる、セッションの確立。
・SUBSCRIBE / NOTIFY メソッドによる、プレゼンス通知。

・3xx応答リダイレクトによる、転送先（ルーティング）の指示。
・4xx応答による、不在通知。

・セッションタイマ（Expiresヘッダ）による、生存チェック。

・Require ヘッダ、Supported ヘッダによる、P2Pモード通知。

・下記ヘッダによる、ロケーション・ノード情報の伝達。
　Request-URIヘッダ
　Toヘッダ
　Fromヘッダ
　Contactヘッダ


●11. Security Considerations
●12. Open Issues
セキュリティーに関するお話。

あっ、あんまり書いてない。。。
詐称に関するモノだけ、書かれていますが、あまり目新しさはないかな。

事実上、NATもがんばって越えてねって書いてあるだけか。。。


●結論
ほとんど P2P な人向けの資料。どちらかというと初心者向き。
でも、SIP の可能性を感じさせてくれる資料でもあります。

P2P に、興味がある方は、是非とも、読んでみることをお奨めします。


●おまけ
んで、議論の方は、こちらで進んでいる模様。
この辺は、また、苦労して読んでみます。
ここに、Chord の資料もあります。

あと、ほかに、こんなのもあるようです。
こちらは、SIPをP2Pプロトコルとして使うには、どんな方法論があるかという
読み物的なモノのようです。
http://www.ietf.org/internet-drafts/draft-johnston-sipping-p2p-ipcom-01.txt
http://www.ietf.org/internet-drafts/draft-matthews-sipping-p2p-industrial-strength-00.txt

エッセンシャルSIP

ソフトフロント社執筆のSIP本の新刊です。
「あっ、やられた！」という、感じです。

なぜなら、プロローグが、

「SIP=IP電話ではない」

と、きました。
さすが、わかってらっしゃると叫んでしまいましたよ。（ｗ
(まぁ、私になぞに言われたくはないかもしれませんが。)

ということで、雑感を少々。


●第一部
SIPをちょっと知っているというのでしたら、もう、見飽きた内容でしょう。
VoIPに関するシーケンスなどの解説です。


●第二部
ここからが、「本命」の内容となります。

SIMPLE の具体的な内容が書かれています。
簡単に言えば、IMに関するSIPの使用法ということです。

VoIP では、滅多にお目にかかれない、SUBSCRIBE,NOTIFY,MESSAGE,PUBLISHあたりが
でてきます。

私の知る限りでは、この辺について詳細に解説している書籍はなかったと思います。
VoIP をメインでやっているSIP屋さんには、ぜひぜひ、読んで頂きたいところです。

SIP に対して、新しい視野が拓けてくること請け合いです！

ちょっと、飛躍はしてしまいますが、SIP の P2Pプロトコルとしての可能性も感じて
もらえるのではないでしょうか？


●第三部
SIPより下位のレイヤーのお話ですが、SIPを使用するためにどのような必須技術が
あるかのお話です。

個人的に不思議な点として、m2m-x が、数行しか書かれていないのですが、、、
なんでなんでしょう？

・第10章
必見です。
SIPに関する情報源の一覧が載っています。

興味がありそうなところのMLに片っ端から登録してしまいましょう！


●第四部
「SIP教科書」でおなじみのシーケンス解説です。

フォークと3PCCが、新たに追加されています。

「初代SIP教科書」「改訂版SIP教科書」と合わせれば、VoIPに必要なシーケンスの
ほぼ、全域がカバーされます。

・第12章
私的には、涙抜きでは読めないところです。（ﾉД｀）ｼｸｼｸ
詳しくは、書けませんが、まぁ、避けては通れない「最初の一歩」ですよね。


●まとめ
とりあえず、「SIP屋さんは買え」という、必携の書ですね。

さて、いままで、意図的に極力避けてきたのですが、そろそろ、ぽつぽつと
思考系の話でも書いてみようかと思います。

某MLに入っている人は、お解りかもしれませんが、個人的に、こういうのは、
大好きなのでして。(^-^;A
（下手の横好きってことで、大目に見てやってください。）


今回は、ぶっちゃけ、yusuke大先生の話に釣られました。(^-^;A

これをベースに、ちょろちょろと書いてみようかと思います。


●儲ける構図
個人的に、Skypeが、2ndPhone以上にはなれないと感覚的に考えていたのですが、
その答えの一つを見つけた感じです。

SIPとSkypeも似た構造にあります。
SIPは、RFCであり、仕様は一般に公開され、実装は各々が行うことになります。
Skypeは、ソフトが提供されており、APIを使用する場合、ライセンスが発生すると
いう構図になっています。

これは、yusuke大先生のblogにある、JavaとZopeの構図の類似といってよい
と思います。


●現在の構図
現在、SIPもSkypeも「電話の延長」としてしか実装されていないような状態です。
そのため、電話をやろうなどと言うところは、限られるわけです。

よって、儲けの構図は、

「電話屋さんが自社の製品のリプレースくらいしかない」

という状況です。
そのため、一社が握っている技術を主製品の基盤として開発しては、リスクが
高すぎるため、Skypeが選択肢に入ることはありえないわけです。

そのため、Skypeががんばっても、2nd製品以上には成り得ないわけです。


●未来の構図
現在、「電話」としてしか使われていませんが、本来的にこれらの物は、

「コミュニケーションツールとした場合」

その真価を発揮できると考えています。
(正確には、SIPはただのセッション管理でしかないですが、これでは、あまりに
抽象的すぎるので。)

このように発展してくると、現在「電話屋」しかない市場が広がっていき、
いろいろなベンダーが参入してくることが予想されます。

この状態となると、まさに、JavaとZopeの構図と同一になるといえるのでは
ないでしょうか？


※※※以上。yusukeさんの説を元とし導き出せる仮説としての考察です※※※

やはり、個人的に気になるのが、メッセージプロトコルがHTTP+XMLという点
ですね。
まさに、SIP+というか、SIPの別プロトコルを考えたら、こうなるよねという
典型的なモデルの一つです。

個人的には、非常にアリだと思っています。

ただ、組み込み系を考慮すると、HTTPサーバ+XMLパーサ+teleoStackを積む
のは、現時点では、スペック的に非常に厳しいと思われます。
現在の流れを考えると組み込み系ははずせないため、ここをどうするのか？が
ポイントになるかなと思います。
(もしかすると、SIP互換という機能は、このためにある可能性アリです。
組み込みは、SIPで通信すると割り切っているのかも。)

でも、これだけじゃ、SIPの問題点は、解消されないという罠。
けっきょく、互換性が一番の問題点ですので。。。




そして、致命的なのが、パスワードの扱いなどのセキュリティーまわり。
暗号化なし、平文でパスワードを流すというのは、もう、致命的とかそういうのを
通り越して、リカイフノウ。

さらに、プロトコル的にセッションハイジャックが比較的簡単にできそうな
印象もあります。

これで、「プリペイド式で金払ってね」と言われても無理がありすぎです。




とてもじゃないが、Skype対抗にはならないというのが、印象です。

どうやら、メッセージは、HTTP+XMLで制御メッセージは通信しています。
ということは、TCPなんですね。
やはり、UDPで制御メッセージのやりとりってアレゲなのかなぁ。
UDPで、やりとりすると、どうしても分割の問題が発生してしまって
他網と接続することを考えたりすると非常に厳しいんですよね。
ほかにも、暗号化しようとしたときに問題もありますし。。。

ちなみに、音声は、RTPをそのまま使用しています。UDPです。




下記に代表的なメッセージのサンプルをピックアップ。
(こんなの書いて、開発元からつっこまれたらやばいなぁ。
つっこまれたら、速攻、削除するので、その辺ご了承ください。)

●ログインメッセージ。
＿|￣|○　ガックシ・・・ また、パスワードは平文かよ。。。
と、いきなりへこみ気味ですが、気を取り直して。

さて、メッセージとしては、単純ですね。
SIPのREGISTERをかなり単純にした物という感じで、あまり、つっこむ
ようなところはないですね。
ただ、バージョン番号が、下記の2種類あるのが気になります。
う〜ん、これだけ内容が違う物が入っているというのは、いやな感じで
すね。

<version id="1.0">
<version id="clientManager-client XML v0.9">

<?xml version='1.0' encoding="UTF-8"?>
<clientMsg>
  <version id="1.0">
    <date>02/16/2005</date>
    <ip>192.168.100.191</ip>
    <mid>073106872</mid>
  </version>
  <sipRegister>
    <uName>teleo2@noritsuna.jp</uName>
    <Password>password</Password>
  </sipRegister>
</clientMsg>

・サーバからの応答メッセージ

<?xml version='1.0' encoding="UTF-8"?>

<serverMsg>

  <version id="clientManager-client XML v0.9">

    <date>Wed, 16 Feb 2005 03:25:01 GMT</date>

    <mid>073106872</mid>

  </version>

  <tAck>

    <errno>200</errno>

    <errmsg>Ok</errmsg>

  </tAck>

</serverMsg>

<sipAccountStatus>

が、肝の部分。

<accountBalance>

が、謎ですが、それ以外は、見たまんまと言うところ。
これが、そのうち拡張されるのかが、個人的には興味アリです。


・サーバからの受信メッセージ

<?xml version='1.0' encoding="UTF-8"?>

<serverMsg>

  <version id="">

    <date>Wed, 16 Feb 2005 03:25:01 GMT</date>

    <mid>236411472</mid>

  </version>

  <sipAccountStatus>

    <uName>teleo2@noritsuna.jp</uName>

    <sessionID>52896CBF-110C-4708-A1C8-833EB8CCAF4C</sessionID>

    <accountBalance>0.5</accountBalance>

    <DID>15109041126</DID>

  </sipAccountStatus>

</serverMsg>

・サーバへの応答メッセージ

<?xml version='1.0' encoding="UTF-8"?>

<clientMsg>

  <version id="1.0">

    <date>02/16/2005</date>

    <ip>192.168.100.191</ip>

    <mid>236411472</mid>

  </version>

  <tAck>

    <status>OK</status>

    <errmsg>SUCCESS</errmsg>

    <sessionID>52896CBF-110C-4708-A1C8-833EB8CCAF4C</sessionID>

  </tAck>

</clientMsg>

<sipAccountStatus>

だけではなく

<sipOk>

という、ものもあるみたい。
どう違うのかは、現在不明。




●コール(発信)
通話した時のメッセージ内容。
これは、SIPとは違う動きをするようなので、詳細に追ってみたいと思います。


1，最初に、どこと通話をしたいのかネゴシエーションをとる。

これは、接続先が、teleoやGW、SIPなどいろいろなプロトコルとの相互接続を
考えているために、プロトコルのネゴシエーションをしているのではないかと
思います。

・サーバへの送信メッセージ

<?xml version='1.0' encoding="UTF-8"?>

<clientMsg>

  <version id="1.0">

    <date>02/16/2005</date>

    <ip>192.168.100.191</ip>

    <mid>073131767</mid>

  </version>

  <sipOutboundCall>

    <uName>teleo2@noritsuna.jp</uName>

    <sessionID>52896CBF-110C-4708-A1C8-833EB8CCAF4C</sessionID>

    <called>15109041126</called>

    <receivePort>30000</receivePort>

  </sipOutboundCall>

</clientMsg>

・サーバからの応答メッセージ1

<?xml version='1.0' encoding="UTF-8"?>

<serverMsg>

  <version id="clientManager-client XML v0.9">

    <date>Wed, 16 Feb 2005 03:25:26 GMT</date>

    <mid>073131767</mid>

  </version>

  <tAck>

    <errno>200</errno>

    <errmsg>Ok</errmsg>

  </tAck>

</serverMsg>

・サーバからの応答メッセージ2(相手もOKという情報)

<?xml version='1.0' encoding="UTF-8"?>

<serverMsg>

  <version id="">

    <date>Wed, 16 Feb 2005 03:25:26 GMT</date>

    <mid>450446506</mid>

  </version>

  <sipOk>

    <status>OK</status>

    <errmsg>SUCCESS</errmsg>

    <uName>teleo2@noritsuna.jp</uName>

    <callID>77757717-3332-8208-4376-688581188635</callID>

    <sessionID>52896CBF-110C-4708-A1C8-833EB8CCAF4C</sessionID>

  </sipOk>

</serverMsg>

一般的ですが、teleoは、全く逆な形を取っているようです。
（ちなみに、このように動くSIPもあります。ACKにアンサーSDPを載せます）

ちなみに、SDPに相当する部分は、かなり似通っていますね。

・サーバからの受信メッセージ

<?xml version='1.0' encoding="UTF-8"?>

<serverMsg>

  <version id='sipManager-stateMachine XML v0.9'>

    <date>Wed, 16 Feb 2005 03:25:26 GMT</date>

    <mid>086512035</mid>

  </version>

  <sipRTPConnect m='audio'>

    <callID>77757717-3332-8208-4376-688581188635</callID>

    <sessionID>52896CBF-110C-4708-A1C8-833EB8CCAF4C</sessionID>

    <rtpAddress direction='IN' type='IP4'>216.143.130.43</rtpAddress>

    <rtpPort>9232</rtpPort>

    <availableMedia>

     <codec a='rtpmap:101' >

       <version>telephone-event</version>

       <rate>8000</rate>

     </codec>

     <codec a='rtpmap:3' >

       <version>GSM</version>

       <rate>8000</rate>

     </codec>

     <codec a='rtpmap:18' >

       <version>G729</version>

       <rate>8000</rate>

     </codec>

     <codec a='rtpmap:8' >

       <version>PCMA</version>

       <rate>8000</rate>

     </codec>

     <codec a='rtpmap:0' >

       <version>PCMU</version>

       <rate>8000</rate>

     </codec>

    </availableMedia>

  </sipRTPConnect>

</serverMsg>

・サーバへの応答メッセージ

<?xml version='1.0' encoding="UTF-8"?>

<clientMsg>

  <version id="1.0">

    <date>02/16/2005</date>

    <ip>192.168.100.191</ip>

    <mid>450446506</mid>

  </version>

  <tAck>

    <status>OK</status>

    <errmsg>SUCCESS</errmsg>

    <sessionID>52896CBF-110C-4708-A1C8-833EB8CCAF4C</sessionID>

  </tAck>

</clientMsg>

これは、SIPで言うところの200応答に相当する物のようです。

・サーバからの受信メッセージ

<?xml version='1.0' encoding="UTF-8"?>

<serverMsg>

  <version id='sipManager-stateMachine XML v0.9'>

    <date>Wed, 16 Feb 2005 03:25:34 GMT</date>

    <mid>387355624</mid>

  </version>

  <sipRTPConnect m='audio'>

    <callID>77757717-3332-8208-4376-688581188635</callID>

    <sessionID>52896CBF-110C-4708-A1C8-833EB8CCAF4C</sessionID>

    <rtpAddress direction='IN' type='IP4'>216.143.130.43</rtpAddress>

    <rtpPort>9232</rtpPort>

    <availableMedia>

     <codec a='rtpmap:101' >

       <version>telephone-event</version>

       <rate>8000</rate>

     </codec>

     <codec a='rtpmap:3' >

       <version>GSM</version>

       <rate>8000</rate>

     </codec>

     <codec a='rtpmap:18' >

       <version>G729</version>

       <rate>8000</rate>

     </codec>

     <codec a='rtpmap:8' >

       <version>PCMA</version>

       <rate>8000</rate>

     </codec>

     <codec a='rtpmap:0' >

       <version>PCMU</version>

       <rate>8000</rate>

     </codec>

    </availableMedia>

  </sipRTPConnect>

</serverMsg>

・サーバへの応答メッセージ

<?xml version='1.0' encoding="UTF-8"?>

<clientMsg>

  <version id="1.0">

    <date>02/16/2005</date>

    <ip>192.168.100.191</ip>

    <mid>387355624</mid>

  </version>

  <tAck>

    <status>OK</status>

    <errmsg>SUCCESS</errmsg>

    <sessionID>52896CBF-110C-4708-A1C8-833EB8CCAF4C</sessionID>

  </tAck>

</clientMsg>

これは、SIPで言うところのACKに相当する物のようです。
これといった、特徴はありません。

・サーバからの受信メッセージ

<?xml version='1.0' encoding="UTF-8"?>

<serverMsg>

  <version id="">

    <date>Wed, 16 Feb 2005 03:25:34 GMT</date>

    <mid>435870003</mid>

  </version>

  <sipOk>

    <status>OK</status>

    <errmsg>SUCCESS</errmsg>

    <uName>teleo2@noritsuna.jp</uName>

    <callID>77757717-3332-8208-4376-688581188635</callID>

    <sessionID>52896CBF-110C-4708-A1C8-833EB8CCAF4C</sessionID>

  </sipOk>

</serverMsg>

・サーバへの応答メッセージ

<?xml version='1.0' encoding="UTF-8"?>

<clientMsg>

  <version id="1.0">

    <date>02/16/2005</date>

    <ip>192.168.100.191</ip>

    <mid>435870003</mid>

  </version>

  <tAck>

    <status>OK</status>

    <errmsg>SUCCESS</errmsg>

    <sessionID>52896CBF-110C-4708-A1C8-833EB8CCAF4C</sessionID>

  </tAck>

</clientMsg>

課金を伴うサービスであるため、切断には、万全の体制を取るのが普通であり
当然の仕様と考えられます。
万が一、切断情報が相手に届かなければ、誤課金へつながるおそれがあるため
です。

・サーバへの送信メッセージ

<?xml version='1.0' encoding="UTF-8"?>

<clientMsg>

  <version id="1.0">

    <date>02/16/2005</date>

    <ip>192.168.100.191</ip>

    <mid>073160559</mid>

  </version>

  <sipHangUp>

    <callID>77757717-3332-8208-4376-688581188635</callID>

    <uName>teleo2@noritsuna.jp</uName>

    <sessionID>52896CBF-110C-4708-A1C8-833EB8CCAF4C</sessionID>

  </sipHangUp>

</clientMsg>

・サーバからの応答メッセージ

<?xml version='1.0' encoding="UTF-8"?>

<serverMsg>

  <version id="clientManager-client XML v0.9">

    <date>Wed, 16 Feb 2005 03:25:54 GMT</date>

    <mid>073160559</mid>

  </version>

  <tAck>

    <errno>200</errno>

    <errmsg>Ok</errmsg>

  </tAck>

</serverMsg>

・サーバからの受信メッセージ

<?xml version='1.0' encoding="UTF-8"?>

<serverMsg>

  <version id="">

    <date>Wed, 16 Feb 2005 03:25:54 GMT</date>

    <mid>472351630</mid>

  </version>

  <sipHangUp>

     <uName>teleo2@noritsuna.jp</uName>

     <callID>77757717-3332-8208-4376-688581188635</callID>

     <sessionID>52896CBF-110C-4708-A1C8-833EB8CCAF4C</sessionID>

  </sipHangUp>

</serverMsg>

・サーバへの応答メッセージ

<?xml version='1.0' encoding="UTF-8"?>

<clientMsg>

  <version id="1.0">

    <date>02/16/2005</date>

    <ip>192.168.100.191</ip>

    <mid>472351630</mid>

  </version>

  <tAck>

    <status>OK</status>

    <errmsg>SUCCESS</errmsg>

    <sessionID>52896CBF-110C-4708-A1C8-833EB8CCAF4C</sessionID>

  </tAck>

</clientMsg>

まぁ、NAT越えしているので、その方が、よいのかもしれません。
ただのポーリングといえば、それまでですが。(^-^;A

・サーバからの受信メッセージ

<?xml version='1.0' encoding="UTF-8"?>

<serverMsg>

  <version id="clientManager-client XML v0.9">

    <date>Wed, 16 Feb 2005 03:25:31 GMT</date>

    <mid>708746305</mid>

  </version>

  <teleoHeartbeat />

</serverMsg>

・サーバへの応答メッセージ

<?xml version='1.0' encoding="UTF-8"?>

<clientMsg>

  <version id="1.0">

    <date>02/16/2005</date>

    <ip>192.168.100.191</ip>

    <mid>708746305</mid>

  </version>

  <tAck>

    <status>OK</status>

    <errmsg>SUCCESS</errmsg>

    <sessionID>52896CBF-110C-4708-A1C8-833EB8CCAF4C</sessionID>

  </tAck>

</clientMsg>

以上。

SIPとも互換性があると謳っているSkype対抗のソフトウェア・teleo。

・普通の固定電話からの着信にも対応！
・IEなどにバーが追加される！（Googleバーみたいなの）
・SIPともお話しできる！

ということなので、いろいろと試してみました。




まず、アプリケーションとして、とても不安定ぽ。
アイコン化された後、何をやっても元に戻せないことが。（ﾉД｀）ｼｸｼｸ

さらに、そのあと、登録されているアカウント情報がめちゃくちゃになり
接続できない事態が発生。。。
ちゃんとした物に書き換えることにより、接続できましたが、その後、
何度起動し直しても、アカウント情報壊れちゃいます。orz

んで、アカウントを登録したのですが、その最終認証画面。
URLの部分をよ〜く見てください。(図、赤い囲みの中)
「http://www.teleo.com/activate.php?user=teleo@noritsuna.jp&pass=password」

IDとパスワードが、平文&パラメータとしてわたってる。しかも、SSLじゃない。orz

・メッセージング機能
電話しかできないんですね、これ。
メッセージくらい送れればよいのに。。。




・通話品質
は、、、（ﾉД｀）ｼｸｼｸ すみません。ヘッドセット持ってないんです。
試せませんでした。ぺこ <(＿ ＿)>




・IE統合機能
いらないかも。。。IE起動するたびに通信してくれるので重いIEがさらに重く
なる罠。。。




・NAT越え
Skypeと同じ形式の模様。
RTPの通信が始まると通信先のIPがプロバイダの物と思われるIPにかわりました。

ただ、これ以上は、下手に調査すると不正アクセスとか言われかねないので
調査していません。

次回は、通信プロトコル編の予定。

噂の企業向けメッセンジャーです。
http://itpro.nikkeibp.co.jp/members/NT/ITARTICLE/20050208/155850/

これは、自分とこに「Live Communications Server 2005」をたてるのが、
前提なので、一般の人には無関係なものなのですが、これ、プロトコルに
SIPを使用していますので、SIPヲタな私としては、反応しないわけには
いかないということで、一応、反応しておくことにしました。




技術的に見ると、ただ単に、SIP的に正常進化しただけです。
今までは、RFC2543という、古いSIPの仕様に準拠していたのですが、
それを、RFC3261という、新しいSIPの仕様に準拠し直したバージョン
という、ところです。

機能的にも、今までのメッセンジャーで出来ていたことだけですし、
他社のSIPソフトフォンでは、もっと、機能が豊富なくらいです。

ただ、さすがは、ゲイツ様謹製ソフトは、ひと味違っておりまして
微妙に、RFC3261からはずれたりして、独自な実装がされている
部分があります。
そのため、純粋なSIPとしてみると、結構、微妙なものがあり、実は
最近、泣かされた経験があります。(^-^;A




と、いった感じで、別に、どうでもよいようなものだったりします。

本文の最後に、普及に関してかかれていますが、まさに、その通りで
国内メーカーが対応してくれるわけがありません。
SIP的に見ても、独自な部分がありますし、機能的にも思いっきり
かぶるとなったら、だれが、対応するんでしょ？って感じです。

そんなことをやるんだったら、無償でAPIまで公開するとか、オープン
ソースするとかしてくれると、非常にうれしいのですが。。。
※Longhornで、SIP関連のAPIが載ってくるようですので、こちらを
　利用すれば、もどきを作ることは可能になるかと思います。




ただ、この辺は、いつものMSの必勝パターンで、最初は糞のような
リリースを出して、そのうち、追いつき、気がついたら、トップシェアと
いうパターンになるんですかね？