Re: Proposal: Add RtpSenderInit parameter to addTrack.

On 4/30/2015 12:54 AM, Justin Uberti wrote:
> This seems like a smart approach; I find points #1/#3 especially 
> persuasive.

As do I.   Especially with something with potentially a lot of options, 
and where adding options is likely, this sort of named parameter 
approach via an Init object/dict is definitely a win.

>
> On Tue, Apr 21, 2015 at 4:06 PM, Peter Thatcher <pthatcher@google.com 
> <mailto:pthatcher@google.com>> wrote:
>
>     While talking to Stefan about the possibility of per-RtpSender
>     control of VAD, and thinking about all the recent discussion
>     around MSID, I realized that there was a common need to add
>     parameters to addTrack.
>
>     I propose we add a dictionary parameter "RtpSenderInit", like we
>     have DataChannelInit that contains parameters for
>     PeerConnection.createDataChannel without making the parameter list
>     a mess.
>

snip

>
>     Let's continue the discussion around voiceActivityDetection,
>     synchronizationGroups, and label/ID on separate threads, but for
>     this thread, I'd like to ask the group:  Does it look like a good
>     idea to follow the createDataChannel(..., DataChannelInit) pattern
>     by having addTrack(..., RtpSenderInit)?
>
>
>     I'm in favor of it because:
>     1.  We'd avoid with a mess of parameters in addTrack over time.
>     2.  It gives the app to specify initial RtpParameters (such as
>     VAD, potentially).
>     3.  It follows the same pattern we already have for
>     createDataChannel, which has been successful in adding many
>     options without making the parameter list a mess.
>     4.  It gives us more flexibility in our work around IDs and labels.
>

-- 
Randell Jesup -- rjesup a t mozilla d o t com
Please please please don't email randell-ietf@jesup.org!  Way too much spam