JP5519183B2

JP5519183B2 - Ｃｃｎ経由音声通話実現方法

Info

Publication number: JP5519183B2
Application number: JP2009119440A
Authority: JP
Inventors: ジェイスチュワートポール; ヤコブソンヴァン; エフプラスマイケル; ケイスメッターズダイアナ
Original assignee: Palo Alto Research Center Inc
Current assignee: Palo Alto Research Center Inc
Priority date: 2008-05-19
Filing date: 2009-05-18
Publication date: 2014-06-11
Anticipated expiration: 2029-05-18
Also published as: JP2009284482A; US20090285209A1; EP2124415A3; US8165118B2; EP2124415A2; EP2124415B1

Description

本発明は、データネットワーク経由音声通話、特にＣＣＮ（content centric network：コンテンツ中心型ネットワーク）経由音声通話を実現する方法に関する。

ＣＣＮはコンテンツ基盤ネットワーク(content based network)とも呼ばれるネットワークである。ＣＣＮ内データ転送手法は斬新な手法であり、通話端末間コンテンツ授受に当たりネットワークトラフィックをアプリケーションレベルで監視するのではなく、データ即ちコンテンツをその名称即ちコンテンツ名によって要求／返送することとし、提供者から利用者へのコンテンツルーティングにネットワーク側が責任を持つ方式を採っている。

ＣＣＮには、コンテンツを非常に効率よく且つ非常に簡便に頒布することができるという長所がある。そのため、ＣＣＮ経由で音声通話等のリアルタイムアプリケーションを提供できるようにすることが望まれている。

ここに、本発明の一実施形態では、そのネットワーク上のデータがそのコンテンツ識別子に従い特定、探索及び頒布され且つそのデータの伝送に自己認証型のデータパケットが使用されるＣＣＮ上で、そのＣＣＮを介した音声通話を実現するため、コンピュータを利用したシステム乃至装置を構築しまたそのための方法及びプログラムを実行する。本実施形態では、まず自分宛音声通話着信へのインタレストをＣＣＮユーザから受信し、また他ネットワーク上にあり発呼元となるデバイスからはＣＣＮユーザとの音声通話に係るパケットを受信する。次いで、受信したそのパケットを、その宛先たるＣＣＮユーザから受信済のインタレストに相応するＣＣＮ識別子と共に、そのＣＣＮユーザに転送する。そのＣＣＮユーザからはその音声通話に係るパケットを受信しそれを発呼元デバイスに転送する。これによって、他ネットワーク上の発呼元デバイスからＣＣＮユーザへの音声通話を、そのＣＣＮユーザに係るＣＣＮ識別子に基づき且つその音声通話に係る状態情報無しで開始及び持続させる。そして、その音声通話を、その音声通話へのインタレストをそのＣＣＮユーザから受信できなくなってから所定時間以上経過後に終了させる。

本発明の好適な実施形態では、更に、ＣＣＮユーザからのアウトバウンド音声通話要求受信へのインタレストを表明し、アウトバウンド音声通話の発呼元となるＣＣＮユーザからアウトバウンド音声通話要求と、そのアウトバウンド音声通話に係るパケットの受信へのインタレストとを受信する。更に、そのアウトバウンド音声通話要求を他ネットワーク上に転送し、それへの応答として、そのアウトバウンド音声通話に係るパケットを当該他ネットワーク上から受信する。次いで、受信したパケットを、発呼元ＣＣＮユーザから受信済のインタレストに係るＣＣＮ識別子に基づきその発呼元ＣＣＮユーザに転送する。それによって、アウトバウンド音声通話要求元ＣＣＮユーザによるアウトバウンド音声通話を開始及び持続させる。そのアウトバウンド音声通話は、そのアウトバウンド音声通話へのインタレストを発呼元ＣＣＮユーザから受信できなくなってから所定時間以上経過後に終了させる。

本発明の好適な実施形態では、更に、他ネットワークに係るフォーマットとＣＣＮに係るフォーマットとの間でデータパケットのフォーマットを変換する。

本発明の好適な実施形態では、更に、自分宛音声通話受信拒否へのインタレストをＣＣＮユーザから受信したときにその音声通話を終了させる。

本発明の好適な実施形態では、更に、それぞれ上掲の動作を実行できる複数個のプロキシサーバ間に、個々のプロキシサーバでその音声通話に係る状態情報を使用することなく、音声通話負荷を分散する。

本発明の好適な実施形態では、更に、ＣＣＮ上の１個又は複数個のノードでそのデータパケットを認証することができるよう、個々の音声通話用データパケットにディジタル署名する。

本発明の好適な実施形態では、更に、ＣＣＮユーザに係る公開鍵についての情報を受信し、他ネットワーク上の端末がそれらの鍵を発見できるよう公開鍵の公開ディレクトリを構築し、そして公開鍵を利用する既存の端末間通信安全化手法に従い通信を安全化する。

本発明の好適な実施形態では、更に、ＣＣＮ上のオンラインユーザ、音声通話着呼待ちインタレスト未表明ユーザ及び音声通話転送待ちインタレスト表明ユーザについての情報を受信し、その情報をＣＣＮ外に提供する。

本発明の好適な実施形態では、更に、ＣＣＮ内音声メールシステムへの音声通話転送を受信済情報に基づき実行する。

本発明の好適な実施形態では、更に、ＣＣＮ外への音声通話転送を受信済情報に基づき実行する。

本発明の一実施形態におけるＶｏＣＣＮプロキシの動作を示す図である。本発明の一実施形態におけるインバウンド（非ＣＣＮ網→ＣＣＮ内）音声通話接続手順の実行例を示すフローチャートである。本発明の一実施形態におけるアウトバウンド（ＣＣＮ内→非ＣＣＮ網）音声通話接続手順の実行例を示すフローチャートである。本発明の一実施形態におけるＣＣＮ内コンテンツフローの一例を示すネットワーク図である。ＳＩＰメッセージの一例を示す図である。本発明の一実施形態におけるインタレスト表明後コンテンツ送信手順、特にＣＣＮ上でＳＩＰシグナリングを行うときの送信手順の実行例を示す図である。本発明の一実施形態におけるインタレスト表明後コンテンツ送信手順、特にＳＩＰによりＣＣＮ上でメディアストリーミングするときのパイプライン的手順の実行例を示す図である。ＣＣＮ上を伝搬するメッセージのＸＭＬ表記例を示す図である。本発明の一実施形態における公開鍵管理手順の一例を示すフローチャートである。本発明の一実施形態における情報転送手順、即ちＣＣＮ上のオンラインユーザ、音声通話着呼待ちインタレスト未表明ユーザ及び音声通話転送待ちインタレスト表明ユーザについての情報を受信し、その情報をＣＣＮ外に提供する手順の一例を示す図である。ＣＣＮ経由音声通話をサポートするコンピュータシステムの一例を示す図である。

［概説］
まず、従来の非ＣＣＮ網では、コンテンツ名ではなくコンテンツの在処（宛先）に従い通話端末間でコンテンツを授受し、そのトラフィックをアプリケーションレベルで監視する、という手法が採られていた。これに対し、ＣＣＮでは、コンテンツの入れ物名に過ぎないファイル名等の情報は使用しない。その代わりに、コンテンツそのものを示すコンテンツ名を識別子として用い、そのコンテンツを識別、要求及び頒布する。

ＩＰ(Internet Prorocol)アドレスと違い、コンテンツ名からはそのコンテンツの在処が判らない。そのため、ＣＣＮではネットワーク側が責任を持ってコンテンツをルーティングする。また、ＣＣＮ識別子たるコンテンツ名（ＣＣＮ名）には持続性及びコンテンツ固有性がある。これは、誰かがコンテンツを改変するとそのコンテンツ名も相応に変わるという性質である。この性質を付与する仕組みとしては、第１に、明示的な版管理機構を使用することができる。これは、例えば、そのコンテンツの在来名（人間が付けた名称）に版情報（「バージョン４」等）を付してコンテンツ名とする機構である。第２に、暗黙的な関連づけ機構も使用することができる。これは、例えば、そのコンテンツの在来名に認証用メタデータを付加してコンテンツ名とする機構である。認証用メタデータとはコンテンツ発行元によるディジタル署名等のことをいう。暗黙的な関連づけ機構では、認証用メタデータの内容が変わるとコンテンツ名が変化する。

