Fix addCodec to return error if payload type exists in codecs list

[itzmanish]

Description

This PR adds changes to return an error if the codec already exists on the codecs list. This way now the implementing party should take care of duplicate codecs addition if the payload type is the same.

Reference issue

Fixes #3015

[codecov]

Codecov Report

Attention: Patch coverage is 81.48148% with 5 lines in your changes missing coverage. Please review.

Project coverage is 78.22%. Comparing base (44062a7) to head (a34cc7e).

Files with missing lines	Patch %	Lines
mediaengine.go	81.48%	3 Missing and 2 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #3016      +/-   ##
==========================================
- Coverage   78.41%   78.22%   -0.20%     
==========================================
  Files          91       91              
  Lines       11251    11262      +11     
==========================================
- Hits         8823     8810      -13     
- Misses       1938     1956      +18     
- Partials      490      496       +6     

Flag	Coverage Δ
go	80.08% <81.48%> (-0.22%)	⬇️
wasm	63.44% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[itzmanish]

While this PR fixes the issue of duplicate payload type codec entry on RegisterCodec, There is still one issue that this PR doesn't cover.

What if we have some registered codecs and the client sends the codecs with different payload types and one of the payload types the client is using clashes with our registered codecs, in that case, the client's codec won't be added to the negotiated codecs list. That's an issue because the server will now be missing that codec.

The flow -

Pion server codec list - []{..,PayloadType: 96, Mime: "video/VP8"..}
Browser sends codecs on sdp which triggers `updateFromRemoteDescription` - []{..., PayloadType: 96, Mime: "audio/OPUS"...}

This PR will make the media engine discard the opus codec. However, the issue remains even without this PR,

Pion server codec list - []{..,PayloadType: 96, Mime: "video/VP9", "profile-id=0"..}
Browser sends codecs on sdp which triggers `updateFromRemoteDescription` - []{..., PayloadType: 96, Mime: "video/VP9", "profile-id=1"...}

Again the client-given codec won't be added and most probably the browser will use "profile-id=0" one only (I am not sure about specs here, so please correct me here).

[JoeTurki]

@itzmanish Thank you so much, Will you be able to fix the lint issues (commit and code?).

What if we have some registered codecs and the client sends the codecs with different payload types and one of the payload types the client is using clashes with our registered codecs, in that case, the client's codec won't be added to the negotiated codecs list. That's an issue because the server will now be missing that codec.

For your use cause (SFU) you will need to manage separate payload type mappings for the send and receive directions in certain cases, as outlined in rfc3264

For recvonly RTP streams, the payload type numbers indicate the value
of the payload type field in RTP packets the offerer is expecting to
receive for that codec. For sendonly RTP streams, the payload type
numbers indicate the value of the payload type field in RTP packets
the offerer is planning to send for that codec. For sendrecv RTP
streams, the payload type numbers indicate the value of the payload
type field the offerer expects to receive, and would prefer to send.
However, for sendonly and sendrecv streams, the answer might indicate
different payload type numbers for the same codecs, in which case,
the offerer MUST send with the payload type numbers from the answer.
Different payload type numbers may be needed in each direction
because of interoperability concerns with H.323.

Worth mentioning rfc3551

This profile reserves payload type numbers in the range 96-127
exclusively for dynamic assignment. Applications SHOULD first use
values in this range for dynamic payload types. Those applications
which need to define more than 32 dynamic payload types MAY bind
codes below 96, in which case it is RECOMMENDED that unassigned
payload type numbers be used first. However, the statically assigned
payload types are default bindings and MAY be dynamically bound to
new encodings if needed. Redefining payload types below 96 may cause
incorrect operation if an attempt is made to join a session without
obtaining session description information that defines the dynamic
payload types.

Dynamic payload types SHOULD NOT be used without a well-defined
mechanism to indicate the mapping. Systems that expect to
interoperate with others operating under this profile SHOULD NOT make
their own assignments of proprietary encodings to particular, fixed
payload types.

Maybe we can make changes to accommodate this.
Pion supports dynamic payload types.

[itzmanish]

Will you be able to fix the lint issues (commit and code?).

Maybe need to re-trigger the commit linter to run. I have updated the PR title and last commit message to pass, but it's not getting triggered for newer commits. @JoeTurki could you please re-trigger the gh action for lint metadata?

[itzmanish]

However, for sendonly and sendrecv streams, the answer might indicate
different payload type numbers for the same codecs, in which case,
the offerer MUST send with the payload type numbers from the answer.

This line. let's say, the server is an offerer and generates SDP with PT 96, mime video/VP8 and PT 97, mime video/VP9. Could it be possible for the client to generate and answer SDP with PT 96, mime video/VP9 and PT 97, mime video/VP8? If yes, according to how we update negotiatedCodecs, it won't get updated.
But the spec says the offerer MUST send with the payload type numbers from the answer, With what PT number the server will send the packet?

[JoeTurki]

Maybe need to re-trigger the commit linter to run. I have updated the PR title and last commit message to pass, but it's not getting triggered for newer commits. @JoeTurki could you please re-trigger the gh action for lint metadata?

PR title doesn't affect it, You'll need to reword your old commits, but since we only allow for one commit per PR it's better if you squash your commits into a single one and fix the lint issues :)

Thanks :)

[JoeTurki]

This line. let's say, the server is an offerer and generates SDP with PT 96, mime video/VP8 and PT 97, mime video/VP9. Could it be possible for the client to generate and answer SDP with PT 96, mime video/VP9 and PT 97, mime video/VP8? If yes, according to how we update negotiatedCodecs, it won't get updated.
But the spec says the offerer MUST send with the payload type numbers from the answer, With what PT number the server will send the packet?

Is this what you mean?

webrtc/mediaengine_test.go

Line 98 in feeeebf

t.Run("Change Payload Type", func(t *testing.T) {

[itzmanish]

yes. I get it now. The negotiated codecs list always respects the answer's codec preferences. Thanks :)

[itzmanish]

Hi @JoeTurki, Sorry for the delay on my end. Please re-review the PR, I have updated it to propagate the error on the updateRemoteDescription flow as well.

[JoeTurki]

Thank you Manish :)