(no subject)

Youenn said:

"I am curious about the reasons behind surfacing the API at transceiver instead of sender/receiver level."

[BA] The document<https://docs.google.com/document/d/1y1hTsMeav5ijPvoqu1R6U4YC564i1QzgkMeIqWhgiis/edit#> states that it is desired to be able to:


  1.  Be able to figure out what extensions (by name) the platform supports

  2.  Enable the negotiation of these extensions on initial SDP negotiation

  3.  Enable or disable these extensions on a specific RTP stream.

Of these problems, #1 and #3 can be handled at the sender/receiver level and do not require additional APIs.  Problem #2 could also be handled at the sender/receiver level but would require two new APIs (one for the sender, another for the receiver), instead of one.

As noted in the document, problem #1 is addressed by the RTCRtpSender.getCapabilities() API:
"To figure out what’s available, one can use RTCRtpSender.getCapabilities() and look at the header extensions section; this returns a sequence<RTCRtpHeaderExtensionCapability>."

Problem #3 is addressable via the RTCRtpSender.setParameters() API.  Currently, RTCRtpParameters.headerExtensions is a read-only parameter.  However, I believe it would be possible to make headerExtensions writeable without violating the requirement in Section 5.2:

"setParameters<https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dom-rtcrtpsender-setparameters> does not cause SDP renegotiation and can only be used to change what the media stack is sending or receiving within the envelope negotiated by Offer/Answer. "

Removing header extensions from the headerExtensions list (so as to stop them from being sent) fits within this restriction, but I don't think that setParameters() can be used to add header extensions that are not negotiated, since that would require SDP renegotiation.


dictionary RTCRtpParameters<https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dom-rtcrtpparameters> {
  required sequence<https://heycam.github.io/webidl/#idl-sequence><RTCRtpHeaderExtensionParameters<https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dom-rtcrtpheaderextensionparameters>> headerExtensions<https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dom-rtcrtpparameters-headerextensions>;
  required RTCRtcpParameters<https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dom-rtcrtcpparameters> rtcp<https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dom-rtcrtpparameters-rtcp>;
  required sequence<https://heycam.github.io/webidl/#idl-sequence><RTCRtpCodecParameters<https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dom-rtcrtpcodecparameters>> codecs<https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dom-rtcrtpparameters-codecs>;
};

dictionary RTCRtpHeaderExtensionParameters<https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dom-rtcrtpheaderextensionparameters> {
  required DOMString<https://heycam.github.io/webidl/#idl-DOMString> uri<https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dom-rtcrtpheaderextensionparameters-uri>;
  required unsigned short<https://heycam.github.io/webidl/#idl-unsigned-short> id<https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dom-rtcrtpheaderextensionparameters-id>;
  boolean<https://heycam.github.io/webidl/#idl-boolean> encrypted<https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dom-rtcrtpheaderextensionparameters-encrypted> = false;
};

To solve Problem #2, we need to influence the offer/answer negotiation, which cannot be accomplished via setParameters().  So this does require a new API, such as setOfferedRtpHeaderExtensions().

RFC 8285 allows the direction to be specified on the a=extmap line:


      m=video
      a=sendrecv
      a=extmap:1 URI-toffset
      a=extmap:2/recvonly URI-gps-string
      a=extmap:3 URI-frametype
      m=audio
      a=sendrecv
      a=extmap:1/sendonly URI-toffset


Depending on the direction, we could potentially be looking at header extensions that would be sent and received, only sent or only received (inactive header extensions aren't included in the SDP).   So if we were to do this at the sender/receiver level, we would need two APIs, RTCRtpSender.setOfferedRtpHeaderExtensions() and RTCRtpReceiver.setOfferedRtpHeaderExtensions().  This would remove the need for a direction attribute (which could be determined based on the header extensions configured for the sender and receiver).  But it would require applications to make two API calls instead of one.