1.
SDP for WebRTC
- 時間の許す限りSDPについて話したい-
2016/5/17
WebRTC Meetup Tokyo #10
@iwashi86
1

2.
2
■名前
岩瀬 義昌 / @iwashi86
■仕事
SkyWayの中の⼈

3.
3

4.
4
この資料の詳細版です

5.
5https://www.flickr.com/photos/ruocaled/6330547994/in/photolist-aDpHnd-uV5JU-6fGd11-92aD3K-5sVuDT-5sZTLb-oe8i3v-9PSir6-e1iS9J-71kgs1-deaJz-dQiF-8QwgQ9-71kg2d-9H1tBA-jQecJ-5YxwD8-jQe8Y-jQe7w-955g33-dM57UT-bsWCeP-vqJ58-8BrM4s-4Yfh8F-65iwAC-5Xs927- jQeaN-
6qwcft-5uwaKr-8hH2KW-77ASRb-2dzhRA-DW9Gj-8yotoc-5RWNp6-dxHMM-4vzHef-6N43J-5mt6za-QtzaD-aEyat-t9aiK-8FucQQ-5piAH6-bLYPik-hhyaMb-77tbL6-dsCk7i-8Qtaii

6.
6https://www.flickr.com/photos/ruocaled/6330547994/in/photolist-aDpHnd-uV5JU-6fGd11-92aD3K-5sVuDT-5sZTLb-oe8i3v-9PSir6-e1iS9J-71kgs1-deaJz-dQiF-8QwgQ9-71kg2d-9H1tBA-jQecJ-5YxwD8-jQe8Y-jQe7w-955g33-dM57UT-bsWCeP-vqJ58-8BrM4s-4Yfh8F-65iwAC-5Xs927- jQeaN-
6qwcft-5uwaKr-8hH2KW-77ASRb-2dzhRA-DW9Gj-8yotoc-5RWNp6-dxHMM-4vzHef-6N43J-5mt6za-QtzaD-aEyat-t9aiK-8FucQQ-5piAH6-bLYPik-hhyaMb-77tbL6-dsCk7i-8Qtaii
今日のゴール
SDPをおかずに、ご飯が食べられる

7.
7https://www.flickr.com/photos/ruocaled/6330547994/in/photolist-aDpHnd-uV5JU-6fGd11-92aD3K-5sVuDT-5sZTLb-oe8i3v-9PSir6-e1iS9J-71kgs1-deaJz-dQiF-8QwgQ9-71kg2d-9H1tBA-jQecJ-5YxwD8-jQe8Y-jQe7w-955g33-dM57UT-bsWCeP-vqJ58-8BrM4s-4Yfh8F-65iwAC-5Xs927- jQeaN-
6qwcft-5uwaKr-8hH2KW-77ASRb-2dzhRA-DW9Gj-8yotoc-5RWNp6-dxHMM-4vzHef-6N43J-5mt6za-QtzaD-aEyat-t9aiK-8FucQQ-5piAH6-bLYPik-hhyaMb-77tbL6-dsCk7i-8Qtaii
今日のゴール
SDPをおかずに、ご飯が食べられる
というのはハードルが高すぎるので
SDPとは何か、ざっくり説明できるようになる
以降は真面目に技術トーク

8.
8
先に未来のWebRTCの話

9.
9

10.
10

11.
11
結局 SDP は重要であり
SDPを自由に操作できれば
なんでもできる

12.
12
結局 SDP は重要であり
SDPを自由に操作できれば
なんでもできる
と、思いきや…

13.
13
https://webrtcstandards.info/end-of-sdp-in-webrtc/
IETFでSDP修正禁止の方向へ
補足：
禁止しても良い理由は、
SDP修正が必要な操作については、APIが提供されるから

14.
14
https://webrtcstandards.info/end-of-sdp-in-webrtc/
IETFでSDP修正禁止の方向へ
あれ？SDPいらなくね？
補足：
禁止しても良い理由は、
SDP修正が必要な操作については、APIが提供されるから