ＣＣＮが有している機能の一つは、種々のコンテンツとそれを表すコンテンツ名との対応関係を維持する機能である。そのコンテンツ名は階層的であるので多くのユーザが理解することができる。例えばそのコンテンツ名が“/abcd/bob/papers/ccn/VoIP”なら、そのコンテンツは、“組織ＡＢＣＤ所属ユーザであるボブの論文集ｃｃｎに含まれる記事ＶｏＩＰ”である。しかも、ＣＣＮでは、コンテンツ利用者が組織ＡＢＣＤを探す手法や、その組織内のユーザたるボブの論文集ｃｃｎがどのホスト上にあるかを探す手法を、アプリケーションレベルで規定する必要もない。ＣＣＮ上では、当該ＣＣＮに所属しているデバイス（ＣＣＮユーザ；例えば電話機等のユーザ端末）がコンテンツを要求する際に、そのコンテンツへの興味・関心をそのコンテンツ名でＣＣＮ側に登録する。これをインタレストの表明と呼ぶ。インタレスト対象コンテンツがもしそのＣＣＮ上でローカルに入手可能なものなら、そのコンテンツは要求元ＣＣＮユーザへとルーティングされる。ルーティング用のインフラストラクチャ（ルーティング基盤）は、インタレスト頒布がスマートに実行され、そのコンテンツを発行可能なデバイスにインタレストが届き、そしてその所要コンテンツが漏れなくインタレスト頒布経路を遡行することとなるように管制する。

ＣＣＮには、この他にも非常に魅力的な性質が幾つか備わっている。まず、ＣＣＮではどのコンテンツも暗号化認証されるので、そのコンテンツの正当使用権者等、ある種のＣＣＮノードにてコンテンツ毎に真正性を確認することができる。次に、ＣＣＮでは、その発行元とは無関係にそのコンテンツ名でコンテンツにアクセスできるほか、コンテンツ要求時にその発行元を指定することもできる。例えば単に“foo.txt”を要求してもよいし、更にその“foo.txt”の発行元が“Bob”でその署名付であることを求めてもよい。更に、ＣＣＮでは、コンテンツ名として自己認証的なコンテンツ名を使用でき、またその命名法をコンテンツ提供者とコンテンツ利用者との間で任意に取り決めることができる。ハイブリッド型の自己認証的コンテンツ名、即ちネットワーク側でルーティングの効率的実行に利用する前半部分と自己認証性を提供する後半部分とからなるコンテンツ名も使用できる。そして、ＣＣＮではコンテンツと与信とが分離しているので、同一コンテンツ乃至同一署名者（同一発行元）に対する与信手法及び与信理由を、そのコンテンツを利用する側の個々のユーザが好き好きに設定することができる。例えば、その署名者との蜜月的関係を根拠にそのコンテンツに与信するＣＣＮユーザもあろうし、自分が信頼できるＰＫＩ（公開鍵基盤）にその署名者も加入しているとの理由でその署名者からのコンテンツに与信するＣＣＮユーザもあろう。

以下説明する実施形態では、ＣＣＮ・非ＣＣＮ網間境界上にステートレスなプロキシサーバを配置している。プロキシサーバとは、他のサーバへの要求転送でクライアントへの音声通話要求に対処するサーバ乃至コンピュータシステムのことである（以下単に「プロキシ」と呼ぶ）。ＣＣＮ・非ＣＣＮ網間境界上に配されるプロキシ、即ちＣＣＮと非ＣＣＮ網とにより共有されるプロキシは、そのＣＣＮと、非ＣＣＮ的プロトコル（例えばＶｏＩＰ(Voice over IP)）を使用して音声トラフィックを配分する非ＣＣＮ網との間の、ＣＣＮによる音声通話接続即ちＶｏＣＣＮ(Voice over CCN)を媒介する。本願で提案するこのＶｏＣＣＮは、従来のＶｏＩＰに比べエレガント且つロバストであり、ネットワーク管理者にとってもその保守が容易である。

一般には、プロキシのうち現在実行中の通信に関しその状態を表す情報を保持するタイプのものをステートフルプロキシと呼び、そうした状態情報を保持しないタイプのものをステートレスプロキシと呼ぶ。状態情報は格納済状態変数及びその値の集まりであり、その値の組合せによって状態が規定されるので、状態変数値が変わるとステートフルプロキシの状態も変化する。対するステートレスプロキシは、与えられたコマンド（受信したデータ）に反応するのみで、状態変数には依存しない。

例えば、ＶｏＩＰではネットワーク境界上にステートフルプロキシを配さねばならない。これは、特に安全な通話状態を確保するのに必要になる。即ち、ＶｏＩＰにて通話の安全性を確保するには、制御情報交換（シグナリング）用のＳＩＰ(Session Initiation Protocol)メッセージが入来したときに、それをＳＳＬ(Secure Socket Layer)稼働サーバ上に通して与信を受ける必要があるため、状態情報保持が必要になる。なお、ＳＩＰはインターネット経由でのマルチメディア通信セッション（音声通話、映像通話等）を設定／切断するためのシグナリングプロトコルとして広く用いられている。ＳＩＰは、１個又は複数個のメディアストリームを孕む二者間（ユニキャスト）又は多者間（マルチキャスト）セッションを開始、修正及び終了させる際に使用される。ＳＩＰは、更に、アドレスやポートの変更、更なる参加者の招待、メディアストリームの加除等にも使用される。また、ＳＳＬはインターネット上での通信、例えばウェブ閲覧、電子メール、インスタントメッセージング等に係るデータ転送を安全に行えるようにする暗号化プロトコルである。セッションとは個々のトランザクション中に個々のユーザが発行する一連の要求のことである。

これに対し、本実施形態では、例えばＶｏＣＣＮが稼働しているネットワークの境界上にステートレスプロキシを配する（このプロキシのことを以下「ＶｏＩＰ／ＶｏＣＣＮプロキシ」又は単に「ＶｏＣＣＮプロキシ」と呼ぶ）。ＶｏＣＣＮプロキシは、例えばＤＮＳ(Domain Name System)を用い、“自分は標準的なＳＩＰプロキシでありＣＣＮ内へのＶｏＩＰアクセスを募っている”とのアナウンスを外界向けに行う。ＶｏＣＣＮプロキシは、ＣＣＮ内での聴取により、ＣＣＮ内でＶｏＣＣＮを介した自分宛音声通話の着信へのインタレスト（音声通話着呼待ちインタレスト）が表明されているか否か、即ち着呼を望んでいるＣＣＮユーザがあるか否かを調べる。ＶｏＣＣＮプロキシでは、それらの識別子を随時記憶することで、外部から通話要求用のＳＩＰメッセージ即ち発呼メッセージが入来したときに、それらのなかから有効なものを検知する。但し、前述の通りそのＣＣＮユーザがＣＣＮ上のどこにいるかを覚える必要はない。これは、ＣＣＮ側ルーティング基盤が、発呼メッセージの入来時に要求側デバイスへのデータパケットルーティングをくまなく管制するからである。また、電話番号記憶は、それ単独で存在検知等の最適化手段たり得る。それによって、入来するＳＩＰメッセージのうち現在インタレストを表明していない電話機への発呼に係るものを、自動的に拒否又はルーティングすることができる。その自動ルーティングは、自分ではインタレストを表明していないＣＣＮユーザの電話番号を借用しいわゆる音声メールシステムがインタレストを表明することで、実行することができる。

これから詳述する通り、ＶｏＣＣＮプロキシの肝要な特徴はそのステートレス性にある。ステートレス性があるということは、音声通話に際しそのプロキシで知るべき情報が、そのプロキシにてコンテンツ送受信に使用するＣＣＮ名だけである、ということである。そのため、ＶｏＣＣＮプロキシは、同時多発しうる音声通話セッションを負荷過剰によるダウン無しで捌くことができ、またそれらのセッションを任意個数の独立したゲートウェイによりトランスパレントに媒介させることができる。言い換えれば、個々の通話で生じる一連のパケットを、ある種の状態情報を専権的に利用する特定且つ単一のゲートウェイに通さなければならないわけではなく、複数且つ任意のゲートウェイで媒介することができる。また、それ自体が発呼であるＳＲＴＰ(Secure Real-time Transport Protocol)ポーションによる通話移管時よりは生じにくいものの、あるＶｏＣＣＮプロキシが例えばＳＳＬにより外部ＳＩＰサーバとの間に安全な接続を確立した後、ＳＩＰによる設定動作中にそれとは別のプロキシへと通話を移管する必要が生じることがある。その場合でも、ＳＳＬセッションから離脱するプロキシから別のプロキシへとＳＳＬセッションを移管するに当たり、ＳＳＬ接続についての状態情報をそれらプロキシ間で交換する必要はない。ＣＣＮでそうしたことが可能になるのは、移管先プロキシがそのＳＳＬ接続状態の名称へのインタレストを表明できるからである。そのインタレストは例えばＣＣＮ内にエニーキャストされ（そのＣＣＮ上のどこからでもアクセス可能になり）、そのインタレストに係る状態下にあるプロキシのうちどれかに到達するので、ＣＣＮ上の全てのプロキシに一巡コンタクトする必要がない。その新たなプロキシは、その状態情報を素早く取得しＳＳＬセッションを引き継ぐことができる。

