1
はじめに
2002 年７月 14 日から７月 19 日まで横浜で開催された第 54 回 IETF1会議にＷＧ１−３2のメ ンバーも参加した。
本報告では、メンバーが参加した IETF WG3のうち TTC ＷＧ１−３活動に関連の深い部分 （enum, midcom, spirits, sip, sipping, simple）について会議内容・技術動向について報告する。
2
開催概要
IETF は、インターネット技術の標準化機関であり、標準プロトコルの研究・開発・選定を行 っている。個人の資格で自由な参加を基に、通常はメーリングリスト（以下、ML と表す）を中 心に議論が進められ、IETF 会議として集会形式での会議を年３回開催する。この内２回が米国、 １回が米国外で開催する。今回の第 54 回 IETF 横浜会議は、WIDE プロジェクトがホストとな り、アジアでは初めて開催した。会場では、情報通信関連の最先端会議である IETF らしく、無 線 LAN やターミナルルームにより、いつでもどこからでもインターネットアクセス可能な環境 が提供されている。恒例の T シャツも参加者に配られた。 初日の 7 月 14 日は、初参加者へのオリエンテーション・チュートリアルが主であり、実質の 会議は 7 月 15 日より始まった。WG, BOF4, IESG5プレナリー等合わせて１００を超えるセッシ ョンが行われ、参加者２０００名以上の内の半数近くが日本からの参加者であった。 会議進行は、最初に決められた議題（agenda）に従って、議長(Chair)が先導し、出席者が会 場に置かれたマイクに列を作って順に発言する形式をとり、物事の決定は“大まかな合意” （rough consensus）による。決定の意志を聞くため議長が出席者にハミングを求めるのも IETF らしいところであろう。また、議論に使用するドキュメントは、事前に ML や Web で配布され ており、基本的には内容の説明は行われない。IETF 横浜会議全体としては、IPｖ６が大きな話題となった他、セキュリティやモビリティに 関して多くの成果が得られた。次章では、TTC のＷＧ１−３活動の観点から関連の深い IETF WG(enum, midcom, sprits, sip, sipping, simple の各 WG)について報告する。なお、これらの 他にＷＧ１−３に関連するものとして IETF WG sigtran/megaco/pint 等もあるが、これらのセ ッションは開かれなかった。
3
参加ＷＧ報告
3.1 Telephone Number Mapping WG (enum) 3.1.1 WG会議の概要
議長 議長 議長 議長
Patrik Faltstrom <[email protected]> 1 Internet Engineering Task Force
2 ＩＰ信号方式(sigtran/megaco/sip 等)に関する標準化 3 Working Group
4 Birds Of Feather, WG の準備会議に相当 5 Internet Engineering Steering Group
第 54 回ＩＥＴＦ横浜会議参加報告
第一部門第三専門委員会
沖電気工業（株） 後藤雅徳
沖電気工業（株） 新井英樹
ＫＤＤＩ（株） 澤田拓也
Richard Shockey <[email protected]> WG WG WG WG についてについてについてについて E.164 番号から URI6への変換を行うための DNS7ベースのアーキテクチャ・プロトコル (enum)の研究開発。 会議内容 会議内容 会議内容 会議内容 日時：2002 年 7 月 15 日 13:00∼15:00 参加者：８０名程度 ① ITU-T SG2 の状況報告 ITU-T においては enum システム実現に向けた DNS 構成や運営についての標準化を進めてお り、プロトコルの標準化を行なう emun WG も連絡を取り合っている。会議では国コードの登 録について暫定的な合意があったこと、e164.arpa 配下に現在六カ国の登録が行われていること が、議長より報告された。 ② RFC2916 bis01 RFC2916 は 2000 年９月にできた enum の最初の版であり、現在は enum を DDDS8のアプ リケーションとして定義する形で改版作業が行われている（次節を参照）。NAPTR レコード内 enumservice フィールドの ABNF シンタックスについて議論があった。議論の中心は、サービ スとプロトコルが何でありどのように表すかに置かれた。この場では以下の形式とし、ML で議 論を継続することになった。
service_field = "E2U" 1*("+" enumservice) enumservice = foo *[bar]
foo = 1*32(ALPHA / DIGIT) bar = ":" foo
③ enum/enum-like システムのシナリオ
enum-like システムとは、enum の仕組み（電話番号から URI への変換）を enum の適用領 域外、例えば E.164 以外の番号への適用や通信事業者特有の目的に則した利用を行なおうとす るものである。会議では紹介のみが行われた。
http://www.ietf.org/internet-drafts/draft-stastny-enum-scenarios-00.txt ④ enum URI
URI として、enum: URI スキーマを追加しようとする提案である。tel: URI にパラメータを つけて表せば十分であると言う意見もあり、ML で継続して議論することになった。
3.1.2 enumとその動向
enum は、E.164 番号を URI へと変換するためのプロトコルであり、RFC2916 “E.164 number and DNS”で規定されている。例えば、enum を用いれば電話番号を使ってインターネ ット上のサービスやリソース（電子メールやＷｅｂ、データベース検索）にアクセスすることが 可能となる。
enum では、E.164 番号から URI へ変換するためのデータベースとして DNS を用い、電話番 号をキーとして DNS へ問い合わせることにより URI を得る。DNS への問い合わせには、完全 修飾ドメイン名（FQDN, Fully Qualified Domain Name）のインターネットアドレスが必要で あるため、enum では、電話番号を FQDN へ形式変換するための手順を定めている。具体的な 例を示すと、日本の電話番号 (03)3432-1551 であれば、1.5.5.1.2.3.4.3.3.1.8.e164.arpa に変換 （図１）され、これをキーとして DNS に問い合わせを行う。DNS からは、NAPTR(RFC 2915)9 と呼ぶリソースレコードが返され、この NAPTR レコードと元の電話番号（図１の手順３の文 字列）により、URI やアクセスするためのプロトコル・サービスを得ることができる（図２）。 DNS から返される NAPTR レコードは複数ある場合がある（一つの電話番号に対して複数の
6 Uniform Resource Identifier 7 Domain Name System
8 Dynamic Delegation Discovery System
9 Naming Authority Pointer, RFC2915 は、RFC 3403(DDDS Part 3 )により obsolete されてい る。
URI を割り当てることが可能である。）。 現在、enum WG では、RFC2916 の改訂作業を進めている。これは、enum を DDDS10のア プリケーションとして定義し直すものである。DDDS は、特定の文字列へ、動的に得られる規 則（データベースに置かれる）を繰り返し適用することにより、出力（例えば URI）を得るた めの抽象的なアルゴリズムを定めたものである。実際に適用するためには、DDDS の規定に従 って、アプリケーションがアルゴリズムやデータベースを定義しなければならない。現在 enum の改訂で行われているのは、この定義作業である。E.164 番号から URI を得る基本的なアルゴ リズムは変っていない（例えば、図１の手順はそのまま残る）。但し、DDDS で NAPTR が規定 され直され、図２の「フラグ」や「サービス」はアプリケーション側で定義することになってお り、前節②のような議論が続けられている。 手順 例 処理 1 (03)3432-1551 元となる電話番号 2 +81-3-3432-1551 E.164 番号とする 3 +81334321551 “+” 以 外 の 非 数 字 を 除 く ( こ の 文 字 列 を 後 で NAPTR 処理に使用)。 4 81334321551 数字以外の文字を除く。 5 8.1.3.3.4.3.2.1.5.5.1 数字の桁間に”.”を置く。 6 1.5.5.1.2.3.4.3.3.1.8 数字の順番を逆順にする。 7 1.5.5.1.2.3.4.3.3.1.8.e164.arpa 文字列の最後に”.e164.arpa”を付与する。 図 1 電話番号の FQDN 化
3.2 Middlebox Communication WG (midcom11) 3.2.1 WG会議の概要
議長 議長 議長 議長
Melinda Shore <[email protected]> WG
WG WG
WG についてについてについてについて
middle box (例、ファイヤーウォールや NAT12)のポリシー制御等ためのアーキテクチャ・通
10 2002 年 10 月に RFC 化された。RFC3401（Part 1）∼RFC3405(Part 5) 11 middle box commnication
12 Network Address Translator
正規表現
図２ ＮＡＰＴＲ レコードの例 $ORIGIN 1.5.5.1.2.3.4.3.3.1.8.e164.arpa .
IN NAPTR 100 10 “u” “sip+E2U” “!^.*$!sip
:[email protected]!” .
置換文字列 サービス フラグ 優 先 オーダ タイプ クラス 注：正規表現・置換文字列で、 ここの例では、”!”が区切り文字
信プロトコル(midcom)の研究・開発・選定および pre-midcom13の開発 会議内容 会議内容 会議内容 会議内容 日時：2002 年 7 月 16 日 14:15∼16:45 参加者：200 名程度 ① 活動状況報告 フレームワークドキュメント及び要求条件ドキュメント14の状況報告。 STUN15は、WG Last call 状態にある。
SPAN16は作業が行き詰まっており、design team の活動停止もあり得ること が報告された。
２つある midcom のセマンティクスドキュメントの統合の必要性が提言され た。（現在、インターネットドラフトとして１つにまとめられている。）
②midcom プロトコル評価
midcom プロトコルとして採用するために、midcom の要求条件に合わせて５つのプロトコル (SNMP17, RSIP18, MEGACO19, DIAMETER, COPS20)の評価を行っている21。
COPS モデルと midcom フレームワークとの間に顕著な不一致がある。 MEGACO に対しては、“方向性”に関して不一致がある。
SNMPv3 には、セキュリティの要求条件を満たす必要がある。 ③ midsom セマンティックス
２つのドキュメントが存在するため、統合することが合意された。
midcom agent の takeover ：ユーザ毎あるいはルール毎・セッション毎に、 別の agent を配置する必要性が合意された。
deterministic outcome（実行結果が決定論的に定まるか？）：agent にはわか らないと認識された。 rule は、その lifetime(寿命)の間有効である。 Group(rule の集まり)の時限：不要である。 奇数ポート番号から偶数ポート番号（およびその逆方向）への対応つけ：不 要である。 DENY rule：おおよそ不要であることで合意された。rule を複雑なものにし ないため。 その他、多重フィルタ用 AND ルール(不要)/ワイルドカード・範囲指定（不 要）の必要性 Grace Period/Atomicity などを審議 ④ STUN WG Last call でのセキュリティの問題に対して、CMS22が有効 でな いこ と、TLS23の server-side 認証と one time password を使う方法があることが報告された。また、denial of service や source address 詐称への対策がとれていないことも報告された。
⑤ SPAN24
13 midcom ができるまでの暫定策（プロトコル）
14 2002 年 8 月にそれぞれ RFC3303、RFC3304 となった。
15 Simple Traversal of UDP Through Network Address, pre-midcom プロトコル 16 Simple Protocol for Augmenting NATs
17 Simple Network Management Protocol, RFC 2574 18 Realm Specific IP, RFC 3103
19 Media Gateway Controller Protocol, RFC 3015/ITU-T Recommendation H.248 20 Common Open Policy Service, RFC 2748
21 IESG(Internet Engineering Steering Group)からの既存プロトコル再利用要求に依る。 22 Cryptographic Message Syntax, RFC 3369
23 Transport Layer Security, RFC2246
５月以来進捗が止まっていること、入コネクション要求に対して Firewall ポリシーを犯すセ キュリティの問題があることが報告された。
3.2.2 midcomの概要
midcom では、通信に介在して特定の機能を果たす装置を middle box と呼んでいる。middle box の代表的なものが、NAT や Fire wall であり、midcom で対象としているものもこの２つ である。 通信アプリケーション25の中には、middle box と連携してサービスを提供するものがある。こ れまでは middle box にそのアプリケーション用機能を埋め込んでサービスを実現するものが多 かった。しかし、このようなアプローチでは、新たなアプリケーションへの対応やアプリケーシ ョンのバージョンアップへの対応が難しく、またサービス提供自体が middle box ベンダーの意 向に制約されやすいといった欠点を持つ。midcom では、これに対して、アプリケーション特有 機能を midcom agent26として、middle box から外出しし、middle box にはアプリケーション 非依存の機能のみを配置することで問題を解決しようとしている（図３）。midcom agent と middle box 間の通信プロトコルが midcom プロトコルである。一般に、通信アプリケーション を利用している end-host は、midcom agent と middle box 間の通信を知らなくてよい。
2002/11 月現在、midcom のフレームワークおよび要求条件が RFC 化(RFC3303/RFC3304) されており、midcom WG では midcom プロトコルの候補となる５つのプロトコル評価、および midcom プロトコルが策定されるまでの暫定プロトコルの検討(STUN)が行われている。
3.3 Service in the PSTN/IN Requesting InTernet Service WG (spirits) 3.3.1 WG会議の概要
議長 議長 議長 議長
Steve Bellovin <[email protected]> Alec Brusilovsky <[email protected]> WG WG WG WG についてについてについてについて PSTN 網から IP 網上の機能を起動するサービスのための、アーキテクチャ、プロトコルおよ となった。 25 SIP を用いた電話サービスで、NAT が介在する場合は、このようなアプリケーションの例と なる。NAT によるアドレス変換に応じて、（例えば NAT に）SIP メッセージのヘッダやボディ にも反映させる機能（メッセージヘッダやボディを書き換える機能）が必要である。
26 midcom agent は、アプリケーションと middle box の双方を認識しており、middle box と連 携してアプリケーション特有の動作、例えばパケットをフィルタしたり変更したりを実施する。 midcom agent (end-hostに共存) midcom PDP midcom プロトコルインタフェース ポリシー インタフェース ファイヤ ウォール NAT VPN トネリング 不正侵入検出 midcom 機能特有ルールと他の属性 m mm m m mm miiiiiiiiddddddddddddddddlllllllleeeeeeeebbbbbbbbooooooooxxxxxxxx管管管管管管管管理理理理理理理理 リ リリ リ リ リ リ リソソソソソソソソーーーーーーーースススススススス m m m m m m m miiiiiiiiddddddddddddddddlllllllleeeeeeeebbbbbbbbooooooooxxxxxxxx機機機機機機機機能能能能能能能能
図３：midcom agente と middle box(RFC 3303 より)
midcom agent (proxyサーバに共存)
midcom agent (アプルGWに共存)
び MIB27の研究、開発。 会議内容 会議内容 会議内容 会議内容 日時：2002 年 7 月 16 日 13:00∼13:40 参加者：60 名程度 ① SPIRITS プロトコルでの IN パラメータに関する課題 SPIRITS プロトコルに関連したインターネットドラフト http://search.ietf.org/internet-drafts/draft-ietf-spirits-in-03.txt では、どの INAP パラメータが SPIRITS に必要とされ、いかに拡張、エンコードするかを提案 している。 このインターネットドラフトでは DTD28による使用例が示されていることから、プロトコル として DTD とスキーマいずれが必須なのかが問題提起された。 結論としては、あくまでも例示であり、SPIRITS プロトコルとしてはどちらも必須とはして いないとされた。 ② SPIRITS プロトコルに関する課題 SPIRITS プロトコルに関するインターネットドラフト http://search.ietf.org/internet-drafts/draft-ietf-protocol-02.txt について以下の議論が行われた。
- 複数 Detection Point への subscribe
SIP の SUBSCRIBE/NOTIFY メソッドがこのような動作をサポートするか、SPIRITS がこのような方法を必要とするかについて疑問があり、この時点ではスコープ外とされた。 - サービス例 ICW29、ICIDD30サービス・コールフローについて、作業を継続することとなった。 ショートメッセージをサービス例とする提案については、ML で審議することとなった。 - セキュリティ関連記述とイベントに関する記述 間もなく完了の予定である。 ③ 残課題 セキュリティドキュメントと MIB ドキュメントが上げられた。 セキュリティについては、SUBSCRIBE メッセージや NOTIFY メッセージの詐称のような SPIRITS 固有の脅威について検討する必要があるが、SIP WG での結果を流用することで解決 するとの方向性を示した。
MIB については、PINT31 MIB の再使用が提案されており、WG で調査することとした。な お、MIB の調査はプロトコルの Last Call を契機に開始することで合意した。
④ 他のインターネットドラフト 議論の対象とならなかったが他に２つの興味深いインターネットドラフトが存在することが 議長から紹介された。 http://search.ietf.org/internet-drafts/draft-ietf-spirits-mobility-00.txt （SPIRITS におけるモビリティ管理） http://search.ietf.org/internet-drafts/draft-gurbani-spirits-location-00.txt （SPIRITS のロケーションサービス） 3.3.2 SPIRITSの概要と状況 PINT WG では電話サービスの起動をインターネット経由で行う方式を検討していたが、その 逆向きのサービス、つまりインターネット上のサービス起動を PSTN 網経由で行う方式の検討 のために SPIRITS WG が独立することとなった。SPIRITS はアーキテクチャ、プロトコル、
27 Management Information Base 28 Document Type Definition 29 Internet Call Waiting 30 Internet Caller-ID Delivery 31 PSTN and Internet Interworking
MIB などを規定するものであり、サービスについては規定しない。SPIRITS アーキテクチャを 規定する RFC3136 "The SPIRITS Architecture"では以下をサービス例としてあげている。
(ア) ICW (Internet Call Waiting)
(イ) ICIDD (Internet Caller-ID Delivery) (ウ) ICF (Internet Call Forwarding)
SPIRITS の機能エンティティとして、「SPIRITS クライアント」、「SPIRITS サーバ」、「サー ビス要求システム（ユーザ端末）」がある。SPIRITS クライアントは PSTN/IN からの要求を SPIRITS サーバに通知し、またユーザからの要求を PSTN/IN 側に通知する機能を持つ。SCP に搭載されるかまたは SCP32とのインタフェースを持つ。SPIRITS サーバは SPIRITS クライア ントからの要求をユーザ端末に通知し、ユーザ端末が選択した処理を SPIRITS クライアントに 通知する機能を持つ。例として、ICW の動作例を簡略化して示す。 ① ダイヤルアップ中の ICW 契約ユーザに着信要求発生 ② 着信回線が話中のために SCP へアクセス ③ SCP（SPIRITS クライアント）は、SPIRITS プロトコルで着信要求を SPIRITS サーバに通知 ④ SPIRITS サーバは契約ユーザの PC に着信要求を通知 ⑤ ユーザは PC に表示される着信要求により、その着信に対する処理（応答、 転送、拒否、録音、等）を選択 既存電話網 IP 網 SCP SPIRITS クライアント SPIRITS サーバ ICW ダイヤルアップ接続 （話中） SSP ①着信要求 ②SCP アクセス ③着信通知 ④ 割込 着信通知 ⑤ 処理選択 （着信/転送/拒否/…） 今後の目標は、以下を RFC 化することにある。 ① SPIRITS で用いる IN パラメータの選択 ② SPIRITS プロトコル ③ SPIRITS MIB
3.4 Session Initiation Protocol WG (sip) 3.4.1 WG会議の概要
議長 議長 議長 議長33333333
Joerg Ott <[email protected]>
Brian Rosen <[email protected]>
32 Service Control Point：IN の一構成要素。交換機を制御することによりルーティングや課金 指示等のサービスを実現する。
33 本原稿執筆時点では、J. Ott 氏および B. Rosen 氏が退任し、J. Peterson 氏および D. Wiilis 氏が新たに就任している。
Rohan Mahy <[email protected]> WG WG WG WG についてについてについてについて IP 網上の音声を含むマルチメディアセッションの確立および管理を行うためのプロトコルで ある SIP (Session Initiation Protocol)の規定およびその拡張機能の規定を検討する WG。 会議内容
会議内容 会議内容 会議内容
日時：(Session I) 2002 年 07 月 15 日 15:30~17:30 (Session II) 2002 年 07 月 16 日 13:00~15:00 参加者：200 名程度 こ の 数 年 間 に 渡 っ て 議 論 を 続 け て き た SIP(RFC2543) の 改 版 作 業 が 直 前 に よ う や く RFC3261-3264 として完成した。今会合中には、トールキンの小説『指輪物語』の序文をもじ った文34を背に入れたオリジナル T シャツを同 RFC の著者全員が着用し、洒落っ気で簡単なセ レモニーと記念撮影が行われたが、このような行動にも端的に見られるように本 RFC 化は SIP 関連のコミュニティにとっては非常に大きなステップと受けとめられている。これを受けて、検 討中の多くの拡張機能が今後 RFC 化されていくことが想定されている。 また、他の SIP のスペックに関わる部分で大きな影響のありそうなトピックとしては、SIP メッセージ転送のトランスポートレイヤとしてはこれまで一般的に UDP が使われてきたが、 UDP では解決できない課題点が複数存在する(輻輳制御、NAT/NAPT 問題、セキュリティ、メ ッセージサイズ制限(フラグメンテーション)等)ため、将来的には使用しない方向で進めるべきと いう意見が多数を占めた。なお、このような事項も含めて、現在の Proposed Standard から Draft Standard へ向けた検討が引き続き行われることが確認されている。
その他の個別事項について以下に報告する。 ① 拡張機能について
<REFER メソッド35関連>
REFER メソッドについて、IESG からのコメントを反映して改版し、再度 IESG で Review を実施することが合意された。また、REFER リクエストの送信元の情報を示す Referred-by ヘ ッダに関して、REFER メソッドを規定するドラフトから分離したことが報告され、同ドラフト に対してコメントが求められた。
<MESSAGE メソッド36関連>
IESG Last Call にかけられている MESSAGE メソッドを規定するドラフトについて、輻輳制 御の観点などいくつかのコメントを受けていることが報告された。コメントを受けて修正後、再 度 Last Call プロセスにかけることになっている。
<Caller Preference37関連>
Caller Preference のドラフトについて、RFC2533 (a syntax for media feature sets)に従った 形式で全面改訂が行われたことが報告された。ドラフトの内容は RFC2533 へのマッピングを記 述する形式となった。すでに WG Last Call の状態であったが、今回の大幅な改版について、内 容がまだ十分理解されておらず、議論に混乱が見られた。まだ、いくつかの課題が存在するため、 改版作業を行って、完成度を高めて WG のコンセンサスを得ていく方向で進めることとなった。
34 “One protocol to rule them all, one protocol to find them, one protocol to bring them all and in the darkness bind them.”。なお、原文は、“One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them.”
35 第 3 者から、指定した宛先(URI)に INVITE 等のリクエストの送信を指示するためのメソッド。呼 転送などの機能を実現するために利用される。 36 テキストメッセージなどをメッセージボディに含めて相手先まで転送するためのメソッド。イン スタントメッセージングなどでの利用が想定される。 37 発信者側で、複数の着信先の候補がある場合において好み(Preference)を表明するための拡張。 Office よりも Home、移動体よりも固定に着信を希望するようなことを表現できる。
<Session Timer38関連>
Session Timer (-09)について、Open Issues があるかの確認が行われ、特に問題点は提起され なかった。
② SIP-NAT 関連
SIP の NAT/NAPT 越えに関してはこれまでいくつかのソリューションが検討されてきたが、 STUN/SPAN/TURN39 (Midcom WG で検討されてきた)の方式を使って解決することを前提に ドラフトがまとめられた。SIP の拡張としては Via ヘッダのパラメータとして rport の追加が提 案されている。また、トランスポートレイヤとして UDP を使用する場合、通常の実装において は NAT の Binding を保持するために非常に頻繁(一般的には数十秒)にメッセージを送出する必 要があるため実用的ではなく、今回の会合での大きな方向性でもある通り TCP を利用すること が推奨されることとなった。本ドラフトの内容で特に議論となる点は残っていないと想定されて いるため、同ドラフトをもって WG Last Call プロセスにかけることとなった。 ③ SIP Security 関連 RFC3261 で規定されている SIP HTTP Digest ベースの認証方式に対する、セキュリティ強 化のための機能拡張を提案しているドラフトの改版内容について説明があった。これまでのドラ フトと比較して、内容をシンプル化しており、まとめると主に次の点についての、セキュリティ の強化案が提案されている。 Authentication-Info に関する処理内容修正 (Client-Server 間の相互認証に 用いる)
Bid-down Protection の追加 (Client-Server 間のメッセージに悪意を持って 修正を加えて使用する認証スキームをより弱いものを使うようにしてしまう攻撃を防ぐ) ヘ ッ ダ 完 全 性 ( メ ッ セ ー ジ ボ デ ィ に 完 全 性 の 保 証 が 必 要 な ヘ ッ ダ を message/sipfrag のボディに追加し、これに対する signature を添付する方式) いずれにせよ、セキュリティについて WG としても非常に強い関心を寄せており、Digest 認 証自体の強化、もしくは S/MIME の利用による強化について引き続き検討を進めていくことと なった。 ④ SIP 輻輳制御関連 SIP の輻輳制御について、UDP を使う場合には、アプリケーションでタイマを持っているが、 UDP 毎に互いに独立してしまっているため、全体としては輻輳制御がきちんと働かないことが 指摘され、TCP や SCTP のようなコネクションオリエンテッドなトランスポートを使い、複数 の呼でコネクションを共有することが必要であるとの共通認識が得られた。 また、この議論において、UDP の使用の是非が俎上に上がり、全体として今後の UDP の使 用を控え、TCP の利用を推奨していこうという方向性が確認された。なお、スケーラビリティ やロバストネス等の UDP の利点や後方互換性の問題等について慎重に検討していくべきである ことについても認識された。 ⑤ SIP における ID 情報およびプライバシー関連
SIP 上で Identity を転送する機構として Trust Domain 内に限定した短期解として提案され ている、P-Asserted-Identity ヘッダ等を規定するドラフトが IESG で承認されたことが報告さ れた。また、長期解として検討されているドラフトについて、message/sipfrag を使用する等変 更があったことが報告され、現状のドラフトの方向で検討を今後も進めることが確認された。 ⑥ Signaling Compression SIP/SDP について LZ77/LZ78 ベースによる圧縮用の静的辞書の作成状況について説明された。 メッセージの交換により辞書は動的にも作成されるため、辞書の精緻化はある程度のところで見 切ってもよいのでは、という意見が多く寄せられたため、ドキュメント化はこのまま進むものと
38 SIP dialog の中でその状態を管理している Proxy Server に対する Keep Alive 機構を提供す るための拡張規定。今会合では特にコメントはなかったが、この後、廃止の提案も含めて簡素化 についての議論が ML で継続している。
39 Client 側から Server までの間に NAT/NAPT が存在しているか、存在している場合その NAT/NAPT のタイプは何か、を調べるためのプロトコル群
思われる。
3.5 Session Initiation Proposal Investigation WG (sipping) 議長
議長 議長 議長40404040
Brian Rosen <[email protected]> Dean Willis <[email protected]> Rohan Mahy <[email protected]>
WG WG WG
WG についてについてについてについて
SIP (Session Initiation Protocol)の利用方法(ISUP とのインタワークや会議通話)や拡張機能 規定に関わる要求条件の整理等を行う。
会議内容 会議内容 会議内容 会議内容
日時：(Session I) 2002 年 07 月 16 日 09:00∼11:30 (Session II) 2002 年 07 月 16 日 17:00∼18:00 参加者：200 名程度 SIP 本体(RFC3261)の RFC 化を受けて、その適用法についてこれまでにも増して様々な議論 が行われ、多くの課題が正式に WG の Working Item として採り上げられることとなった。ま た RFC3265 で規定されたイベント通知のメカニズムを利用する Package についても多数提案 が行われており、より高度な利用について検討が深まっている傾向が確認された。 以下に本会合における主な議論事項について報告する。 ① SIP-T (SIP-ISUP Interwork)について
SIP-T のフレームワークに関するドラフトは IESG で BCP として承認され、ISUP to SIP Interworking と Overlap Signaling についても IESG Last Call 中であることが報告された。ま た、ISUP と SIP のマッピングに関するドラフトに関しては、直近での主な変更点が説明され、 改めて確認とコメントが求められた。
また、BICC/ISUP と SIP のインタワークについての勧告作成作業を行っている ITU-T SG11 を代表して Tom Taylor 氏から進捗状況が報告された。主な内容は次の通りであった。
2 つの関連勧告 (Q.SIPPROF、Q.1912.SIP)は 11 月に勧告化予定41。 すでに技術案件に関して IETF のドラフトの著者と意見交換をしている。 現段階での勧告案を SIPPING の Web ページにアップロードし、ITU-T 外か らでも閲覧可能とし、IETF 参加メンバーからの確認と意見を求める。
ISUP→SIP 時のバックワードパスや FCI/BCI の値等 ITU-T での検討内容と 異なる点について、すでにリエゾン済み。
② Call Flow 例について
基本 Call Flow 例については、SIP のみのフロー、PSTN (ISUP)とのインタワークを含むフ ロー、Torture Test に分離されたことが報告された。基本的にはこれで Last Call プロセスに入 ることとなった。
Service Flow 例については、2 者での通話から 3 者通話に移行するシナリオや、会議の特定に URI を使うシナリオが追加/変更されるなど、最新版における修正点が説明された。現状での課 題点としては、Join/Fork の利用や会議用 URI のアドレス解決、Single Line Extension の内容 精査、会議用 Package の導入、REFER メソッドに関するドラフト改版に合わせた修正、など が挙げられ、今後も改版作業を続けることとなった。 ③ 会議通話について SIP を用いた会議通話を実現する方式としてこれまで異なる複数の案が提案されているが、一 貫したコンセプトに基づいたソリューションが必要であるとの認識の下、Design Team が事前 に今後の進め方について検討した結果が報告された。その結論として、担当を定めて次のような 40 本原稿執筆時点では、B. Rosen 氏が退任し、新たに G. Camarillo 氏が就任している。 41 本原稿執筆時点までで、来年度以降での勧告化に予定が延期されている。また、Q.SIPPROF (SIP のプロファイル定義)については勧告化の要否についても検討されている。
ドラフト群を次会合までを目途に作成する(一部は MMUSIC WG で策定)こととし、WG での理 解も得られた。また、SIMPLE WG で検討されているプレゼンス機能との連携も視野に入れて 検討を進めることとなった。
策定予定文書: High-Level Requirements, Use Case, Framework, Mid-Level Requirements, Example BCP (TBD), Floor Control Requirements, Media Layout and Presentation Requirements, Update cc-Framework
④ Event Packages について
RFC3265 で規定されているイベント通知機能(SUBSCRIBE-NOTIFY メソッド)用のいくつ かの Package について、以下の通り状況のアップデートが行われた。
<Conference Event Package>
会議セッションの情報に関する Package について、そのスコープについて議論され、今後意 見を収集していくこととなった。また、会議用 Package ということで単一の Package とするの か、複数の Package に分けるのかについても今後の課題とされた。前記の通り検討を進める会 議通話の議論の結論によるところが大きいため、そこでの議論と絡めて詳細を詰めていくことと なった。
<Dialog Event Package>
SIP UA42における dialog の情報を伝達するための Package について、最新版での変更点や検 討状況、課題点について報告された。大きな変更点としては XML Schema で記述されることに なったことであるが、W3C43での状況(DTD から XML Schema の使用を推奨)から了承され、若 干の手直しの後、WG Last Call とすることが確認された。
<Registration Event Package>
Registration 状態に関する情報を伝達するための Package について、検討状況および課題点 に ついて報告された。基 本 的に はプ レゼ ンス 情報 と連 携し て 利用さ れ るも ので ある が、 Registration Package と Presence Package を分離することで、Registrar Server と Presence Server を別筐体として扱うことができるため、IETF で標準化する必要性があるとの主張がなさ れた。議論の結果、本内容について正式な SIPPING WG の Work Item として検討していくこ とが確認された。
<Message Waiting Event Package>
以前より検討されている Message Waiting 通知のためのフォートについて、VPIM44 WG で 検討されている Message Context を利用したものへの変更が提案された。これまでのものと後 方互換性のない大幅な変更となるが、実際の用途に即したものであり、拡張性の確保もされるた め、提案された方式で今後の検討を進めることとなった。
⑤ Request History について
SIP Proxy Server を経由した場合に変更される Request-URI の履歴の保持に関して、必要性 と実現すべき要求条件(Security と Privacy を含む)についての検討状況が報告された。今回の議 論において、正式に WG の Work Item として検討を進めていくことが確認された。
⑥ SIP UA の設定について
SIP UA の設定内容と設定方式についての検討状況が報告された。SIP UA の Configuration において検討が必要な事項として次の要素が挙げられた。 Discovery (Configuration 用のサーバを見つける) Enrollment (サーバに登録する) Profile Retrieval (設定を取得する) Change Notification (設定変更を通知する) Profile Upload (新規設定をアップロードする) 42 User Agent。SIP のプロトコル上でのエンドポイントで端末等に実装される論理エンティテ ィ。一般的には SIP 端末と同義としても使われる。
43 World Wide Web Consortium。XML など Web 記述言語やその他の Web 関連技術の検討を 行うための業界団体。
Security Data Container
今回の議論において、正式に WG の Work Item として検討を進めていくことが確認された。 ⑦ Connection Reuse
Scalability, Security, NAT 通過等の観点から SIP エンティティ間でコネクションオリエンテ ッドなトランスポートを SIP メッセージの送受信に利用する場合に、双方向で同じコネクショ ンを使うこと(Reuse)の必要性とその実現方式案が提案された。今回のひとつの大きな動きであ る UDP ではなく TCP を SIP のトランスポートとして主に利用していくという方向性とともに、 本方式は強く支持され、WG の正式な Work Item となることが確認された。 ⑧ Markup 言語とアプリケーションの統合について SIP を使ったアプリケーションを構築するときに、DTMF トーン等を利用する場合があるが、 現在提案されている方式(RFC2833 等)における制約条件と拡張性の欠如が認識されており、 Markup 言語を使ったユーザ入力の必要性について議論がなされた。その有用性は WG で理解 され、早急に Design Team を結成し検討を進めることとなった。 ⑨ IEPREP: IP 上の緊急通信について
IEPREP (Internet Emergency PREParedness) WG との合同検討が実施された。SIP は IEPREP の検討の中でも重要な位置を占めることが認識され、SIP による緊急用セッション確 立における優先制御、既存電話網とのインタワーク、帯域の確保、位置情報の利用、等について、 その要求条件を SIPPING WG の中で検討していくこととなった。
3.6 SIP for Instant Messaging and Presence Leveraging Extensions WG (simple) 議長
議長 議長 議長
Robert Sparks <[email protected]> J. Peterson <[email protected]> WG WG WG WG についてについてについてについて SIP の機構(メッセージルーティングやイベント通知機能)を利用して、インスタントメッセー ジングやプレゼンス機能の実現を検討する。 会議内容 会議内容 会議内容 会議内容 日時：2002 年 7 月 17 日 09:00∼11:30 参加者：200 名程度 ① MESSAGE メソッドについて SIP WG ですで に結論 があった 通り、 メッセ ージを伝 送する ための メソッド である MESSAGE について SIP WG で決定された方向通り進めることが SIMPLE WG でも了解され た。 ② CPIM45とのマッピングについて 他のプロトコルを用いた IM&P システムとの相互接続のための共通フォーマット(CPIM)につ いて検討が行われた。CPIM については、最終案が数ヶ月でまとまる予定であるとの見解が策定 担当 WG である IMPP46 WG の議長より報告された。 ③ Presence List について
Presence List (一般には Buddy List とも呼ばれているが、今回の版より全て“Present List” に用語を変更した)のデータフォーマット(PLIDF47)についての検討状況が報告された。技術的な 未決課題も多く残っており、今後も議論を継続することが確認された。 また、Presence List に関する設定(状態管理や認証レベル等)に関する要求条件が検討された。 具体的にはデータ操作(Manipulation)方式の規定や XML をベースとしたデータ形式の提案が なされた。
45 Common Presence and Instant Messaging 46 Instant Messaging and Presence Protocol 47 Presence List Information Data Format
④ IMTP: Instant Messaging Transport Protocol
これまで、インスタントメッセージの伝送方式について“Pager Model”と“Session Model”の両 方のモデルが検討されてきており、“Pager Model”についてはこれまでも MESSAGE メソッド を利用する方式で検討されてきていた。今会合では“Session Model”にも MESSAGE メソッドを 使い、その伝送の方式(トランスポート)に関して IMTP (=IMSX48 + SIP subset)を用いる提案が なされた。この“Session Model”における実現方式の変更案について、概ね了承された。 ⑤ 3GPP における要求条件について Presence に関する 3GPP での要求条件について報告があったが、これについては 3GPP とい うような制限の中だけではなく、より一般的な枠組みの中で整理する方向で意見集約された。ま た、インスタントメッセージングに関する 3GPP での要求条件の状況についてはまだ検討の初 期段階にあり、現在議論中であることが報告された。
48 IM Simple Exchange。RFC3080 で規定される BEEP (Blocks Extensible Exchange Protocol)の IM 転送用 Profile
