, 23 tweets, 5 min read Read on Twitter
A little thread about how Google accommodates its #WebRTC IETF drafts to its implementation in libwebrtc 👇
Let's talk first about REMB which, among others, defines a RTCP feedback packet that tells the sender the maximum bitrate it can send (based on remote side bandwidth estimation). REMB is a RTCP feedback packet so it needs a sender_ssrc and media_ssrc fields in the packet header.
Since REMB works at transport level (instead of at RTP stream level) its media_ssrc field does not make much sense. The specification [1] (by Google) says:
-----------------------------
SSRC of media source (32 bits): Always 0; this is the same convention as in RFC5104 section 4.2.2.2 (TMMBN).
-----------------------------

[1] tools.ietf.org/html/draft-alv…
Then let's talk about Transport-wide Congestion Control which, among others, defines a RTCP feedback packet that helps the sender estimate its uplink bandwidth in client side. Similar to REMB, Transport-CC RTCP feedback packets need sender_ssrc and media_ssrc fields.
And again, being transport level (instead of RTP stream level) the media_ssrc field does not make much sense. The specification [2] (by Google) says:
-----------------------------
SSRC of media source: 32 bits The synchronization source identifier of the media source that this piece of feedback
-----------------------------

[2] tools.ietf.org/html/draft-hol…
Oh, you see? It does not say "Always 0". It may say it perfectly (as it does in REMB) but it does not. Instead it keeps the generic definition of "SSRC of media source" in "Extended RTP Profile for RTCP" specification [3]:

🤔
-----------------------------
SSRC of media source: 32 bits The synchronization source identifier of the media source that this piece of feedback information is related to.
-----------------------------

[3] tools.ietf.org/html/rfc4585#s…
OK, now let's go to the Google's implementation, this is: libwebrtc (sorry, I'll never name it "webrtc").
Let's inspect the rtcp_receiver.cc module [4] which defines the RTCPReceiver class (let's focus on libwebrtc M77):

[4] webrtc.googlesource.com/src/+/refs/bra…
BTW all RTP senders and RTP receivers hold their own RTCPReceiver instance. By design, all received RTCP packets are delivered to *all* RTP senders and RTP receivers (this should give us a clue about a flaw in the libwebrtc design).
So let's assume we are sending audio, video and screen sharing (so a separate video) over the same tuple (BUNDLE on).

😀😀😀
Let's imagine our PeerConnection receibes a REMB feedback packet. It delivers it to all our RTP senders (there are 3). Let's see what rtcp_receiver.cc does:

webrtc.googlesource.com/src/+/refs/bra…
Later, it calls TriggerCallbacksFromRtcpPacket():

webrtc.googlesource.com/src/+/refs/bra…

As you can see, the media_ssrc of the REMB packet is NOT inspected at all! 😊✌️
Now let's imagine our PeerConnection receives a Transport-CC feedback packet. It's also delivered to all our RTP senders:

webrtc.googlesource.com/src/+/refs/bra…
Later, it calls TriggerCallbacksFromRtcpPacket():

webrtc.googlesource.com/src/+/refs/bra…

Oh... here the media_ssrc of the RTCP feedback packet is inspected and matches with the media ssrcs in each RTP sender! 😨
How is this? by looking closely to the code and, since all RTP senders receive all RTCP packets, the first one that processes this Transport-CC feedback will handle it in a way that other RTP senders will not find information into it (so it's processed just once). But remember...
The Transport-CC feedback packet MUST have a media_ssrc that matches, at least, with the sending SSRC of *any* of our RTP senders!!! 😵😵😵

Cool? No.
In summary: the internal design of libwebrtc conditionates the specs that Google writes. Is this good? No, it's not. 😡

Special caution if you are writing your own WebRTC stack and producing your own REMB and Transport-CC feedback packets. You cannot "just" read the specs.
BTW the "Transport-wide Congestion Control" draft has just two versions and the latest one was written in 2015. I see zero love here and I'm afraid that reading Google drafts is of little value if you do not *also* check *their* implementation.

No. This is not good.
*matched
An endpoint generating Transport Feedback packets is supposed to read the wide-seq-number RTP header extension in received packets of *different* streams (so different SSRCs). Which one should it add as media_ssrc into the feedback packet?

Solution: any, if posible the last one.
Missing some Tweet in this thread?
You can try to force a refresh.

Like this thread? Get email updates or save it to PDF!

Subscribe to Iñaki Baz Castillo
Profile picture

Get real-time email alerts when new unrolls are available from this author!

This content may be removed anytime!

Twitter may remove this content at anytime, convert it as a PDF, save and print for later use!

Try unrolling a thread yourself!

how to unroll video

1) Follow Thread Reader App on Twitter so you can easily mention us!

2) Go to a Twitter thread (series of Tweets by the same owner) and mention us with a keyword "unroll" @threadreaderapp unroll

You can practice here first or read more on our help page!

Follow Us on Twitter!

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just three indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3.00/month or $30.00/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!