Issue 1021: get/setParameters does not have a parameter for packetization interval

Issue: https://github.com/w3c/webrtc-pc/issues/1021

Related Issues: https://github.com/w3c/webrtc-pc/issues/1022
https://github.com/w3c/webrtc-pc/issues/1024

Issue 1021 as well as related Issues 1022 and 1024 are on the agenda for the March 1 Virtual Interim.  Since these issues are related,  it seemed like a good idea to get some discussion going prior to the meeting.

Brief summary:

Varun:  "We have a few parameters for video and simulcast, would like to have one for packetization interval. Currently, I cannot find a way to change it without messing with the SDP."
Taylor: "Currently, you'd have to read "sdpFmtpParameters" and parse the "key=value; key=value;" structure. I'd propose changing this to a Dictionary, like in ORTC, assuming all codecs use the "key=value" structure."
Varun: "What about setting the packetization interval on setParameters?"
Taylor: "Well, I thought codecs can only be reordered, not modified, so that wouldn't be supported. Though RTCRtpParameters.codecs isn't marked read-only; is that just an oversight?"

[BA] In PR https://github.com/w3c/webrtc-pc/pull/1025 which is a fix for Issue 1024, Taylor has proposes a clarification saying that setParameters() cannot be used to add a new codec to the codecs[] sequence, or modify the RTCRtpCodecParameters dictionary entries (which includes payLoadType, mimeType, clockRate and channels as well as the sdpFmtpLine attribute).  As part of the discussion of Issue 1022, it would appear that for a sender the sdpFmtpLine attribute is obtained from the remote peer's SDP, so this effectively says that once a remote description is applied the fmtp parameters determined from the negotiation cannot be modified by setParameters().

Example 1:  For H.264/AVC, the remote peer's profile-level-id is included within RTCRtpSender.getParameters.codecs[].sdpFmtpLine and cannot be modified by setParameters().  To modify what is being encoded, use encodings[].maxBitrate, .maxFramerate, etc.

PR 1025 also provides a clarification to setCodecPreferences, stating that codecs in the codecs[] sequence need to be among those returned by RTCRtpReceiver.getCapabilities(kind).codecs[] or RTCRtpSender.getCapabilities(kind).codecs[], and also that RTCRtpCodecParameters dictionary entries cannot be modified.  Therefore this PR would preclude use of setCodecPreferences to modify the codec-specific parameters included in the SDP provided createOffer() or createAnswer().


Example 2: An application is using Opus to provide audio support in a situation where stereo is not necessary.  Since stereo is supported by both the local and remote peer implementations, RTCRtpSender/RTCRtpReceiver.getCapabilities().codecs[].numChannels returns 2 for Opus, and the sdpFmtpLine attribute for either the RTCRtpSender or RTCRtpReceiver would contain "stereo=1".Rather than using setCodecPreferences() to modify sdpFmtpLine so as to contain "stereo=0" prior to calling createOffer(), the SDP signaled by the remote peer is modified to change "stereo=1" to "stereo=0" prior to calling setRemoteDescription().

In Issue 1022, Taylor raises the question of what the sdpFmtpLine attribute contains.  This includes whether it actually contains "a=fmtp:" and the payload type values, or just the list of parameters.  If it is just the list of parameters, the question is raised as to whether it would better be expressed as a dictionary (which would perhaps make it easier to modify individual values with setCodecPreferences() if in fact that is allowable).   There is also the question of what the sdpFmtpLine attribute contains, both in RTCRtpReceiver.getParameters().codecs[].sdpFmtpLine (here it is presumably the contents of the fmtp parameters of the local peer) and in RTCRtpSender.getParameters().codecs[].sdpFmtpLine (here it is presumably the contents of the fmtp parameters of the remote peer).

Some questions for the WEBRTC WG:


a.    Do we need setCodecPreferences() to be able to modify codec-specific parameters?

b.    Do we need to be able to set the ptime value without modifying SDP?

c.     Is it necessary to be able to discover the maxptime value without parsing SDP?