また、ＶｏＩＰで与信されるのは、通過サーバ数が１個だけで、そのサーバの名称及びアドレスが共に周知で、しかもそのアドレス及び名称に係る証明書が発行されている情報だけである。そのＳＳＬサーバは、設定後に音声通話を行えるようそのネットワークのファイアウォールにトンネルをあけねばならず、またその通話が終了するときにそのトンネルを閉じねばならない、という意味で、必然的にそのネットワークの基幹部となる。従って、ＶｏＩＰにおけるＳＳＬサーバは、通話を開始させる時点だけでなく通話継続中はずっと、トンネルを閉ざすのに十分な状態情報を保持していなければならないし、またオンライン状態であり続けなければならない。その上に、ＳＳＬサーバが単一でなければならないという条件が課されるので、数千もの通話が行き交う規模の音声通信は、ＶｏＩＰでは実現困難である。

これに対し、本実施形態では例えば個々のＣＣＮ内パケットに署名されるので、サーバ側で音声通話に係る状態情報を保持していなくても、そのトラフィックに応じ音声通話をサーバ間移管することができる。即ち、本実施形態では無欠性や信頼性がデータによって提供されるので、データ転送に使用されるチャネルにそうした性質が備わっている必要がない。更に、本実施形態ではファイアウォールを維持し続ける必要もない。これは、ＣＣＮユーザに対する発呼に続く一連のパケットへのインタレストを表明しているＣＣＮユーザのみに対し、その通話をルーティングするようにしているからである。ＶｏＣＣＮプロキシは、ＣＣＮユーザが発する個々のインタレストから、そのインタレストに相応する次の音声パケットをネットワーク境界越しにそのＣＣＮユーザへと転送しなければならないことを知る。また、通話を終了させるのは、そのＣＣＮユーザ（例えば電話機）による後続パケットへのインタレスト表明が途絶したときである。ＶｏＣＣＮプロキシはこれに応じ自動的にパケット転送を中止する。通話状態をアクティブにモニタする必要はない。つまるところ、ＶｏＣＣＮプロキシは、ＣＣＮユーザによるインタレスト表明に応じ且つそのＣＣＮユーザの代理として、次の作業を実行する。

また、ＶｏＣＣＮではＣＣＮフォーマットのパケット（ＣＣＮパケット）内にＳＩＰメッセージが埋め込まれる。即ち、ＶｏＣＣＮプロキシは、非ＣＣＮ網から到来する通話要求をＣＣＮ内に転送することができるよう、また着呼先となるＣＣＮユーザから応答パケットを受信し通常のＶｏＩＰパケットとしてその非ＣＣＮ網へと転送することができるよう、ＩＰフォーマット・ＣＣＮフォーマット間でパケットフォーマットを変換する。ＶｏＣＣＮプロキシはＣＣＮ内への送信に先立ちパケットに署名するので、着呼先のＣＣＮユーザは事前認証済のデータを受け取ることができる。そのため、不要なデータがむやみやたらにＣＣＮユーザに転送されることはない。

［基本動作］
図１Ａに、本実施形態におけるＶｏＣＣＮプロキシの動作を示す。図示の通りＶｏＣＣＮプロキシ１６８はＣＣＮ１６０の境界上に配されており、ユーザ端末１７０と通信中である。プロキシ１６８はＩＰ網１６２にも属していて、そのＩＰ網１６２内には従来既知のＳＩＰプロキシ１６６が配されている。プロキシ１６６はユーザ端末１６４と通信中である。

ＣＣＮ１６０内のユーザ端末１７０は、インバウンド通話を受信する準備が整ったら自分宛音声通話のデータトラフィックを待つ旨の音声通話着呼待ちインタレストを表明する。この状態でユーザ端末１６４が端末１７０宛に発呼すると、ＳＩＰプロキシ１６６はその発呼に係るパケットをＶｏＣＣＮプロキシ１６８へ転送する。プロキシ１６８は、まず、その発呼についての第１コンテンツ名をＣＣＮ１６０内に送信し、次いでその発呼に係る最初のパケットをＣＣＮ１６０内に転送する。プロキシ１６８による第１コンテンツ名の送信は、端末１６４に成り代わってのインタレスト表明、具体的には第１コンテンツ名宛のあらゆるパケットを受信する旨の音声通話転送待ちインタレスト表明である。端末１７０は、それに続き転送される最初のパケットのコンテンツ（例えば端末１６４で設定されたもの）に基づき第１コンテンツ名を識別する。言い換えれば、最初のパケット内の情報から導出できる第１コンテンツ名が、この音声通話セッションにおける端末１６４の識別子となる。

着呼先ユーザ端末１７０は、次いで、第１コンテンツ名宛データパケットによって応答し、更に第２コンテンツ名を設定する。ＶｏＣＣＮプロキシ１６８は、この第２コンテンツ名に基づき、そのパケットが端末１６４への応答であることを識別する。それに前後し、端末１７０は、全ての第２コンテンツ名宛データへのインタレスト（音声通話転送待ちインタレスト）を表明する。

アウトバウンド通話、即ちＣＣＮ１６０内で開始されＣＣＮ１６０外に接続される通話の際には、ＶｏＣＣＮプロキシ１６８が、まずその音声通話に相応するコンテンツ名又はその一部（プレフィクス等）、例えばＶｏＩＰの宛先アドレスや公衆電話交換網（ＰＳＴＮ）の電話番号へのインタレスト（音声通話発呼待ちインタレスト）を表明する。このインタレスト表明に応じ、ユーザ端末１７０は例えばユーザ端末１６４との音声通話を要求する。その際、端末１７０は、まず接続要求用のＳＩＰメッセージをＣＣＮパケットに埋め込んで送信し、次いで、いずれかの端末例えば１６４を対象とした音声通話転送待ちインタレストを表明する。その際、端末１７０は、プロキシ１６８が端末１６４からのメッセージを転送する際使用できるコンテンツ名を、指定することができる。

ユーザ端末１７０からの接続要求用ＳＩＰメッセージ入りＣＣＮパケットは、ＶｏＣＣＮプロキシ１６８によって受信される。プロキシ１６８は、そのパケットをフォーマット変換してＳＩＰメッセージを取り出し、そのメッセージに係るパケット即ちＳＩＰパケットをＳＩＰプロキシ１６６へ転送する。プロキシ１６６はそのパケットをユーザ端末１６４に転送する。端末１６４は、そのパケットを受信すると、音声通話セッション開始手順を完了させるためのＳＩＰメッセージを返送する。それらのＳＩＰメッセージがＣＣＮ１６０・ＩＰ網１６２間境界に到達すると、プロキシ１６８は、それらのＳＩＰメッセージをコンテンツ名と共にＣＣＮパケット内に埋め込む。そのコンテンツ名としては、端末１７０によって先に指定されているコンテンツ名、例えばＳＩＰメッセージ自体から導出できるコンテンツ名即ちプロキシ１６８のステートレス性を保てるコンテンツ名を使用する。端末１７０は、そのコンテンツ名に係るコンテンツを待つ旨の音声通話転送待ちインタレストを既に表明しているので、それらのＳＩＰメッセージを首尾よく受信することができる。前述のＣＣＮ・ＳＩＰ間変換手順をこのようにして実行することで端末１７０・１６４間初期ハンドシェイクを確立することができ、またそれに続いてＳＩＰによるセッション開始手順等を実行することにより音声通話セッションを開始させることができる。

