What is the reason for the goroutine that reads incoming RTCP packets?

[mstyer]

I'm looking at the code for several of the examples, e.g. reflect, and I see the following code (e.g. lines 96-106 in reflect/main.go):

	// Read incoming RTCP packets
	// Before these packets are returned they are processed by interceptors. For things
	// like NACK this needs to be called.
	go func() {
		rtcpBuf := make([]byte, 1500)
		for {
			if _, _, rtcpErr := rtpSender.Read(rtcpBuf); rtcpErr != nil {
				return
			}
		}
	}()

What is the reason for this? I'm trying to find any docs that would help explain what this is doing and why it's needed, but I'm coming up empty.

My follow-on question is, if I have multiple tracks with mutiple rtpSender objects, I assume I need to do this for all tracks separately. Is that correct?

[Sean-Der]

Hi @mstyer

By calling Read you are giving Pion an opportunity to process and respond to these messages. Pion is generate TWCC Feeback and possibly emitting NACKs.

By design we don't launch any additional threads and allow users to disable these features if they want to use different implementations.

[Sean-Der]

If the Read isn't called the sender of media will not be notified of packet loss/congestion so you will have a worse experience. However many exceptions/behavior differences exist so this doesn't apply in all cases :)

[mstyer]

OK, thanks, that's interesting. Where does Pion define which interceptors are called on Read()?

On your second point, how exactly does Read() notify the sender of packet loss/congestion? Is that also via an interceptor? if so, which one?

[Sean-Der]

The defaults are set in RegisterDefaultInterceptors

Yes that is all done via Interceptors! For congestion twcc you can also use that for packet loss, but most commonly nack