rtpfunnel

RTP funnel is basically like a normal funnel with a few added functionalities to support bundling.

Bundle is the concept of sending multiple streams in a single RTP session. These can be both audio and video streams, and several of both. One of the advantages with bundling is that you can get away with fewer ports for sending and receiving media. Also the RTCP traffic gets more compact if you can report on multiple streams in a single sender/receiver report.

One of the reasons for a specialized RTP funnel is that some messages coming upstream want to find their way back to the right stream, and a normal funnel can't know which of its sinkpads it should send these messages to. The RTP funnel achieves this by keeping track of the SSRC of each stream on its sinkpad, and then uses the fact that upstream events are tagged inside rtpbin with the appropriate SSRC, so that upon receiving such an event, the RTP funnel can do a simple lookup for the right pad to forward the event to.

A good example here is the KeyUnit event. If several video encoders are being bundled together using the RTP funnel, and one of the decoders on the receiving side asks for a KeyUnit, typically a RTCP PLI message will be sent from the receiver to the sender, and this will be transformed into a GstForceKeyUnit event inside GstRTPSession, and sent upstream. The RTP funnel can than make sure that this event hits the right encoder based on the SSRC embedded in the event.

Another feature of the RTP funnel is that it will mux together TWCC (Transport-Wide Congestion Control) sequence-numbers. The point being that it should increment "transport-wide", meaning potentially several bundled streams. Note that not all streams being bundled needs to be affected by this. As an example Google WebRTC will use bundle with audio and video, but will only use TWCC sequence-numbers for the video-stream(s).