Re: Issue 497: RID as read-only in setParameters()?

I think we decided that you can't change the RIDs.  I don't really see any
value in calling addTrack + setParameters to set the RIDs.  I think it
would be more simple to only allow adding or modifying of RIDs in
addTransceiver or addTrack.  Allowing the addition via setParameters means
we have to define when that's OK and when that's not OK, and it can get
complicated.

For example, isn't it possible for addTrack to reuse an existing
RtpSender?  What if that RtpSender is already tied to a remote description,
which means that it's already tied to what RIDs are allowable or not?  In
that case, setParameters could explode here, depending on the
matching/resuing rules for RtpSenders.  That makes setParameters with new
RIDs can of dangerous to use, since sometimes it may work and sometimes it
may not.

I think it would be more simple to just say "they must be passed into
addTransceiver and may not be added or modified anywhere else".


Or.... we could simply allow modification by the JS at any point, but that
would allow sending RIDs that aren't in the remote SDP, which I'm guessing
many people would be unhappy with.



On Thu, Feb 11, 2016 at 11:26 AM, Jan-Ivar Bruaroey <jib@mozilla.com> wrote:

> On 2/11/16 12:01 PM, Bernard Aboba wrote:
>
> Issue link: https://github.com/w3c/webrtc-pc/issues/497
>
>
>
> The question has arisen as to whether setParameters() can change the RID
> value.
>
>
>
> The specification allows the RID to be set in in addTransceiver() (via
> init.sendEncodings), prior to calling createOffer()
>
>
> So currently in Firefox Nightly, users can do this:
>
>   var sender = pc.addTrack(stream.getVideoTracks()[0], stream);
>   sender.setParameters({ encodings: [{ rid: "A",  maxBitrate: 300000 },
>                                      { rid: "B",  maxBitrate: 100000 }] });
>   pc.createOffer().then(d => pc1.setLocalDescription(d));
>
>
> Works without having to use addTranceiver. Did we decide this should not
> work?
>
> This is perhaps a separate question from whether RIDs should be be
> modifiable after O/A.
>
> .: Jan-Ivar :.
>
>  This results in the setting of the RID value in the SDP produced by
> createOffer().  An O/A exchange may then occur.
>
>
>
> However, after the O/A exchange has completed, is it then possible to
> change the value of the RID in a call to setParameters() without another
> O/A exchange?
>
>
>
> The effect of such an setParameters() call would include placement of the
> modified RID value in an SDES header extension to RTP, as well as placement
> in an SDES RTCP packet, as described here:
>
> https://tools.ietf.org/html/draft-roach-avtext-rid
>
>
>
> Assuming that the RTCP SDES packet is not lost, the remote peer will be
> informed that RTP packets including a new RID value can be expected to
> arrive (or may have arrived!).
>
>
>
> However, without an O/A exchange, won’t the remote peer be lacking
> important information needed to process RTP packets containing the new RID
> (such as the constraints associated with the new RID value)?
>
>
>
> If this is correct, then an SDP O/A exchange is needed, and the RID should
> be considered “read only” for setParameters().
>
>
>
>