15.
15
https://www.flickr.com/photos/sophotow/16559284088/in/photolist-rehEf5-5QNDcr-8UcSNJ-4saSBE-bfXD7Z-5QNDck-aeGSsg-pHMoKD-q1d6GF-pHMstF-pHQWKH-Je31q-q1kTBQ-po5LLm-pZ7sL9-wikMVv-chr4iL-byeHcQ-5Qkbca-oxpB23-5QNDcc-aCJZrf-5Qkbck-qGnKZL-p4qxdq-aNSvqx-p4qyr7-8vvXRV-Ht8dT-8vw7nz-2JrZ6v-q13iri-p81asa-pY7w2h-
q13uf2-AjSb7-5Km7rg-oxp2v6-5QDnfL-5QDfE5-pY7uo7-oPBH9B-62UP3c-iU4rN-nv4Akh-94WB5G-pHR2xZ-aeKutf-q1d2Wp-3bJSQe
SDPにはWebRTCの
通信の仕組みが隠れている
⇒ 知っといて損はない

16.
16https://www.flickr.com/photos/wiertz/5623695161/in/photolist-9yWUDp-7XP9vv-4HLBnh-4HGkTM-rhMMZM-czoDK5-iMzz1w-VAk5e-a8VgCz-9TdxYo-7xNfxe-a9yVr2-7uVjRt-64caum-5RhAS8-6ieMFs-7wJug3-4krww7-ziHtN-94TckU-95gMni-dsNyA7-9QFc5i-afgCC-4pMD7r-pzFUXQ-8cpErK-
7XShKc-9PSLHY-rpeMXX-6aK1Mh-8BZaLz-8nXSkK-pFVyMb-2nFrFL-rFAsRz-5ruR2k-b7w2vv-86AAki-9tMnHg-D8Bar-n4XLG-99D3ju-6aK1yo-4k5hdy-rfGy2W-4HGjhz-4tiWnr-euELfc-qJFZHN
先に注
SDPを取り巻く仕様は量が多すぎるので
ポイントを絞って解説
なるべく原典のドキュメント(RFC番号)は
併記するので、最後はご自身で！

17.
17
SDPの前に
オファーアンサーとは？

18.
柔軟にメディア疎通するためには
通信条件のネゴシエーションが必要
18
昔々
条件が一緒なので
ネゴシエーション不要
Aが使える Aが使える
通信条件は簡単には変えられない…

19.
柔軟にメディア疎通するためには
通信条件のネゴシエーションが必要
19
昔々
最近
条件が一緒なので
ネゴシエーション不要
Aが使える Aが使える
VP8とH264
が使える
VP8だけ
使える
VP8とH264が使えるよ、と申し出る
VP8だけ使えるよ、と答える
ネゴシエーションで柔軟に通信条件を変更できる！
通信条件は簡単には変えられない…

20.
このようなモデルを
オファーアンサーモデル(RFC 3264)と呼ぶ
20
VP8とH264が使えるよ、と申し出る
VP8だけ使えるよ、と答える
オファー(Offer)
アンサー(Answer)
Agent
(Offerer)
Agent
(Answerer)
メディア(音声・映像・データ)

21.
SDPはオファー(Offer)とアンサー(Answer)の
記述方法（RFC4566の表現形式）
21
VP8とH264が使えるよ、と申し出る
VP8だけ使えるよ、と答える
オファー(Offer)
アンサー(Answer)
Agent
(Offerer)
Agent
(Answerer)
メディア(音声・映像・データ)
＜SDPの例＞
v=0
o=- 7919192553830045546 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE video
a=msid-semantic: WMS IJaEuKH4cYDg9YxONEt16knZtoFuZZ4ioQRq
m=video 51986 RTP/SAVPF 100 116 117 96
c=IN IP4 192.168.123.1
a=rtcp:51986 IN IP4 192.168.123.1
a=candidate:964645231 1 udp 2122260223
（略）

