Re: Issue 106: RTCRtpParameter defaults?

Actually, here is another option I just thought of:  We used to have a
createParameters(RtpCapabilities) -> RtpParameters which we deemed to
difficult to get working correctly.  Well, what if we have a sort of
fillInTheBlanks(RtpParameters) -> RtpParameters.  Perhaps call it
finishParameters().  That way, the call flow could be:

var params = { ... /* stuff I know how to fill in, but no SSRCs */ ... }
params = RtpSender.finishParameters(params);
RtpSender.send(params);


At this point, the JS knows exactly what the parameters are, and it doesn't
have any timing/async complexity, but it doesn't have to fill in the SSRCs.
 In fact, we could expand this to allow lots of things to be left blanks,
like header extension IDs and payload types.  But mainly I think this is
about the SSRCs for now.


On Fri, Jul 18, 2014 at 1:43 PM, Peter Thatcher <pthatcher@google.com>
wrote:

> Forgive me for having lost track of this topic, but I thought we had
> decided that we would simply require JS to fill in all the values in the
> RtpParameters (in other words pick SSRCs) so that it wasn't necessary have
> the Promise in the first place.  Did that decision get undone, or was I
> simply misunderstanding?  To me, it still sounds like the best thing to do.
>
>
>
> On Mon, Jul 14, 2014 at 1:14 PM, Bernard Aboba <
> Bernard.Aboba@microsoft.com> wrote:
>
>> I am wondering if there isn't a relatively simple solution to this.
>>
>> a. Sender object.  On the sender, it seems possible to use Promises with
>> send, as follows:
>>
>>
>> partial interface RTCRtpSender : RTCStatsProvider {
>> Promise send (RTCRtpParameters parameters);
>> };
>>
>> We can then require that the sender object fill in the RTCRtpParameters
>> by the time the Promise is fulfilled.   getParameters can then be called to
>> retrieve the RTCRtpParameters object.
>>
>> Yes, it is possible that dictionary elements could change over time, but
>> I don't see why we need an event for that.
>>
>> For example, the SSRCs might change due to an SSRC conflict, but the
>> application shouldn't need to deal with this explicitly.
>>
>>
>> b. Receiver object.  Here, getParameters seems sufficient to me.
>>
>> There doesn't appear to be a good reason to have an event to tell the
>> developer when RTCRtpParameters changes. The only relevant info that could
>> be delivered is latching events and arrival of RTCP SDES packets (with
>> CNAME info), etc. but this does not seem critical.
>>
>
>