NGN/SIP標準化動向レポート

2008年11月8日土曜日

IETF73のSIP-WGアジェンダ草案

WG共同議長のDean Willisから、
IETF73（11/16～21）のアジェンダ草案がでています。

個人的にはDERIVEに注目です。
実際に普及するかどうかはともかく発想がすばらしいです。

DERIVEは、送られてきたSIPリクエストに書かれている
発信者ID（Fromヘッダ）の中身が正しいかを検証する
方法の提案です。

今までにも発IDの改ざん防止方法がいくつかRFC化されていて、
・ネットワーク内の装置でチェックする（RFC3325のP-Asserted-Identityの方式）
・証明書を使ってアルゴリズム的にセキュリティを担保する（RFC4474：SIP Identityとか、IAB）

というのがあったのですが、前者は単純なので普及は進んでますが、途中でいけないサーバが一つでもあるとダメなので使える範囲が限定されてしまうとか、後者は方式が複雑なので作るのも運用するのも大変で普及せずという状態だった、などあまりいけてない状況だったわけです。

それでIETFは、いろんな方式を作っては捨てというのを繰り返してきてたのですが、
DERIVEはひょっとすると定番になるかもしれません。

DERIVEの発想はとてもシンプル。
着信のINVITEが飛んできたら、そこに書かれているFromヘッダの人に向かって、
「今INVITE送った？」って聞くための制御メッセージを投げるっていうもの。
勝手に他人の発IDを使ったら、「そんなの送ってないよ」って通知されるから
検出できるでしょ、っていうもの。

目からうろこですね。
何で今まで誰も考え付かなかっただろうって思いました。
（自分も考え付かなかったですが。。。）

今までの発ID検証方式とは互換性がないので、
今からの普及は難しいかもしれませんが、
ちょっとしたカタルシスを味わうことができて、満足です。

きっと、SIP-WGでも楽しく議論されるんでしょうねえ。
参加したいところですが、今回はAudioのストリーミングで我慢するかあ。。。。

http://www.ietf.org/proceedings/08nov/agenda/sip.html

Agenda for SIP at IETF 73, Monday November 17, 2008, 1740-1930, Salon D
Charter?	Topic	Discussion Lead	Drafts	Time
N/A	Agenda, Status	Chairs	None	5
Y	URI Delivery	Jonathan Rosenberg	draft-rosenberg-sip-target-uri-delivery-00	40
Y	UA Initiated Privacy	Mayumi Munakata	draft-ietf-sip-ua-privacy-03	30
Y	Info Events	Eric Burger	draft-ietf-sip-info-events-01	35

Agenda for SIP at IETF 73, Thursday, November 21, 1300-1500 Salon D
Charter?	Topic	Discussion Lead	Drafts	Time
N/A	Agenda Bash	Chairs	None	5
Y	SAML	Hannes Tschofenig	draft-ietf-sip-saml-05	15
Y	SIP Draft Standard Work	Robert Sparks	draft-sparks-sip-steps-to-draft-00	30
N	Keepalive sans Outbound	Christer Holmberg	raft-holmberg-sip-keep-02	15
N	Return Routability check Using RFC 4235	Victor Pascual Ã vila	draft-kuthan-sip-derive-00	30
N	Identity Issues	Jon Peterson	N/A	25

2008年8月9日土曜日

IETFのSIP/VoIP関連メーリングリストまとめ

1．ディスカッションリスト

略称	正式名称
avt	Audio/Video Transport
bliss	Basic Level of Interoperability for SIP Services
drinks	Data for Reachability of Inter/tra-NetworK SIP
ecrit	Emergency Context Resolution with Internet Technologies
enum	Telephone Number Mapping
geopriv	Geographic Location/Privacy
iptel	IP Telephony
mediactrl	Media Server Control
mmusic	Multiparty Multimedia Session Control
p2psip	Peer-to-Peer Session Initiation Protocol
sigtran	Signaling Transport
simple	SIP for Instant Messaging and Presence Leveraging Extensions
sip	Session Initiation Protocol
sipping	Session Initiation Proposal Investigation
speechsc	Speech Services Control
speermint	Session PEERing for Multimedia INTerconnect
xcon	Centralized Conferencing