22.
オファーアンサー(O/A)モデルには
セッション(親) と メディア(子) の概念がある
22
Agent
(Offerer)
Agent
(Answerer)
セッション
(複数のメディアを含む総体)
音声メディア
映像メディア
データメディア
補足：メディアとは、実際の音声ストリームデータ等を指す

23.
そのためSDPにも
①セッション記述部 と ②メディア記述部 がある
23
v=0
o=mozilla...THIS_IS_SDPARTA-37.0 256835513207089710 0 IN IP4 0.0.0.0
s=-
t=0 0
以下、略
m=audio 59540 RTP/SAVPF 109 9 0
以下、略
①セッション記述部
②メディア記述部

24.
24
SDPの基本

25.
25
SDPの文法則
• <type>=<value>で規定する
例：v=0
• <type>=<value>に余計な空白文字を含めてはいけない
例：`v = 0` はNG
• メッセージ中にあらわれる行の出現順序は
厳密に規定されている（例： v, o, s, t)
# この辺を間違えると、SDP Parse Error
補足：実際にはもっとたくさんありますが、重要と考えるのだけ

26.
26
SDPのO/A制約[1]
• m=行の数はオファーとアンサーで
同一になっている必要があること
(Offer)
m=audio
m=video(Camera)
m=video(ScreenShare)
補足：実際にはもっとたくさんありますが、重要と考えるのだけ

27.
27
SDPのO/A制約[1]
• m=行の数はオファーとアンサーで
同一になっている必要があること
(Answer)
m=audio
m=video(Camera)
(無)
(Offer)
m=audio
m=video(Camera)
m=video(ScreenShare)
補足：実際にはもっとたくさんありますが、重要と考えるのだけ

28.
28
SDPのO/A制約[2]
• メディアの登場順序は同一であること
(Answer)
m=audio
m=video(ScreenShare)
m=video(Camera)
(Offer)
m=audio
m=video(Camera)
m=video(ScreenShare)
補足：実際にはもっとたくさんありますが、重要と考えるのだけ

29.
29
SDPを詳しく

30.
①セッション記述部から
30
v=0
o=mozilla...THIS_IS_SDPARTA-37.0 256835513207089710 0 IN IP4 0.0.0.0
s=-
t=0 0
以下、略
m=audio 59540 RTP/SAVPF 109 9 0
以下、略
①セッション記述部
②メディア記述部
以降、
Chrome利用者のが多い気がするので、ChromeのSDPで説明します。
SDPは以下のサイトにて、Chrome v50 で作成したものです。
https://webrtc.github.io/samples/src/content/peerconnection/munge-sdp/

31.
31
v=0
o=- 3471158663735344000 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLEaudio video data
a=msid-semantic: WMS QWrTC0fFpuTPjbHgxCZwj4peXYLEib2RnaJu
SDPエリア
解説エリア
先に凡例

32.
32
v=0
o=- 3471158663735344000 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLEaudio video data
a=msid-semantic: WMS QWrTC0fFpuTPjbHgxCZwj4peXYLEib2RnaJu
・SDPのバージョン
・RFC4566より 0 固定

33.
33
v=0
o=- 3471158663735344000 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLEaudio video data
a=msid-semantic: WMS QWrTC0fFpuTPjbHgxCZwj4peXYLEib2RnaJu
・Originの略
・o=<username> <sess-id> <sess-version>
<nettype> <addrtype> <unicast-address>
・知っておいた方が良いのは、<sess-id>。
他のセッションとの識別のために利用されている。
一意であれば良いので、クライアントによって値が全然違う。

34.
34
v=0
o=- 3471158663735344000 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLEaudio video data
a=msid-semantic: WMS QWrTC0fFpuTPjbHgxCZwj4peXYLEib2RnaJu
・Session nameのこと
・`-` しか設定されないので説明略

35.
35
v=0
o=- 3471158663735344000 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLEaudio video data
a=msid-semantic: WMS QWrTC0fFpuTPjbHgxCZwj4peXYLEib2RnaJu
・start-time と stop-time
・RFC4566にて両方とも0を指定と規定

