If you’re new to WebRTC, Jitsi was the first open source Selective Forwarding Unit (SFU) and continues to be one of the most popular WebRTC platforms. They were in the news last week because their parent group inside Atlassian was sold off to Slack but the team clarified this does not have any impact on the Jitsi team. Helping to show they are still chugging along, they released a new feature they wanted to talk about – off-stage layer suspension. This is a technique for minimizing bandwidth and CPU consumption when using simulcast. Simulcast is a common technique used in multi-party video scenarios. See Oscar Divorra’s post on this topic and that Fippo post just last week for more on that. Even if you are not implementing a simulcast, this is a good post for understanding how to control bandwidth and to see some follow-along reverse-engineering on how Google does things in its Hangouts upgrade called Meet.
webrtc-internals
All posts tagged webrtc-internals
webrtcH4cKS: ~ YouTube Does WebRTC – Here’s How
I logged into YouTube on Tuesday and noticed this new camera icon in the upper right corner, with a “Go Live (New)” option, so I clicked on it to try. It turns out you can now live stream directly from the browser. This smelled a lot like WebRTC, so I loaded up chrome://webrtc-internals to see and sure enough, it was WebRTC. We are always curious here to see how large scale deployments are implemented, so I immediately asked WebRTC reverse engineering master Philipp “Fippo” Hancke to investigate deeper. The rest here is his analysis.
webrtcH4cKS: ~ WebRTC Externals – the cross-browser WebRTC debug extension
I am a big fan of Chrome’s webrtc-internals tool. It is one of the most useful debugging tools for WebRTC and when it was added to Chrome back in 2012 it made my life a lot easier. I even wrote a lengthy series of blog post together with Tsahi Levent-Levi describing how to use it to debug issues recently.
Firefox has a similar about:webrtc page which shows the local and remote SDP for each page as well as a very useful grid of ICE candidates. But unlike Chrome it does not show the exact order of API calls or nice graphs obtained from the getStats API. I miss both features dearly. Edge and Safari don’t support similar debugging helpers currently either.
webrtcH4cKS: ~ Dear Slack: why is your WebRTC so weak?
Dear Slack,
There has been quite some buzz this week about you and WebRTC.
WebRTC… kind of. Because actually you only do stuff in Chrome and your native apps:
I’ve been there. Launching stuff only for Chrome. That was is late 2012. In 2016, you need to have a very good excuse to launch something with WebRTC and not support Firefox like this:
Maybe you had your reasons. As usual, I tried to get a dump from chrome://webrtc-internals to see what is going on. Thanks to Dag-Inge Aas for providing one. The most interesting bit is the call to setRemoteDescription:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
type: answer, sdp: v=0 o=- 1242503183783 1242503183783 IN IP4 127.0.0.1 s=Room with no name.. t=0 0 a=group:BUNDLE audio a=msid-semantic: WMS janus m=audio 1 RTP/SAVPF 111 c=IN IP4 10.9.4.95 a=mid:audio a=recvonly a=rtcp-mux a=ice-ufrag:rKmT a=ice-pwd:AOrIm8kDxew5sVNUCQrrmJ a=ice-options:trickle a=fingerprint:sha-256 C5:5F:DA:7D:84:47:B1:BF:6B:55:16:62:48:31:3E:D3:F1:7B:25:89:92:4A:4B:4D:4D:D9:D5:AF:EA:D8:15:44 a=setup:active a=connection:new a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=rtpmap:111 opus/48000/2 a=fmtp:111 minptime=10; useinbandfec=1; usedtx=1 a=candidate:1 1 udp 2013266431 10.9.4.95 12000 typ host a=candidate:2 1 udp 2013266431 172.31.0.190 12000 typ host |
I would like to note that you reply to Chrome’s offer of UDP/TLS/RTP/SAVPF with a profile of RTP/SAVPF. While that is still tolerated by browsers, it is improper.
Your a=msid-semantic line looks very interesting. “WMS janus”. Sounds familiar, this is meetecho’s janus gateway (see Lorenzo’s post on gateways here). Which by the way works fine with Firefox from what I hear.
