Re: Issue 80: filterParameters

I like preferredPayloadType being there like you put it.  And I think
preferredId on RtpHeaderExtension would be fine, too, the more I think
about it.

By the way, what's up with "hzRate"?  Isn't that kind of redundant?  It
sounds to me like calling it "rateRate" or maybe "poundsWeight".  Is there
a deeper meaning that I'm missing?


On Mon, May 19, 2014 at 2:15 PM, Bernard Aboba <Bernard.Aboba@microsoft.com>
wrote:

>  Peter said:
>
>
>
> “​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?
>
> ”
>
>
>
> [BA] Agree that with preferredPayloadType, RTCRtpCodec should have enough
> info to setup a single stream audio or video call by exchanging
> capabilities.
>
>
>
> Also agree that currently headerExtensions wouldn’t work because there are
> no IDs (would preferredID fix this? Do we care?).
>
>
>
> Am wondering how much we can do with features and rtcpFeedback as
> currently defined.
>
>
>
> For example, we should be able to figure out what feedback messages (e.g,
> PLI, FIR) are available for repair with the single-stream video.
>
>
>
>
>
>
>
> partial interface RTCRtpSender {
>
>     void send (optional RTCRtpParameters parameters, optional
> RTCRtpCapabilities remoteCapabilities);
>
> }
>
>
>
> partial interface RTCRtpReceiver {
>
>     void receive (optional RTCRtpParameters parameters, optional
> RTCRtpCapabilities remoteCapabilities);
>
> }
>
>
>
> dictionary RTCRtpCapabilities {
>
>     sequence<RTCRtpCodec> audioCodecs;
>
>     sequence<RTCRtpCodec> videoCodecs;
>
>     sequence<DOMString>   headerExtensions;
>
>     Capabilities          features;
>
>     Capabilities          rtcpFeedback;
>
> };
>
>
>
>
>
> dictionary RTCRtpCodec {
>
>     DOMString       name = "";
>
>     unsigned short? hzRate = null;
>
>     unsigned short  preferredPayloadType;
>
>     unsigned short? numChannels = 1;
>
>     Capabilities    formats;
>
> };
>
>