図１Ｂに、本実施形態におけるインバウンド（非ＣＣＮ網→ＣＣＮ内）音声通話接続手順の実行例をフローチャートにより示す。この例では、まず、ＣＣＮユーザが音声通話着呼待ちインタレストを表明したとき、そのインタレストをＶｏＣＣＮプロキシが受信する（動作１００）。ＣＣＮユーザは、音声通話着呼待ちインタレストを表明することによって、同じＣＣＮ上に存するあらゆるエンティティ、即ちルータ、ゲートウェイ、プロキシその他のあらゆるピアに対し、着呼準備が整っていることを通知する。

その後、ＶｏＣＣＮプロキシは、他ネットワーク上からＣＣＮユーザ宛音声通話接続要求を受信すると（動作１１０）、その要求をＣＣＮ内に転送する（動作１２０）。その種の要求にはその通話で使用されるコンテンツ名がセットされるので、着呼先になりうるＣＣＮユーザは、音声通話実行に先立ち、そのコンテンツ名に対応するコンテンツを待つ旨の音声通話転送待ちインタレストを表明しておくことができ、またその後に転送されてくる音声通話接続要求に応答することができる。ＶｏＣＣＮプロキシはその応答を他ネットワーク上に転送する（動作１３０）。音声通話への命名手法即ち識別子付与手法としては、例えば左側プレフィクスを“親”にする構造化命名法を使用する。この手法では例えば“/parc/home/smetters”が“/parc/home/smeters/test.txt”の親になる。

その後、ＶｏＣＣＮプロキシは、他ネットワーク上の発呼元とＣＣＮ上の着呼先との間に介在しその音声通話を開始及び持続させる（動作１４０）。この動作は着呼先に係る識別子及びその音声通話に係る識別子に基づき行われる。その音声通話に係る状態情報を持ち続ける必要はない。着呼先が周期的インタレスト表明を続けている間はその通話は継続されるが、そのインタレストを受信できない時間が所定時間以上続いたら、その通話は自動的に終了される（動作１５０）。なお、当該所定時間は通話の種類に応じて変化させることができる。

図１Ｃに、本実施形態におけるアウトバウンド（ＣＣＮ内→非ＣＣＮ網）音声通話接続手順の実行例をフローチャートにより示す。この例では、まずＶｏＣＣＮプロキシがアウトバウンド通話接続要求を待つ旨の音声通話発呼待ちインタレストを表明する（動作１８０）。アウトバウンド音声通話を所望するＣＣＮユーザは、そのインタレストに応じ、アウトバウンド接続要求用ＳＩＰメッセージ入りのＣＣＮパケットを送信することによって発呼する。ＶｏＣＣＮプロキシはそのパケットを受信する（動作１８２）。発呼元たるＣＣＮユーザは、それと前後し、応答たるインバウンドＳＩＰメッセージを待つ旨の音声通話転送待ちインタレストを、指定名称付で送信する。ＶｏＣＣＮプロキシは、そのインタレスト及び指定名称を受信する。即ち、発呼元は、着呼先からのＳＩＰメッセージを転送する際に、ＶｏＣＣＮプロキシが使用してよいコンテンツ名を指定することができる。

ＶｏＣＣＮプロキシは、次いでその接続要求用ＳＩＰパケットをＳＩＰプロキシサーバに転送する（動作１８４）。ＶｏＣＣＮプロキシは、それへの応答たるＳＩＰメッセージを着呼先から受信する（動作１８６）。ＶｏＣＣＮプロキシは、更に、発呼元が指定したコンテンツ名と共にそのＳＩＰメッセージをＣＣＮパケットに埋め込み（動作１８８）、そのパケットを発呼元に転送する（動作１９０）。その後、ＶｏＣＣＮプロキシは、発呼元に音声通話を開始及び継続させる（動作１９２）。発呼元が、その通話に係るコンテンツを受信する旨のインタレスト表明を停止すると、その通話は自動的に終了される。

このように、ＣＣＮ上では、そのコンテンツ名即ちコンテンツ識別子に従い情報が特定、探索及び頒布され、またそのルーティング手法がコンテンツ識別子に基づきＣＣＮ側で決定される。データパケットは自己認証型であり、どのデータパケットも自分自身についての認証情報を含んでいる。即ち、どのデータパケットも、その利用者が信用している誰かによりディジタル署名されているので、そのデータパケットを誰からでもキャッシュ、複製及び取得することができ、またその無欠性及び真正性を確認することができる。具体的には、ＣＣＮにおける認証はコンテンツ名・データ対によるものである。即ち、そのコンテンツをＣＣＮ上に持ち込む際、発行元は「私はこのコンテンツＣにＮというコンテンツ名を付ける」と宣言し、それらコンテンツ名Ｎ・コンテンツＣ間の対応関係についてディジタル署名する。ＣＣＮ上にある個々のコンテンツのフルネームは、発行元が付けたコンテンツ名に、そのコンテンツ名とコンテンツとの対応関係についての署名を付加したものとなる。これには、更に、発行元識別子（例えばその発行元の公開鍵の暗号ダイジェスト）、タイムスタンプ、コンテンツ種別表記等、相応量の認証用メタデータを付加することもできる。

図２に、本実施形態におけるＣＣＮ内コンテンツフローの一例をネットワーク図により示す。この例では、発行元２００からＣＣＮノード２１０及び２２０を経て加入者２５０へとコンテンツが流れている。２７０、２８０及び２９０はその流れ即ちコンテンツフローを表している。ＣＣＮでは、発行元２００・加入者２５０間に介在する中間ノード（２１０、２２０及び２３０）のうち何個所でも、ＣＣＮ上を流れるコンテンツをローカルキャッシュしそのコピーを保持することができる。従って、ある加入者があるコンテンツにアクセスした後、その加入者の近隣に存する他の加入者がそれと同じコンテンツへのアクセスを求めた場合、当該他の加入者はＣＣＮノード上のコピーを暗黙のうちに利用することができ、ネットワーク負荷が軽くなる。例えば、加入者２５０が以前に要求したことがあるコンテンツを図中の加入者２４０が要求した場合に、ノード２２０上にそのコピーがあるのでれを加入者２４０に提供できる。同様に、加入者２５０が以前に要求したことがあるコンテンツへのインタレストを加入者２６０が表明した場合、ノード２１０又は２３０上のコピーを加入者２６０に提供できる。いずれの場合も、発行元２００に至るデータ伝送経路全体を遡行しなくてもよい。音声通話も同様のコンテンツフロー及びローカルキャッシングを経るので、電話会議等のマルチキャスト音声セッションを円滑に実施することができ、また移動した加入者例えば２５０をノード２３０等で捉え直すことができる等ユーザ移動に好適に対処することができる。加えて、例えばあるＣＣＮノードとの通信にフェイル乃至フォールトが発生しても、他のＣＣＮノードと通信できれば支障なく通信を継続できるので、フェイル／フォールトトレラント性を高めることができる。

［ＳＩＰシグナリング］
本実施形態ではＳＩＰに従いシグナリングを実行する。ＳＩＰは、ＴＣＰ(Transmission Protocol)等のストリーム型高信頼接続かそれともＵＤＰ(User Datagram Protocol)等のデータグラム接続かによる挙動の違いを規定している点を除けば、その土台となる転送機構に拠らないかたちで規定されている。また、ＳＩＰのＲＦＣ(Request For Comment)では、その発呼元から種々のプロキシサーバを経て最終的な着呼先に到達するまでにＳＩＰメッセージが辿る経路について、ホップバイホップアカウンティングの保全手法を説明している。従って、ＳＩＰによるシグナリング（ＳＩＰシグナリング）はＣＣＮ上でも実行することができ、またその接続形態としてはデータグラム方式が適している。この方式では、要求用と応答用とにＰＤＵ(Protocol Data Unit)を分解し、それらを対応するコンテンツ内にマッピングすることによって、ＳＩＰシグナリングを難なく実行することができる。

ただ、古典的なＳＩＰ方式では、発呼元のユーザ端末が相応構成のＳＩＰプロキシとの接続を確立し、そのプロキシに頒布タスクを委ねている。これに対し、本実施形態では、ＶｏＣＣＮプロキシがＳＩＰメッセージのコンテンツに対しＣＣＮ式命名法に従い命名する。従って、既に招待へのインタレストを表明しているＣＣＮ上のどの受信者も、そのＳＩＰメッセージを受信することができる。例えば、図３に示す招待用のＳＩＰメッセージには“/abcd.com/bob/sip/invite”と命名されるであろう。このコンテンツ名で表されるコンテンツは、組織ＡＢＣＤ所属ユーザであるボブを招待する、というものである。ＣＣＮ上に転送されたＳＩＰメッセージは、そのコンテンツへのインタレストを表明した全てのデバイスに届くので、ＳＩＰアドレスに代わるコンテンツ名をそうした一貫性あるＣＣＮ式命名法に従い導出することで、ＶｏＩＰアプリケーションにつきものであった場所制限が排除される。図３に示す例なら、招待用ＳＩＰメッセージ中のメソッド名“INVITE”、プロトコル識別子“sip”並びに着呼先エンティティ（着呼先名“bob”及びその所属先組織“abcd.com”）に基づきコンテンツ名が導出されるので、発呼側は、着呼先がＣＣＮ上のどこに存するか、またそれを探し出すのにどこに尋ねればよいかを知る必要がない。ＣＣＮではネットワーク側がコンテンツ頒布に責任を持つ。

