debiancdn

AWS, Content Delivery Network and Debian

日別アーカイブ: 2007/09/12

B-6-24 電話起動のWS連携 NTTSI研 宮城

既存電話では情報提供サービスはDTMFなので自由度が低い。ユーザは待たないといけない。同じことばっかやってるのに。

そこで入力を音声にすりゃいいじゃん「暗証番号を変更したい」で、起動させる。さらにカスタマイズ、パーソナライズできるとなおいい。ということで音声契機のサービス合成機能研究へ。

今あるもの?:サービステンプレートに基づいて必要なサービスコンポーネントを組み合わせてユーザパーソナライズ、状況に応じたサービスを動的に提供する。例としては旅行支援サービス。ユーザがSTを自由に編集できる。既存のWSを取り込み可能

新規テレコムサービス提案:MRFで音声認識、キーワード化、ST検索(現在は全てのSTを取得しているが、一発でいけるようなのがほしい)、ST発見、ST実行の流れ。

新規ST作成:面倒。時間がかかる。

既存STのキーワード検索:特殊キーワードはどうすんだ、検索データの収集が必要

既存STのカテゴリ情報活用検索:カテゴリ分類作業が必要になる

Q:具体例おしえて

A:「銀行 暗証番号 変更」からカテゴリ分類。足りない情報はユーザに質問してわかったらST実行。

Q:前提では音声だけですか

A:そう。インターネット上でやってもいいとは思う。

Q:音声で暗証番号変更を学会発表でするなんて恥だ

Q:会話の予備調査はしているのか?音声認識がある程度いっているという前提は正しいのか? 雑音とか状況は?

A:eznaviwalkなどでもできているし何とかなると思うが。

 

印象:ここにxxどうにゅう!みたいな話にはなってないような。

BS-5-1 サービスプラットフォームの役割とアーキテクチャに関する考察 富士通研 上野さん

背景:利用者自身が開発できるネットワークサービス開発環境、そのための動向、サービス部品と要件は、提案サービスプラットフォーム

動向としては多くはSOAの考え方。具体的なサービス部品を検討してみる。ロジックは大きく3つ。通信プロトコル処理部(基本部)、サービス状態変化により指定された処理を行う拡張部、AAA。

基本部はプロトコル隠蔽、拡張部は抽象化された機能を担当する。

  1. 部品をそろえて
  2. 同じ要素の重複開発をふせいで、サービス迅速化
  3. インフラの知識なくサービス構築可能となる

ではどういう基盤機能?機能要素、部品、サービサ間の管理がキーとなる。

サービサ自身がカスタマイズ項目を管理するのは実際むずかしい。なので、あらかじめつけておく。

認証認可について:サービス部品にアクセスする前に認証認可 or サービス部品からの問い合わせに回答する、その両方のために抽象クラスを用意

NWリソース管理:それぞれの部品にネットワーク監視させるのはコスト高なので、監視クラスを提供。

ポイント:SOAに基本的に従う。WF分析だけでは足りず、通信部分の隠蔽、リアルタイム性も重要。

Q:インターネットでやるのかNGNでやるのかはっきりさせてほしい。一般論を議論してないのにテレビ会議だけやってるのはおかしいのでは

A:たしかにNGNに限らない。通信サービス。

Q:特化しないと共通技術のだしようがない、共通とかいっていると気持ちいいかもしれないけど、役に立たないものができるよ

Q:個別の共通の間には何があるの?

A:拡張部分のレベルまで共通化部品として提供したい

Q:ネットワークをどこまで隠蔽するの?

Q:(1)サービスをわけていくのは昔からやっている。IN時代のトラウマがあるけどどこがブレイクスルーなのか。NGNならなんでうまくいくんだろう?(2)隠蔽で線をひくと「もっと中みせろ」という人がいるのだがどういったアプローチがあるか

A:(1)SIP+WSが一般になってきたのが大きい。エンドユーザが利用できるようになってきた。(2)文句があったら個別に対応していく

