Fix ftmp matching for all codecs

[jech]

Pion used to match m lines in SDP by doing a simple comparison of the fmtp lines. This does not work in general, as some fmtp parameters are symmetric (they must have the same value on both sides for the m lines to match) and others are declarative (they only give additional information about what the announcing peer is able to send or receive). It might also be the case that some symmetric parameters can be omitted, indicating that the announcer will accept whatever value the other side finds convenient (not sure, the RFCs are unclear on this subject).

Here's the situation, as far as I can tell from a quick browse of the relevant documents:

• VP8 https://datatracker.ietf.org/doc/html/rfc7741
  • both parameters max-fr and max-fs are declarative.
• VP9 https://datatracker.ietf.org/doc/html/draft-ietf-payload-vp9
  • the parameter profile-id is symmetric, but may be omitted;
  • the parameters max-fr and max-fs are declarative.
• Opus https://datatracker.ietf.org/doc/html/rfc7587
  • all parameters are declarative.
• H.264 https://datatracker.ietf.org/doc/html/rfc6184
  • the parameters profile-level-id and packetization-mode are symmetric, with weird matching for profile-level-id (see https://github.com/pion/webrtc/pull/1903);
  • level-asymmetry-allowed changes the matching algorithm;
  • all other parameters are declarative;
  • there are weird rules for sprop-parameter-sets.

[aler9]

The situation is the following:

Symmetric parameters now play a role in matching codecs between senders and receivers, in particular:

• H264 symmetric parameters were implemented with #1903
• VP9 symmetric parameters were implemented with #2772 and #2773

The only thing that remains is that the library does not prevent matching incompatible codecs, since there's a fallback matching algorithm that takes into consideration the mime type only:

https://github.com/pion/webrtc/blob/2d529be5717a7c8a454abbafad4c6851d30ca793/rtpcodec.go#L112-L117

[Sean-Der]

The final issue was fixed with https://github.com/pion/webrtc/pull/3021 (correct me if I'm wrong @aler9!

If you define codecs with explicit values (ClockRate etc...) the matching will be explicit now. The fallback behavior still happens if the values are empty.

[aler9]

@Sean-Der this issue was a little bit too generic since it refers to "all codecs", present and future 🤣, let's just say that given all information that we have available right now on the codecs explicitly mentioned in the first post (VP8, VP9, H264, Opus), format matching should work properly.

In the future, in case of additional codecs that might require additional matching logic we can open a dedicate issue or even better a PR. What i'm thinking about is:

• H265 surely requires a profile id-based matching
• H266 / VVC might require a profile level-based matching