本実施形態では、非ＣＣＮ網上のデバイスに成り代わり、ＶｏＣＣＮプロキシがその音声通話に係るコンテンツへのインタレストを表明する。ＣＣＮ上の着呼先は、ＶｏＣＣＮプロキシによって転送される招待用ＳＩＰメッセージのコンテンツから、ＳＩＰによる今回のやりとりに係るコンテンツ用のコンテンツ名を導出する。また、着呼先エンティティ、プロトコル識別子及びメソッド名に加え、通話識別子を、ＶｏＣＣＮプロキシにて（コンテンツ名に）付加することもできる。これによって、複数発生しうるシグナリングインスタンスを互いにはっきり区別すること、即ち今回のシグナリングにアクティブに参加しているインスタンスだけにそのコンテンツを受け取らせることができる。図３に示した招待用ＳＩＰメッセージを受け取ったＣＣＮユーザ、例えば図１Ａ中のユーザ端末１７０は、例えば“/efgh.com/alice/sip/response/12345600@efgh.com”なるコンテンツ名を有する音声通話コンテンツを送信する。

また、本実施形態では、ＶｏＣＣＮプロキシのステートレス性を維持するため、インバウンド及びアウトバウンドのメッセージを利用し、相手側への到達に必要な状態情報を搬送する。具体的には、ＣＣＮ名に状態情報を埋め込む手法を使用するが、ペイロードデータに状態情報を付加する手法も使用できる。総じて、メッセージで状態情報を搬送する手法は少なくとも三種類、即ち状態情報を（１）ＣＣＮ式のコンテンツ名に埋め込む手法、（２）ＳＩＰメッセージそのものに埋め込む手法、（３）ＣＣＮ式のデータメッセージに埋め込む手法等があるが、そのうちの手法（１）を使用するのは、多くの場合にややオーバヘッドになるとはいえ他のいろいろな点で有利であるからである。例えば図３に示した招待用ＳＩＰメッセージに対しＶｏＣＣＮプロキシにて命名する場合なら、前述の“/abcd.com/bob/sip/invite”ではなく“/abcd.com/bob/sip/invite/13.1.14.5/2303”と命名するだけで、コンテンツ名に状態情報を埋め込むことができる。ＣＣＮ上の着呼先は、自分からの応答メッセージのコンテンツ名“/efgh.com/alice/sip/response/12345600@efgh.com/13.1.14.5/2303”をＳＩＰメッセージから導出できる。ＶｏＣＣＮプロキシは、この応答メッセージのコンテンツ名から状態情報“/13.1.14.5/2303”、ひいてはその応答メッセージの転送先ＶｏＩＰアドレスを導出できる。ＶｏＣＣＮプロキシは、その通話に係る状態情報を必要としない。また、ＳＳＬハンドリングの違い等がある場合は、コンテンツ名やデータ構成部分に、より多くの状態情報を埋め込むこともできる。

更に、コンテンツを送信するに当たりそれへの応答メッセージが欲しい場合、本実施形態では、送信側が音声通話転送待ちインタレストを表明する。その応答メッセージのコンテンツに付与されるコンテンツ名は、コンテンツ送信に使用されたメッセージのコンテンツによって暗黙のうちに決まるので、送られてくるはずの応答メッセージのコンテンツ名又はそのプレフィクスを、コンテンツの送信より前に導出することが可能である。このロックステップ式トランザクションはＣＣＮトラフィックのフロー制御につながる。即ち、音声通話転送待ちインタレストが表明されていないのにコンテンツが送信されたら、それを無視してもかまわない。こうした手順のことを、略してインタレスト表明後コンテンツ送信と呼ぶこととする。図４に、本実施形態におけるインタレスト表明後コンテンツ送信手順、特にＳＩＰシグナリングでの手順の例を示す。図中、発呼元４００・着呼先４０５間の矢印線はコンテンツ及びインタレストの流れ及びその向きを表している。添え字（Ｉ）が付いているメッセージはインタレスト表明用、添え字（Ｃ）が付いているメッセージはコンテンツ送信用である。具体的には、まず着呼所望のデバイス４０５が招待を待つ旨の音声通話着呼待ち“Invite”インタレストを表明する（４１０）。発呼元４００は、これに応じ着呼先４０５からの応答を待つ旨の音声通話転送待ち“Call1/SIP”インタレストを表明し（４１５）、次いで着呼先４０５を現在の呼“Call1”に招待する旨の“Invite[Call1]”コンテンツを送信する（４２０）。着呼先４０５は、発呼元４００からの応答を待つ旨の音声通話転送待ち“Call1/SIP”インタレストを表明し（４２５）、次いで発呼元４００からの招待に応じる旨の“Call1/SIP[OK]”コンテンツを送信する（４３０）。発呼元４００は、これに応じ着呼先４０５からの応答を待つ旨の音声通話着呼待ち“Call1/SIP”インタレストを継続表明し（４３５）、次いで招待成立を確認する旨の“Call1/SIP[ACK]”コンテンツを送信する（４４０）。着呼先４０５も“Call1/SIP445”インタレストを継続表明する（発行）。この手順は、発呼元４００及び着呼先４０５が通話継続を望んでいる間は継続される。従って、ＶｏＣＣＮプロキシがその通話についての状態情報を保持する必要がない。なお、ここで述べた通信手順はＣＣＮ経由１対１通話の一般的なパターンである。

ＣＣＮは本実施形態向けの諸機能をサポートすることができる。第１に、最終的な着呼先がＳＩＰメッセージによる招待に関して表明したインタレストをＣＣＮ内に横溢させることができる。少なくとも、そのインタレストに係るコンテンツをそのインタレストが充足される端末までルーティングすることができる程度には、そのインタレストが頒布される。第２に、ＣＣＮでは潜在的着呼先がＳＩＰメッセージによる招待に関し表明するインタレストを保全することができる。潜在的着呼先はいつまでも着呼を待ち続けられるので、そのデバイスが通話への参加にインタレストを表明している限りはずっと、ネットワーク上又はそのデバイス自身に、継続してインタレストを保持させることができる。本発明の好適な実施形態では、ＣＣＮ上からその音声呼の継続へのインタレストが表明されている限りその音声通話を継続させることができる。また、ある相応の非聴取期間（数秒程度）の発生を以てインタレスト表明中断とすることで、その動作を停止したデバイスやネットワークから切り離されたデバイスを、そのインタレストに関し基本的にＣＣＮから切り離すことができる。

［音声通話セッション］
ＳＩＰシグナリングが首尾よく終わったら、ストリーミング対象を諸パラメタの交換によって特定した上で、諸ＳＩＰパケットのペイロードを用い相応するメディアストリームを発生させる。ＳＩＰによる音声通話セッションならば、ＳＤＰ(Session Description Protocol)タイプのペイロードをストリーミング対象として特定し、そのペイロード中のデータをＲＴＰ(Real-time Transport Protocol)に係る手順に従い実際にリアルタイム伝送させることで、オーディオビジュアルな通話セッションを実現するのが普通である。

これに対し、本実施形態では、ＲＴＰに従い伝送されてきたデータをサーバ等でＣＣＮ向けにマッピングすることにより、ＶｏＣＣＮを実現する。その際には、同一メディアストリーム内ＲＴＰフレームの相互区別用情報断片（シーケンス番号）をコンテンツへの命名に利用する。これは、ＳＩＰシグナリング時に使用した着呼先エンティティ及び通話識別子に加え、そうしたシーケンス番号を使用してコンテンツに命名することで、ＲＴＰによるメディアストリーム（ＲＴＰストリーム）を受信側で再現可能となるからである。例えばあるフレームのコンテンツ名が“/abcd/bob/rtp/ 12345600@efgh.com/5678”といった形式なら、その最後に付されているシーケンス番号（この例では“5678”）に基づき、ＲＴＰストリームを再現することができる。また、命名法がこのような手法であるので、複数個のフレームをＣＣＮ上に一時保存することによって、送信側・受信側間のラテンシを吸収することができる。