2．全体周知系

ietf

ietf-announce

i-d-announce

IETFメーリングリストの購読手続き

どんなメーリングリストがあるのか？

IETFでは議論、周知、連絡のための手段として、メーリングリストが活用されている。Discussion List、Announcement List、Other Listの３つカテゴリに、全部で１００を超えるメーリングリストが設置されている。

No.	種類	内容	主なメーリングリストの名称
1	Discussion List	議論を行うためのメーリングリスト	ietf IETF全体にかかわる議論を行う sip SIPプロトコルの検討を行っている、SIP-WGのメーリングリスト sipping SIPプロトコルに関わる技術調査を行っている、SIPPING-WGのメーリングリスト mmusic SDP、RTSPプロトコルの検討を行っている、MMUSIC-WGのメーリングリスト他にもWGごとに多数のメーリングリストが設置されている
2	Announcement List	周知、連絡のためのメーリングリスト	ietf-announce IETF全体にかかわる周知 id-annouce インターネットドラフトの周知 iesg-announce IESGのアジェンダの周知
3	Other List	その他のメーリングリスト群

どのリストに登録すればよいのか？

全体的な周知が行われる、ietf、ietf-announce、id-announceと、興味のある技術分野のWorking GroupのDiscussion Listに登録しておくとよい。

過去ログはWeb上で公開されているので、たまにメーリングリストの内容を見たいという程度のものは、それで事足りる。

自分が投稿する可能性のあるメーリングリストには、購読登録しておいた方がよい。メーリングリストに登録されてないアドレスからの投稿は、管理者の承認がないと送られない仕組みになっている。タイムラグがでる場合もあるし、承認されない可能性もある。必要なときにあわてなくてすむ。

どうやって登録するのか？

Web上での申し込みと、メールでの登録という２つの方法がある。

ここではメールでの登録方法を紹介する。

１．購読申込みメールを送る

　登録したいアドレスから、購読申し込み用のアドレスあてにメールを送る。購読申し込み用のアドレスは、[メーリングリスト名称]-request@ietf.org となる。SIP-WGのメーリングリストの場合は、sip-request@ietf.org となる。Subjectには何も書かず、本文に"Subscribe"とだけ書く

SIPメーリングリストへの購読メールの例
　　　 To: sip-request@ietf.org
　　　Subject: （何も書かない）
　　　本文に Subscribe と書く

２．IETFから送られたきたConfirmメールに返信

　確認のメールが送られてくるので、それに対して返信を返す

　・本文に "confirm xxxxxxxxxxxxxxxxx" の文字列が含まれてればよさそう
　・Subjectは何でもいい、見てないようだ
　・メール中に日本語が入ってるとだんまりになるようなので、
日本語署名などが入らないようにする

以上で購読手続きは完了。

2007年4月17日火曜日

バッカス・ナウア記法（BNF）の読み方

BNF（Backus-Naur Form）は、プログラミング言語やプロトコルフォーマットの構文記述に用いられるメタ言語である。RFCでもABNF（Augmented Backus-Naur Form）と呼ばれる拡張BNFが用いられているため、RFC読解には理解する必要がある。

以下にABNFを中心として、BNFの概要をまとめた。

●BNF（バッカス・ナウア記法）

BNFはプログラミング言語「ALGOL60」の構文定義を行うために考案されたメタ言語である。John Backus氏が提案して、Peter Naur氏により修正された言語であるため、両氏の名前を冠し、Backus-Naur Form（バッカス・ナウア形式）と呼ばれている。