36.
36
v=0
o=- 3471158663735344000 2 IN IP4 127.0.0.1
s=-
t=0 0
(書かれてないもの)
a=group:BUNDLEaudio video data
a=msid-semantic: WMS QWrTC0fFpuTPjbHgxCZwj4peXYLEib2RnaJu
・SDP自体(RFC4566)に規定されている
i= / u= / e= / p= / r= / z=
などはWebRTCで利用しないので省略

37.
37
v=0
o=- 3471158663735344000 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLEaudio video data
a=msid-semantic: WMS QWrTC0fFpuTPjbHgxCZwj4peXYLEib2RnaJu
・a=XX は全て拡張属性
・a=groupはRFC5888で定義される
・もともとLipSyncなどをグルーピングする仕様
・後ろに出てくるaudio/video/data などは、
メディア記述部で、 a=mid:audio とリンク
・WebRTCでは…

38.
38
v=0
o=- 3471158663735344000 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLEaudio video data
a=msid-semantic: WMS QWrTC0fFpuTPjbHgxCZwj4peXYLEib2RnaJu
・WebRTCでは、a=group(RFC5888)を拡張してBUNDLEを定義し
audio/video/dateを1つに多重化して利用している
・少しでも利用するポート数を減らして、
効率的に通信するのがWebRTCのやり方
詳細はコチラ：
https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-29

