peerconnection: SetRemoteDescription should validate against inconsistent track and mimetypes

[tmatth]

Your environment.

• Version: github.com/pion/webrtc/v3 v3.1.45 h1:pJpD9TSMqtWIAGKXmpRhFmsQrrMlNgRx0UX1fGHbfoY=
• Browser: N/A

What did you do?

Using janus 0.x prior to this PR surfaced an issue where, when given a borked SDP where both rtx and opus were mapped to payload type 97, I was seeing a track with RtpCodecTypeAudio but mimetype video/rtx

More details here: meetecho/janus-gateway#3078 (comment)

And details on how to run Janus + Pion to test in general here: pion/example-webrtc-applications#120 (comment)

What did you expect?

SetRemoteDescription should probably error out on this kind of mismatch

What happened?

No errors and when receiving the track and switching on track.Kind() the track's mimetype was video/rtx, and I only caught this when I started parsing the mimetype (whereas previously I'd assumed it had to be Opus).

[tmatth]

Besides the track type + mimetype mismatch, there might be other worthwhile validation to do.

[tmatth]

Here's an example of the borked SDP that was being passed to setRemoteDescription

v=0
o=- 1664231968142910 1 IN IP4 192.168.0.91
s=Mountpoint 1
t=0 0
a=group:BUNDLE audio video
a=extmap-allow-mixed
a=msid-semantic: WMS janus
m=audio 9 UDP/TLS/RTP/SAVPF 97
c=IN IP4 192.168.0.91
a=sendonly
a=mid:audio
a=rtcp-mux
a=ice-ufrag:LlUE
a=ice-pwd:WoEZI6hAGdeSB+IivHSZNF
a=ice-options:trickle
a=fingerprint:sha-256 8B:DF:49:98:E2:D2:23:6B:42:37:BC:09:26:08:8C:3D:07:B9:2E:49:9F:86:05:BD:01:5B:D5:58:C5:81:FB:66
a=setup:actpass
a=rtpmap:97 opus/48000/2
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
a=msid:janus janusa0
a=ssrc:3980440877 cname:janus
a=ssrc:3980440877 msid:janus janusa0
a=ssrc:3980440877 mslabel:janus
a=ssrc:3980440877 label:janusa0
a=candidate:1 1 udp 2015363327 192.168.0.91 56486 typ host
a=candidate:2 1 udp 2015364351 172.17.0.1 44752 typ host
a=candidate:3 1 udp 2015363583 10.42.0.0 33735 typ host
a=end-of-candidates
m=video 9 UDP/TLS/RTP/SAVPF 96 97
c=IN IP4 192.168.0.91
a=sendonly
a=mid:video
a=rtcp-mux
a=ice-ufrag:LlUE
a=ice-pwd:WoEZI6hAGdeSB+IivHSZNF
a=ice-options:trickle
a=fingerprint:sha-256 8B:DF:49:98:E2:D2:23:6B:42:37:BC:09:26:08:8C:3D:07:B9:2E:49:9F:86:05:BD:01:5B:D5:58:C5:81:FB:66
a=setup:actpass
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtcp-fb:96 goog-remb
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96
a=ssrc-group:FID 1032543601 1674899379
a=msid:janus janusv0
a=ssrc:1032543601 cname:janus
a=ssrc:1032543601 msid:janus janusv0
a=ssrc:1032543601 mslabel:janus
a=ssrc:1032543601 label:janusv0
a=ssrc:1674899379 cname:janus
a=ssrc:1674899379 msid:janus janusv0
a=ssrc:1674899379 mslabel:janus
a=ssrc:1674899379 label:janusv0
a=candidate:1 1 udp 2015363327 192.168.0.91 56486 typ host
a=candidate:2 1 udp 2015364351 172.17.0.1 44752 typ host
a=candidate:3 1 udp 2015363583 10.42.0.0 33735 typ host
a=end-of-candidates

[stephanrotolante]

Would it be ok if i try to take a crack at this?