BNFは、拡張性に富み、簡易であるという理由から、拡張が行われ、ISO、IETF等の標準仕様においてプロトコルのフォーマット記述に用いられるようになった。BNFは拡張が容易であることから、独自にさまざまな拡張が行われることになった。ISO、IETFではそれぞれ、EBNF、ABNFと呼ばれるBNF拡張体系が標準化されている。

●ABNF（Augmented BNF for Syntax Specification）

IETFの仕様書で使われている拡張BNF。初期のRFCでは、RFCの中で使うBNFの拡張内容をそのRFCの中で記述するということが行われていたが、1997年11月にRFC2234（Augmented BNF for Syntax Specifications: ABNF）が制定され、RFCで利用するABNFの標準が規定された。その後、2005年10月にABNFの標準仕様の改版が行われている。改版された仕様書はRFC4234として発行されている。

●SIPのBNF

RFC3261（Session Initiation Protocol）をはじめとしたIETFのSIP仕様でも、プロトコルフォーマットの記述にABNFが用いられている。RFC3261は、RFC2234のABNFが用いられている。RFC3261は2002年6月に制定されており、RFC4234の発行前の制定であるため。

以下にABNFの文法について、SIPのABNFを例にひきながら解説する。解説は特に注釈のない限り、ABNFの標準仕様の最新版であるRFC4234に基づいて行う。

●ABNFの全体像

RFC4234に規定されるABNFの規定は、大きく「規則定義」「演算子」「ABNFコア規則」の3つの部分に分けられる。「規則定義」は、規則を記述する基本的な書式、規則名の命名規則、終端値という概念、拡張エンコーディングについて規定している。「演算子」では、並列、選択、追加、範囲指定、グループ指定、繰り返し指定、オプション指定、コメント記述方法について規定している。「ABNFコア規則」では、「SP(スペース)」「ALPHA(アルファベット)」「DIGIT(数字)」などの規則が定義されている。

以下にそれぞれの規則の概要を説明していく。

●規則定義

1．基本的な書式

ABNFは、以下の書式で記述する。

    <規則名> = <仕様>

nameという規則名は、"Hitokuchi"という文字列であると定義する場合には、下記のように記述する。なお、""の中に記載された英文字は大文字と小文字を区別しないので、"hiToKuChi"なども、nameに含まれる。

    name = "Hitokuchi"

さらに仕様の中に、別の規則名を記述することもできる。

2．規則名の命名規則(作成中)
3．終端値(作成中)
4．拡張エンコーディング(作成中)

●演算子

並列、選択、追加、範囲指定、グループ指定、繰り返し指定、オプション指定、コメント記述方法という8つの演算子が定義されている。

1．並列(作成中)
2．選択(作成中)
3．追加(作成中)
4．範囲指定(作成中)
5．グループ指定(作成中)

6. 繰返し指定（Repetition）

同じ表現を複数繰り返す場合には、仕様の前に数字を付ける。

      7DIGIT        ; 7桁の数字
　　1*3DIGIT    ; 1桁～3桁の数字列
　　2*ALPHA    ; 2文字以上の英文字
　　*5SP             ; 0～5つ以内のスペース
      *DIGIT       ; 0桁以上の数字

RFC3261に記載されているIPv4アドレスの形式を以下に示す。このABNFは、IPv4Addressは、1桁から3桁の数字列4つを、"."（ピリオド）で結んだ形であるということを示している。

　　IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT

7. オプション指定（Optional Sequence）

オプションの要素を表現する場合には、[]で囲む。

下記は、RFC3261に記載される、Request要素の例である。Requestには、Request-Lineと0個以上のメッセージヘッダ（message-header）と改行文字(CRLF)が含まれるが、メッセージボディ（message-body）は任意であり、あってもなくてもよい。

    Request = Request-Line
                       *( message-header )
                       CRLF
                       [ message-body ]

8. コメント記述方法（作成中）

●ABNFコア規則(CORE ABNF)

