Closed alexhenrie closed 6 months ago
Nicely spotted! I guess to be perfectly compatible we should actually allow overriding the detected codec based on later rtpmap lines even if the payload type is recognized... but this change is already a nice improvement over current behavior. 👍 I'll try to do a proper code review (to make sure there's no weird regressions or anything) in the coming week.
@Thulinma Thanks for your feedback. Have you had a chance to look at it again? Of the three pull requests I sent, this one is the most important.
By the way, this probably goes without saying, but all of these contributions are made under the Unlicense just like the rest of MistServer is. Please let me know if you need a more formal license declaration from me or from the company I work for.
Merged to development
branch as a1fbb9e1869320489696e83267159536281adf04.
This will be part of the next release. Apologies for the long wait on this and thank you for the contribution!
The Bosch FLEXIDOME 4000i camera sets the RTP payload type to 35 for H264, which causes MistServer to output "FAIL: Payload type 35 not supported!"
The camera probably uses 35 for H264 because the ATSC standard requires it. A/153 Part 7 states: [1]
The camera also sends "a=rtpmap:35 H264/90000" to explicitly map the value 35 to H264. This is perfectly valid; although payload types 96 through 127 are recommended for dynamic use, the RTP protocol allows any AVP payload type to be dynamically reassigned. The relevant section of RFC 3551 states: [2]
If the payload type is not recognized, assume that an rtpmap line will follow that defines it. If in the end there is no rtpmap line, error out in the same way whether the payload type is between 96 and 127 inclusive or whether it is outside of that range.
[1] https://prdatsc.wpenginepowered.com/wp-content/uploads/2021/04/A153-Part-7-2012.pdf#page=14 [2] https://datatracker.ietf.org/doc/html/rfc3551#page-6