ＣＣＮノード等では、こうして送信されるフレームのコピーがキャッシュされる。既にキャッシュされているものと同一のコンテンツ名を有するフレームが到来した場合、前者に代わって後者がキャッシュされるので、キャッシュされるコピーはシーケンス番号１個に付き１個となる。そのシーケンス番号は１６ビット二進数であるのでＲＴＰストリーム内でグローバルにユニークな値とはならないが、そのストリームにおけるフレーム個数が２¹⁶個に達しないうちは、受信側で何も問題なく利用することができる。また、それ以上に古いフレームが受信側で必要とされるときには、その個数以上のフレームをＣＣＮ上で流通させうるよう、ＲＴＰのＲＦＣに従い拡張シーケンス番号を計算して使用すればよい。ただ、シグナリング時に倣いインタレスト表明とコンテンツ送信をロックステップ的に実行した場合、即ちインタレスト表明後コンテンツ送信を実行した場合、ＲＴＰストリームでは、そのネットワークの分散性やラテンシの影響でラウンドトリップラテンシが長くなる可能性がある。そのストリームを正常に再生できないほどに、パケットの受信を待たされる可能性もある。

本実施形態では、同一チャネルを使用し複数のインタレストをパイプライン送信することができるので、そうした問題をなくすことができる。図５に、本実施形態におけるインタレスト表明後コンテンツ送信手順、特にＳＩＰによりＣＣＮ上でメディアストリーミングするときのパイプライン的手順の例を示す。この手順では、受信側５００が通話受信へのインタレストを複数回連続して表明し、それに応じ送信側５１０が発呼する。従って、ＣＣＮ上でのデータ頒布速度が、受信側５００からのインタレスト到着頻度ではなく、メディアコーデック等の符号化装置５２０からのコンテンツ送出速度で決まる。

また、本実施形態では、ストリーム受信側のＣＣＮユーザにて、そのメディアストリームへのインタレストを所定個数同時に係属させる。即ち、受信側ではストリーム生成時又はネットワーク状態変化時にそのストリームへのインタレストを所定個数表明する。受信側は、そのストリームに属するフレーム（コンテンツ）を受信するたびに新たなインタレストを表明し、それによってインタレスト係属個数を当初個数に戻すことで、同一ストリームへのインタレストを、パイプライン受信に必要な個数に維持する。システム側では、それらのインタレストを１個のインタレストに統合し、統合前の個数を保存しておく。インタレストと違いコンテンツは、同じ名称のものが複数同時に保持されることはないので、そのコンテンツが相応するインタレストの表明元へと回送するたびに、保存しておいた個数値をデクリメントさせる。従って、そのＣＣＮユーザにコンテンツが到着する頻度は、発行者からそのコンテンツが送出される速度、例えば符号化装置５２０によるデータ送出速度で決まる。但し、その上限は、受信側となるＣＣＮユーザが同時表明するインタレストの個数によって制約される。

［通話の安全化］
まず、標準的な端末間通信安全化手法としてはＭＩＫＥＹ(Multimedia Internet KEYing)が知られている。ＳＲＴＰに従い標準的なＶｏＩＰパケットで音声トラフィックを伝送するネットワークでは、その音声トラフィックを収容する伝送路の暗号化や鍵の交換に、このＭＩＫＥＹを使用することができる。しかし、ＭＩＫＥＹでは、通信相手の公開鍵を認証できねばならない。ＭＩＫＥＹを使用しＣＣＮ上で音声通話を安全化するにはこの課題をクリアする必要がある。また、ＣＣＮ上での通信には、どのパケットも公的認証可能でなければならないという条件が課されている。この条件を満足させるには、ＣＣＮパケット内に埋め込まれた情報を公開認証できねばならない。しかしながら、ＳＲＴＰでは、メディアストリーム内の個々のパケットを保護するのに共有鍵ベースの暗号化及び認証方式が使用されるので、その鍵が配布された端末（通話当事者）以外は、ＳＲＴＰによるパケットを認証・改変することができない。

そこで、本実施形態では、若干機密漏洩の危険を孕むものの、ＶｏＩＰにおける上述の鍵配布問題を解決するため単一拠点型構築(single point configuration)を実行する。これは、そのＣＣＮに属するあらゆるデバイス（例えばその組織内のあらゆる電話機）の公開鍵をＶｏＣＣＮプロキシが探し、標準的なディレクトリプロトコル例えばＬＤＡＰ(Light Weight Directory Access Protocol )に従いその公開鍵をＣＣＮ外の電話機等に提供する、という手法である。このＣＣＮに属する電話機は、自分の秘密鍵へのアクセスによって音声通話着呼待ちインタレストを表明しＣＣＮ上に送出する。ＶｏＩＰ区間に属するゲートウェイは、そうしたインタレストを受信する一方、目的とするノード用の公開鍵をＣＣＮ側に要求する。ＶｏＣＣＮプロキシは、ＬＤＡＰメッセージによる要求を受け、所要ノード（例えば通話当事者たる組織内電話機を含む）用の公開鍵を返送する。その際、ＶｏＣＣＮプロキシに予め公開鍵を覚えさせておく必要はない。ＶｏＩＰ区間に属するゲートウェイは、音声通話データの拡散制御が必要なら、そのインタレストに付された署名の真正性を確認することができる。

また、本実施形態ではＶｏＣＣＮプロキシを認証プロキシとしても機能させる。これは、そのＣＣＮのインフラストラクチャにとり真正なＶｏＩＰパケットを認証できるようにするためである。前述のように、ＶｏＩＰによる通話の安全化には、チャネル自体を安全化することと、そのチャネル上のＶｏＩＰパケットを通話当事者だけで認証可能にすることが求められるが、ＣＣＮでは逆に、どのデータパケットもディジタル署名等で公的認証できねばならない。そのため、本実施形態では、ＶｏＣＣＮプロキシがそのＣＣＮ上の他のノードから与信を受け、ＣＣＮパケットに埋め込まれてＣＣＮ上に送出されるＶｏＩＰパケットに、署名を付すようにしている。その署名には標準的なディジタル署名方式を使用してもよいし、他の何らかの形態で公的認証可能なストリーム署名を行ってもよい。ストリーム署名は、個々のディジタル署名のコストがメディアストリーム上の複数のパケットで償却される方式であり、通常は、その生成後所定期間以内のパケットしか認証することができない。例えば、パケット１００個分の音声通話データを収集したＶｏＣＣＮプロキシがそれに続いてディジタル署名を１個送出すると、それら１００個のパケット全てが認証される。ただ、これを行うとＶｏＣＣＮプロキシのステートレス性が侵害される可能性があるので、認証側にて主な状態情報を保持することも求められる。こうした仕組みを実現するための技術としては、既存又は将来の暗号論文献に記載の技術を随意に利用することができ、また種々のメディアストリームにより効率的にディジタル署名できる仕組みをそれによって実現することができる。

図７に、本実施形態における公開鍵管理手順をフローチャートにより示す。この手順では、ＶｏＣＣＮプロキシが、まずＣＣＮユーザに係る公開鍵についての情報を受信し（動作７００）、次いで公開鍵の公開ディレクトリを構築する（動作７１０）。ＶｏＣＣＮプロキシは、これによって他ネットワーク上の端末がそれらの鍵を発見できるようにした上で、公開鍵を利用する既存の端末間通信安全化手法に従い通信を安全化する（動作７２０）。

本実施形態の利点の一つは、単一拠点型構築を実行しているため、ＶｏＣＣＮ方式におけるＴＣＯ(Total Cost of Ownership)がＶｏＩＰ方式に比べ低いことにある。既に存在検知や公開鍵ディレクトリ自動構築との関係で例示説明した通り、ＶｏＣＣＮ方式で個々の電話機に持たせる必要があるのは“この電話機はボブのもの”等といったアイデンティティ情報だけであり、その他の構成設定は追って自動実行される。その“ボブのもの”なるアイデンティティ情報は、公開鍵秘密鍵対として或いはその生成素材として使用され、生成された鍵はＣＣＮ上に送出されて所属組織の認証を受ける。なお、この動作はその電話機への構成設定の一部として実行できるが、安全性にやや欠けても容易に行いたいなら、例えば“ボブのもの”であることを宣明する第１の鍵を認証した上でひとまず待機する、という方法を採ればよい。自分宛の呼び出しを受信することができなければ電話機の持ち主ボブは苦情を申し立てるであろう。そうした申立があれば、その電話機のアイデンティティ情報が窃取されたと見なして対処することができる。

