Re: Should we add a RIDs parameter to PeerConnection.addTrack?

On Wed, Feb 17, 2016 at 10:50 AM, Jan-Ivar Bruaroey <jib@mozilla.com> wrote:

> We could add that, or we could just make what we have today work:
>
>     var sender = pc.addTrack(stream.getVideoTracks()[0], stream);
>     sender.setParameters({ encodings: [{ maxBitrate: 60000 }] });
>
> which seems unambiguous, so what exactly is the value of expanding the API
> here?
>

That's more a question of how you need to call getParameters() before you
call setParameters().  That really doesn't have anything to do with RIDs,
or the point I'm trying to make in this thread.


>
> I have to confess I don't understand the purity argument around defining
> setParameters as exclusively bound by the SDP O/A envelope, and shaping
> further design around that distinction (even though it made sense as an
> arbitrary line in the sand to me for what to consider for 1.0 vs. future).
>
​

> If the goal with WebRTC 2.0 or whatever, is to eventually surpass the
> restrictions of SDP O/A, aren't we better off grooming setParameters toward
> handling *all* parameters, and might we regret shifting functionality off
> into distinct "set-once" dictionaries in add/constructor patterns?
>


Being able to say "you can setParameters to anything, regardless of ​what
the remote SDP is" is exactly what I proposed for simulcast "Plan B": the
JS just sets simulcast in the parameters, and we don't need any simulcast
in the SDP.  But it wasn't well received, except as a backup plan in case
RIDs don't work out.

​I think we'll have to wait for WebRTC NV to have that flexibility.​


>
> .: Jan-Ivar :.
>
>
> On 2/17/16 12:32 AM, Peter Thatcher wrote:
>
> In a previous thread, we discussed how RIDs should be read-only, but that
> brought up the question: could we allow RIDs to be passed into addTrack?
>
> Initially, I thought we shouldn't allow that because then if the RtpSender
> returned were bound to an existing m-line with a remote description, then
> the RIDs could conflict.  However, after thinking about it more I realized
> that it would be possible if we made this rule:  if RIDs are specified in
> addTrack, then addTrack must create a new RtpSender, not use an existing
> one, just like addTransceiver does.  Then, it would use the same rules as
> addTransceiver and be safe from this problem.
>
> The only problem I can think is that an app developer might be surprised
> when a transceiver is reused in some cases, but then not when RIDs are
> specified.  But that seems like a pretty small issue.
>
> If we do choose to add RIDs to addTrack with this rule, I think we should
> expand addTrack to take a full "sequence<RTCRtpEncodingParameters>
> sendEncodings", just like addTransceivers, with the same rules, so that
> they are consistent with each other.  We may even consider packaging it
> into an RtpSenderInit dictionary similar to RtpTransceiverInit.  That would
> be a cleaner place to put .streams anyway.
>
> Something like:
>
> dictionary RTCRtpSenderInit {
>   sequence<MediaStream> streams;
>   sequence<RTCRtpEncodingParameters> sendEncodings;
> };
>
> partial interface PeerConnection {
>   RTCRtpSender addTrack (MediaStreamTrack track, RTCRtpSenderInit init);
> }
>
>
>