Dynamic RTP payload types break streaming in non Chromium browsers #2237
Description
Your environment.
- Version: 3.1.34
- Browser: Firefox 100.0.2 (on MacOS and Arch Linux)
Ran the pion/mediadevices webrtc example
What did you expect?
The example to work in major browsers
What happened?
The example works fine in Chromium based browsers. In Firefox everything connects correctly and the video stream shows it is playing but there's no output. The audio stream does not play. Same issue with desktop Safari, mobile Firefox, and mobile Safari.
I ran into the same issue with the VP8 codec. I wasn't able to get a stream working with Safari iOS either. I think it was the same issue but haven't confirmed yet.
Additional info
Here's the SDP log for a failed session in Firefox: https://gist.github.com/matt-allan/4bbed61755adc9cb5ef67a8e8dbe226a
This is what about:webrtc looks like when this is happening:
And this is what I'm seeing:
This is what I see for desktop Safari:
Debugging notes
I've found a lot of previous issues suggesting this is caused by Pion using a hardcoded payload type for the RTP packets when they should be dynamic. It works in Chrome because the payload type matches what Chrome uses. It doesn't work in Firefox because Firefox uses different type IDs than Chrome.
I was able to confirm that changing the payload type from 125 to 126 (because Firefox is trying to use 126) in codec.go of the mediadevices package fixes the issue for Firefox. However I'm filing an issue here and not a PR in that repo since it appears to be an issue with the core webrtc code and not the mediadevices codec.
From what I can tell it's expected for browsers to use dynamic payload types:
payload type
values in the range 96-127 MAY be defined dynamically through a
conference control protocol
https://www.rfc-editor.org/rfc/rfc3551.html#section-6
For some (older) codecs like PCMU the payload type is assigned statically as described in RFC3551. For others, it is assigned dynamically through the SDP. Note: there are no guarantees on the stability of a payload type assignment.
For this allocation, the range from 96 to 127 is used.
https://webrtc.googlesource.com/src/+/HEAD/pc/g3doc/rtp.md
The doc comment for payloadType indicates it can be negotiated. It looks like maybe this line does that but I added some logging and it's never hit in my case.
Related issues
There are prior issues that appear to be about the same thing:
A lot of these issues were closed but they link to a page that 404s so I can't tell what code change may have addressed this. If you can point me to the right place I can try and make a PR.