鍵の認証が済んだら、そのＣＣＮのインフラストラクチャはその電話機に対する呼の自動ルーティングを開始する。即ち、その電話機は、どこにいようとも音声通話着呼待ちインタレストを表明し始めるので、インフラストラクチャは、その種のインタレストを表明した電話機宛の発呼があったらその電話機にその通話要求をルーティングする。このとき、その電話機がどのポートに接続されているかが判るようにＣＣＮのインフラストラクチャを構成する必要はない。また、電話機の存否はその電話機によるインタレスト表明の有無で判定できる。その電話機が卓上電話機なら、常時着呼可能であることを利用して、その電話機のユーザ宛の音声メールをその電話機に録音させることもできる。その電話機が携帯電話でありソフトウェアの搭載及び構成設定の上で動作しているのなら、そのユーザが電話にでられないときにその電話機宛の呼び出しをインフラストラクチャ側で他に転送することや、そのユーザからその呼び出しにでられないとの通知があったときにそのユーザ宛の音声メールをインフラストラクチャ側で録音することができる。

本実施形態では、単一拠点にて構成設定を行うだけでこれらの機能を実行させうる。即ち、電話機にアイデンティティ情報を与えれば、その電話機で安全に通話することができる。その電話機についてのポリシーや全電話機に有用な付加サービスについての構成設定は、いずれも、それらのサービスが提供される諸デバイスにて実行することができる。構成の誤設定（コンフィギュレーションエラー）はこうした単一拠点型構築で顕著に減り、またＶｏＣＣＮ方式の実施コストは単一拠点型構築の効果でかなり抑圧される。

図８に、本実施形態における情報転送手順、即ちＣＣＮ上のオンラインユーザ、音声通話着呼待ちインタレスト未表明ユーザ及び音声通話転送待ちインタレスト表明ユーザについての情報を受信し（処理８００）、その情報をＣＣＮ外に提供する（処理８１０）手順の一例を示す。その情報は、例えば、発呼元を音声メール又はＣＣＮ外電話機へとルーティングするのに使用される。

［ＣＣＮにおけるワイヤプロトコル］
本実施形態では、ＦａｓｔＩｎｆｏｓｅｔ等、ＸＭＬ(eXtensible Markup Language)ベースのワイヤプロトコルを使用する。但し、他の種々の圧縮用フォーマットも使用することができる。例えば、ＸＭＬの“end”タグは明示的に符号化しなくてもよいがその場合は全てのフィールドにその長さでタグ付けする、といったＸＭＬ文書構造を考慮に入れていて、しかもその二値コンテンツを符号化した後そのコンテンツをＢａｓｅ６４へとリソートする必要がないものである。

図６に、図３に示したＳＩＰメッセージ（ＩＮＶＩＴＥメソッド）を送信する場合を例に、ＣＣＮ上を伝搬するメッセージのＸＭＬ表記を示す。ＣＣＮにてコンテンツにマッピングされるＰＤＵは、図示の通り少なくとも一対の“ccn”タグを含んでいる。ＰＤＵのうち“ccn”タグで括られている部分には、“interest”タグや“content”タグを任意個数記述することができる。また、その部分への“interest”タグや“content”タグの加除は随時行えるので、ネットワーク上の任意のデバイスにてＰＤＵ同士を統合しまたＰＤＵを複数個のＰＤＵに分割することもできる。更に、ネットワーク的観点からすると、それらが同一フレーム内に存するか否かによって、個々の“interest”タグ又は“content”タグのタグの扱いを変える必要はない。いずれにせよ、“interest”タグで括られている部分や“content”タグで括られている部分には、経路指定情報が本願中の他の個所で使用した表記での順序と同じ順でリストアップされているので、ＣＣＮ上でネットワーク層へとコンテンツをルーティングする上で重要な情報を、そこから抽出することができる。なお、本実施形態に関しご理解を頂くため、ここではＸＭＬ用語を用いてワイヤプロトコルを説明したが、実際の使用時には、ＦａｓｔＩｎｆｏｓｅｔ等の圧縮用フォーマットに符号化したデータをＸＭＬ表記に変換等する必要はない。

また、本実施形態ではアプリケーションＰＤＵが保持される。即ち、シグナリングとデータ（ＳＩＰとＲＴＰのコンテンツ）が同一フレームに一緒に埋め込まれるので、ＣＣＮ上でフレームのルーティングに必要になるのは、そのフレームのコンテンツに共通して潜む少量の情報だけである。

［ＣＣＮエージェント］
本実施形態では、ＣＣＮによるフロー制御をＣＣＮエージェントが担っている。即ち、どのアプリケーション乃至ネットワークインタフェースも、個々のＣＣＮノードと通信を行う際に、ＣＣＮエージェントのプロセスを１回実行しなければならない。本実施形態で使用するＣＣＮエージェントは、ＵＮＩＸ（登録商標）ドメインソケットにより諸アプリケーションと通信するための独立したプロセスである。ＣＣＮエージェントは単一スレッド型であり、接続先ソケットのうちいずれかからデータが到来するまで選択ループを実行して待つよう構成されている。それらソケットへのネットワーク接続を担うのはまた別のプロセスである。それらのプロセスは、アプリケーションが行うのと同様にしてＣＣＮエージェントに接続し、パケットの双方向伝送を担う。また、この機能をＣＣＮエージェント本体に取り込むことも可能だが、それによって生じる効率向上は僅かなものである。

ＣＣＮエージェントは、コンテンツキャッシュ及び係属インタレストテーブルを使用する。係属インタレストテーブルは、現在表明されているインタレスト（係属インタレスト）及びその個数をインタフェース別に管理するテーブルである。パケットが到来すると、ＣＣＮエージェントは、そのパケットを分解して個別のインタレスト及びコンテンツを取り出し、それら到来インタレスト及び到来コンテンツを互いに別個に処理する。そのうち到来コンテンツについては、ＣＣＮエージェントは、まず、コンテンツキャッシュを参照することによって、その到来コンテンツと完全に同一名称のコンテンツがそこに保存されていないことを確かめる。コンテンツ名はコンテンツをユニークに特定できるよう付されているので、もし同一名称のコンテンツがコンテンツキャッシュ上に既に保存されているのであれば、その到来コンテンツを重複と見なして無視する。

ＣＣＮエージェントは、次いで係属インタレストテーブルを参照することによって、その到来コンテンツとマッチする係属インタレストを探す。“マッチ”とは、その到来コンテンツのコンテンツ名のプレフィクスと、係属インタレストテーブル上にあるその係属インタレストの名称とが、一致することをいう。もしその到来コンテンツとマッチする係属インタレストが見つかったら、ＣＣＮエージェントはその係属インタレストを消費し（即ちそのインタフェース別計数値をデクリメントさせ）、更にその到来コンテンツを対応するインタフェースに送信するスケジュールを設定する。また、ＣＣＮエージェントは、どの場合でもその新たなコンテンツをコンテンツキャッシュ上に保存する。

到来インタレストに関しては、到来コンテンツに関する処置より立ち入った処置を実施する。即ち、ＣＣＮエージェントは、コンテンツキャッシュを参照することによって、その到来インタレストとマッチする未送信のコンテンツを探す。“マッチ”とは、その当ラインタレスをそのコンテンツで充足させうること、具体的には上記同様のプレフィクスマッチング条件を満たしていることをいう。“未送信”とは、そのコンテンツをまだ送信していないこと即ちそのインタレストの発行元インタフェースがまだ受信していないことをいう。もし該当するコンテンツが見つかったら、ＣＣＮエージェントはそのコンテンツを送信するスケジュールを設定し、その到来インタレストを消費する。

また、その到来インタレストとマッチするコンテンツがコンテンツキャッシュ上に複数ある場合、そのうち１個だけを送信対象にする。正確性という点ではどれを送信しても支障はないが、本実施形態におけるＣＣＮエージェントは到来時期が最も古いものを送信対象にする。逆に、その到来インタレストとマッチするコンテンツがコンテンツキャッシュ上に見つからなかった場合、ＣＣＮエージェントは、その到来インタレストをその発行元インタフェースと関連づけて係属インタレストテーブルに登録し、その新たな係属インタレストを他のインタフェースへと頒布する。

