PowerPoint プレゼンテーション

(1)

ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所 NTT秘(財産的情報) NSLAB© NTT 2003

インタラクティブマルチメディアを支える技術動向

−ＱｏＳを中心に−

２００３年１０月１０日

ＮＴＴネットワークサービスシステム研究所

森田直孝

(2)

ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所 NTT秘(財産的情報)

1. SIPに関する技術動向

2. ｲﾝｽﾀﾝﾄﾒｯｾｰｼﾞﾝｸﾞとﾌﾟﾚｾﾞﾝｽに関する技術動向

3. NAT/FW通過制御に関する技術動向

4. 新しいQoS実現方式の提案(PPS方式)

5. Q&A

(3)

ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所

NTT秘(財産的情報)

NSLAB© NTT 2003

１．SIPに関する技術動向

(4)

ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所 NTT秘(財産的情報) 【MIDCOM: Middlebox Communication】 • NAT/FW機能を実現する装置（middlebox）を制御するプロトコルを検討 • 2001/12 WG設立

【SIMPLE: SIP for Instant

Messaging and Presence

Leveraging Extensions】

• SIPﾒｯｾｰｼﾞの拡張によるﾌﾟﾚ

ｾﾞﾝｽ/ｲﾝｽﾀﾝﾄﾒｯｾｰｼﾞ機能

【SIMPLE: SIP for Instant

Messaging and Presence

Leveraging Extensions】

• SIPﾒｯｾｰｼﾞの拡張によるﾌﾟﾚ

ｾﾞﾝｽ/ｲﾝｽﾀﾝﾄﾒｯｾｰｼﾞ機能

【IMPP: Instant Messaging

and Presence Protocol】

• ﾌﾟﾚｾﾞﾝｽ/ｲﾝｽﾀﾝﾄﾒｯｾｰｼﾞの共

通ﾃﾞｰﾀﾌｫｰﾏｯﾄを規定

• 2002/11 終結

【IMPP: Instant Messaging

and Presence Protocol】

• ﾌﾟﾚｾﾞﾝｽ/ｲﾝｽﾀﾝﾄﾒｯｾｰｼﾞの共

通ﾃﾞｰﾀﾌｫｰﾏｯﾄを規定

• 2002/11 終結

【SIPPING: Session

Initiation Proposal

Investigation】

• 新機能の要求条件を明確化

• 2001/8 WG設立

【SIPPING: Session

Initiation Proposal

Investigation】

• 新機能の要求条件を明確化

• 2001/8 WG設立

【SIP: Session Initiation

Protocol】

• SIPプロトコルの改良

• 1999/11 WG設立

【SIP: Session Initiation

Protocol】

• SIPプロトコルの改良

• 1999/11 WG設立

セッション制御機能

ﾌﾟﾚｾﾞﾝｽ/ｲﾝｽﾀﾝﾄﾒｯｾｰｼﾞ機能(Application Area)

転送系の制御方式

SIPを中心とするIETFのワーキンググループ

【ENUM: Telephone Number Mapping】 • E.164→IPアドレスへの番号解決 【ENUM: Telephone Number Mapping】 • E.164→IPアドレスへの番号解決 【IPTEL: IP Telephony】 • ｻｰﾋﾞｽｶｽﾀﾏｲｽﾞ記述 (CPL) • GWへのﾙｰﾁﾝｸﾞﾌﾟﾛﾄｺﾙ (TRIP) • 2003/11 終結予定 【IPTEL: IP Telephony】 • ｻｰﾋﾞｽｶｽﾀﾏｲｽﾞ記述 (CPL) • GWへのﾙｰﾁﾝｸﾞﾌﾟﾛﾄｺﾙ (TRIP) • 2003/11 終結予定

ｱﾄﾞﾚｼﾝｸﾞ/ﾙｰﾁﾝｸﾞ制御機能

【AVT: Audio/Video

Transport】

• 音声や画像情報の転送ﾌﾟﾛﾄｺ

ﾙ(RTP)を検討

【AVT: Audio/Video

Transport】

• 音声や画像情報の転送ﾌﾟﾛﾄｺ

ﾙ(RTP)を検討

【MMUSIC: Multiparty

Multimedia Session

Control】

• ﾒﾃﾞｨｱ属性記述

(SDP/SDPng)、ｽﾄﾘｰﾐﾝｸﾞ制

御ﾌﾟﾛﾄｺﾙ(RTSP) を検討中

【MMUSIC: Multiparty

Multimedia Session

Control】

• ﾒﾃﾞｨｱ属性記述

(SDP/SDPng)、ｽﾄﾘｰﾐﾝｸﾞ制

御ﾌﾟﾛﾄｺﾙ(RTSP) を検討中

メディア転送/制御機能

【XMPP: Extensible

Messaging and Presence

Protocol】

• Jabberをｺｱﾌﾟﾛﾄｺﾙとする

XMLﾍﾞｰｽのIM

• 2002/11 WG設立

【XMPP: Extensible

Messaging and Presence

Protocol】

• Jabberをｺｱﾌﾟﾛﾄｺﾙとする

XMLﾍﾞｰｽのIM

• 2002/11 WG設立

【IEPREP: Internet Emergency Preparedness】 • 災害時の通信方法 【IEPREP: Internet Emergency Preparedness】 • 災害時の通信方法

【NSIS: Next Steps in

Signaling】

• QoS, NAT/FW制御を目的としたRSVP型の新信号方式を検討

【NSIS: Next Steps in

Signaling】 • QoS, NAT/FW制御を目的としたRSVP型の新信号方式を検討

SIP

【XCON: Centralized Conferencing】 • 明確なﾒﾝﾊﾞｰｼｯﾌﾟ管理のある会議サービス 【XCON: Centralized Conferencing】 • 明確なﾒﾝﾊﾞｰｼｯﾌﾟ管理のある会議サービス 【MIDCOM: Middlebox Communication】 • NAT/FW機能を実現する装置（middlebox）を制御するプロトコルを検討 • 2001/12 WG設立

(5)

5 SIP標準化動向

SIP基本部について、RFC2543bis04までと、その後約半年で改版されたRFC3261では、大幅に変更あり。主な変更点は、

セキュリティ強化、および、複数サーバ環境を考慮したルーチング処理である。

SIP基本部について、RFC2543bis04までと、その後約半年で改版されたRFC3261では、大幅に変更あり。主な変更点は、

セキュリティ強化、および、複数サーバ環境を考慮したルーチング処理である。