RFC4234 Appendix B. の CORE ABNF のうち RFC3261 で使われているものを以下に抜粋した。

　　ALPHA = %x41-5A / %x61-7A ; A-Z / a-z、英文字を示す
　　CRLF = CR LF ; 改行文字
　　CR = %x0D ; cariiage retuan
　　LF = %x0A ; linefeed
　　WSP = SP / HTAB ; スペースか、水平タブ
　　SP = %x20 ; スペース
　　HTAB = %x09 ; 水平タブ
　　DIGIT = %x30-39 ; 0-9の数字を示す

（以下作成中）

2007年4月11日水曜日

perl入門メモがき

perlの文法の簡単な説明と、コードの記述例を下記にまとめた。
「変数と制御構文」、「プログラムコードの整理、管理に用いられる名前空間（パッケージ）／サブルーチンの使い方」および「オブジェクト指向におけるオブジェクト、クラスの作成、使用方法」の3つを記載した。
「正規表現」はカバーしてない。（別のところで記載するか、追記するかしたい）

-------------------------------------------------------
1．変数と制御構文

・スカラ型、配列型、ハッシュの3つの変数型を利用できる。
・リファレンス（変数の参照）も利用可能。
・分岐（if/unless）、繰り返し（for, foreach, while）の制御構文を利用可能

●変数定義
$はScalarのS、@はarrayのaに形を似せている。Hashがなぜ%かは不明。
my $str = "Hello, world"; # スカラ型（Scalar）
my @array = (0, 1, 2); # 配列（Array）
my %hash = ('one' => 1, 'two' => 2); # ハッシュ（Hash）

●配列/ハッシュの参照
配列やハッシュも参照時の頭文字は$である。[]か{}で配列とハッシュを区別する。
$array[1]; # 1; 配列の参照
$hash{'two'} # 2; ハッシュの参照

●リファレンス
\を頭につけることで変数へのリファレンス（参照、ポインタ）を表現する。
my $sref = \$int; # スカラーへのリファレンス
my $aref = \@array; # 配列へのリファレンス
my $href = \%hash; # ハッシュへのリファレンス

●デリファレンス（参照元へのアクセス）
リファレンス変数の前にプレフィックス（$：スカラ、@：配列、%：ハッシュ）をつける。
my $s = $$sref; # $sref の参照元
my @a = @$aref; # $aref の参照元
my %h = %$href; # $href の参照元

●参照元のデータタイプ
デリファレンスを使うためには、参照元の型を知る必要がある。
参照元の型を知るには、ref関数を用いる。
ref 1; #
ref $sref; # 'SCALAR'
ref $aref; # 'ARRAY'
ref $href; # 'HASH'
ref A::B->new(); # 'A::B' （たぶん）

●制御構文（if, while, for, foreach, unless, until）
elsifのつづりに注意。後置可能。
foreachが少し変わっている以外は、特に目新しいのはない。
if ($cond) { } elsif($cond2){ } else { }
doit if ($cond);
while($cond){ };
doit while($cond);
for(my $i = 0; $i < $count; $i++){ } foreach(0..$count){ } # for(0..$count)も可 print for (@ARGV); doit unless ($done); # doit if (! $done); doit until ($done); # doit while (! $done);
--------------------------------------------
2．コード管理（サブルーチンとパッケージ）

・サブルーチンで一連の処理をまとめられる。
・パッケージにより、サブルーチン名、変数名の重複を避けることができる。

