Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Are camelCase codec parameters useful at all? #689
Currently EDGE does not use camelCase RTP codec parameters (it uses
But, at the end, not even EDGE implements the ORTC camelCase syntax. Given that having a different naming provides zero benefit here, why not keep untouched the SDP naming?
Also, as @aboba pointed:
(definitely I'm one of those "confused" developers...).
referenced this issue
May 8, 2017
We have IETF RFCs defining
Here is the guidance on camelCasing property names. Of course, there can be justified exceptions to that guidance, but seeing that there are cases where the SDP names contains hyphens (
Indeed I would like that both, WebRTC and ORTC, use camelCase everywhere. But when it comes to deal with codec parameters (defined in so many RFC's), having to keep a mapping is problematic. Just consider the real fact that Edge does not use camelCase parameters (as defined in ORTC) but keeps the original naming. I've implemented two ORTC<->SDP shims and, again, I've found it terribly problematic.
As told above, having camelCase in ORTC means that the ORTC spec must define all the existing codec parameters. This is not a good idea. Some ORTC implementations may want to add custom codecs or parameters not supported by ORTC itself. If so, pointing to the related RFC would not be enough. Instead, a custom parameter mapping should also be provided.
Honestly I see zero advantage in forcing camelCase for RTP parameters in ORTC, no matter what the JS / W3C guidelines state.