B-6-23 電子マネーカード決済を支えるビジネス専用IPネットワーク 元NTT,元芝浦工大 宮口

年金もらって趣味で学会をやっている。流通業界通信網の歴史と動向。VANからTCP/IPへの要求があったが提供側はTCPIP化を拒否していた。

CAFISの概要。9600とコアと1200の端末系

Open Business Networkというのが流通側からの要求で設計することにした。IP-VPN。DNSあり、事前登録済みのあて先のみ通信できる。portまで登録。OBN直収が500社。JCB30万台そのほか20万台(ダイアルアップ)。カード決済代行会社(CS)が生まれた。

CAFISが30秒かかってたのが1秒になった。利用料金が定額制になった(格安になった)。それで広まった。1秒以内にSuicaオートチャージもできるようになった。NGNでこういうのができるか心配している。

NGNにも回線つなぎっぱなしがほしい。エッジルータは大丈夫か?

具体的に回線がクリティカルなアプリケーションの話としておもしろい。SIP的なつなぎっぱなしは対応したSDPを書けばいいけどGGSNに与えられるかが問題か。

B-6-22 IMSにおける3pcc実現方式 NTT 中島

IMSにおける3pcc規定 TISPAN ES 283 003 の解説、特徴。3pccのサービスはASがやる、ヘッダ操作のみ規定され、シーケンスなどは規定されていない。Routing B2BUA(SIP端末が発呼)、Initiating B2BUA(AS発呼)

3pccをIMSでやるとサービス競合が起こる可能性がある。3pccイネーブラからの出はS-CSCFに通るので競合制御はそこで行うはずなのであまり考えなくてもいい。そのためにP-Charging-Vector, P-Asserted-Identity, route, replacesヘッダについての解説

しかしながら、IMS網とSIP網の違いによりS-CSCFにおいて異なるダイヤログ間関連性を判断できないことに起因する信号ループ、大量着信が発生しうる。

JSR116/286ではそのあたりを対応していないのでそれに対応したプラットフォームを検討したい

Q:3pccは普通になってるんでは

A:実際にはそのままじゃ動かない

Q:具体的なサービスは?

A:想定具体的にはしていない。Parlay-X相当。click2dialにはまだ道がある。

Q:標準化の場は?

A:実装技術の標準なのでIMSやTISPANの場ではない。JSRの場になるかも。

B-6-21 SCIMのJSR116による実装 NTT SI研 金子

SCIMの紹介、動向、実装方式の提案。

要求条件はキャリアグレードの信頼性。スケーラビリティ重要。負荷変動が予測できない。

市中技術:サービス振り分けロジック、プロトコルアダプタ、振り分けロジック。これらをノード系PF,JAIN SLEE, SIP Servlet系で比較。ノード系はアクティブスタンバイが多い、ベンダ独自。JAINはN-act(というかJAVA依存)、対応ベンダすくない。

というわけでSIP Serveletをつかうとベンダロックインもないのでつかうことにする。

SIP Servelet上に実装するなら、B2BUA ASからくるINVITEが新規呼になってしまうので注意が必要。そこで、JSRでは任意のヘッダ、24.229ではRouteHeaderを使っている。

今後の課題は性能上の課題が多い。

Q:表をもっと説明

A:JAIN SLEE系の問題は昔はJavaだったこと自体がネックになっている。

Q:SIP Servlet系だと制約が多いのでは

A:状態保持をいじっている。JAIN SLEEだと自由度が高い。HTTPServeletとの類似性もあって開発しやすいのでは

SCIMでもService Chainの話をしているような。狭義のSCIMについての話をしていただけに見える。

B-6-20のIMSにおけるアプリケーションサーバへのMRF制御情報通知方式(NTT SI研 徳永)

IMSの音声系メディアサービス。MRFCをSrインターフェース経由でASとつないでそこからSOAP用意してWSからたたけるようにする。

