For codecs we have getCapabilities() for figuring out what is supported by the browser, setCodecPreferences() for controlling what to negotiate, and getParameters() to see what was actually negotiated. In addition, getStats() can tell you more details (such as if multiple codecs were negotiated, which one is being used right now).
Should we have a similar API for header extensions? There is already getParameter()'s headerExtensions for reading what RTP header extensions were negotiated, but there is no way to detect what is supported without trial and error, and worse yet, if you want to control which ones are negotiated you have to munge SDP.
Aside from header extensions, there are is also RTCP-related info. So should in WebRTC 1.0, should we just have a setPreferences() method that covers everything?
Copied from Issue https://github.com/w3c/webrtc-pc/issues/2243
For codecs we have getCapabilities() for figuring out what is supported by the browser, setCodecPreferences() for controlling what to negotiate, and getParameters() to see what was actually negotiated. In addition, getStats() can tell you more details (such as if multiple codecs were negotiated, which one is being used right now).
Should we have a similar API for header extensions? There is already getParameter()'s headerExtensions for reading what RTP header extensions were negotiated, but there is no way to detect what is supported without trial and error, and worse yet, if you want to control which ones are negotiated you have to munge SDP.
@jonex