Pion spuriously negotiates transport-cc

[jech]

In Galene, I'm explicitly constructing a MediaEngine with just the right parameters. However, Pion is still negotiating transport-cc, even though I didn't enable it in the MediaEngine. More precisely:

• in v3, transport-cc is negotiated in answers but not in offers [edit: this is not split into 2944];
• in v4, transport-cc is negotiated in both offers and answers.

Full test at https://go.dev/play/p/IBH55knGgkb

[kcaffrey]

I think this might be the culprit:

webrtc/api.go

Line 57 in e53cbc4

err := RegisterDefaultInterceptors(a.mediaEngine, a.interceptorRegistry)

If you don't provide an interceptor registry, the default interceptors are used (and transport-cc is included in the default interceptors). It appears like this may have been intentional: 21c5a71

One fix would be to supply an empty interceptor registry if you don't want any interceptors. It is documented on NewAPI(), so I suspect it probably was an intentional behavior change in v4, but @Sean-Der can comment on that.

[Sean-Der]

Thank you so much @kcaffrey that's some great debugging. Completely slipped my mind.

Users complained about the inverse. When they created a SettingEngine they were frustrated that interceptor/mediaengine was empty. So the behavior was changed.

I documented it here but I think it buries the impact. What should I say/would be better do you think @jech ?

[jech]

That would explain the behaviour with v4. But what about the behaviour with v3, where transport-cc is negotiated in the answer but not in the offer? [Edit: this part was split into #2944.]

If you don't provide an interceptor registry, the default interceptors are used (and transport-cc is included in the default interceptors).

[...]

What should I say/would be better do you think @jech ?

My understanding was that simple applications (that want a default set of interceptors) should be using webrtc.NewPeerConnection, but that applications that use api.NewPeerConnection get exactly what they ask for (and should call RegisterDefaultWhatevers if they want reasonable defaults). That's a behaviour that's easy to understand and easy to explain.

If the other behaviour is desired, I can live with it, but it needs to be documented here: https://pkg.go.dev/github.com/pion/webrtc/v4#API.NewPeerConnection

[jech]

I've split the second part of this into #2944, since it appears there is another related bug.

[jech]

Thinking about it some more, I don't dislike the new behaviour. Having webrtc.NewPeerConnection have different semantics from api.NewPeerConnection is uselessly confusing, and applications that want the old behaviour can easily add an empty InterceptorRegistry.