Tweet
Tweet

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

3

Slide 4

Slide 4 text

4 この資料の詳細版です

Slide 5

Slide 5 text

5 https://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

Slide 6

Slide 6 text

6 https://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をおかずに、ご飯が食べられる

Slide 7

Slide 7 text

7 https://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とは何か、ざっくり説明できるようになる 以降は真面目に技術トーク

Slide 8

Slide 8 text

8 先に未来のWebRTCの話

Slide 9

Slide 9 text

9

Slide 10

Slide 10 text

10

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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の 通信の仕組みが隠れている ⇒ 知っといて損はない

Slide 16

Slide 16 text

16 https://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番号)は 併記するので、最後はご自身で！

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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 （略）

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

そのため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 以下、略 ①セッション記述部 ②メディア記述部

Slide 24

Slide 24 text

24 SDPの基本

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

29 SDPを詳しく

Slide 30

Slide 30 text

①セッション記述部から 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/

Slide 31

Slide 31 text

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エリア 解説エリア 先に凡例

Slide 32

Slide 32 text

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 固定

Slide 33

Slide 33 text

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= ・知っておいた方が良いのは、。 他のセッションとの識別のために利用されている。 一意であれば良いので、クライアントによって値が全然違う。

Slide 34

Slide 34 text

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のこと ・`-` しか設定されないので説明略

Slide 35

Slide 35 text

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を指定と規定

Slide 36

Slide 36 text

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で利用しないので省略

Slide 37

Slide 37 text

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では…

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

②メディア記述部 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 ①セッション記述部 ②メディア記述部

Slide 41

Slide 41 text

②メディア記述部 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が読めれば分かるため。 どうしても読むのが難しい内容だけ、最後に補足。

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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が出てきたときに実施 ・ポイントは、この順序が左側にあるほど優先度が高い点 （数字の大小は、優先度に関係無い点に注意）

Slide 44

Slide 44 text

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で取得されるため

Slide 45

Slide 45 text

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ポート

Slide 46

Slide 46 text

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は、短期的な通信相手同士の認証というイメージ)

Slide 47

Slide 47 text

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を用いる。

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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対象に指定しているという意味

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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ヘッダ拡張に付与するという意味

Slide 52

Slide 52 text

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を多用することになる。

Slide 53

Slide 53 text

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のやり方

Slide 54

Slide 54 text

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番で利用するコーデックや その他オプションの指定

Slide 55

Slide 55 text

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 という意味

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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を提供

Slide 58

Slide 58 text

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番と決まっている。

Slide 59

Slide 59 text

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という 記法に変更になる ・記法というよりは、中に記載されている内容を理解すべき

Slide 60

Slide 60 text

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と 紐付けするためのもの

Slide 61

Slide 61 text

61 SDPの落ち穂拾い

Slide 62

Slide 62 text

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 ①セッション記述部 ②メディア記述部

Slide 63

Slide 63 text

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消費は多め

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

67 まとめ

Slide 68

Slide 68 text

68 https://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とは何か ざっくり 説明できるようになる

Slide 69

Slide 69 text

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

Slide 70

Slide 70 text

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