XMPPでP2Pの音声チャットセッションを確立する方法2
これの続き。
XEP-0176: Jingle ICE-UDP Transport Method
を読む。
This specification defines a Jingle transport method that results in sending media data using raw datagram sockets via the User Datagram Protocol (UDP). This transport method is negotiated via the Interactive Connectivity Establishment (ICE) methodology defined by the IETF and thus provides robust NAT traversal for media traffic.
これと並列なものとして、
XEP-0177: Jingle Raw UDP Transport Method
というのもある
This specification defines a Jingle transport method that results in sending media data using raw datagram sockets via the User Datagram Protocol (UDP). This simple transport method does not provide NAT traversal, and the ICE-UDP transport method should be used if NAT traversal is required.
NAT越えが必要なら前者。後で後者も読む。
The current document defines a transport method for establishing and managing data exchanges between XMPP entities over the User Datagram Protocol (see RFC 768 [2]), using the ICE methodology developed within the IETF and specified in Interactive Connectivity Establishment (ICE) [3] (hereafter referred to as ICE-CORE). Use of the ice-udp method results in a lossy transport suitable for media applications where some packet loss is tolerable (e.g., audio and video).
XMPP entity間でUDP、ICEを使用してデータ転送する方法を定義する。ice-udpはパケットロスに耐えられる音声、映像アプリケーションに向く。
ICEとの違い
・signaling channelにSIPではなく、XMPPを使用する
・ICEでは、全てのtransport候補をいっぺんに送るところ、個別に送ってもいい。XMPPの
・SDPの文法はXMPPのxmlにマッピングされている（前回のpayload typeのところかな）
・ICE candidates can be upgraded during a session (e.g., to change an IP address)
IPアドレスの変更に耐えられるってこと？mobilityのサポートってこと？なんだろこれ
・どちらのxmpp entityでも、セッション中にいつでもnegotiationをやり直せる
あー、その前に、ICE-COREの方読まなきゃわかんなそうだ。。
Abstract
This document describes a protocol for Network Address Translator
(NAT) traversal for UDP-based multimedia sessions established with
the offer/answer model. This protocol is called Interactive
Connectivity Establishment (ICE). ICE makes use of the Session
Traversal Utilities for NAT (STUN) protocol and its extension,
Traversal Using Relay NAT (TURN). ICE can be used by any protocol
utilizing the offer/answer model, such as the Session Initiation
Protocol (SIP).
offer/answerモデルでUDPを使用したマルチメディアセッションのNAT超えについて記述する。
ICEはSTUNとその拡張であるTURNを使用する。
SIPなど、offer/answerモデルであるあらゆるプロトコルで使用できる。
気になるところ抜粋
2.5. Security for Checks
Each STUN
connectivity check is covered by a message authentication code (MAC)
computed using a key exchanged in the signalling channel. This MAC
provides message integrity and data origin authentication, thus
stopping an attacker from forging or modifying connectivity check
messages.
STUNのSTUN bind request/responseによるPeer同士のconnectivity checkのセキュリティ。
xmppの方で交換した鍵を使って暗号化する
More fundamentally, however, the prioritization
defined by this specification may not yield “optimal” results. As an
example, if the aim is to select low latency media paths, usage of a
relay is a hint that latencies may be higher, but it is nothing more
than a hint. An actual RTT measurement could be made, and it might
demonstrate that a pair with lower priority is actually better than
one with higher priority.
Peer同士の接続候補の選択方法はこの仕様で定められている優先順位が最善とは限らない。
RTTを計測したらリレーサーバを通した方が速いってこともありえるしねー
- Example
ってのがある！これだけ読めばいいかも。
STUN Bind RequestのSDP表現はこんな
v=0
o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1
s=
c=IN IP4 192.0.2.3
t=0 0
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
m=audio 45664 RTP/AVP 0
b=RS:0
b=RR:0
a=rtpmap:0 PCMU/8000
a=candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host
a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr 10.0.1.1 rport 8998
これをXMPPにマッピングしなおすと
ここにあるtransportになりそう
The transport negotiation process is defined in the Protocol Description section of this document.
よし！
まずは
5.2 Transport Initiation
[xml]
[ … ]
pwd=‘asd88fgpdd777uzjYhagZg’
ufrag=‘8hhy’/>
[/xml]
pwdとufragはICE-COREに仕様がある
The ice-ufrag and ice-pwd attributes MUST be chosen randomly at the beginning of a session.
This attribute is used with Interactive Connectivity Establishment (ICE), and provides the password used to protect STUN connectivity checks.
お互いのクライアントがセッション初期化時に作成する
これはufrag:ユーザー、pwd:パスワードに相当していて、
後でSTUN Bind Request/Responseで使う。
レスポンス
[xml]
この後ICE transportのnegotiationを行う。
STUN Bind RequestをSTUNサーバにして、自分の候補（IPとポートの組み合わせ）をそろえる。
そろったら、こんな
[xml]
pwd=‘asd88fgpdd777uzjYhagZg’
ufrag=‘8hhy’>
[/xml]
[xml]
[/xml]
レスポンスを返す。
同時にjulietからも候補を
送信者（romeo）がjulietの候補を受け取ったら、
P2Pで接続チェックをする。
STUN Binding Request/Responseを送りあって、複数もってる候補のうち、優先度順にどれがつながるかチェックしていく。
送信者のSTUN Binding RequestにはICE-CONTROLLING属性をつけ、
受信者のにはICE-CONTROLLED属性をつける。
STUN short term credentialsを使用し、セッション初期化時のice-ufrag, ice-pwdを使用してXMPPでXMPPサーバ経由でやってるやり取りとP2Pのやり取りを結びつける。
お互い接続を確立したら受信側から送信側へ、候補を受け入れるよって通知する。
[xml]Example 6. Responder sends candidates
pwd=‘YH75Fviy6338Vbrhrlp8Yh’
ufrag=‘9uB6’>
[/xml]
[xml]
[/xml]
一度成功したnegotiationを変更したり新規に新しいIPやnicができたからって候補を追加することもできるみたい。
とりあえず正常系の雰囲気はつかめた気がする。
次は、libjingle動かしてみるか、自前で小さなテストアプリつくってみるか。