IMS端末からWSを起動するようにするのが目的。従来はMSCML(RFC4722)24.880で決まっている。主にSIP INFOが飛ぶ。DTMFなどでWSを制御する方法を提案する。

MRFCからWSに通知する方法ついて提案方式は3つ。

S-CSCFを通過させる方法ではINFOが飛びまくる。とくにDTMFをつかうとひどいことに

SIPASを通過させる方法、1よりはマシだが呼処理が面倒

直接WSにSOAP投げる方法。一番楽。が、MRFが当然SOAPさわれないと意味がない。

Q:インターネットでできるのになんでNGNなんですか?二の舞になるんでは。インターネットでやるのがコスト問題で駆逐されるんじゃ

Q:3つの比較にどんな軸があるのか

A:呼処理付加

Q:セキュリティの面や状態遷移をしらないCSCFがあるのは問題では?

A:そもそもシナリオがあまりよくないのがそもそも問題なのでこれを拡張すれば2,3、の方式はいらないかも

B-6-19のSIP相互接続検査仕様に関する検討(NTT-AT 児玉憲造)

対象RFCは3261,3264.2617,3265を最小仕様として選定し、さらに、ユニキャスト、UDP,ダイジェスト認証にのみ絞った。パケットのみを検査で内部処理についてはスルーする。相互接続イベントに持っていっていった。

他との比較SIP-test-docu.txt, RFC4475(SIP rfcを、4月に決まったSIP仕様接続(NTT?)のものがあるが、それらは敷居が高い。IMSに適合できるようにしたい。

RFC2119に基づくテスト。MUST,SHALL,REQUIRED,SHOULD,RECOMMENDEDを対象にしている。MAYとOPTIONALは対象外。

Q:新規参入者にやさしいとはどういうことか?どういうテストをするのが妥当だと考えているか? タイムアウトに関する検査はどうかんがえるか?

A:現状ではSIPのテストは決まっていないので、実証実験が大事。検査項目は独自に定めている。

妥当性はNTT-ATのひとりよがりにもみえるので今後に期待したい。テスト自動化は?SIPpとかとの関係は?などなど疑問はいっぱい。

鳥取出張

9時からテレカン。そのあと1時半すぎに会社でるまではmanagerと話したりいろんなものを仕込んだり。

高井戸で電車のったときは降っていなかった雨が駒場では大雨というか雷に。渋谷で山手線にのりかえて品川についたらホーム階段がものすごい雨漏りというか排水管に穴があいているかんじで階段が使えずエスカレータに行列。おかげで京急乗り遅れるところだった。

無事羽田到着。JTBのカウンターが3番とかいってSNAのとなりでものすごく遠い。まあしかたないが。受付をすませて手荷物検査通過してカードラウンジへ。とりあえずトマトジュースをのんだりしながら出発まで待つ。

乗ってしまえば1時間で羽田またされることもなく出発し、到着する。バスで鳥取駅へ。路線バス450円なのだが途中一つのバス停にもとまらなかった。

鳥取にはついたのだが、、ホテルに問題が。ホテルモナーク鳥取というところにとまったのだが、モデム貸し出し式のLANというやつが、、モデムがもうない、使いたいならロビーがfreespotになっているのでそこでやれ、という話。しかしfreespotはかなりはまり道で、gmailつながらない、MSN messengerつながらない、でえらいこと。かろうじてexchangeにはつながるもののSMTPはブロックされているようでメールが出せない。freespotはどんなフィルタをするかは設置者の自由らしいけど正直まいるなあ。

6時半からレセプションがあった。偉い人のためのもので知ってる人はいないことは毛頭覚悟の上で行ってみた。学生参加ってことで2500円。一人で飯をたべていたF島先生をみつけたので挨拶をして、M先生登場を待ってたり。ひさしぶりに東北大のS先生にあって、さらに3人ほど紹介される。

おわってからNICTとNTTの人とのみに行く。ありがたい。