Compress SDP messages

[feross]

SDP message compression can significantly lighten the load on the webtorrent tracker and dht by making the signaling messages much smaller. This could be done by giving each peer a common dictionary of frequently-occurring strings that can be referenced to compose a complete SDP message.

[feross]

Update: Wow! There's actually an RFC for this already https://www.rfc-editor.org/rfc/rfc3485.txt And it appears there's some mechanism for updating the dictionary that two peers share based on real-world data. This might be overkill since peers only exchange two signaling messages in webtorrent.

Also, this feature would help the webtorrent tracker server scale a lot better by making the messages it has to pass around a lot smaller. Relevant for #145

[piranna]

Update: Wow! There's actually an RFC for this already
https://www.rfc-editor.org/rfc/rfc3485.txt And it appears there's some
mechanism for updating the dictionary that two peers share based on
real-world data.

This should be build in an independent package, so other projects could be
able to use it, too.

[feross]

Yep, of course. 👍

[feross]

In addition to implementing some sort of SDP compression, we should first eliminate the audio lines that are currently being unnecessarily included.

Current example:

v=0
o=- 5292042953471465513 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio data
a=msid-semantic: WMS
m=audio 56990 RTP/SAVPF 111 103 104 0 8 106 105 13 126
c=IN IP4 172.56.6.183
a=rtcp:56990 IN IP4 172.56.6.183
a=candidate:328666875 1 udp 2122260223 172.20.10.2 63412 typ host generation 0
a=candidate:328666875 2 udp 2122260223 172.20.10.2 63412 typ host generation 0
a=candidate:1561653771 1 tcp 1518280447 172.20.10.2 0 typ host tcptype active generation 0
a=candidate:1561653771 2 tcp 1518280447 172.20.10.2 0 typ host tcptype active generation 0
a=candidate:3133702446 1 udp 1686052607 172.56.6.183 56990 typ srflx raddr 172.20.10.2 rport 63412 generation 0
a=candidate:3133702446 2 udp 1686052607 172.56.6.183 56990 typ srflx raddr 172.20.10.2 rport 63412 generation 0
a=ice-ufrag:RKPpHpp/HtlVDiwY
a=ice-pwd:P9OLI9JiBmOYHwmTIhMLXJBW
a=ice-options:google-ice
a=fingerprint:sha-256 86:2A:46:8E:5B:1E:C6:CD:27:FD:11:FF:6F:6A:74:9E:A9:12:9A:D0:36:90:64:D1:F6:D9:1D:E7:2E:8F:58:BF
a=setup:actpass
a=mid:audio
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=recvonly
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
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
a=maxptime:60
m=application 56990 DTLS/SCTP 5000
c=IN IP4 172.56.6.183
a=candidate:328666875 1 udp 2122260223 172.20.10.2 63412 typ host generation 0
a=candidate:1561653771 1 tcp 1518280447 172.20.10.2 0 typ host tcptype active generation 0
a=candidate:3133702446 1 udp 1686052607 172.56.6.183 56990 typ srflx raddr 172.20.10.2 rport 63412 generation 0
a=ice-ufrag:RKPpHpp/HtlVDiwY
a=ice-pwd:P9OLI9JiBmOYHwmTIhMLXJBW
a=ice-options:google-ice
a=fingerprint:sha-256 86:2A:46:8E:5B:1E:C6:CD:27:FD:11:FF:6F:6A:74:9E:A9:12:9A:D0:36:90:64:D1:F6:D9:1D:E7:2E:8F:58:BF
a=setup:actpass
a=mid:data
a=sctpmap:5000 webrtc-datachannel 1024

Should look something like:

v=0
o=- 5292042953471465513 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE data
a=msid-semantic: WMS
m=application 56990 DTLS/SCTP 5000
c=IN IP4 172.56.6.183
a=candidate:328666875 1 udp 2122260223 172.20.10.2 63412 typ host generation 0
a=candidate:1561653771 1 tcp 1518280447 172.20.10.2 0 typ host tcptype active generation 0
a=candidate:3133702446 1 udp 1686052607 172.56.6.183 56990 typ srflx raddr 172.20.10.2 rport 63412 generation 0
a=ice-ufrag:RKPpHpp/HtlVDiwY
a=ice-pwd:P9OLI9JiBmOYHwmTIhMLXJBW
a=ice-options:google-ice
a=fingerprint:sha-256 86:2A:46:8E:5B:1E:C6:CD:27:FD:11:FF:6F:6A:74:9E:A9:12:9A:D0:36:90:64:D1:F6:D9:1D:E7:2E:8F:58:BF
a=setup:actpass
a=mid:data
a=sctpmap:5000 webrtc-datachannel 1024

[feross]

The unnecessary audio lines have been eliminated from the SDP.

Regarding SDP compression, after some investigation, I decided to punt on SDP compression. It's actually quite tricky to get right with all the variations of SDP and the evolving spec. It's also premature optimization. I'll re-open this when/if the webtorrent tracker starts to experience significant load.

[feross]

For anyone interested, @fippo got this working!

https://twitter.com/HCornflower/status/580623559019638784
http://code.gar.zone/?gist=c85814f9a1ffec5340e8

[fippo]

note that delivering the answer in near-realtime (<10s) is pretty critical. Updated version soon probably, found a couple of issues.

[feross]

Why is it necessary to deliver the answer in near-realtime?

On Thu, Mar 26, 2015 at 5:44 PM Philipp Hancke notifications@github.com
wrote:

note that delivering the answer in near-realtime (<10s) is pretty
critical. Updated version soon probably, found a couple of issues.

—
Reply to this email directly or view it on GitHub
#148 (comment).

[fippo]

for crazy complicated annoying reasons :-)

there is a 30s timeout on ice checks from the answerer. And since TURN is involved, there are additional complications and round-trips involved. Still debating whether there is a bug, too...

[feross]

More info here: https://webrtchacks.com/the-minimum-viable-sdp/

[substack]

and soon: an npm package fippo/minimal-webrtc#2

[gauravsaini]

This is exciting 👍

[feross]

Published as sdp-minimizer https://www.npmjs.com/package/sdp-minimizer

[piranna]

Awesome! :-D

[feross]

Now that there's a nice module for this, let's try using it for WebTorrent.