●サブルーチン
定義にはsubを使う。subの後にサブルーチン名を書いて、処理内容を{}でくくる。呼び出しは、単にサブルーチン名を書く。&を頭に付けてもよい。()を付けて引数を渡す。戻り値は、定義の中に return 変数と書くのが行儀のよいお作法。returnがないときは最後の変数が返される。 sub hello{ print "Hello, workd!\n"; } # サブルーチンの定義 hello(); # 呼出１ &hello(); # 呼出2 hello; # 呼出3 sub hello { return "Hello!\n"; } # 戻り値、return 省略可 print hello(); # "Hello!"と出力 sub mul{ my ($op1, $op2) = @_; # 引数（@_に格納） return $op1 * $op2; } sub mul{ $_[0] * $_[1] }; # 引数（$_[0]、$_[1]で参照） my $subref = \&mul; # サブルーチンの参照 warn $subref->(7,6); # 42 ちょっと紛らわしい
my $subref = sub{ $_[0], $_[1] }; # 無名サブルーチン
print $subref->(1, 2); #
print &$subref(1, 2); # こうも書ける

●パッケージ
packageでパッケージ名を宣言。呼び出しは、$パッケージ名::変数名で指定する。
package Foo;
our $bar = 'baz';
package main;
our $bar = 'quux';
warn $bar; # 'quux'
warn $Foo::bar; # 'baz'

-------------------------------------------------------
3．オブジェクト指向

・perlでもオブジェクト指向のオブジェクト／クラスを実現できる

●クラスの定義
クラス名は、package名で表現される。コンストラクタは、newサブルーチンを定義して用いる。
package Klass; # クラスの定義（Packageで実現）
sub new{ # コンストラクター
my $pkg = shift;
return bless { @_ }, $pkg;
}
sub meth{ # メソッド、アクセサー
my $self = shift;
$self->{meth} = shift if @_;
$self->{meth};
}

●オブジェクトの使用
クラス名->メソッド名で呼び出す。
my $obj = Klass->new( meth => 'od' );
warn $obj->meth; # 'od';
# Perlは"->"の演算子を以下のように読み替えて解釈している。
my $obj = Klass::new('Klass', meth => 'od' );
warn Klass::meth($obj);

-------------------------------------------------------
参考文献

●Wikipedia
http://ja.wikipedia.org/wiki/Perl
●Perl最強講座
http://www.rfs.jp/sb/perl/
●perl5.8.xのドキュメント（日本語）
http://www.kt.rim.or.jp/~kbk/perl-5.8/
●オブジェクト指向を理解する－ITPro
http://itpro.nikkeibp.co.jp/article/COLUMN/20060921/248617/

2007年4月6日金曜日

セッション開始プロトコル（SIP）におけるSIPS URIの利用のためのガイドライン