39.
39
v=0
o=- 3471158663735344000 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLEaudio video data
a=msid-semantic: WMS QWrTC0fFpuTPjbHgxCZwj4peXYLEib2RnaJu
・やや古い記法なので、あまり真面目に覚えなくてOK
(Chromeにまだあるが、いつか変わるはず）
・一応補足すると・・・
a=msid:XX を新たに定義して、WMS(WebRTC Media Stream)
で利用するという意味。WMSを指定してWebRTCであることを
明示していたが、どうせWebRTCしか使わないので、意味薄。
https://tools.ietf.org/html/draft-ietf-mmusic-msid-12

40.
②メディア記述部
40
v=0
o=mozilla...THIS_IS_SDPARTA-37.0 256835513207089710 0 IN IP4 0.0.0.0
s=-
t=0 0
以下、略
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 126
(略)
m=video 9 UDP/TLS/RTP/SAVPF 100 101 116 117 96 97 98
(略)
m=application 9 DTLS/SCTP 5000
①セッション記述部
②メディア記述部

41.
②メディア記述部
41
v=0
o=mozilla...THIS_IS_SDPARTA-37.0 256835513207089710 0 IN IP4 0.0.0.0
s=-
t=0 0
以下、略
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 126
…
①セッション記述部
②メディア記述部
以降ではAudioのみ説明
∵videoやapplicationは、audioが読めれば分かるため。
どうしても読むのが難しい内容だけ、最後に補足。

42.
42
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 126
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:47rxaO74RBacCqx3
a=ice-pwd:QlFMPNexQW+NgXV3G2f1DBbe
a=fingerprint:sha-256
23:E7:A4:A2:CA:49:81:36:CA:08:50:27:71:5B:76:FD:61:A9:1A:30:38:27:75:BC:D7:8B:
21:EC:AC:20:3E:83
a=setup:actpass
・m=audioで音声通信をすることを意味
・続く「9」は、本来ポート番号を書く欄であるが
TrickleICEでは「9」を設定する
https://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-02
・UDP/TLS/RTP/SAVPFはproto指定だが、
ひとまずおまじないと考えておいて良い
https://tools.ietf.org/html/rfc5764

43.
43
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 126
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:47rxaO74RBacCqx3
a=ice-pwd:QlFMPNexQW+NgXV3G2f1DBbe
a=fingerprint:sha-256
23:E7:A4:A2:CA:49:81:36:CA:08:50:27:71:5B:76:FD:61:A9:1A:30:38:27:75:BC:D7:8B:
21:EC:AC:20:3E:83
a=setup:actpass
・続く111~126はペイロードタイプであり、a=rtpmap:XX とリンク
・説明はrtpmap:XXが出てきたときに実施
・ポイントは、この順序が左側にあるほど優先度が高い点
（数字の大小は、優先度に関係無い点に注意）

44.
44
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 126
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:47rxaO74RBacCqx3
a=ice-pwd:QlFMPNexQW+NgXV3G2f1DBbe
a=fingerprint:sha-256
23:E7:A4:A2:CA:49:81:36:CA:08:50:27:71:5B:76:FD:61:A9:1A:30:38:27:75:BC:D7:8B:
21:EC:AC:20:3E:83
a=setup:actpass
・c=IN IP4 0.0.0.0
はコンタクトアドレス（メディアの送り先のIPアドレス）を書く行
・IN = Internet の IPv4 の 0.0.0.0 のアドレスという意味だが、
アドレスから分かるようにSDP上の値は暫定値
・実際のアドレスは、TrickleICEで取得されるため

45.
45
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 126
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:47rxaO74RBacCqx3
a=ice-pwd:QlFMPNexQW+NgXV3G2f1DBbe
a=fingerprint:sha-256
23:E7:A4:A2:CA:49:81:36:CA:08:50:27:71:5B:76:FD:61:A9:1A:30:38:27:75:BC:D7:8B:
21:EC:AC:20:3E:83
a=setup:actpass
・rtcp とあることから分かるように、RTCP向けの情報であり、
前行の c= と、ほぼ同じ形式になっている
・RTCPは、RTPと多重化するのであまり意識する必要はない
・読み方は c= と一緒
・rtcp:9 の9は、TrickleICE用のdummyポート

46.
46
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 126
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:47rxaO74RBacCqx3
a=ice-pwd:QlFMPNexQW+NgXV3G2f1DBbe
a=fingerprint:sha-256
23:E7:A4:A2:CA:49:81:36:CA:08:50:27:71:5B:76:FD:61:A9:1A:30:38:27:75:BC:D7:8B:
21:EC:AC:20:3E:83
a=setup:actpass
・ice-ufragは ICE Username Fragmentの略
・Fragmentの意味は破片であり、ICEでは通信するペア同士の
ufragを結合して、ユーザネームを作成する
・ice-pwdはICE Passwordの略で、ufragと併せて、
STUN Short-term credentialの仕組みで利用する
(short-term credentialは、短期的な通信相手同士の認証というイメージ)

47.
47
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 126
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:47rxaO74RBacCqx3
a=ice-pwd:QlFMPNexQW+NgXV3G2f1DBbe
a=fingerprint:sha-256
23:E7:A4:A2:CA:49:81:36:CA:08:50:27:71:5B:76:FD:61:A9:1A:30:38:27:75:BC:D7:8B:
21:EC:AC:20:3E:83
a=setup:actpass
・DTLSの証明書のfingerprint
・WebRTCでは、ICEによる疎通が成功した後に、
DTLSのハンドシェイクをはじめるが、
その際にCertificateを互いに交換する。
その際のCertificateが正しいかどうかを確認するために、
このFingerprintを用いる。

48.
48
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 126
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:47rxaO74RBacCqx3
a=ice-pwd:QlFMPNexQW+NgXV3G2f1DBbe
a=fingerprint:sha-256
23:E7:A4:A2:CA:49:81:36:CA:08:50:27:71:5B:76:FD:61:A9:1A:30:38:27:75:BC:D7:8B:
21:EC:AC:20:3E:83
a=setup:actpass
・どちらがtcpコネクション確立を開始するかどうか規定
・actpassはコネクションを待ち受けてもいいし、
自ら始めても良いという意味
・offer側がactpassを設定するように、使用で定義されている
https://tools.ietf.org/html/rfc5763#section-5

49.
49
(セッション記述部)
a=group:BUNDLEaudio video data
~~~略~~~
(メディア記述部)
a=mid:audio
・midは media stream identification のこと
https://tools.ietf.org/html/rfc5888
・SDPのどの部分とメディアが対応できるか識別できる
・上記の例では、
a=mid:audioが含まれるm=行ブロックを
BUNDLE対象に指定しているという意味

50.
50
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=sendrecv
a=rtcp-mux
・RTPヘッダの拡張として、
音声のレベルをRTP拡張ヘッダに付けて送るという意味
https://tools.ietf.org/html/rfc6464

51.
51
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=sendrecv
a=rtcp-mux
・パケットをワイヤ上(通信経路上)に、
送り出した時間をRTPヘッダ拡張に付与するという意味

52.
52
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=sendrecv
a=rtcp-mux
・方向属性を意味していて、全部で4種類ある
・sendrecv：送受信両方
・sendonly：送信のみ
・recvonly：受信のみ
・inactive：何もしない
・今回は、送受信両方しますという意味。
配信系のユースケースとかだと、*onlyを多用することになる。

53.
53
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=sendrecv
a=rtcp-mux
・rtpとrtcpを多重化するという意味
https://tools.ietf.org/html/rfc5761
・BUNDLE同様に少しでも利用するポート数を減らして、
効率的に通信するのがWebRTCのやり方

54.
54
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 126
~~~略~~~
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10; useinbandfec=1
・m=行で説明を割愛したペイロードタイプの番号は、
a=rtpmapなどの項目にリンクしてくる
・やっていることは、111番で利用するコーデックや
その他オプションの指定

55.
55
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 126
~~~略~~~
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10; useinbandfec=1
・opusというコーデック・48000hz・2ch という意味

56.
56
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 126
~~~略~~~
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10; useinbandfec=1
・トランスポート全体での輻輳制御向けの拡張
https://tools.ietf.org/html/draft-holmer-rmcat-transport-wide-cc-extensions-01

57.
57
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 126
~~~略~~~
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10; useinbandfec=1
・minptimeというのは、音声をパケット化するときの
最小のミリ秒の数値。この例は最小10ミリ秒でパケットを作成
・useinbandfecは1の場合は、インバンド(RTPのストリーム内で
実施という意味なはず)でFECを提供

58.
58
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 126
~~~略~~~
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:126 telephone-event/8000
・opus以降の詳細説明は割愛
・覚えておくと良いのは、0-95まではスタティックペイロードで
96-127までがダイナミックペイロードということ
・例えば、黒電話でも使われる PCMU は0番と決まっている。

59.
59
a=ssrc:1665280581 cname:/6cn4x08FotE9GHG
a=ssrc:1665280581 msid:QWrTC0fFpuTPjbHgxCZwj4peXYLEib2RnaJu ed198241-
0a4f-4bd0-a254-ae5d8fefb928
a=ssrc:1665280581 mslabel:QWrTC0fFpuTPjbHgxCZwj4peXYLEib2RnaJu
a=ssrc:1665280581 label:ed198241-0a4f-4bd0-a254-ae5d8fefb928
・PlanBという古い記法であり、将来的にはUnifiedPlanという
記法に変更になる
・記法というよりは、中に記載されている内容を理解すべき

60.
60
a=ssrc:1665280581 cname:/6cn4x08FotE9GHG
a=ssrc:1665280581 msid:QWrTC0fFpuTPjbHgxCZwj4peXYLEib2RnaJu ed198241-
0a4f-4bd0-a254-ae5d8fefb928
a=ssrc:1665280581 mslabel:QWrTC0fFpuTPjbHgxCZwj4peXYLEib2RnaJu
a=ssrc:1665280581 label:ed198241-0a4f-4bd0-a254-ae5d8fefb928
・SSRCは、Synchronization Source Identifier のことで、
要は、メディアストリームを一意に識別するためのもの
・msidは、MediaStream Identificationのことで、
JavaScript上から見えるメディアストリームのIDと
紐付けするためのもの

61.
61
SDPの落ち穂拾い

62.
m=videoをちょっと補足
62
v=0
o=mozilla...THIS_IS_SDPARTA-37.0 256835513207089710 0 IN IP4 0.0.0.0
s=-
t=0 0
以下、略
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 126
(略)
m=video 9 UDP/TLS/RTP/SAVPF 100 101 116 117 96 97 98
(略)
m=application 9 DTLS/SCTP 5000
①セッション記述部
②メディア記述部

63.
63
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccmfir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=rtcp-fb:100 goog-remb
a=rtcp-fb:100 transport-cc
a=rtpmap:101 VP9/90000
a=rtcp-fb:101 ccmfir
a=rtcp-fb:101 nack
a=rtcp-fb:101 nack pli
a=rtcp-fb:101 goog-remb
a=rtcp-fb:101 transport-cc
a=rtpmap:116 red/90000
・ビデオもコーデックが多く存在
・注目すべきは、VP8とVP9がStableで標準サポートされている点
・VP8はNW帯域を多く使うが、CPU消費は小さめ
・VP9はNW帯域を少なく使うが、CPU消費は多め

64.
64
a=ssrc-group:FID 3668517244 500761633
a=ssrc:3668517244 cname:/6cn4x08FotE9GHG
a=ssrc:3668517244 msid:QWrTC0fFpuTPjbHgxCZwj4peXYLEib2RnaJu eb062ea9-8ed0-49ca-b878-
db2f27ebd99d
a=ssrc:3668517244 mslabel:QWrTC0fFpuTPjbHgxCZwj4peXYLEib2RnaJu
a=ssrc:3668517244 label:eb062ea9-8ed0-49ca-b878-db2f27ebd99d
a=ssrc:500761633 cname:/6cn4x08FotE9GHG
a=ssrc:500761633 msid:QWrTC0fFpuTPjbHgxCZwj4peXYLEib2RnaJu eb062ea9-8ed0-49ca-b878-
db2f27ebd99d
a=ssrc:500761633 mslabel:QWrTC0fFpuTPjbHgxCZwj4peXYLEib2RnaJu
a=ssrc:500761633 label:eb062ea9-8ed0-49ca-b878-db2f27ebd99d
・ChromeではMultiStreamを指定しなくても、
Videoで複数SSRCが流れる
・この2つ目のストリームはRTX（再送ストリーム）
http://www.ietf.org/rfc/rfc4588.txt

65.
65
m=audio 9 …
b=AS:50
・Chromeが自律的に生成するわけではないが、
通信帯域幅をビットレートで指定可能
・b=ASは略さずに意味を書くと、
bandwidth = Application Specific: XX
という記法であり、XXにビットレートが書く

66.
今日省略したICEについては↓のスライド参照
66http://www.slideshare.net/iwashi86/webrtcice

67.
67
まとめ

68.
68https://www.flickr.com/photos/ruocaled/6330547994/in/photolist-aDpHnd-uV5JU-6fGd11-92aD3K-5sVuDT-5sZTLb-oe8i3v-9PSir6-e1iS9J-71kgs1-deaJz-dQiF-8QwgQ9-71kg2d-9H1tBA-jQecJ-5YxwD8-jQe8Y-jQe7w-955g33-dM57UT-bsWCeP-vqJ58-8BrM4s-4Yfh8F-65iwAC-5Xs927- jQeaN-
6qwcft-5uwaKr-8hH2KW-77ASRb-2dzhRA-DW9Gj-8yotoc-5RWNp6-dxHMM-4vzHef-6N43J-5mt6za-QtzaD-aEyat-t9aiK-8FucQQ-5piAH6-bLYPik-hhyaMb-77tbL6-dsCk7i-8Qtaii
今日のゴール
SDPとは何か
ざっくり 説明できるようになる

69.
69
本日 ご理解いただいたこと
• SDPのO/Aの基本・制約
• SDPの文法則
• Audioを中心としたSDPの読み方
• SDP落ち穂拾い

70.
70
本日 ご理解いただいたこと
• SDPのO/Aの基本・制約
• SDPの文法則
• Audioを中心としたSDPの読み方
• SDP落ち穂拾い おしまい！