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

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

> On 2/11/16 2:50 PM, Peter Thatcher wrote:
>
> 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.
>
>
> The only value I can see would be users being able to set bitrates without
> absorbing the (more complicated) transceiver model.
>
​
I don't see what is more com​plicated about calling addTransceiver vs.
addTrack.  A longer name?




>
> 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?
>
>
> The spec seems to say about reuse that "Doing so will cause future calls
> to createOffer and createAnswer to mark the corresponding media description
> as sendrecv or sendonly, as defined in [JSEP]. "
>
> Which seems to be about reusing m-lines for subsequent O/A. Is it also
> about being able to send instantly, without O/A?
>

​So, if you have an m-line that is sendrecv on the remote side, and
recvonly on the local side, then the RtpSender is inactive, but there is an
existing remote description, which constraints which RIDs can be chosen for
that RtpSender.  Then, addTrack may activate that RtpSender, which is
already constrained on which RIDs it can choose, and setParameters may fail
if it picks different RIDs.


I guess the more general problem is: if you re-use an RtpSender, you need
to getParameters() + modify + setParameters.  Only when you construct a new
RtpSender (addTransceiver) can you just set the parameters without first
reading it.



>
>
> .: Jan-Ivar :.
>
>