6月 △ RFC3264, 3266 (SDPのoffer/answer, SDP IPv6 7月 △ bis04 6月 △ RFC3261 10月 △ bis05 構成変更バグ修正完 6月 △ RFC3265 (非同期イベント通知要求機能の抽象クラス) 各サービス対応のイベント通知要求機能の仕様はパッケージとして規定予定 (例) ・Presence ・Conference State ・Dialog State ・メッセージあり通知 10月 △ RFC2976(INFO) 12月 △ RFC3204 (ISUP,QSIG用メディアタイプ) 9月 12月 △ △ RFC3372,3398 (SIP-T) (SIP-ISUP連携) 6月 △ RFC3262 (1xxレスポンスの送達確認) 11月 △ RFC3324,3325 (発ID通知・非通知制御、網内流通ID) ヘッダ名前空間にプライベイト(P-xxx)の導入 6月 △ RFC2848 (PINT) 3月 △ bis09 セキュリティの強化・SIPS URL ・サーバはTLS対応必須化・S/C相互認証機能追加・基本認証廃止・S/MIMEによるボディの暗号化ルーチング処理変更・複数サーバ環境での多段接続サーバにおけるサービス起動

2000

2001

2002

2003

SIP基本部 _{機能追加分の不明確点} 議論中 99.2 RFC2543制定 SIP拡張部 電話網相互接続電話系付加サービス Presence, IMサービス対応

(6)

SIP仕様の差分-1

●主な機能差分

1. セキュリティ関連規定の見直し

• セキュアなトランスポート

TLSの使用を指定するアドレス規定“SIPS”URIの追加サポート

• サーバにTLSを必須化

• Message bodyの暗号化方式を、PGPからS/MIMEへ変更

• セキュリティの弱い基本認証の廃止

2. トランスポートの見直し

・ユーザにTCPを必須化（長いメッセージへの対応）

3. DNS手順の拡張

・リソースレコード

SRV/NAPTRへの対応

SRV(サーバ選択)型のみから、SRV,NAPTR(名前付け権限ポインタ)への拡張

(7)

7 SIP仕様の差分-2

●主な手順変更

1. 呼設定中の解放手順等、準正常手順の明確化

2. offer-answerモデルによるSDP交換手順の明確化

別

draft化した後、RFC3264として規定

3. Max-Forwardsの必須化によるループ検出手順の簡素化

転送サービスの考慮漏れに対応

4. レコードルート手順の簡素化

ルーチング情報設定方法の変更（

Strict routingとloose routingを規定）

5. via branchの必須化によるトランザクション識別の簡素化

(8)

SIPルーチング

・ｲﾆｼｬﾙﾘｸｴｽﾄ(例:INVITE)と、後続のﾘｸｴｽﾄ(例:BYE)が同じ経路を用いるとは限らない。

⇒Record-Route,Routeヘッダの設定により、同じ経路使用可。

・ｲﾆｼｬﾙﾘｸｴｽﾄ(例:INVITE)と、後続のﾘｸｴｽﾄ(例:BYE)が同じ経路を用いるとは限らない。

⇒Record-Route,Routeヘッダの設定により、同じ経路使用可。

■Record-Route設定なし

ｲﾆｼｬﾙ・ﾘｸｴｽﾄ

INVITE sip:[email protected]

BYE sip:[email protected]

サーバ

P1

サーバ

P2

ﾚｽﾎﾟﾝｽ

後続ﾘｸｴｽﾄ

ﾚｽﾎﾟﾝｽ

User B

User A

■Record-Route(=RR)設定あり

BYE UserB

Route: P1,P2

INVITE UserB

サーバ

P1

User B

INVITE UserB

RR: P2

RR: P1

BYE UserB

INVITE UserB

RR: P1

サーバ

P2

BYE UserB

Route: P2

Record-Route: Proxyがinitialﾘｸｴｽﾄに挿入 UAが参照してRoute設定。 Route: UAがsubsequentﾘｸｴｽﾄに挿入

Proxyが参照してルーチング。

User A

(9)

9 SIPルーチング処理の変更

Looseルーチングの導入

着アドレスが設定されるフィールド(Request-URI)について、Proxyで書き換えを行う場合があった。そ

のため、着アドレスがサービスを示す場合、サーバでサービス起動不可になってしまう。

⇒Request-URI書き換えず、Routeヘッダを用いてルーチング。

Looseルーチングの導入

着アドレスが設定されるフィールド(Request-URI)について、Proxyで書き換えを行う場合があった。そ

のため、着アドレスがサービスを示す場合、サーバでサービス起動不可になってしまう。

⇒Request-URI書き換えず、Routeヘッダを用いてルーチング。

■Strictルーチング

サーバ

P2

INVITE P2

Route:UserB

INVITE UserB

INVITE P1

Route:P2,UserB

サーバ

_P1

User B(0120)

User A

■Looseルーチング

INVITE UserB

Route: P1:lr,P2:lr

サーバ

P1

サーバ

P2

INVITE UserB

Route:P2:lr

INVITE UserB

User B(0120)

User A

(10)

SIP Asserted IDの概要(RFC3325)

• 信頼関係が成立する範囲内で、ネットワークの保証したユーザIDを転送する機能。

• 信頼できないサーバや端末に対しては、ユーザIDは削除して転送される。

• ID自体は暗号化されていないため、信頼できる範囲での利用が前提。

• 信頼関係が成立する範囲内で、ネットワークの保証したユーザIDを転送する機能。

• 信頼できないサーバや端末に対しては、ユーザIDは削除して転送される。

• ID自体は暗号化されていないため、信頼できる範囲での利用が前提。

Untrusted

domain

Trusted domain

SIP

proxy

#1

SIP

proxy

#2

SIP

proxy

#3

INVITE INVITE* (IDあり) INVITE (IDあり) INVITE (IDなし) 発ID通知/非通知制御のための拡張ヘッダ(P-Asserted-Identity)でネットワークが保証するＩＤを転送する。ユーザからの最初のメッセージに対し、プロキシは認証を要求することで、ユーザの正当性を確認する。 INVITE (IDなし) INVITE*の例

INVITE sip:[email protected] SIP/2.0

Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-124 Via: SIP/2.0/TCP proxy.cisco.com;branch=z9hG4bK-abc To: <sip:[email protected]>

From: "Anonymous" <sip:[email protected]>;tag=9802748 ∼

P-Asserted-Identity: "Cullen Jennings" <sip:[email protected]> P-Asserted-Identity: tel:+14085264000 Privacy: id ユーザは、untrusted domainに対し IDを転送するか否かをPrivacyヘッダで指定できる。好みのIDをP-Preferred-Identityヘッダで指定することもできる。

(11)

NSLAB© NTT 2003

(12)

IM+プレゼンス概要

プレゼンスサービスとは、通信相手の存在や状態を、事前に通知する機能であり、通信相手の状況

に応じた通信手段の選択や、通信の開始が可能となる。一般に、このプレゼンスサービスと共に、

IM(instant messaging)サービスが提供される。

プレゼンスサービスとは、通信相手の存在や状態を、事前に通知する機能であり、通信相手の状況

に応じた通信手段の選択や、通信の開始が可能となる。一般に、このプレゼンスサービスと共に、

IM(instant messaging)サービスが提供される。

プレゼンス

サーバ

見せる人

X

(Presentity X)

③状態登録

①状態開示要求

④状態通知

見る人

B

(Watcher B)

×

拒否

②状態開示要求

／承認

①状態開示要求 ④状態通知

見せる人Y (Presentity Y)

見せる人Z (Presentity Z)

私は今，着席

中です．

･着席中（キーボードがアクティブ）･離籍中（スクリーンセイバと連動等）･通信中･外出中（ユーザ設定）等

Xさんは，

着席中です．

Bさんには

通知しない．

Xさんは今どうし

ているかな？

ユーザX：着席

ユーザ

Y：通信中

ユーザ

Z：外出中等

ユーザX：着席

ユーザ

Y：通信中

ユーザ

Z：外出中等

見る人Ａ

(Watcher A)

【状態例】

•見る人の側では、複数の見せ

る人の情報を集めて、お友達

リストを作成することが可能

•Watcher単位に多様な設定が

可能（通知拒否等）

(13)

NSLAB© NTT 2003

13 IMPP WG 検討状況

• 当初は、Instant MessagingとPresenceのための標準プロトコル仕様を追求していたが、

合意に至らなかった。

(SIMPLE, APEX, PRIMの３方式)

• 最終的には、独立なプロトコル間を相互接続するための論理的な共通仕様を策定した。

• 当初は、Instant MessagingとPresenceのための標準プロトコル仕様を追求していたが、

合意に至らなかった。

(SIMPLE, APEX, PRIMの３方式)

• 最終的には、独立なプロトコル間を相互接続するための論理的な共通仕様を策定した。

CPIM

XMPP

モデル：

CPIM (draft)

用語：

RFC2778

要求条件：

RFC2779

XMPP ⇔

_CPIM

APEX ⇔ CPIM

SIMPLE

⇔

CPIM

P

R

IM

⇔

C

P

IM

APEX

論理的仕様

具体的仕様

（各プロトコルで設定）

SIMPLE

情報の書式

日付・時刻の表記：

RFC3339

プレゼンス情報：

PIDF(draft)

メッセージ：

MSGFMT(draft)...WGLC済み

PRIM

(14)

SIP共通のイベント通知方式(RFC3265より)

• SIPが利用する状態変化通知手順を、Event Notificationとして汎用に規定。

• この手順に従って、プレゼンス等の具体的通知手順を規定する。

Event template package

イベントの周辺情報

watcher information

Subscriber

Notifier

(=presence agent相当)

Event package

通知対象となるイベント

user presence

メンバに加入

SUBSCRIBE/200 OK

加入時点の状態を

直ちに通知

NOTIFY/200 OK

状態変化

直前の加入期限が

切れる前に再度加入

状態変化に応じて

_通知

SUBSCRIBE/200 OK

NOTIFY/200 OK

(15)

15 SIMPLE WG検討状況

規定済みの基本機能に加え、プレゼンスデータの操作手順や、交換されるメッセージの集約、新たな

登録メソッドである

PUBLISHなど、標準化範囲の拡大や手順の効率化を検討中。

規定済みの基本機能に加え、プレゼンスデータの操作手順や、交換されるメッセージの集約、新たな

登録メソッドであるPUBLISHなど、標準化範囲の拡大や手順の効率化を検討中。

見せる人

X

(Presentity X)

③状態登録

①状態開示要求

④状態通知

[承諾]

②状態開示要求

／承認

○複数端末からの状態登録

複数端末同時使用を考慮したプ

レゼンス状態の登録。

(PUBLISH)

①状態開示要求 ④状態通知 [拒否]

○通知情報書式

CPIM(Common Profile for

Instant Messaging)による、プレゼン

スとメッセージの書式規定

○通知情報の絞込み

Watcherの都合に合わせた、通知

情報のフィルタリング機能

：基本機能決定

：ﾒｿｯﾄﾞ決定・書式検討中

プレゼンス

サーバ

見る人Ａ

(Watcher A)

見る人

B

(Watcher B)

○状態開示判断時の情報

状態開示の承認に対する許

可の情報を含む、

Watcher情

報とその書式の規定

○Event(プレゼンス等)のリスト化による制御

端末（携帯等）の処理能力を考慮しWatcher-Server間のメッセージ送受信数の削減

○データ操作

ﾌﾟﾚｾﾞﾝｽﾘｽﾄなどのデータ

の参照・編集動作規定

(16)

SIPによるインスタントメッセージング

IM (Instant Messaging)の2つのモード(pagerモード、sessionモード)のうち、

Pagerモードについての検討が終了。sessionモードを今後検討。

IM (Instant Messaging)の2つのモード(pagerモード、sessionモード)のうち、

Pagerモードについての検討が終了。sessionモードを今後検討。

■sessionモード

SIPのINVITE,BYEを用いて、セッション開始・終了を

識別。その間、media streamとしてメッセージを送信。

一連のメッセージの関連付け可。

■pagerモード

SIPの拡張であるMESSAGEメソッドを用いて

メッセージを送信。一連のメッセージに関連なし。

通常のSIPメッセージと転送ルートを共有するため

輻輳制御等の注意が必要。

SIP Proxy

MESSAGE

body:

text or MSGFMT

INVITE

message(ex. text)

MESSAGE

RFC3428にてMESSAGEメソッドを規定（pagerモードのみ）

(17)

17 XMPP

XMLの交換により、インスタントメッセージとプレゼンス機能を実現する。

TCP上のXMLストリームにより、XMLスタンザ(メッセージ)を交換する。

Gateway

XMPP

XMPP server

SIP/

SIMPLE

XMPP

XMLの交換により、インスタントメッセージとプレゼンス機能を実現する。

TCP上のXMLストリームにより、XMLスタンザ(メッセージ)を交換する。

AからBへのメッセージ例

_{BからAへのメッセージ例}

<?xml version='1.0'?> <stream:stream to='example.com' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'> <?xml version='1.0'?> <stream:stream from='example.com' id='id_123456789' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'> ... authentication ... <message from='[email protected]' to='[email protected]' xml:lang='en'>

<body>Art thou not Romeo, and a Montague?</body> </message>

<body>Neither, fair saint, if either thee dislike.</body> </message>

</stream:stream>

(18)

XCON: Centralized Conferencing

• 2003年7月にBoFを開催。今後WG化の予定。

• 集中管理型の会議サービスに必要なプロトコルの検討。

• SIPを例題とする汎用な規定を目指す。

– A mechanism for membership and authorization control

– A mechanism to manipulate and describe media "layout" or "topology" for

multiple media types (audio, video, text)

– A mechanism for notification of conference related events/changes (for example

a roster)

– A basic floor control protocol

– Peer-to-peer cascading of conferences (one conference is a participant in another

and vice versa)

• Loosely Coupled Conference: A loosely coupled conference is a conference

without coordinated signaling relationships amongst participants. Loosely

coupled conferences frequently use multicast for distribution of conference

memberships.

• Tightly Coupled Conference: A tightly coupled conference is a conference in

which a single user agent, referred to as a focus, maintains a dialog with each

participant. The focus plays the role of the centralized manager of the

(19)

NSLAB© NTT 2003

(20)

TCP/IPとUDP/IP

TCP/IPあるいはUDP/IPでは、５タプルでフローを識別する。

（送信元IPアドレス、宛先IPアドレス、送信元ポート番号、宛先ポート番号、プロトコル番号）

TCP/IPあるいはUDP/IPでは、５タプルでフローを識別する。

（送信元IPアドレス、宛先IPアドレス、送信元ポート番号、宛先ポート番号、プロトコル番号）

0 4 8 16 31(ビット) 0 16 31(ビット) パケット長識別子生存時間送信元IPアドレス宛先IPアドレスバージョンヘッダ長サービスタイプフラグフラグメントオフセットプロトコル番号ヘッダチェックサム送信元ポート番号宛先ポート番号シーケンス番号確認応答番号 Data Offset 予約コードビットウィンドウサイズチェックサム緊急ポインタパケット長識別子生存時間送信元IPアドレス宛先IPアドレスバージョンヘッダ長サービスタイプフラグフラグメントオフセットプロトコル番号ヘッダチェックサム TCPヘッダフォーマット データチェックサムパケット長宛先ポート送信元ポート UDPヘッダフォーマット ＵＤPヘッダ＊ポート番号は１６ビットなので０∼６５５３９まで表現できる（8バイト）データ IPヘッダ _IPヘッダ（20バイト） _{（20バイト）} TCPヘッダ（20バイト）＊IPアドレスは３２ビットなので０∼約４２億まで表現できる

(21)

21 ＩＰアドレスとポート番号による通信の識別

クライアント httpd2 （８０）ＩＰ TCP httpd3 （８０） httpd1 （８０）ＩＰ TCP Webブラウザ画面１画面２ (2001) (2002) ＩＰ TCP Webブラウザ画面１ (2002) (1) クライアント１２画面１サーバー同一クライアントの通信の識別１７２．２０．１００．１０１７２．２０．１００．３４（１）と（２）の通信は、画面を２つ開いて、同じサーバ上の別のページを同時に見ようとしている。このとき、送信元／宛先IPアドレスと、宛先ポート番号が一緒であるが、送信元ポート番号が異なるので、それぞれが別の通信であることを識別する。 (2 ）１７２．２０．１００．２０ＩＰヘッダ _{TCＰヘッダ} (3) データ宛先ﾎﾟｰﾄ番号８０送信元ﾎﾟｰﾄ番号２００１ TCP 6 宛先IPｱﾄﾞﾚｽ 172.20.10.34 送信元IPｱﾄﾞﾚｽ 172.20.100.10 (1) データ宛先ﾎﾟｰﾄ番号８０送信元ﾎﾟｰﾄ番号２００２ TCP 6 宛先IPｱﾄﾞﾚｽ 172.20.10.34 送信元IPｱﾄﾞﾚｽ 172.20.100.10 (2) データ宛先ﾎﾟｰﾄ番号８０送信元ﾎﾟｰﾄ番号２００２ TCP 6 宛先IPｱﾄﾞﾚｽ 172.20.10.34 送信元IPｱﾄﾞﾚｽ 172.20.100.20 別クライアントの通信の識別（２）と（３）の通信は、別々のコンヒュータから同じ画面を見ようとしている。このとき、宛先ポート番号、宛先IPアドレスが一緒であるが、仮に送信元ポート番号が同じであっても送信元IP アドレスが異なるので、それぞれが別の通信であることを識別する。 (3)

(22)

セキュリティポリシーと運用

現在の企業NWの構成とFWポリシー

FW/NAT 192.168.1.102 DMZ（非武装地帯）企業NW インターネット社内LAN

Webサーバ

← ポート80（HTTP）

メールサーバ ← ポート25（SMTP）

← ポート110（POP）内部からのみ

FTPサーバ

← ポート21（FTP）

DNSサーバ

← ポート53（DNS）

原則として、その他のポートはすべて閉鎖しておき、

余分なパケットは通過させない。

VoIPで利用されるポート

9シグナリングパケット

← 例）SIP ポート５０６０（TCP,UDP）

ただしこのポート番号はデフォルト値であり、変更可能

9音声パケット

←1024∼65535（UDP）

（ＲＴＰ）

APLに依存。一般的に偶数が使われる

9音声制御パケット

←1024∼65535（UDP）

（ＲＴＣＰ）

APLに依存。一般的にRTPよりも１大きいポート番号を使う

少なくとも、これらのポートを通信時に許可する必要がある

(23)

23 セッション確立と連動したポート制御とセキュリティへの影響

プライベートＩＰ網

パブリックIP網

User#1

FW

従来環境

HTTP

_{必要最小限のポートのみ開放し、}

余分な通信を防ぐ。

⇒トロイの木馬型ウィルスでの悪用やセ

キュリティホールへの攻撃を防ぐ。

FTP

Virus／

ｾｷｨﾘﾃｨﾎｰﾙ

プライベートＩＰ網

パブリックIP網

User#1

FW

ＳＩＰ

Virus/

ｾｷｭﾘﾃｨﾎｰﾙ

Voice

VoIP環境

[１]認証や、端末間でのﾈｺﾞｼｴｰｼｮﾝがある

ことから、従来のﾃﾞｰﾀ通信よりも相手を特

定しやすく信頼性が高い

HTTP

従来のＨＴＴＰ等のためのポート開放と、セキュリティ面の差はない。

[２]動的にﾎﾟｰﾄを開放することにより侵入を

困難にしているだけでなく、用途を音声に限

定することにより、悪意のあるﾊﾟｹｯﾄの侵入

を防ぎやすい

(24)

SIPのNAT不通過問題

■ＩＰヘッダのアドレスは「ＮＡＴ」が自動変換するが、ＳＩＰメッセージ内（ＳＤＰ部等）に記載

のＩＰアドレスは変換されないため、ＳＩＰプロトコルレベルでの通信ができないという問題が

発生している。

⇔

方

向

G1

ｸﾞﾛｰﾊﾞﾙ

ｱﾄﾞﾚｽ

P1

ﾌﾟﾗｲﾍﾞｰﾄ

ｱﾄﾞﾚｽ

NAT

G3

P1

プライベート端末

ホームネットワーク

ＳＩＰメッセージ

ﾌﾟﾗｲﾍﾞｰﾄｱﾄﾞﾚｽ（Ｐ１）

SDP （音声受信ﾎﾟｰﾄ）

C=IN IP4

192.168.1.5（=P1）

SIPサーバ

ｸﾞﾛｰﾊﾞﾙｱﾄﾞﾚｽ（G3）

G2

G3

グローバル端末

ｸﾞﾛｰﾊﾞﾙｱﾄﾞﾚｽ（G2）

SDP （音声受信ﾎﾟｰﾄ）

C=IN IP4

192.168.1.5 G3

G1

G2

P1

音声

プライベートアドレスを宛

先としたパケットなので

ルーチングされない

_{ＳＤＰの内容に基づき、}

返信パケットを生成

(25)

25 STUNの機能(RFC3489)

• 第１の目的は、グローバル側からプライベート側へのパケット通過を可能とするために、ＮＡＴのグローバ

ル側アドレス／ポートを検出すること。

• その他、サーバの認証と、後続メッセージの完全性保証のために利用する暫定パスワード入手手順と、

ＮＡＴの有無や種別を判定する手順、NATの有効時間を検出する手順を含む。

• ＳＩＰ以外のＡＰＬにも利用可能。ストリーム系配信で利用されるＲＴＳＰでの利用もＩＥＴＦにて検討中。

①セキュリティ手順

（サーバ認証、暫定パスワード決定）

NAT

Private NW Global NW

STUN Server _{認証 Server}

STUN Client ①リクエスト ①レスポンス ②リクエスト ②レスポンス

①セキュリティ手順

（サーバ認証、暫定パスワード決定）

②アドレス検出手順

③NAT種別判定手順

（②の繰り返し）

③NAT種別判定手順

（②の繰り返し）

④NAT有効時間検出手順

（②の応用）

④NAT有効時間検出手順

（②の応用）

(26)

STUNにより通過可能なNATの種別（その１）

?

10.10.1.1 port=10 port=11 port=12 X Y Z プライベート網 192.168.1.1 port=10000 プライベート網 Y Z 10.10.1.1 port=10

NAT

通信相手にかかわらず、同じIPアドレスとポート番号に変換するタイプのNAT(=下記の円錐型NAT)であれば、

STUNサーバへのアクセス結果で、NAT変換後のアドレスが推定でき、NATを通過したパケットの受信が可能。

X

_{円錐型ＮＡＴ(cone NAT)}

相手端末にかかわらず、同じアドレスやポート番号に変換するもの ⇒STUNサーバ(X)にアクセスすればクライアントの変換後のアドレスは推定できる（左記の例では、Xにアクセスするパケットのソースアドレスとポート番号を見れば、10.10.1.1のport=10を使うことがわかる）ＳＩＰで相手(YやZ)に 10.10.1.1 port=10を、通知すれば 192.168.1.1 port=10000で

パケットの受信が可能

対称型ＮＡＴ(symmetric NAT)

相手端末に応じてアドレスやポート番号が変わるもの ⇒STUNサーバ(X)にアクセスしても、クライアントの変換後のアドレスは特定できない（左記の例では、Xにアクセスしたパケットのソースアドレスとポート番号を見ても、 YやZにアクセスするときのポート番号はわからない） 192.168.1.1 port=10000 通信相手に応じて変換されるポート番号が変わるので相手に通信すべきポート番号が不明

⇒パケットの受信は不可能

NAPTの場合注意 ○ＮＡＴは、プライベート網側にある端末のアドレスやポート番号を変換するもので、パブリック網側にあるアドレスを変換するものではない。 ○インターネットプロトコルは、送受のＩＰアドレスとポート番号で通信を識別するので、片方が同じＩＰアドレスとポート番号を使っていても、通信の識別は可能。

(27)

27 STUNにより通過可能なNATの種別（その２）

プライベート網 X, port=p X, port=q Y, port=r 10.10.1.1 port=10

NAT

Full cone NAT

一度プライベート網からパブリック網にパケットを送出すると、任意の端末から通信可能。 ⇒ドアノブは一つ（左記の例では、X, port=pにパケットを送出すると、Y, port=rからのパケットも受信可能となる。） 192.168.1.1 port=10000

STUNでは、STUNサーバに

予備のポート／IPアドレスを

用意し、デフォルトのポートへ

のアクセスに対し、予備の

ポート／IPアドレスからメッ

セージを返信することにより、

左記のNATの種別を判定す

る。

（restricted cone NATは、予

備アドレスからの応答は通さ

ないが、予備ポートからの応

答は通す。

port restricted cone NATは、

予備ポートからの応答も通さ

ない。）

プライベート網 X, port=p X, port=q Y, port=r 10.10.1.1 port=10 X, port=p X, port=q Y, port=r 10.10.1.1 port=10

NAT

Restricted cone NAT

一度プライベート網からパブリック網にパケットを送出すると、同一IPアドレスの端末から通信可能。 ⇒ドアノブは相手IPアドレス毎（左記の例では、X, port=pにパケットを送出すると、X, port=qからのパケットも受信可能となる。） 192.168.1.1 port=10000

NAT

Port restricted cone NAT

一度プライベート網からパブリック網にパケットを送出すると、同一ポートからは通信可能。 ⇒ドアノブはポート毎（左記の例では、X, port=pにパケットを送出しても、X, port=p以外からのパケットは受信不可能となる。） 192.168.1.1 port=10000 プライベート網

(28)

STUNの主な信号シーケンス

• STUNプロトコルは、STUNクライアント(=端末)からの要求メッセージに対し、STUNサーバ(=網内サーバ)

からの応答メッセージにより実行される、クライアント／サーバモデル。

NAT

Binding Response Request Binding Response ところに返信さサーバの予備のアドレスやポー信を要求する a -> S A <- S a -> S A <- S Binding Request A-> S Binding Response S MAPPED-ADDRESS: Requestのソースアドレスとポート（＝ NATの外側のアドレス） SOURCE-ADDRESS: Responseのソースアドレスとポート（＝STUN サーバのアドレス） CHANGED-ADDRESS: STUNサーバの予備のソースアドレスとポート（NAT種別判定用にあとでクライアントが利用） REFLECTED-FROM: Requestのソースアドレスとポート(Requestが別のアドレスに返信を要求した場合の、オリジナルのアドレス)

STUNクライアント

STUNサーバ

Shared Secret Request a -> S

サーバ認証＋

暫定ﾊﾟｽﾜｰﾄﾞ取得（ＴＬＳ／ＴＣＰ上）

Shared Secret Response A <- S USER NAME: 暫定ユーザ名 PASSWORD: 暫定ユーザ名に対する暫定パスワード Binding Request Binding ＮＡＴ種別判定アドレス検出アドレス検出 RESPONSE-ADDRESS: 返信先アドレス（別のせたい場合） CHANGE-REQUEST: STUN トからの返 a <-NATで変換されたアドレスをクライアントに通知するのが STUNの基本機能

(29)

5. 新しいQoS実現方式の提案

(30)

IMM（P2P型）通信におけるQoS制御の課題

• IMM通信では、中高速、任意の対地間で、オンデマンドの帯域保証が必要となり、従来の余剰帯

域によるベストエフォート型ではサービス上、許容されない危険性がある。

• 実効帯域に応じた、端末での送信帯域の変更では、サービス品質が維持できず、従量制課金へ

の発展性がない。

⇒ 中高速通信、任意対地、オンデマンドなどの特徴に適した、QoS制御が必要。

• IMM通信では、中高速、任意の対地間で、オンデマンドの帯域保証が必要となり、従来の余剰帯

域によるベストエフォート型ではサービス上、許容されない危険性がある。

• 実効帯域に応じた、端末での送信帯域の変更では、サービス品質が維持できず、従量制課金へ

の発展性がない。

⇒ 中高速通信、任意対地、オンデマンドなどの特徴に適した、QoS制御が必要。

スループットに加えて、

遅延時間やジッタの低減が重要

サービスの基準はスループット

会話の要求に応じて、しかもセッション

が終了するまでの安定したQoS制御が

必要

⇒ オンデマンドの帯域割当型

スループットの一時的な低下や、

再送は許容される。

⇒ ベストエフォート型

数100kbps∼数Mbps

⇒ 中高速

（ユーザ主導のP2P型通信であるため、①ア

プリケーションによっては、より大きな帯域が

期待され、また②任意の対地間に通信が発

生する可能性がある。）

∼64kbp以下

⇒ 低速

インタラクティブマルチメディア通信

（P2P型通信）の特徴

従来型通信

（webや電子メール）の特徴

ネットワーク全体の課題

⇒ 受付制御方式

ルータ単体の課題

(31)

31 フロー制御/トラヒック制御の実現方式の比較 ∼提案方式のポイント∼

リアルタイム系通信

（提案型）

TCP

データ系通信

リアルタイム系通信

（従来型）

目標：通信したいユーザ間で、ＮＷリソースを公平に分割（例１０人なら１／１０、１００人なら１／１００）実現方法：端末側のＴＣＰによるフロー制御にて自律分散的に実現ＮＷは土管のみ提供目標：通信したいユーザ数にかかわらず、一定数のｾｯｼｮﾝの品質を確保（例１０人でも５人、１００人でも５人の通信品質は確保）実現方法：端末側のフロー制御なし。ＮＷのリソース管理にて実現

データ系では、端末の機能に依存しているため、網の

機能が単純化でき、エンド･エンドのグローバルな制御

が実現可能（↑）。

一方、従来のリアルタイム系通信は、網機能への依存

度が高すぎるため、汎用性にかける（♂）。

端末とＮＷの機能分担を見直すことにより、汎用のＱｏ

Ｓ保証方式をねらう（→）。

データ系では、端末の機能に依存しているため、網の

機能が単純化でき、エンド･エンドのグローバルな制御

が実現可能（↑）。

一方、従来のリアルタイム系通信は、網機能への依存

度が高すぎるため、汎用性にかける（♂）。

端末とＮＷの機能分担を見直すことにより、汎用のＱｏ

Ｓ保証方式をねらう（→）。

実現方法：

端末側で、受信品質に応じたＴｏＳ値の設定

ＮＷ側は、優先制御のみでリソース管理なし

(32)

プライオリティプロモーション方式とは

■ねらい

インタラクティブな音声・画像通信を対象に、ネットワークの混雑時でも、少なくとも接続中の通信

については、通信が完了するまで、所定の品質を維持することを狙いとしたQoS制御方式。

パケット単位に帯域を公平に分け合うのではなく、セッション単位に帯域を譲り合うサービス。

■ねらい

インタラクティブな音声・画像通信を対象に、ネットワークの混雑時でも、少なくとも接続中の通信

については、通信が完了するまで、所定の品質を維持することを狙いとしたQoS制御方式。

パケット単位に帯域を公平に分け合うのではなく、セッション単位に帯域を譲り合うサービス。

■アプローチ

多様化する通信網を考慮すると、エンドエンドの通信品質維持のためには、端末の協力（最終判

断）が不可欠であることに着目。

■アプローチ

多様化する通信網を考慮すると、エンドエンドの通信品質維持のためには、端末の協力（最終判

断）が不可欠であることに着目。

ネットワーク側は、

一度確立した通信は必ず最後まで保証します。

ただし、余裕のあるときだけです。

余裕があるかどうかは、最初に調べてください。

セッション単位ではなく、クラス単位の優先制御により、確立墨の優先クラスの通信品質は保証するとともに、非優先クラスを利用した残帯域の推定が可能。

■メリット／ポテンシャル

ユーザ網や複数網を横断したエンドエンドでの品質保証

■メリット／ポテンシャル

ユーザ網や複数網を横断したエンドエンドでの品質保証

さらにネットワーク側は、

ときどきチェックしますよ。

端末側は、

本当に通信できるかどうか、

自分で試して、判断してください。

ただし、他人に迷惑をかけないように。

送信側は非優先クラスで試験パケットを送出し、受信側からの受信結果で品質良好な場合のみ、優先クラスで通信を確立。

(33)

33 Priority Promotion Schemeが前提とするキュー方式

• 下記のようなキュー方式を、MFクラス(Measurable Forwarding; 観測可能な転送クラス)と定義。

• MFクラスでは、試験パケットにより、リンクの残帯域が推定可能。

• 基本動作は、既存の優先制御(=Diffserv)で容易に実現可能

• 下記のようなキュー方式を、MFクラス(Measurable Forwarding; 観測可能な転送クラス)と定義。

• MFクラスでは、試験パケットにより、リンクの残帯域が推定可能。

• 基本動作は、既存の優先制御(=Diffserv)で容易に実現可能

残帯域が測定可能なキュー方式

flow #1

flow #2

リンク容量を上回るパケットを流入しても

フロー＃１のパケット（優先クラス）は必ず転送される。

⇒非優先クラスで試して、通過すれば優先クラスでも転送されるはず。

⇒試験パケットにより、残帯域が測定可能

flow #2

通常のキュー方式

flow #1

flow #2

flow #1

flow #2

品質劣化の

原因

リンク容量を上回るパケットが流入すると

区別なく廃棄が発生する。

⇒フロー＃１のパケットの品質は保証されない。

(34)

プライオリティプロモーション方式の帯域空き判定 ∼動作概要∼

• ルータでは、帯域しきい値BWmf以下ではH+Mの転送を保証し、しきい値を越えた場合は、Mを優先的に廃

棄する。

• 端末は、通信の前に試験パケットを非優先クラスMで送出し、通信可否判定をする。

廃棄がなければ、通信可能と判断し、優先クラスHで通信を確立する。

廃棄があれば、通信不可と判断し、通信を確立しない。

• 上記動作の組み合わせにより、結果的に、品質が確保できる範囲で通信が確立されることになる。

• ルータでは、帯域しきい値BWmf以下ではH+Mの転送を保証し、しきい値を越えた場合は、Mを優先的に廃

棄する。

• 端末は、通信の前に試験パケットを非優先クラスMで送出し、通信可否判定をする。

廃棄がなければ、通信可能と判断し、優先クラスHで通信を確立する。

廃棄があれば、通信不可と判断し、通信を確立しない。

• 上記動作の組み合わせにより、

結果的に、品質が確保できる範囲で通信が確立

されることになる。

回線が混んでいる時は、Mが廃棄されるため、端末は通信を確立しない。

試験パケットは、非優先なので、すでに確立されているHの通信は邪魔されない。

回線が混んでいる時は、Mが廃棄されるため、端末は通信を確立しない。

試験パケットは、非優先なので、すでに確立されているHの通信は邪魔されない。

時間 M M H M H M H M H M H M H M H M H M H

回線が空いている時は

loss

再び回線が空いてきたら

端末は、Hで通信を確立

再び回線が空いてきたら

端末は、Hで通信を確立

M loss

BWmf

(35)

35 キュー方式への要求条件

ネットワーク内の装置において、下記のMFクラスの実装が最低限の要求条件であり、これさえ実装されていれば、

プライオリティプロモーション方式(=自律分散制御)によるエンド−エンドの品質保証が提供できる。

ネットワーク内の装置において、下記のMFクラスの実装が最低限の要求条件であり、これさえ実装されていれば、

プライオリティプロモーション方式(=自律分散制御)によるエンド−エンドの品質保証が提供できる。

MF class(Measurable forwarding class)とは

MF-HとMF-Mの二つのクラス(HとM)が存在する。

HとMの合計の利用可能帯域には上限があり

その上限以下であれば転送は保証される。

また、Hが上記の上限以下であれば

Mの有無にかかわらず転送が保証される。

言い換えれば、Mで試すことにより、

Hに被害を与えることなく、Mの追加可否の判断ができる。

追加可の場合、Hに格上げすることで安定品質を確保する。

MF

MF-H

MF-M

M

H

Mで試して、ＯＫなら

Ｈに格上げする。

?

(36)

自律分散型QoS制御（Priority Promotion Scheme: PPS）

安定的な品質を実現するために、端末とNWの機能分担を見直し、受信端末での品質の観測結果をもとに、

送信端末がパケットの優先度を付与する、汎用的なセッションレベル（ＳＩＰと連携した）での品質制御方式。

安定的な品質を実現するために、端末とNWの機能分担を見直し、受信端末での品質の観測結果をもとに、

送信端末がパケットの優先度を付与する、汎用的なセッションレベル（ＳＩＰと連携した）での品質制御方式。

SIP サーバエッジ装置ﾓﾆﾀｻｰﾊﾞエッジ装置 RTP(非優先クラスの試験パケット) RTP(優先クラスの音声・画像パケット) RTCP(受信状況報告) 受信状況報告優先制御利用可能帯域の測定と通信可否判断帯域上限 M M M H H M M H H M H M H HとMのセットで帯域を保証し、Mを優先的に廃棄するキュー方式により、 Hの品質を保証しつつ、Mで通信可否が判定できる。基本はDiffServ loss M loss←通信は確立されない契約ユーザ管理、端末監視指示、課金情報収集選択的な詳細監視 (二次監視) 通信可否、流量監視（一次監視） ■ﾊﾟｹｯﾄ優先度の遷移例 Middleﾚﾍﾞﾙ Highﾚﾍﾞﾙ Lowﾚﾍﾞﾙ通信経過時間 ToS値成功（優先権獲得）失敗失敗ﾄﾗｲﾄﾗｲﾄﾗｲ ①通信の前段で、非優先クラスの試験パケットを送出 ②受信端末で、受信ﾊﾟｹｯﾄから通信品質を測定し、RTCPﾊﾟｹｯﾄとして返送 ③送信端末は、一定時間NW品質を観測し、 ・品質がよかった場合：優先度を上げてRTPを送出 ⇒安定状態（優先権確保）・品質が悪かった場合：優先度を下げてRTPを送出 ⇒一般レベルに逆戻り ⇒一定時間後再挑戦

品質制御ﾒｶﾆｽﾞﾑ

IP端末 IP端末

(37)

37 プライオリティプロモーション方式の位置づけ

スケーラブル化へのアプローチスケーラブル化へのアプローチ

アドミッションコントロールのスケーラブル化へのアプローチとしては、従来、IntServの適用をアクセスネットワ

ークに限定したり、リソース予約のためのアクセスネットワークを軽量化するアプローチが検討されている。

様々なアプローチの中でプライオリティプロモーション方式は

アクティブ方式

として分類される

アドミッションコントロールのスケーラブル化へのアプローチとしては、従来、IntServの適用をアクセスネットワ

ークに限定したり、リソース予約のためのアクセスネットワークを軽量化するアプローチが検討されている。

様々なアプローチの中でプライオリティプロモーション方式は

アクティブ方式

として分類される

サブネット間のリソース予約を集約したり、ルータが管理する状態を集約することでスケーラビリティを向上させることが考えられるアクセスネットワークは「IntServ」、バックボーンネットワークは「DiffServ」をサポートする。 IntServからはDiffServクラウドはIntServアクセスネットワークを繋ぐ仮想リンクに見える。 IntServ / RSVP の軽量化 IntServ / RSVP の軽量化

IntServ over DiffServ

エンドポイント間に、アドミッションを要求するフローと同等のレートで

プローブフローを新たに加え、その

QoS

_QoS

の観測から内部状態を推定し、

アドミッションコントロールを行う

エンドポイント方式エンドポイント方式ネットワークの内部状態を推定するための機能をエンドポイントに持たせアドミッションコントロールを行う方式

アクティブ方式

パッシブ方式パッシブ方式新たにプローブフローを加えることなくパケットを観測することにより、網の内部状態を推定し、アドミッションコントロールを行う形式 *間瀬憲一「インターネットにおけるスケーラブルなアドミッションコントロール方式」電子情報通信学会 vol.85 No.9 pp.655-661 2002.9

(38)

セッション単位のQoS保証技術の比較

• 現状は、ルータでの優先制御と余裕を持った設備設計により、間接的にQOSを保証している。

• 将来的には、リアルタイム系通信により数Mbps以上の継続的なトラヒックが、任意の対地間で発生するため、セッション単位

の受付判定による直接的なQOS保証が必要となる。

SIP proxy

余裕をもった設備設計（現状）

SIP proxy

３．ルータでフロー毎の受付判定（例 RSVP）

SIP proxy

１．NWのﾘｿｰｽを把握しているサーバで受付判定

SIP proxy

２．端末主導で受付判定

!

ﾘｿｰｽ管理ｻｰﾊﾞルーチング情報を元にトポロジーと利用可能帯域を完全把握し、受付判断する。

!:受付判断機能

残余帯域の判定可能なQに対し端末から試験パケットを送出し受信状態に応じて受付判定を行う。各ルータがフロー単位の通信状況を管理し受付判定を行う。それまでの交流トラヒックをもとに余裕をもった設備設計をし明示的な受付制御なく品質を維持する。

• 現状は、ルータでの優先制御と余裕を持った設備設計により、間接的にQOSを保証している。

• 将来的には、リアルタイム系通信により数Mbps以上の継続的なトラヒックが、任意の対地間で発生するため、セッション単位

の受付判定による直接的なQOS保証が必要となる。

(39)

39 QoS制御／エッジルータ制御技術動向

∼２００２年

２００３年

２００４年

▲2004/11 ▲2004/8 ▲2004/2 ▲2003/11 ▲2003/3 ▲2003/7 ■Diffserv WG

EF, AF, BEの規定をもって完了

■MIDCOM WG (Middlebox communications) => SNMPv3

NATのような網内装置をミドルボックスと位置づけ、APL対応サーバから制御する方式を検討２００３年７月時点では、NAT制御に限定し、SNMPｖ３の適用を検討中

■NSIS WG (Next Steps in Signaling)

メディアの転送ルートを意識した新たな信号制御(RSVPの改良)を検討中 QoS制御とＮＡＴ／ＦＷ制御を想定共通部(NTLP)と個別制御部(NSLP)から構成される。

プロトコル議論中心

IETF

■SG13(アーキテクチャ) Q.16のY.qosarにてアーキテクチャを検討(集中管理型) Q.4にてルータ動作を検討 ▲2003/7 全体会合 ▲2003/11 ﾗﾎﾟｰﾀ会合 ▲2004/2 全体会合

アーキテクチャから検討

▲2003/9 JRG ▲2004/1 JRG

ITU-T

■SG11(信号方式) Q.1,6のQ.ncap1, 2にてゲート制御プロトコル(GCP)の要求条件を検討 Q.11のQ.ncap3にてGCP用にmegaco profileを検討

Q.7,8,9のTRQ.IPQoS.Sig.CS1にてIP-QoSの要求条件を検討 ▲2003/9 全体会合 ▲2003? ﾗﾎﾟｰﾀ会合 ▲2004? 全体会合 ▲2002/11 全体会合 ▲2003/4 ﾗﾎﾟｰﾀ会合

プロトコル議論を先行

□ETSI 次世代NWアーキテクチャ検討の一環でMegacoの改良によるエッジ制御を２００２年６月に規定済み □Packet Cableや3GPPでは、COPSを規定

PowerPoint プレゼンテーション

インタラクティブマルチメディアを支える技術動向

−ＱｏＳを中心に−

２００３年１０月１０日

ＮＴＴネットワークサービスシステム研究所

森田 直孝

目次

1. SIPに関する技術動向

2. ｲﾝｽﾀﾝﾄﾒｯｾｰｼﾞﾝｸﾞとﾌﾟﾚｾﾞﾝｽに関する技術動向

3. NAT/FW通過制御に関する技術動向

4. 新しいQoS実現方式の提案(PPS方式)

5. Q&A

１．SIPに関する技術動向

【SIMPLE: SIP for Instant

Messaging and Presence

Leveraging Extensions】

• SIPﾒｯｾｰｼﾞの拡張によるﾌﾟﾚ

ｾﾞﾝｽ/ｲﾝｽﾀﾝﾄﾒｯｾｰｼﾞ機能

【SIMPLE: SIP for Instant

Messaging and Presence

Leveraging Extensions】

• SIPﾒｯｾｰｼﾞの拡張によるﾌﾟﾚ

ｾﾞﾝｽ/ｲﾝｽﾀﾝﾄﾒｯｾｰｼﾞ機能

【IMPP: Instant Messaging

and Presence Protocol】

• ﾌﾟﾚｾﾞﾝｽ/ｲﾝｽﾀﾝﾄﾒｯｾｰｼﾞの共

通ﾃﾞｰﾀﾌｫｰﾏｯﾄを規定

• 2002/11 終結

【IMPP: Instant Messaging

and Presence Protocol】

• ﾌﾟﾚｾﾞﾝｽ/ｲﾝｽﾀﾝﾄﾒｯｾｰｼﾞの共

通ﾃﾞｰﾀﾌｫｰﾏｯﾄを規定

• 2002/11 終結

【SIPPING: Session

Initiation Proposal

Investigation】

• 新機能の要求条件を明確化

• 2001/8 WG設立

【SIPPING: Session

Initiation Proposal

Investigation】

• 新機能の要求条件を明確化

• 2001/8 WG設立

【SIP: Session Initiation

Protocol】

• SIPプロトコルの改良

• 1999/11 WG設立

【SIP: Session Initiation

Protocol】

• SIPプロトコルの改良

• 1999/11 WG設立

セッション制御機能

ﾌﾟﾚｾﾞﾝｽ/ｲﾝｽﾀﾝﾄﾒｯｾｰｼﾞ機能(Application Area)

転送系の制御方式

SIPを中心とするIETFのワーキンググループ

ｱﾄﾞﾚｼﾝｸﾞ/ﾙｰﾁﾝｸﾞ制御機能

【AVT: Audio/Video

Transport】

• 音声や画像情報の転送ﾌﾟﾛﾄｺ

ﾙ(RTP)を検討

【AVT: Audio/Video

Transport】

• 音声や画像情報の転送ﾌﾟﾛﾄｺ

ﾙ(RTP)を検討

【MMUSIC: Multiparty

Multimedia Session

Control】

• ﾒﾃﾞｨｱ属性記述

(SDP/SDPng)、ｽﾄﾘｰﾐﾝｸﾞ制

御ﾌﾟﾛﾄｺﾙ(RTSP) を検討中

【MMUSIC: Multiparty

Multimedia Session

Control】

• ﾒﾃﾞｨｱ属性記述

(SDP/SDPng)、ｽﾄﾘｰﾐﾝｸﾞ制

御ﾌﾟﾛﾄｺﾙ(RTSP) を検討中

メディア転送/制御機能

【XMPP: Extensible

Messaging and Presence

Protocol】

森田直孝