Mismatch between RID restrictions and RTPEncodingParameters

[amithilbuch]

There is a mismatch between how clients set up streams and how they communicate the created state. This is relevant to the case of Unified Plan and RIDs and is highlighted in the case of simulcast.

A client sets up their streams with a call to addTransceiver() in which they provide 'RTPEncodingParameters' also known as send_encodings. These encodings describe the layers. Some of the parameters in send_encodings (such as max_bitrate_bps and max_framerate) match RID restrictions (such as max-br and max-fr). However some of the parameters do not match. Specifically the parameters that indicate the resolution of the layer, which are of utmost importance to the simulcast scenario do not match. In the RID description, they are max-width and max-height but in the send_encodings they are scale_resolution_down_by. This makes communicating the setup during negotiation harder than it needs to be. This is even harder when the offer is coming from the SFU which does not necessarily know the resolution of the imaging device on the other end. In such a case, there could also be performance impact from choosing "bad" values.

Some possible options to resolve (in no particular order):

1. Offers are only initiated by the simulcast sender.
2. Synchronize the parameters between the two specs (not strictly possible because new restrictions can be added in the future).
3. Fix this in the implementation layer (by passing on the values to the engine) and ignore send_encodings.
4. Put the onus of translating between the two 'formats' on the user that should set up the transceivers accordingly.
5. Ignore incoming restrictions as if they are 'not understood' removing them from the answer (using RIDs only as identifiers).
6. Signal the information out-of-band and only use the RIDs as identifiers.

[alvestrand]

To my mind, there is no particular advantage in signalling the resolution, bitrate or framerate on a send rid. Those are parameters that the sender can decide unilaterally. It makes sense to be able to signal those parameters on a recv rid, because it indicates what the receiver is capable of receiving on those rids. The parameters in send_encodings control what the sender is going to send, and can change (using setParameters) over the course of a call, without any new negotiation. So the fact that some of them match RID syntax should not drive the design of what to signal.

[aboba]

@alvestrand Agree that there is no advantage in signaling (any) restrictions on a send rid. While I can see the value of allowing a receiver to indicate "preferred" stream characteristics, draft-ietf-mmusic-rid describes a more traditional Offer/Answer framework. For example, with respect to signaling them in a receive rid, draft-ietf-mmusic-rid Section 6.3 says:

  The answerer MAY choose to modify specific "a=rid" restriction
   values in the answer SDP.  In such a case, the modified value
   MUST be more restrictive than the ones specified in the offer.
   The answer MUST NOT include any restrictions that were not
   present in the offer.

My interpretation is that if a conference server sends an offer with a recv rid and restrictions and the browser responds (even without modifying the restriction), this implies agreement by the Answerer to maintain the restriction. So for example, if the Offer with a recv rid contained max-br or max-fps restrictions and the browser responds without modifying the restrictions, has the browser agreed to set limits on what the sender can set maxBitrate and maxFramerate values to in the future?

With respect to current unsupported restrictions, or future potential restrictions, Section 6.2.2 of draft-ietf-mmusic-rid does not allow unsupported restrictions to be ignored:

   If the "direction" field is "recv", the answerer ensures that the
   specified "a=rid" restrictions are supported.  In the case of an
   unsupported restriction, the "a=rid" line is discarded.

[aboba]

@juberti Were rid restrictions discussed during the development of JSEP?

[aboba]

Consensus from the January 22, 2019 virtual interim is that restrictions are not supported (see PR https://github.com/w3c/webrtc-pc/pull/2075 )