AddTransceiverFromTrack and AddTrack don't set the codec preferences

[jech]

When adding a local track to a PC, the created transceiver's codec preferences stay at the default. The result is that the peer might negotiate a codec that is different from the one of the track, which yields to silent failures (as opposed to a clean failure at negotiation time).

I've worked around the issue with the following code:

https://github.com/jech/galene/blob/master/rtpconn/webclient.go#L392

I volunteer to submit a PR that applies the restriction within AddTransceiverFromTrack, but I need to know if that's the right place to do it.

[digitalix]

Are you sure there is a problem? Once a new transceiver is created it will always use the set of codecs from MediaEngine.

mediaEngineCodecs := t.api.mediaEngine.getCodecsByKind(t.kind)
if len(t.codecs) == 0 {
    return mediaEngineCodecs
}

This is exactly the same behavior as before SetCodecPreferences was added.

[jech]

I'm not sure, that's why I'm asking rather than sending a pull request.

Suppose that I have a local track with the H.264 codec. I call AddTrack, the track gets added. I offer it to a browser that doesn't support H.264, the browser successfully negotiates VP8, I start writing RTP packets to the H.264 track, the packets go to nowhere.

If the call to AddTrack restricted the set of codecs for the track, then the negotiation would fail, which would yield an exception in the browser, which could either try to recover (e.g. by negotiating an audio-only session) or inform the user of the problem. The latter behaviour seems preferable to me.

So what should AddTrack do?

[digitalix]

Ohh I see! At first, I thought you meant something else but it looks like a completely new issue unaffected by SetCodecPreferences.

Suppose that I have a local track with the H.264 codec. I call AddTrack, the track gets added. I offer it to a browser that doesn't support H.264, the browser successfully negotiates VP8, I start writing RTP packets to the H.264 track, the packets go to nowhere.

In a case like this, I think Bind on track would fail but honestly, I'm not sure what's going to happen. If you call AddTrack after negotiation and the browser doesn't support H.264, then I'm pretty sure that AddTrack would return an error.

Edit:

I looked at peerconnection.go and startRTPSenders is called from SetLocalDescription and SetRemoteDescription which then calls Send and finally Bind so it should return an error in all cases.

If the session is already negotiated and you try to add a track that is not supported by your browser then AddTrack will return an error.

If the session hasn’t been negotiated yet and you add track before then SetLocalDescription or SetRemoteDescription will return an error.