そのインタレスト頒布の際、本実施形態におけるＣＣＮエージェントはフルード（横溢）方式を使用する。即ち、ＣＣＮエージェントは、頒布しようとしているインタレストのうちインタレスト識別子未保有のものに、ランダムに発生させたインタレスト識別子を１個ずつ割り当てて頒布し、到来するインタレストのうち以前に到来したことがあるインタレスト識別子を伴っているものを全て無視することによって、ループ伝送発生を防いでいる。その際、適当な長さの時間窓を設定することで、インタレスト識別子受信履歴を保存するためのテーブルのサイズを抑えることもできる。また、ＣＣＮエージェントは、インタレスト頒布に当たり、個々のインタレストの送信タイミングを微妙に且つランダムにずらすので、その送信を待つ間に、頒布対象とされた（何個かの）インタレストにマッチする新たなコンテンツが（何個か）到来する可能性がある。そのような状況が発生した場合には、そのインタレストの頒布をキャンセルしてそのインタレストを消費する。逆に、マッチするコンテンツの到来と行き違いで頒布されてしまったインタレストについては、ＣＣＮエージェントは、敢えて取り消すようなことはしない。そして、相応の時間が経過しても消費されなかったインタレストはタイムアウトになる。

本実施形態では、インタレストをタイムアウトにする仕組みとして指数減衰方式、即ちそのテーブルへのインタレスト係属個数に比例する速度で係属インタレストテーブルからインタレストを抹消していく方式を使用している。この方式では、ある時間（半減期）が経過すると係属インタレストのうち半数が抹消されるのが原則であるが、インタレスト係属個数が１個のときは例外で、そのラスト１個のインタレストはそれに続く一半減期に亘り維持されるようにする。具体的には、スケールファクタとして５を使用し、一半減期当たりの４回インタレスト係属個数ｘを更新させるには、次の式
(数１)
ｉｆｘ≦５ｔｈｅｎｘ＝ｘ−１；
ｅｌｓｅｘ＝ｆｌｏｏｒ（（ｘ＊５＋３）／６）；
に従いインタレスト係属個数ｘを更新すればよい（５／６は２-^1/4の好適な有理数近似値）。アプリケーション側では、抹消されたインタレストをリフレッシュする役目を果たすため、これと同様の指数減衰方式を用いリフレッシュ所要時期を判別する。また、ここではそのうちの最も重要なものとしてインタレスト頒布及び係属インタレスト抹消について説明したが、同様の時間ベース動作が必要となる場面は他にも幾つかある。例えば古くなった情報をコンテンツキャッシュから削除する動作や、長時間に亘り使用されなかったインタレスト用のデータ構造を退隠させる動作である。ＣＣＮエージェントは、自分用の動作スケジュールリストを参照し、オペレーティングシステムのカーネルによるコールアウト機能と類似した形態で、そうした動作を実行させる。また、ＣＣＮエージェントがこうした選択ループにて使用するタイムアウト値は、スケジュールリスト上でその次にある動作の実行時刻に従い算出する。

［コンピュータ兼通信システム］
図９に、本実施形態でＣＣＮ経由音声通話の実現に使用されるコンピュータシステムの例を示す。図示の通り、このコンピュータ兼通信システム９００はプロセッサ９１０、メモリ９２０及び記憶装置３３０を備えており、その記憶装置３３０にはプロセッサ９１０で実行される種々のプログラムが格納されている。そのうちプログラム９４０はＶｏＣＣＮプロキシ機能を提供するためのステートレスＶｏＣＣＮプロキシアプリケーションであり、ＣＣＮ９５０を介した音声通話はそのプロキシ機能によって実現されている。また、この図にはシステム９００が置かれた環境も示されている。即ち、システム９００はＣＣＮ９５０・他ネットワーク９７０間に位置しており、ネットワーク接続手段９８０及び９９０を介しそれらに接続されている（符号同順）。その接続手段９８０及び９９０は、ブロードバンドでも無線でも電話でも衛星でもよい。即ち、目的とするネットワークに接続することができればよい。また、ＣＣＮ９５０上には複数個のノード（例えば他のコンピュータシステム）９６０〜９６４がある。それらのノード９６０〜９６４は、種々のユーザ端末乃至デバイスと共に、ネットワーク即ちＣＣＮ９５０を形成している。システム９００はＣＣＮ９５０、他ネットワーク９７０又はその双方の一員とも扱える。その稼働時には、記憶装置９３０上のアプリケーション９４０をメモリ９２０上にロードし、更にプロセッサ９１０によって実行することにより、システム９００をＶｏＣＣＮプロキシとして機能させる。即ち、ＣＣＮ９５０・他ネットワーク９７０間で上掲の諸機能を実行させる。

１００〜１５０，１８０〜１９２，７００〜７２０動作、１６０，９５０ＣＣＮ、１６２ＩＰ網、１６４，１７０ユーザ端末、１６６ＳＩＰプロキシ、１６８ＶｏＣＣＮプロキシ、２００発行元、２１０〜２３０，９６０〜９６４ＣＣＮノード、２４０〜２６０加入者、２７０〜２９０コンテンツフロー、４００発呼元、４０５着呼先、４１０，４１５，４２５，４３５，４４５インタレスト、４２０，４３０，４４０コンテンツ、５００受信側、５１０送信側、５２０符号化装置、８００，８１０処理、９００コンピュータ兼通信システム、９１０プロセッサ、９２０メモリ、９３０記憶装置、９４０ステートレスＶｏＣＣＮプロキシアプリケーション、９７０他ネットワーク、９８０，９９０ネットワーク接続手段。

Claims

そのネットワーク上のデータがそのコンテンツ識別子に従い特定、探索及び頒布され且つそのデータの伝送に自己認証型のデータパケットが使用されるコンテンツ中心型ネットワーク（ＣＣＮ）上で、
自分宛音声通話着信へのインタレストをＣＣＮユーザから受信する一方、他ネットワーク上にあり発呼元となるデバイスからはＣＣＮユーザとの音声通話に係るパケットを受信し、
受信したそのパケットを、その宛先たるＣＣＮユーザから受信済のインタレストに相応するＣＣＮ識別子と共に、そのＣＣＮユーザに転送し、
更に、そのＣＣＮユーザからその音声通話に係るパケットを受信して発呼元デバイスに転送することによって、
他ネットワーク上の発呼元デバイスからＣＣＮユーザへの音声通話を、そのＣＣＮユーザに係るＣＣＮ識別子に基づき且つその音声呼に係る状態情報無しで開始及び持続させ、
そして、その音声通話に係るインタレストをそのＣＣＮユーザから受信できなくなってから所定時間以上経過後に、その音声通話を終了させる、
という動作を、任意のコンピュータで実行するＣＣＮ経由音声通話実現方法。
請求項１記載のＣＣＮ経由音声通話実現方法であって、更に、
ＣＣＮユーザによるアウトバウンド音声通話要求へのインタレストを表明し、
アウトバウンド音声通話の発呼元となるＣＣＮユーザから、アウトバウンド音声通話要求と、そのアウトバウンド音声通話に係るパケットの受信へのインタレストとを受信し、
そのアウトバウンド音声通話要求を他ネットワーク上に転送し、
それへの応答として、そのアウトバウンド音声通話に係るパケットを当該他ネットワーク上から受信し、
受信したそのパケットを、発呼元ＣＣＮユーザから受信済のインタレストに係るＣＣＮ識別子に基づき、その発呼元ＣＣＮユーザに転送することによって、
アウトバウンド音声通話要求元ＣＣＮユーザに係るアウトバウンド音声通話を開始及び持続させ、
そして、そのアウトバウンド音声通話へのインタレストを発呼元ＣＣＮユーザから受信できなくなってから所定時間以上経過後に、そのアウトバウンド音声通話を終了させるＣＣＮ経由音声通話実現方法。
請求項１記載のＣＣＮ経由音声通話実現方法であって、更に、上記他ネットワークに係るフォーマットとＣＣＮに係るフォーマットとの間でデータパケットのフォーマットを変換するＣＣＮ経由音声通話実現方法。
請求項１記載のＣＣＮ経由音声通話実現方法であって、更に、自分宛音声通話受信拒否へのインタレストをＣＣＮユーザから受信したときにその音声通話を終了させるＣＣＮ経由音声通話実現方法。