Re: Issue 80: filterParameters

​Now that we've removed ​filterParameters/createParameters, I think we need
to find another way to make the simple use case and simple example work.  I
really don't want our "simple example" to be dependent on a JS library, or
have to choosing ssrcs.   I'd like the simple examples to remain simple.

So what can we do?  Here is an idea:

1.  Allow passing in RtpCapabilities into RtpSender.send and
RtpReceiver.receive.  That way, the signalling could just exchange
capabilities and not have to create RtpParameters for the simple case.

2.  Send and receive with the preferredPayloadType.  The sender just picks
some SSRC, and the receiver automatically locks onto them, as if the JS had
listened to "onunsignalledrtp" and added SSRCs manually.


That doesn't support header extensions (since the receiver wouldn't know
the IDs) or layering or FEC, but that might be OK for the simple use case.


Are there dragons that I'm not thinking of that would make this not work?



On Fri, May 16, 2014 at 10:40 AM, Bernard Aboba <Bernard.Aboba@microsoft.com
> wrote:

> Based on the discussion at the 15 May ORTC CG meeting, should we:
>
> * Remove filterParameters/createParameters ?
> * Modify Examples 7 & 8 which call these functions?
> * Do something else?
>
> My suggestion would be to remove the filterParameters/createParameters
> functions, but keep them in Examples 7 & 8,
> noting that these functions are expected to be provided in Javascript
> libraries.
>