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

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?

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?

.: 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);
> }