Guidelines for the use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)
意図している分類：Informational RFC
ファイル名：draft-ietf-sip-sips-02.txt
著者：F. Audet(Nortel Networks)
2007年3月5日
--------------------------------------------------------------
SIPS-URIの使用方法のガイドライン。当初はRFC3261のUpdateとして検討されていたが、結局、既存の規定変更を含まないInformational RFCの位置づけとして、検討されることとなった。第68回IETF会合においてSIP-WG議長から、2007年3月にWGLC(Working Group Last Call：WG内での最終レビュー）が行われると説明されており、近いうちにSIP-WGでの検討を終え、IESGに送られる予定である。（が、4月になっても議論は続いているようであるが・・・）

エンドポイントのアプリケーションのための単純なSIP利用シナリオ

Simple SIP Usage Scenario for Applications in the Endpoints
意図している分類：Informational RFC
ファイル名：draft-sinnreich-sip-tools-01.txt
著者：H. Sinnreich（Adobe）, A. Johnston(Avaya), E. Shim(Locus), K. Singh(Adobe)
2007年3月2日
--------------------------------------------------------------
エンドポイントのアプリケーションでの簡易なSIPの使い方についての考察。SIPの仕様が複雑化しているのは、SIPのサーバ側に呼制御、サービス制御機能を持たせてアプリケーションを実現しようとしているからであるという認識にもとづき、SIPサーバはRFC3261で規定されるエンドポイントの発見機能のみを行い、それ以外の機能をエンドポイントで行うようにすることで、今あるSIP関連のRFC、約100件を11件にまで減らすことができるとしている。

SIP and VoIP Top

2007年4月5日木曜日

SIPPING-WGの議事録案（第68回IETF会合）

3月18日～23日に開催された第68回IETF会合の各セッションの議事録案（Minutes）が、IETFのホームページに掲載され始めている。SIP関連で3月19日（月）と3月23日（金）の2回に分けて開催されたSIPPING-WGセッションの議事録案（Minutes）が公表されているので、内容をまとめてみた。長いので今回は3月19日（月）の第1回セッション分を記載する。

●資料

・議事録案（Minutes）

http://www3.ietf.org/proceedings/07mar/minutes/sipping.txt

・アジェンダ

http://www3.ietf.org/proceedings/07mar/agenda/sipping.html

・発表資料

https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=68

●議事内容まとめ（第1回セッション）

・開催日時：3月19日（月） 9時～11時30分（現地時間）

○Agenda Bash

・議長からのアジェンダ紹介

○Configuration Framework （Sumanth Channabasappa）

draft-ietf-sipping-config-framework-11.txt

Configurationのデザインチームでの検討状況が報告された。インターネットドラフトの内容としては、わかりにくいのでわかりやすくした方がよい、という議論が行われていて、以下のようなコメントが出されていたようだ。

・ドラフトが長いので、エグゼクティブ・サマリーと例を追加しては？

・用語（terminology）の明確化が必要では？別の仕様（例えば、イベント通知フレームワーク）で定義されている用語を使うとか、新たな用語は定義するとか。

あと検討の進め方として、DNSでの観点が不足してるという認識があり、デザインチームにDNSの専門家も加わってもらうべきだという話がでている。また、スライドに記載されていたOpen Issueについては、下記の2件のような議論があったとMinutesに記載されている。

・"device ID" parameter は削除する必要はなさそう、という結論になった

・HTTP Fallback について賛否両論がでて、会合中、結論はでなかった

○A User Agent Profile Data Set for Media Policy

draft-ietf-sipping-media-policy-dataset-03.txt

Session Policy関連の一連のインターネットドラフトのうちの1つという位置づけだが、他の Session Policy Framework や Event Package はWGLCに進められるレベルに達しているが、このインターネットドラフトにはまだ課題が残っている、というのがWGとしての認識のようだ。特にこのインターネットドラフトが参照しているインターネットドラフト（draft-petrie-sipping-profile-datasets-04.txt）が、まだ個人名ドラフトでRFC化が遠いという点が問題視されていて、進め方をどうするかが話し合われた。参照をやめて依存関係を断ち切るのか、現在のままにするのかはメーリングリスト上で議論する必要がある、ということとなり、メーリングリスト上での継続審議となった。

○Overload Design Team Status Update （Jonathan Rosenberg）

draft-ietf-sipping-overload-reqs-00.txt

IETFの人とPSTNの輻輳制御のバックグラウンドを持つ人で構成されているデザインチームの活動状況報告がJonathan Rosenbergから行われた。近いうちに中間報告をするというアナウンスがあった。

○Service Identification （Jonathan Rosenberg）

draft-rosenberg-sipping-service-identification-01.txt

メーリングリストで否定的なものも含めて多くの意見がだされていて、その内容の総括をJonathan Rosenbergが総括する形で議論が始められた。このインターネットドラフトをWGの検討対象とすることについては、会合中にhum（採決）が取られたが、結論がでず、さらにアドホックミーティングで再度議論を行い、17対7で進めることが決められた。

○How do we achieve WG deliverables? （Chairs）

WGLC終了期限に間に合わないインターネットドラフトの期限をずらすことで合意（？）

以上

SIP and VoIP Top

セッション開始プロトコル（SIP）でヒッチハイクする人のためのガイド

A Hitchhiker's Guide to the Session Initiation Protocol (SIP)
意図している分類：Informational RFC
Filename：draft-ietf-sip-hitchhikers-guide-02
Author： J. Rosenberg（Cisco）
2007年3月8日
--------------------------------------------------------------
　セッション開始プロトコル（SIP）の仕様を定めるRFCは、現時点（2007年3月）で100程度あるといわれており、目的とするRFCを探し出すこと自体が困難な状況となっている。そこで、SIPで適切なRFCを探し出す人のためのガイドラインが、インターネットドラフトとして提案されている。

　セッション開始プロトコル(SIP)は、IETFで生産された多くの仕様書の主題となっている。このため、適切なドキュメントを見つけるのは難しいかもしれないし、SIP に関する Request for Comments (RFC) のセットが何かを決定するのはさらに困難かもしれない。この仕様は、SIP RFCシリーズのガイドとして役立つことを意図している。SIPの傘の下の仕様書をリストし、簡潔に各々を要約し、いくつかのカテゴリに分類している。

2007年3月29日木曜日

IESG定例会議（2007/2/22、RAIエリア関連トピック）

2007年2月22日（木）にIESGのミーティングが開催されたので、SIP関連の内容を中心に下記にまとめた。なお、今回のミーティングの議事録は、IETFのホームページで参照できる。IESGのミーティングは、IETF議長および各エリアディレクタにより構成される。2週間に1度開催され、下記の7つの内容を扱っている。

「IESG定例ミーティングの議題」
1．Administrivia ：前回議事録確認、課題管理等
2．Protocol Actions ：Standard Track/BCP RFC案の審議
3．Document Actions ：Informational/Experimental RFC案の審議
4．Working Group Actions ：WG新設/廃止、憲章変更
5．IAB News We Can Use ：IABからの報告事項（あれば）
6．Management Issues ：組織運営に関する事項
7．Working Group News We Can Use ：WGグループからの報告事項（あれば）

「IESG定例ミーティング」
●日時：2007年2月22日（木）
●場所：電話会議
●参加者：
・IETF Chair以下、各エリアディレクタ他19名が参加。
・RAIエリアディレクタのJon Peterson（Neustar）／Cullen Jennings（Cisco）
も参加している。
・以下に今回のミーティングの参加者リストを示す

Loa Andersson / substitute IAB liaison
Jari Arkko (Ericsson) / Internet Area
Ross Callon (Juniper Network) / Routing Area
Brian Carpenter (IBM) / IETF Chair, General Area
Yoshiko Chong (ICANN) / IANA Liaison
Michelle Cotton (ICANN) / IANA liaison
Spencer Dawkins (Huawei (USA)) / Scribe
Lars Eggert (Nokia) / Transport Area
Bill Fenner (AT&T) / Routing Area
Sandy Ginoza (ISI) / RFC Editor liaison
Ted Hardie (Qualcomm, Inc.)/ Applications Area
Russ Housley (Vigil Security, LLC) / Security Area
Cullen Jennings (Cisco) / Real-time App. and Infra. Area
David Kessens (Nokia) / Operations and Management Area
Jon Peterson (NeuStar, Inc.) / Real-time App. and Infra. Area
Dan Romascanu (Avaya) / Operations and Management Area
Dinara Suleymanova (NSS) / IETF Secretariat
Amy Vezza (NSS) / IETF Secretariat
Magnus Westerlund (Ericsson) / Transport Area

●今回の定例会議の議事録
https://datatracker.ietf.org/public/view_telechat_minute.cgi?command=view_minute&id=362

●議事内容（RAIエリア関連のみ）

・IPTEL-WG（RAIエリア）の下記のインターネットドラフト1件が継続審議。
【draft-ietf-iptel-tgrep-08.txt】
A Telephony Gateway REgistration Protocol (TGREP) (Proposed Standard)
◇担当AD：Cullen Jennings
◇現状：Open Issue未解決のため継続審議

・Media Server Control（mediactrl）のWGの新設を承認

・SIMPLE-WGの憲章(Charter)の変更を承認

SIPandVoIPトップに戻る

登録: 投稿 (Atom)